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

From: Andrew Sullivan <[email-masked]>
Date: Tue, 9 Feb 2016 13:59:18 -0500

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
[email-masked]

---

From: Avri Doria <[email-masked]>
Date: Thu, 11 Feb 2016 20:30:42 +0000

> hard-coded all over the place.

seems fundamentally broken.  Has seemed that way to me for a while now.
I know things like this can't be fixed, but ...

avri

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Edward Lewis <[email-masked]>
Date: Sat, 13 Feb 2016 01:06:57 +0000

>I know things like this can't be fixed, but ...

Pragmatically, there's nearly zero operational interest in making classes
useful.

I can't imagine a future in which a revival of the class feature will
benefit anyone.

These are weak reasons for saying - I wouldn't endorse spending too much
effort to fix or make more sense out of the DNS class concept.

Beyond that, I don't see that DNS classes have an impact on how Domain
Names would be further defined nor do I see DNS classes being something to
incorporate into a discussion of a name space.

I don't want to gut the concept from the protocol, because I don't think
the effort would be well spent, but I also don't see that I'd want to
preserve where it is in case there comes a time we could use it.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 14 Feb 2016 13:09:32 -0500

> effort to fix or make more sense out of the DNS class concept.

I have a not-quite-finished draft here that proposes closing the class
registry, however.

> preserve where it is in case there comes a time we could use it.

I claim you can't.  I should be able to submit this soon.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 14 Feb 2016 20:12:53 -0500

Hi,

> I have a not-quite-finished draft here that proposes closing the class

I decided that closing the registry would involve too much
windmill-tilting, so I didn't do it.

https://datatracker.ietf.org/doc/draft-sullivan-dns-class-useless/

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Feb 2016 21:56:22 +0000

>https://datatracker.ietf.org/doc/draft-sullivan-dns-class-useless/

"Heh-heh, he said vestigial, heh-heh" - in the voice of Beavis & Butthead.

I'm not sure how to work this in, but I'd like to make it clear that
CLASSES was an invention as part of the development of the DNS, the system
that is, and not something from Domain Names.

I'll underline and underscore (I'd do it in ASCII-art but...well..) that
I'm not sure how to work that in. Besides wanting to tell the future DNS
engineers to pave over it when they can, I'd like CLASS to not be a red
herring in any attempt to clarify (if you will) the Domain Name namespace.

I could be wrong - this is just my personal opinion, at this time, so take
the comment as just an opinion.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Feb 2016 17:28:44 -0500

> that is, and not something from Domain Names.

Hmm.  Good point.  Ok, if anything more happens with this I'll include
that.  Thanks!

A

-- 
Andrew Sullivan
[email-masked]

---

From: Avri Doria <[email-masked]>
Date: Sun, 21 Feb 2016 11:58:06 +0200

Hi,

> the comment as just an opinion.

I think something has to be done, because on first level of inspection,
it looks like a reasonable solution to problems of the policy variety -
such as overlapping use of names or establishing different schemes with
other authorities.  It is only once a person dives in that they discover
it is broken.

Personally I would have preferred a miracle fix to this but I understand
that isn't going to happen and probably isn't even possible given global
deployment.  Something I think a pity, but I think you have to put a
stake into it or it will remain a temptation.

I guess I think it is more than a red herring.

avri

---