Subject: [dnsext] Name equivalence: why some protocol change is needed

From: Brian Dickson <[email-masked]>
Date: Fri, 10 Sep 2010 01:23:23 -0300

(The following presumes DNSSEC signing as part of the problem space.)

Here's the problem in a nutshell: scaling.

Or rather, here's the conundrum: DNAME or exceptions, pick one.

First, a definition:

Given two domains which are meant to be "the same", including subdomains
etc., an "exception" is a single member of each domain, whose relative name
is the same, but whose RDATA differs.

E.g., if example.com and example.net are meant to be "the same", then every
member "foo.bar" of example.com has the same RDATA (in all classes and RR
types) as "foo.bar" in example.net,
EXCEPT for "exception.example.com" and "exception.example.net", which have
(some) different RRsets, for some class and type.

(Here, we presume non-DNSSEC-specific RR types, of course).

So, excluding the "exception", the two domains are "the same".
And, the "exception" has the same name (relative to the parent domain), and
differs only by value.

There are several conceivable reasons for the general registrant wanting, or
more likely, needing, one or more "exceptions".

HTTPS is one example which has been given, albeit with some potential
work-arounds. There are likely others as well.

It is not necessarily the case that those work-arounds will work for every
registrant, so the general case *must* support "exceptions".

However, use of DNAME as a mechanism for making two domains "the same", by
making the zones at the top of the domain "the same", necessarily means all
descendant zones will also be "the same".
This is because follows delegations with the rewritten QNAME, not the
original QNAME (prior to DNAME target substitution).
(This eliminates zone cuts as a means of differentiating domain members.)

It is also, unfortunately, extremely likely that for any registrant with a
set of domains which need to be "the same", that *every* domain will have
the same exception.

This removes the usability of DNAME in any solution which requires support
for "exceptions". (I.e. specific registrants, case-by-case, and any parents
of any such registrants, i.e. TLDs)

And thus, the real problem is compounded by the place in the hierarchy that
the exception occurs.

If it happens in the registrant's normal second-level domain, it's already
pretty bad. If it is below that, at third or more, with "sameness" at each
level, it can potentially be catastrophic.

Provisioning tools may be useful in some circumstances, but they clearly
cannot scale to TLD levels with widescale use.

So, the conclusions are:
- something else needs to be added to the solution set
- DNAME is still useful, but only below the TLD level
- The above presumes no changes to DNAME rules - while it is quite likely to
be disregarded eventually, consideration should be given to re-examining
them and considering whether the pain is worth it
- The problem is in some sense introduced by DNSSEC, so we could also
consider subtle changes (i.e. additions) to the DNSSEC validation logic, as
that may involve fewer moving parts, and has no impact to non-DNSSEC use
cases
- The zone cut is a useful tool for achieving "exceptions", however, that is
only feasible if the parent->child difference is preserved across "the same"
zones. Having all parents point to "the same" child is moot...
- It's not a strictly "either/or" situation, more of a "what is the smallest
number of changes or additions, with least impact" situation (IMHO)

Brian