Two message replies in one: On Sun, Jul 05, 2015 at 05:16:05PM +0000, Evan Hunt wrote:
> 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. You're quite right that nobody is really exercising classes anyway, but if you read RFC 1034 the story doesn't get a lot better. One could argue that CNAME and DNAME do not alias namespaces across class boundaries because when you do the DNAME and CNAME substitutions, you do it "matching down, label by label, in the zone." That would seem to help, except that if you look up what a zone is RFC 1034 (section 4.2) says this: The class partition is simple. The database for any class is organized, delegated, and maintained separately from all other classes. Since, by convention, the name spaces are the same for all classes, the separate classes can be thought of as an array of parallel namespace trees. Note that the data attached to nodes will be different for these different parallel classes. Since the RDATA for a CNAME or DNAME is another point in the tree, the above convention would suggest in fact that you _can't_ point to a different alias (or else, we'd get a very unusual meaning of the terms "parallel" and "same"). > 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. Especially if you're also supposed to honour some convention about parallel namespaces. > 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. If all we want is a convention for instructing the local resolver, repurposing classes seems like a lot of work. After all, apparently Bonjour and Tor -- and for that matter, DKIM -- are able to figure this out by grovelling through magic labels in the owner name. It's filthy, but the code all shiped ages ago. On Sun, Jul 05, 2015 at 10:38:18PM +0100, Ray Bellis wrote: > I agree. I very strongly suspect that the omission of explicit QCLASS > matching in DNAME is a simple omission that none of us caught at the > time rather than a deliberate attempt to make DNAME class independent. I recall quite clearly raising the issue at the time (though maybe not on dnsext -- perhaps only in private conversation. That'll teach me), because I had the distinct, um, pleasure of simultaneously trying to explain DNAME to people who thought it would magically solve all their variant issues, and trying to understand a certain M. Morfin's plan to bootstrap his Intersem using new classes. I would have liked it if the answer to everyone I could think of was, "Please do what you like with your namespace," but it didn't seem to work that way. So this was not at least an oversight in my case. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop