Re: Weakness of DNS classes (was Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard)

[John C Klensin <[e-mail]>]

Andrew,

Thanks.  I have always assumed that class-independent aliases
were either an error or fuzzy thinking in RFC 1034/1035, but the
response format issue is significant.  Your explanation led me
to realize that while I can, in principle, specify records from
several CLASSes in the same (external format) zone file, or even
have a single owner in that zone file with records associated
with different classes, either would constitute a threading
nightmare for different root and delegation structures.   That
"same zone file" or "same owner" capability is, in retrospect,
completely consistent with class-independent aliases: with
appropriate restrictions, one could get one or the other to work
but not hoth.

The combination is, to me at least, at least as clearly
"mis-specified and cannot work" as, e.g., RFC 1034 inverse
queries.  

Good idea while it lasted.  The feature of separate trees (and,
btw, label types or equivalent) is probably a candidate for the
"DNSng" list.  Also, your explanation and parts of the above may
be candidates for any update to RFC 2181.

     john


--On Tuesday, July 21, 2015 16:39 +0200 Andrew Sullivan
<[e-mail]> wrote:

> Hi,
> 
> Warning to the ietf@ audience: this contains a bunch of stuff
> about the DNS.  If that makes your eyes glaze over, you might
> as well go to the next message.  It's probable that, if this
> generates more follow up, the thread should move to dnsop@ or
> dnsext@ (WG is closed, but the list is still alive) or
> something like that.
> 
> On Mon, Jul 20, 2015 at 01:15:11PM -0400, John C Klensin wrote:
>> 
>> I agree with your analysis, modulo one question.  You make the
>> comment that CLASSes don't really work, as have others.  I'd
>> like to understand it better.
> […]
>> actually be needed. I would not be surprised if you told me
>> that CLASS has been botched in some implementations and there
>> has been no incentive to fix it, that shouldn't surprise me
>> at all. However, if there were an important application, I
>> assume those implementations could be fixed.  So what do you
>> see as the issue?   Is it that we have needs to intermix
>> ordinary public names with "don't try to resolve this there"
>> stuff in the same environments?  I agree that would be a
>> problem for CLASS, but note some very strong analogies with
>> the IDNA kludge.
> 
> The first issue is exactly what you suggest: the class code is
> almost completely unexercised except to get responses to CHAOS
> queries, and that generally just for one purpose.  So we have
> an enormous installed base with likely bit-rot, even assuming
> the code ever did the right thing.  But that's not the problem.
> 
> It turns out that aliases are defined as class-independent.
> The CNAME algorithm (it works similarly in DNAME) is defined
> in RFC 1034, in section 3.6.2.  That algorithm says that you
> look for a CNAME record with a matching class, which sounds
> like you can have different RDATA at a name in one class vs
> another, which would mean that even though the CNAME RR is
> class independent there is no influence between classes.
> 
> Unfortunately, the discussion of the way the namespace is
> divided up says this:
> 
>     The class partition is simple.  The database for any class
> is     organized, delegated, and maintained separately from
> all other     classes.  Since, by convention, the name spaces
> are the same for     all classes, the separate classes can be
> thought of as an array of     parallel namespace trees.  Note
> that the data attached to nodes     will be different for
> these different parallel classes.
> 
> Now, if the databases are parallel for all classes, then
> presumably the RDATA of an aliasing record ought to maintain
> that parallelism. Since in principle the RDATA in different
> classes ought not to affect the other classes, this seems at
> least problematic.
> 
> Now perhaps we could just reject this "convention" (which
> would be the opposite of what we did with the preferred
> syntax, but of course that was widely used whereas classes
> perhaps are not).  At that point, we start to realise why
> people didn't use classes in the first place. For in a DNS
> packet, the class is in a really awkward place.  Even though
> the names might not be the same in all the classes, when you
> get an RR you get the name first, and only after that learn
> what the class is.  This means that you really have to parse
> the entire message before you realise, "Oh, look, this class
> says not to look this record up."  At bottom, the DNS message
> format is designed such as to make classes a pain in the neck
> to use.  I suspect that this fact is what is really
> encouraging the encoding of metadata about resolution inside
> the domain name itself: the name is the piece of data that is
> first and most easily accessible.  So, this is why I say that
> classes don't really work.
> 
> Best regards,
> 
> A