In message <20160316012227.go89...@mx2.yitter.info>, Andrew Sullivan writes: > 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.
No. The order in RRset is irrelevent. It is the <qname,qtype,qclass> tuple that is used to select answers. The <qname,qclass> tuple is used to select the zone (which is defined to be single class). > 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. No, the problem was that rules for name matching are independent of the class. This is not the same as names come first. Now it would be possible to define that class X names are UTF-8 strings with 'a' - 'z' being case folded when matching. We could even do that for class IN. One could easily have XXX (code point 1000) and YYY (code point 1000) where both XXX and YYY are class specific and the two classes are different. If we want to achieve this then we need to be stricter on allocating class independent RR types or else there will be no codepoints to share across classes. We still have room for ~4 billion record types. Only a couple of 100000 <qtype,qclass> are currently specified. NXDOMAIN means the name is not in that qclass (qclass != *). > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
