Hi, Thanks for the comment.
On Tue, Mar 15, 2016 at 02:34:43PM +0000, Ray Bellis wrote: > "But given the DNS message format, the name server cannot find the class > until it knows the name." > > I don't believe that this is relevant. I do think that putting the > class and type fields after the variable length name field in a question > or in an RR was an unfortunate choice. > > However I think it's a long stretch to get from there to assigning any > blame on the packet format for any failure of the class field to fulfill > its potential. Well, the point is that the class can't do the job it was supposed to (select one of many parallel delegation sets) because the names are prior to the classes. I didn't intend to blame anything, but to suggest that if names were supposed to be subsidiary to classes then being able to tell which class you were in before selecting the name would be handy. For example, suppose that instead of the IDNA kludge (I think even the authors will concede this description -- no disrespect to the effort intended), we had used a class to indicate additional conventions for name matching and so on. This would have been a big help, if only because case folding outside ASCII is sort of a pain in the neck. But you can't do any of that, because instead of classes actually differentiating name spaces, the whole tree is expected to be basically the same across classes. I suspect that the real goal was to make the DNS useful for non-Internet networking technologies, and the idea was that anyone using these various other technologies would likely have Internet presence as well. As a practical matter, though, the Internet technology basically swallowed everything else anyway. The one counter-example that's widely deployed we have is mDNS -- it basically uses a piece of the Internet technology that doesn't really work at Internet scale and effectively makes the network function differently. Yet a different class was not selected; instead, we got a new protocol with a wire format and operational conventions very similar to traditional DNS. I'll try to make all of this clearer in the next go-round. Thanks for the comment! A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
