You have to be careful with WHOIS privacy for your domain otherwise you doxx your Lightning Wallet and with your idea your Nostr account 

 logical 

 But it's the same with NIP5 or lnurl, right? 

 Yes which is also a problem 

 Ok, but with BIP353, at least you don't need to rent a server, so you decrease your attack vector significantly.  

 Agreed 

 The one good thing GDPR did was make almost all domain whois private by law. 

 So, what's missing? 
A NIP referring to the BIP, and specifying the Nostr specific nuancses?  

 It has been indeed several times suggested as a modification of NIP-05, and... rejected several times too. 

 For example:

nostr:nevent1qqs9wlyjhf64edcxg8t364dfzgq4vt0m54z48lwc8k75jev7e2qu9tqpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg95fvqe8pylvpv87zshenxn4h3xv698udhtg5avkx55umqlgk627vpsgqqqqqqs85vxq8 

 Indeed, your domain registrar can always rug you by pointing a record to their own server and issuing a fresh https certificate.

Meanwhile DNSSEC is easier to verify, @matt wrote some Rust code for it, unlike https which only browsers can.

Privacy downside in is having to fetch the TXT record with the proof somehow, e.g. with DNS-over-HTTP. But you could have relays share the records. 

 I'm not sure there's any downside with the DNS option, as you have to do anyway a DNS resolution also in the HTTPS option. 

 Assuming it's a shared domain, then by querying for the sjors@ TXT record I'm revealing that (to e.g. Google if doing dns over http).

Whereas with https I'm only revealing the domain at the dns level. But then the server knows exactly what I asked for. 

 Yes, that's true for a shared domain, yes.
The TXT record points out directly to the final user. True.

On the other hand, DNS architecture allows the user to hide behind a DNS recursive server (from the ISP, institution, DoH providers, etc), whereas it's easier to leak your final IP to the HTTPS server (if you don't user a webproxy).

Different privacy compromises, I guess. 

 You could but why should you if there's no need? Unless there's a compelling reason why it's worth it to require extra steps.
You could also potentially do NIP05 over SMTP by sending emails back and forth. Many DNS providers also provide email, so why not? 

 A big reason is that the two ways are almost the same, so it makes sense to choose one instead of supporting both.

The HTTP approach has two advantages over the DNS approach:
1. it's easier to add other metadata to the pubkeys, like we do today in some cases;
2. it's 10000x easier to support dynamic name resolution, for providers that have multiple users, each with its own name and pubkey.

The first NIP-05 draft used DNS records, but then I realized that it was inferior. 

 People who have domain names are generally capable of hosting websites. It's not a big burden.

If you already have a website, adding a static file or a simple 3-line handler for /.well-known/nostr.json routes is super easy too (unlike with the Lightning Address LNURL scheme which required an active process capable of generating invoices). 

 using nostr webserver+relay  but with regular DNS pointing . so how can nostr naming be an advantage? without using DNS of any sort or via onion 

 What do you mean? It's just a way to point a human-readable name to a pubkey. 

 This seem reasonable, thanks.