BIP-353's Missing Privacy Layer
- The promise
- The gap nobody ships
- The three layers that matter
- The composition that closes the gap
- Why this matters
The promise
BIP-353 lets you use a name like alice@example.com as a Lightning payment destination backed by DNS. You own the domain, the record, the address. No LNURL server, no custodian, no third-party routing your payment to your inbox.
The gap nobody ships
Every DNS resolver that answers your BIP-353 lookup knows three things: who is paying (your IP), who is being paid (the domain you queried), and when. If you route your Lightning payment over Tor but resolve the BIP-353 address through your system resolver, you have leaked the payment relationship to your ISP’s DNS before a single sat moved.
The three layers that matter
Layer 1: DNSSEC
DNSSEC validates that the TXT record comes from the legitimate zone owner and has not been tampered with in transit. Without it, an attacker who controls your resolver can substitute any pubkey they want. This layer protects record integrity.
Layer 2: Tor routing for DNS
DNS queries must leave through Tor, not through your local resolver. The catch: Tor’s DNSPort (port 5353) only resolves A, AAAA and PTR records. A BIP-353 TXT lookup sent to DNSPort silently fails. The correct path is TCP DNS through the SOCKS port:
torsocks dig +tcp +dnssec TXT alice.user._bitcoin-payment.example.com @9.9.9.9
Verify nothing left in the clear: tcpdump port 53 during the lookup should show no unencrypted DNS traffic.
Layer 3: Local DNSSEC validation
Trusting a remote resolver’s ad (authenticated data) bit moves the trust assumption from your ISP to that resolver. The cleaner path is local validation with torsocks delv +tcp or a local recursive resolver like unbound with full DNSSEC, so no remote party can lie about record validity.
The composition that closes the gap
BIP-353 lookup via torsocks into unbound running locally with full DNSSEC validation, no remote trust assumption at all.
This is achievable today with open-source tools. No wallet implements it automatically. The user has to wire it up by hand, or the lookup leaks.
Why this matters
The threat model for Lightning privacy is not just the payment path. It is the full payment lifecycle: address discovery, routing, settlement. BIP-353 without DNS privacy protects the destination but leaks the intention. BOLT12 without BIP-353 privacy protects the payment but leaks the lookup. Only the full stack closes the gap.
Write a comment