On Mon, Jul 06, 2015 at 06:48:18AM +0000, Evan Hunt wrote: > > The remark prefaced with "by convention" doesn't strike me as particularly > definitive.
I suppose I'd feel better about that if LDH weren't enshrined at least in operational policies all over the Internet. But I suppose you're right: we could issue a document formally deprecating the convention and then explicitly noting that since aliases are defined in terms of zones, therefore alias processing is not permitted to cross class boundaries and can result in non-parallel name spaces. In principle classes would be useful again (though you're still right to note that the code is almost completely unexercised. I have been led to believe that Jefsey Morfin and his friends intend to run/are running an experiment using classes, so perhaps we're in for some excitement). > Point taken, but the problem we're facing is magic special-purpose labels > potentially being repurposed in the global DNS and thus becoming ambiguous. > Allocating class ONION, class MDNS, etc, for things like this may actually > turn out to be less trouble in the long run than ensuring that ICANN never > sells anybody a TLD called .onion. ICANN does have a policy that entries in 6761 are automatically out of bounds, and I can't imagine the parallel universe where they decided that was a bad rule. So I'm not super worried about a collision. You have an interesting point anyway, however, which is I guess what Bill was saying in the first place. If an application actually wanted to protect itself from DNS processing the answer would not be to use a magic string (which could well leak to the IN-class DNS) but instead to call for resolution using a different class. I wonder how many libraries allow you to specify this. I observe that at least the getdns API has it available. Maybe it really is time for another class. I seem to recall that John Klensin suggested a separate class to handle IDNs many years ago. I'll see whether I can find any of the relevant discussion as to why that road was not followed. A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
