Re: [DNSOP] why classes are useless, was New Version Notification for draft-sullivan-dns-class-useless-01.txt

[Michael StJohns <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop