ietf
[Top] [All Lists]

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)

2015-07-21 12:25:16
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
<ajs(_at_)anvilwalrusden(_dot_)com> 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





<Prev in Thread] Current Thread [Next in Thread>