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
--
Andrew Sullivan
ajs@xxxxxxxxxxxxxxxxxx