[dnsext] Some thoughts on the updated aliasing draft

[Ted Hardie <[e-mail]>]

The draft under discussion  was updated just before the meeting, and it has
some useful updates.  I think, however, it is anxious to scope the problem
in ways that leave out what I believe is a well-recognized aspect of the
basic desire of those who brought the work forward.  The draft says:


  To some extent, the desired behavior can be described: "identical DNS
  resolution" means that the process of resolving two domain names will
  end with the same result, in most cases the same IP address.  In the
  history of DNS protocol development, there have been two attempts to
  specify such "identical resolution" behavior:CNAME[RFC1034] which
  maps or redirects itself, and DNAME[RFC2672] which maps or redirects
  its descendants.  In the case of bundles or groups of names, however,
  some operators have asserted they need identical DNS resolution at
  all levels' domain names, including the domain name itself and its
  descendants.

But the reality is that the operators actually want the applications to
treat two domain names as the same.  That's a lot harder than simply having
the same IP returned when looking up an A record at each one.  Especially in
the case of secured zones, it involves issuing multiple certificates or
certs that cover both, and otherwise ensuring that whatever services are
present at that IP can effectively handle either name.  It's moderately
obvious that this is a tougher job than putting in a CNAME or DNAME.

It is possible to store additional data in the DNS that asserts X=Y for some
values of X, Y, and equals, and we could, theoretically, mint records that
had appropriately scoped forward knowledge about other equivalent domains.
Where apparent administrative domains are crossed, it may take additional
work to check that all parties concur.  It gets ugly fast, but it may be
better than the alternate of brute-force registration.

The real trouble, though, is getting applications to check for the existence
of such records.  The DNS is a known-item lookup protocol, and it basically
has to return the information that corresponds to the question that was
asked.  It can return additional data, but if it does so, there is a fairly
serious risk that only the answer to the question asked will be stored and
forwarded to the consuming application.

The only way around that that I can see at the moment is to either declare
one record to be canonical (forcing applications to "correct" any names they
are currently using to the canonical name) or use an additional layer of
indirection so that all of the records that are the same point to some
meta-target.  That might work--it's the same basic use of pointers that's
already present in CNAME, but it requires a pointer from all the "same"
domain names to some target that's not in the set.  The structure of that
record might be the same as the normal targets, using something like prefix
addressing to signal its use; it might also have a different structure.

But the problem remains daunting.  Even if DNSEXT creates the perfect record
for sameness, we still have to get apps to check it--and that suggests to me
designing the system for that goal should be a primary consideration in the
design space.