[Inip-discuss] aliases and classes (was Re: Domain Names)

[Andrew Sullivan <[e-mail]>]

Hi,

On Sat, Jan 23, 2016 at 09:56:02AM -0500, Andrew Sullivan wrote:
> The class-insensitivity of CNAME and DNAME is another reason why
> classes don't really work: since they both redirect the name, that
> means that name aliasing in one class entails the same alias
> relationship in every other class, which means that for practical
> purposes the name spaces must be parallel at least around the point
> where any alias is introduced.  So the operation of different classes
> for the a given name can't be separated, and this makes classes at
> best of questionable utility.

I've been working through this harder, and I think I've concluded I
was wrong.  The class discussion in RFC 1034 is a mess, it's still a
lousy way to do this division, and I think it's underspecified; but
aliasing doesn't necessarily break classes.

RFC 1034, section 4.2, 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.  The most
    common reasons for creating a new class are the necessity for a
    new data format for existing types or a desire for a separately
    managed version of the existing name space.

Note the specification, "The database is … delegated … separately."
This is the key.

Suppose you have two classes, XY and YZ.  These are two acceptable
arrangements:

example.com. XY CNAME example.net.

example.com. YZ CNAME example.org.

The reason for this is that you get a different delegation from
com. to example.com. when you query with class==XY than you get with
class==YZ.  So when you ask the name server for example.com in class
XY for example.com, it already knows that it's in class XY and so it
will hand out the RDATA example.net.  No problem, right?

Of course, there is a problem.  The handling of the query the name
server gets is specified in RFC 1034 section 4.3.2.  Nowhere in that
algorithm, as far as I can tell, is the class considered.  I guess the
idea is that you already know which class you're in because of the
delegation.

Yet while section 4.2 says that the class delegations are separate,
there is of course no way to ensure that the NS record RDATA for
example.com, class==XY, and the NS record RDATA for example.com,
class==YZ, is always different.  This means that the name server could
be the same, and the nameserver for example.com therefore needs to be
able to break out the class from the name before it starts following
the algorithm in section 4.3.2.  And of course, it can't break out the
class until it has matched the name, because the name gets matched
before the class because of the way the RRs are arranged.  I guess the
answer is that a multi-class-serving name server needs to look at the
QCLASS in the query it gets, and then select the class in question,
before it starts trying to match name by name.

But of course, once you put it that way, it's obvious that for classes
to be really useful they need to be at the beginning of the RR.  So
it leads us again to the conclusion that classes are not actually
useful, which doubtless explains why we've ended up with the IN class
hard-coded all over the place.

A

-- 
Andrew Sullivan
[e-mail]