Subject: [dnsext] Aliasing Discussion

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Jul 2010 10:45:12 -0400

It seems to me that we have a big issue here with distinguishing
'requirements' and 'problems'. Specifically the term problem is being
used to refer to both requirements and constraints. And that makes for
confusion.

The issue is being discussed in terms of problems created by the
introduction of IDNs. And this is unsatisfactory as it is not clear
whether the problems are technical issues or requirements that are not
being met or whatever. And this in turn makes it difficult to know
what specific objective the proposals are intended to meet.

At its simplest the 'cause' here is that it is very commonly the case
that domain name owners have multiple domains and wish to provision
identical trees for the two domains. For example AliceCorp.com merges
with BobCorp.com to form AliceAndBob.com. AliceCorp.com is also
registered as AliceCorp.cn and in various international variations.

The consequences of this issue are:

1) Administrative difficulties
     AliceCorp has multiple trees to test and verify. One could
imagine instances where the number of domains is very large (10, 20 or
more) and possibly even end up with nested zones leading to a
combinatorial issue.

2) SSL issues
     A certificate bound to one site address may not function for all,
an issue compounded with the oversight in the SSL protocol that means
the server does not know which domain the client is attempting to
reach until after the negotiation is complete and consequently IP
addresses are used for domain name negotiation.

3) Cache issues
     If the number of names is very large there may be caches
containing very large numbers of responses that are essentially the
same.

4) DNSSEC issues
     Signing each domain independently will increase the cost of
running DNSSEC, number of signatures to generate etc.

Now we can imagine requirements coming out of these consequences
designed to mitigate them, but will they be of utility? We need to
consider the constraints:

1) Names must resolve reliably to be of use
    An aliasing scheme is not going to help matters if it means that
the resolvability of names depends on where you are. It will cause
things to break. For example Francoise writes a web page including
URLs that point to the French version of ecran.fr with the accents in.
It works perfectly for her as the local DNS resolver supports the
alias scheme. But none of her readers can read her pages as their
resolvers do not support it.

2) Legacy infrastructure may persist for a long time
    An administrative convenience that does not sork with legacy
infrastructure is going to be a nightmare, not a convenience.

I could support an alias scheme that was narrowly tailored to address
the efficiency issues that are raised by having multiple trees. But it
is clear to me that many of the 'problems' being raised are in fact
constraints that frustrate the requirements.

There are two basic approaches that can be taken

1) Aliasing aware provisioning

2) Expansion of aliases to support non-compliant services

3) Alias records in the DNS

Note that any implementation of (2) will provide a means of achieving (1).

Since legacy infrastructure does not support alias records, any
solution that only supports (3) is not going to meet the constraints.

I conclude that there are two viable options 1 on its own or 2+3 which
provides the effect of 1.

So looking at the set of issues I conclude that if the requirement is
to mitigate the administrative difficulties we cannot escape the
provisioning/expansion approach.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Jul 2010 11:03:17 -0400

Another way to look at this issue is that an alias zone tree is simply
a variation of a wildcard and so we should look for technical
implementations that are equivalent.

This would lead to designs in which the alias records are mainly
administrative aids expanded out by the authoritative name servers and
the only times they will appear on the wire are during zone transfers
and in the context of DNSSEC.