On Mon, Jul 08, 2013 at 06:49:53PM +0000, Dickson, Brian wrote: > > Thoughts?
My immediate thought is, "What problem is this trying to solve?" In the DNSSSEC case, the problem is that you're trying not to break the chain of trust, and you need a mechanism that is cryptographically securable to make the communication. This is made harder in some sense by the fact that the DS and DNSKEY RRsets are authoritative on different sides of the zone cut. In the NS case, because the child side RRset is the really authoritative one, that's the one that generally gets cached. Since both sides of the cut have the same RRTYPE, and since only one of the RRsets can be cached, you end up with only one such set and it's the one that gets used. It's it possible to bollocks this so that resolution fails? Yes. But that's not a result of disagreement between two different RRsets, so in this case having the additional communication path (especially inside the DNS) is less necessary. Best, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
