Subject: Multiple methods for aliasing (Was Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work)

From: Brian Dickson <[email-masked]>
Date: Wed, 28 Apr 2010 12:49:36 -0300

There are some issues that I think might be being overlooked a bit, in
that we're mixing discussions of specific proposals, and
requirements...
(More below...)

> Given the three types of redirection that I previously outlined, which
> of them (and to what extent) do you think the BNAME proposal solves?
> To remind, I offered these three candidates (see
> http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00890.html).

One thing to consider is, that at each label in the FQDN of a name
being resolved, it is possible
that *different* kinds of aliasing could be implemented.

The reasons for using different alias methods might in fact be derived
from the characteristics of each method.

And, as such, we should be careful to consider the benefits of
supporting more than one such method, in our analysis,
recommendations, IDs, etc., especially as concerns what new WG work to
consider.

Here's a not-necessarily complete list of method-types and
implications to deployed code and/or DNS zones:

(a) client-side (resolver-side) alias methods.
These are things similar to CNAME, DNAME, and BNAME (as proposed).
They require the resolver to do additional work, and to understand new types.
The main characteristic is, they are effectively "restrictive", and
occur on the parent side of aliasing only.
Some changes are needed to both recursive resolvers, and validating
resolvers for DNSSEC, in addition to having authoritative servers
serve up the new type.
They are "transparent" to the child side of the alias target, in that
the child does not need to know about the alias(es), and that the
child basically can't prevent the alias from happening.

(b) server-side (authority-side) alias methods.
These are things which involve changes to meta-data and authority servers only.
They do not require the resolver to do anything new, and are
effectively backward-compatible completely, except as concerns DNSSEC.
For DNSSEC, there may or may not be additional work in changing
validation logic, in order to make the combinatorial issues for
signatures go away.
In the absence of changes to DNSSEC validation, however, the
implementation via having DNSSEC signatures on all combinations of
aliases, would make these methods *completely* backward compatible.
The main characteristic is, they are effectively "permissive", and
occur on the child side of aliasing only. The parent side of aliases
simply use delegations (NS with optional DS) to the alias-implementing
server(s).
They are "transparent" to the parent side of the alias target, in that
the parent does not need to know about the alias(es), and the parent
can't enforce aliasing.

My observations on these methods are the following:
Server-side methods can be implemented *now*, without protocol
changes. These would provide an evolutionary path to achieving
scalable, widely deployed aliasing.
Additional server-side incremental changes to DNSSEC validation have
an easier deployment path, with fewer protocol changes, and a shorter
"tail" (since they only require changes to existing validating
resolvers deployed).
Sever-side methods are likely to be popular at the SLD level and
below, simply because there is less work involved (on making changes
upstream) and more backward compatibility.
Client-side methods are likely to be popular, or even mandated
eventually, at the root and TLD levels, specifically because of the
"restrictive" characteristic. Enforceability and least-surprise goals
inform this conclusion.
Thus, even though the tail is longer, there is more intrinsic impetus
to deploy client-side changes (i.e. upgrading resolvers).
Server-side -> client-side as an evolutionary path makes *both*
attractive as WG items, especially given possible deployment long-tail
issues.
And finally, I believe these are mix-and-match, with no topological
restrictions per se. I don't see anything that would make client-side
beneath server-side impossible, or vice versa.

Brian

P.S. server-side would look something like this, to give a concrete example:

On authority server ns.example.com:
foo.example.com NS ns.foobar.example.com (and glue)
bar.example.com NS ns.foobar.example.com (and glue)

On authority server ns.foobar.example.com:
foo.example.com SOA ....
(link internally to zone data for foo.example.com)

bar.example.com SOA ...
(link internally to zone data for ===> foo.example.com <===)

Additional meta-data is needed controlling things like "notify",
"secondary", reload-signaling, etc.:
A linked zone which is primary, would need to notify any secondaries
of any aliases.
A linked zone which is secondary, would need to track only one primary
alias, and reload all aliases when a zone transfer happens, and also
notify further secondaries (tertiaries).
Signing of zone data would need to know about all aliases which
require signatures.
It is theoretically possible that aliases are topologically sparse on
the master->[alias->]secondary->alias [...] tree, with some aliases
not being present on the master, but which still require signatures.

Again, the server-side method has the two important characteristics:
fully backward compatible, and hard-linked (within any given server
and associated with a specific SOA SN) aliasing of zone data (name ->
rdata).

Brian