Warren Kumari wrote: > I'd also like to point out another option -- I threw up a little when first > suggesting it, but it may be worth considering again (and please feel free > to point me at the list if it already was). > An opportunistic solution is vulnerable to intentional (or accidental) > blocking, causing a fallback to unencrypted -- blocking of port 853, stupid > middleboxes, etc. You also cannot try just do both 53 and 853 in parallel, > because, well, that would just be stupid.
Why is trying 53 and 853 in parallel stupid? You can cache whether the port 853 attempt succeeded or not for a long time, perhaps even in non-volatile storage, and this will end up suppressing a huge amount of future unsuccessful connection attempts. Even with a few million authoritative nameserver IP addresses the amount of storage required is pretty low. > When resolving www.example.com, the com servers have already provided you > with: > dig +nocomment ns example.com > > example.com. 86383 IN NS a.iana-servers.net. > example.com. 86383 IN NS b.iana-servers.net. > a.iana-servers.net. 172783 IN A 199.43.135.53 > b.iana-servers.net. 172783 IN A 199.43.133.53 > a.iana-servers.net. 172783 IN AAAA 2001:500:8f::53 > b.iana-servers.net. 172783 IN AAAA 2001:500:8d::53 > > The NS records here are signed and dnssec verifiable (the glue isn't, but > that is a separate fight). No? The delegation NS records served by the com servers are not authoritative and are not signed. The only signed material you get from that transaction is the RRSIG covering the DS RRset, right? You would still need to contact the example.com servers with a separate NS query to DNSSEC-validate any signals encoded in NSDNAMEs. -- Robert Edmonds _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
