On 3/18/2016 5:53 PM, John Levine wrote:
what's stopping a second $class from working is STD 13, half of which
says that zones and rrsets span classes, and half of which says that
each class has its own zone cut hierarchy. we would have to decide, and
revise.
If we spent a year arguing about what STD 13 should really have said
about classes, there's two places we could end up:
1) There's one name tree, and classes provide variant meanings
of some RRTYPEs.
b) Every class has a separate name tree.
In the first case, classes buy you nothing. If you want RRTYPEs that
mean something different from existing ones, define some new ones.
It's not like we're in any danger of running out of RRTYPE code
points. (We can argue about how hard it really is to implement new
RRTYPEs, but I doubt the answer would change much with or without
classes.)
Disclaimer: I am NOT arguing to retain classes - especially as CLASSes.
For your case (1) above, I occasionally thought about trying to write an
ID which redefined classes as a way of expanding the search terms for
DNS to allow differentiation for example between "internal" and
"external" address records attached to a name. Or "preferred" and
"non-preferred" or "virtual" and "non-virtual" addresses. It mostly
didn't go anywhere.
DNS only has name/type/class in the query tuple. I've sometimes wished
for the ability to say "I only want a few of the records at this name
with this type and here's how you figure out which ones" - especially to
keep the responses within the UDP sizes. The class field might have
been a useful way to do that, especially for things related to keys and
signatures.
Mike
In the latter case, classes still buy you nothing. Set up some root
servers for your new name tree and you're done. I suppose one might
argue that gives an unfair advantage to the IN class and we should
instead have the existing roots serve different answers to queries for
different classes, but good luck with that.
Deprecate this vermiform appendix and be done with it.
R's,
John
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
