On 6/18/23 12:53 AM, Masataka Ohta wrote:
Matt Corallo wrote:
That's great in theory, and folks should be using DNSSEC [1],
Wrong.
Both in theory and practice, DNSSEC is not secure end to end
Indeed, but (a) there's active work in the IETF to change that (DNSSEC stapling to TLS certs) and (b) that wasn't the point - the above post said "It’s not like you can really trust your packets going to B _today_ are going to and from the real B (or Bs)." which is exactly what DNSSEC protects against! It may not protect the client, but it protects the recursive resolver, which is often on the same AS as the client (or if its not, its usually connected via DoH/DoT, which is itself a secure channel).
and is not very useful.
If its not useful, please describe a mechanism by which an average recursive resolver can be protected against someone hijacking C root on Hurricane Electric (which doesn't otherwise have the announcement at all, last I heard) and responding with bogus data? Or, alternatively, describe a mechanism which allows a recursive resolver to not return bogus data in the case of *any* authoritative server BGP hijack.
For example, root key rollover is as easy/difficult as updating IP addresses for b.root-servers.net.
Then maybe read the rest of this thread, cause lots of folks pointed out issues with *just* updating the IP and not bothering to give it some time to settle :) Matt