The BIP doesn’t specify that, but that’s supported for the LN usecase! Because the various parts of the overall flow are relevant to different groups the total spec is somewhat confusingly split across three places, but most of the lightning-specific stuff is at Define blip-0032, DNSSEC proof querying over onion messages by TheBlueMatt · Pull Request #32 · lightning/blips · GitHub and indeed includes a flow like that (but we make the payer only do a single DNS lookup by requiring such deployments use a wildcard to return the “ask node X for the offer” result).
That doesn’t result in the privacy advantage that you note, but I also wanted to keep this generic for all of Bitcoin (including on-chain, fedimint, cashu, silent payments, whatever) so kind of want to avoid explicitly baking in a lightning onion message dependency. Of course that means its annoying to add on-chain addresses for large custodians, but maybe after lightning they can invest in figuring out how to run bind and create a zonefile…turns out even with a million or ten records it works just fine 
The current bLIP spec there may change in that currently it adds two round trips (one to ask for a standard offer, then one to turn that offer into an invoice_request), but I may want to change that to an offer where you include the user/domain in the invoice_request. Needs some discussion with lightning folks to figure that out I think.