Examining DNAMEs -- the Verisign white paper and the comments in the Klensin paper

[John C Klensin <klensin@xxxxxxx>]

Several people have asked me in private email about whether the
Verisign white paper proposing the use of DNAME records and my
remark that they should be examined are consistent.  The
question should probably be answered in this forum.  

Verisign's paper contains an excellent review of DNS and IDN
technology.  I assumed that those participating in an IDN TLD
discussion would have most of that background or that they
would obtain it from the "Signposts in Cyberspace" book cited
in my footnote (1).  I still recommend that book to those,
especially those with a policy rather than technical
background, who are not deeply familiar with the actual
structure and protocols of the DNS and IDNs, but there are no
obvious inconsistencies between that explanation and the
Verisign one.

Nonetheless, my recommendation, in my "Simple Aliases"
subsection, is to look carefully at the DNAME possibility,
while I interpret the Verisign paper as urging moving ahead
now.  Perhaps that is just a difference in writing style.  But,
if I am more hesitant, it is due to a series of issues.  They
are:

(1) It remains unclear what specific problem those who are
anxious to have top-level IDNs are trying to solve (see the
last section of my paper for additional discussion on this
topic).  I suspect that different people and different groups
have different objectives.  This has, of course, always been
the case.  In particular, of all of the possible approaches
that I'm aware of, the DNAME one is probably the least
satisfactory to anyone whose primary objective is to wrest
control of the DNS root away from ICANN or the US Government.


(2) While I agree with the Verisign paper that DNAME should be
examined carefully for the class of problems it would solve, I
do not believe we have significant large-scale operational
experience with it except as a short-lived transition mechanism.
We probably do not have a huge amount of experience even for
that purpose.  DNAME is not even supported on all of the root
servers today, as I think the Verisign paper mentions, and it is
not supported by one extremely popular operating system.  The
idea of committing ourselves to large-scale use of DNAME records
in the root should be a little scary.  That doesn't mean we
should not try it, but it should be considered and phased in
very carefully.  


(3) As part of that operational experience question, there are
some issues with reverse-mapping and with protocols (SMTP is the
most prominent example) that insist on primary names in various
contexts.  Even more generally, a number of protocols, including
HTTP, are sensitive to hosts knowing their own names.  If a
reference is made via a DNAME record, and the target host is not
aware of that alias, the resulting behavior may not be as
expected.    So, probably, at least some of the users of a DNAME
alias are going to be in the same position as users of a
top-level applications alias or even a keyword: they are going
to need to be prepared to see, and sometimes supply, the target
name.  Of course, in the case of IDN DNAMEs, they need to be
prepared to see the punycode too, so a user who accesses an
ASCII-LDH TLD via and IDN DNAME may need to understand that
there are actually three separate names: the TLD name, the DNAME
in native characters, and the DNAME in punycode.

To explain this a little bit further, the nature of the DNS is
such that an alias for a name is just that, an alias.  Whether
the alias is implemented as a DNAME, as an application (or
plug-in) or DNS forwarder remapping of one name into a
different part of the DNS tree (using, e.g., the technique
first prominently introduced to the ICANN community by
new.net), as an alias in a local application (see the
discussion in the papers cited in my footnote (10)), or through
some keyword or "above DNS" searching system, there will be
some circumstances in which the _only_ form that will be
completely safe for sharing a reference between applications or
users will be the non-aliased name actually stored in the DNS.
For each of these cases, the alias or alternate forms are
likely to be fine in the overwhelming number of cases as long
as users are communicating within a single national, language,
and cultural group and using similar software.  For cases very
different from ones showing those similarities of behavior, the
users are likely to need to be aware that they are using
aliases or transformations and not the actual target names.  

In other words, while things will get better over time, it will
never be completely possible to rely on DNAME, nor on any other
aliasing or name-location technique, on the assumption that the
names are the actual, globally-available ones.  No magic is
available in the IDN area, and DNAMEs are not magic either.


(4) The limit on the maximum number of names we can safely
accommodate in the root has more to do with manageability than
with "technology".  Since DNAMEs point to names and not
addresses, they should be stable once added, i.e., changes in
delegation of the target names will not impact the DNAME
records.  However, the decision to add a DNAME alias would
presumably go through the usual, careful (and often slow) ICANN
and US Government review and approval processes for root
changes.  There have been concerns expressed in the past about
how long those processes take.  Although things seem to be
getting better, the delay problem has not disappeared and, for
at least some cases, almost certainly will not.  Some careful
studies about the impact on existing types of requests and
processes of adding many DNAMEs to the approvals queue would
therefore be in order: if the price of adding DNAMEs (or
national-language TLDs) would be to slow down the overall
approval time for delegation and server changes, the community
would need to consider the balance very carefully.  Of course,
the impact of DNAMEs in that regard would be no greater, and
probably much less, than the impact of adding many new TLDs (IDN
or otherwise), but it would be unreasonable to simply assume
that it would have zero impact.

   John Klensin