On Sun, Jul 05, 2015 at 10:44:40AM -0400, Andrew Sullivan wrote: > Imagine the alternative-resolution class FAKE. In the IN class, > example.com has a DNAME entry pointing to example.net. What should > happen when someone performs a query for QNAME localentry.example.com, > TYPE AAAA, and CLASS FAKE?
What *should* happen, IMHO, is the DNAME shouldn't come into consideration because it only exists in class IN. localentry.example.com/FAKE/AAAA is in a different namespace entirely, and a query for it should never reach the example.com/IN zone. What *does* happen is unclear; maybe nothing. To the best of my knowledge, nobody currently uses non-IN namespaces except for strictly local authoritative data such as version.bind/CHAOS/TXT. I'm not sure whether it's even theoretically possible to do more than that today; in any case it hasn't gotten much attention from implementors or operators, so if the code exists, it's not being exercised. Non-IN delegation and recursion probably aren't adequately specified, certainly aren't adequately tested, and if my interpretation above is correct, they'd imply a need for a ./FAKE root zone alongside the ./IN one, which opens up multiple cans of distressingly wiggly worms. However, I can imagine a mechanism in which a query for some.tld/FAKE instructs the local resolver to use an alternate resolution mechanism for some.tld, with the DNS protocol being used only for that first hop. This might be suitable for things like .onion. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop