Re: [DNSOP] Some distinctions and a request - Have some class?

[Andrew Sullivan <[e-mail]>]

Two message replies in one:

On Sun, Jul 05, 2015 at 05:16:05PM +0000, Evan Hunt wrote:

> What *does* happen is unclear; maybe nothing.  To the best of my
> knowledge, nobody currently uses non-IN namespaces except for strictly
> local authoritative data such as version.bind/CHAOS/TXT.  I'm not sure
> whether it's even theoretically possible to do more than that today; in any
> case it hasn't gotten much attention from implementors or operators, so if
> the code exists, it's not being exercised.

You're quite right that nobody is really exercising classes anyway,
but if you read RFC 1034 the story doesn't get a lot better.

One could argue that CNAME and DNAME do not alias namespaces across
class boundaries because when you do the DNAME and CNAME
substitutions, you do it "matching down, label by label, in the zone."
That would seem to help, except that if you look up what a zone is
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.

Since the RDATA for a CNAME or DNAME is another point in the tree, the
above convention would suggest in fact that you _can't_ point to a
different alias (or else, we'd get a very unusual meaning of the terms
"parallel" and "same").

> Non-IN delegation and recursion
> probably aren't adequately specified, certainly aren't adequately tested,
> and if my interpretation above is correct, they'd imply a need for a
> ./FAKE root zone alongside the ./IN one, which opens up multiple cans of
> distressingly wiggly worms.

Especially if you're also supposed to honour some convention about
parallel namespaces.

> However, I can imagine a mechanism in which a query for some.tld/FAKE
> instructs the local resolver to use an alternate resolution mechanism for 
> some.tld, with the DNS protocol being used only for that first hop.
> This might be suitable for things like .onion.

If all we want is a convention for instructing the local resolver,
repurposing classes seems like a lot of work.  After all, apparently
Bonjour and Tor -- and for that matter, DKIM -- are able to figure
this out by grovelling through magic labels in the owner name.  It's
filthy, but the code all shiped ages ago.

On Sun, Jul 05, 2015 at 10:38:18PM +0100, Ray Bellis wrote:
 
> I agree.  I very strongly suspect that the omission of explicit QCLASS
> matching in DNAME is a simple omission that none of us caught at the
> time rather than a deliberate attempt to make DNAME class independent.

I recall quite clearly raising the issue at the time (though maybe not
on dnsext -- perhaps only in private conversation.  That'll teach me),
because I had the distinct, um, pleasure of simultaneously trying to
explain DNAME to people who thought it would magically solve all their
variant issues, and trying to understand a certain M. Morfin's plan to
bootstrap his Intersem using new classes.  I would have liked it if
the answer to everyone I could think of was, "Please do what you like
with your namespace," but it didn't seem to work that way.  So this
was not at least an oversight in my case.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]