> But since unless you manually or do some other finagling can't easily > establish trust if you don't have trust above, root-servers.net should only > sign after .net is signed at this point in the rollout.
The dependency on .net for the root name servers seems strange to me. Intuitively, I should not have to trust .net to get a validated set of root name servers. The names of the root name servers are somewhat arbitrary, and since they are very integral to the root zone, it would seem more straight-forward to not put them into a public registry TLD, but rather to use a special TLD ( e.g. "root-servers" or possibly a sub-domain of ARPA ). I don't see any reason to use a sub-zone, the records may as well go in the root I think ( allows a secure resolver to start up slightly faster ). > And any PROPER useage of DNSSEC won't rely on root-servers.net ever being > signed at all, because its only on the name path for resolvers. I think a proper use of DNSSEC is to use it to get a validated set of root server IP addresses. This doesn't cure all the security ills of the world, but does constitute a small improvement in security, especially for TLDs that have not yet been signed. If TLDs also do not sign their name server domains, then a single blind spoof packet allows an attacker to intercept all the traffic for a resolver. Even the root server traffic is somewhat sensitive - it can often be what some end-user has just typed, which could well be confidential, such as a password ( e.g. they think they are entering a password, but are actually typing into an address bar ). Sure, it doesn't allow an attacker to forge signatures - but that's not the be-all and end-all of security. I note that .se does sign it's name servers. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
