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@xxxxxxxxxxxxxxxxxx> 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