CNAME, DNAME, NS, A

John C Klensin klensin at jck.com
Thu Jan 31 21:53:32 CET 2008



--On Thursday, 31 January, 2008 05:59 -0800 Erik van der Poel
<erikv at google.com> wrote:

> Hi John,
> 
> Thanks for mentioning some of the issues surrounding CNAME and
> DNAME.
> 
> On Jan 25, 2008 9:05 AM, John C Klensin <klensin at jck.com>
> wrote:
>> The only type of explicit
>> case-by-case DNS mapping I can think of would be to have the
>> label containing the lowercase sigma associated with a CNAME
>> or DNAME record that pointed to an otherwise-identical label
>> containing a final-form sigma.  That type of mapping certainly
>> cannot be prohibited.  It would cause some interesting
>> problems with email and some other protocols because of
>> restrictions on the use of aliases.  It would violate current
>> policy in many domains (including almost all TLDs) against
>> CNAME entries.
> 
> I also note in Vaggelis' slides that DNAME only really works
> for names *below* the level for which DNAME is given:
> 
> http://www.icann.org/meetings/lisbon/presentation-idns-greece-
> 27mar07.pdf

Yes, that is how DNAME is defined.  

> He also mentions that when they do not use DNAME records, the
> names in the bundle must have the same NS records. Presumably,
> they would also have the same A (and/or AAAA) records. I may
> have missed it, but I do not see any mention of CNAME and
> DNAME in your RFC on bundling, etc:
> 
> http://ietf.org/rfc/rfc4290.txt

RFC 4290 is essentially a generalization and interpretation of
its CJK-specific source, RFC 3743.  3743 is quite careful to
avoid specificity about what one does with a variant bundle
after it is defined.   One possibility, which avoids all of the
difficulties of trying to have two DNS subtrees that somehow
match is simply to permit one of the names in the bundle to be
registered and prohibit all of the others.  There are registries
that do that.  A second is to insist that all of the names that
are registered "belong to" the same entity, letting them decide
how to proceed from there.  In that case, the NS records for two
registrations can point to the same server or not, depending on
registrant preferences.

One can go further than that and try to define and enforce "same
tree" by using DNS facilities, not just registry policy. That is
obviously what .GR is trying to do.    It is an option that the
JET team avoided for several reasons.  One was that DNAME was
just a little too unstable and unsupported at the time.   A lot
can happen in four years, although I note that there is an
Internet-Draft active now that once again clarifies some details
about how DNAME works.   Another is that, because of the "tree
below" characteristic and the fact that DNAME, unlike CNAME, can
share a node with records of other RR types, DNAME often doesn't
behave as casual users (or registrants) would expect, leading to
confusion and surprise.  Having NS records for two names point
to the same server can help if the operator of the master zone
files make the right decisions, but they are still two master
zone files with potential for divergent branches further down,
unsynchronized records in caches, and so on (in addition to the
potential for various types of deliberate mischief).

So the JET team just didn't go there and my document didn't
either.


> I think it would be very useful to have a section or document
> that outlines that pros and cons of each approach (CNAME vs
> DNAME, etc). In particular, I am very curious about the
> scalability of each of these approaches. The recent
> discussions about sigma and tonos show that the decisions made
> for IDNA have an effect on the places where we try to process
> them.

I would enthusiastically endorse an effort to produce such a
document.
 
> Since final sigma is mapped to sigma in the client software
> *before* the name hits the DNS resolver, this mapping can be
> done in pre-resolution client-side libraries. On the other
> hand, letters with tonos are *not* mapped to their tonos-less
> counterparts before DNS resolution, thereby forcing the
> lower-level domains of the .GR TLD to deal with the issue,
> either using DNAME or NS/A. This seems to me to essentially
> push the problem from the pre-resolution library to the chain
> of servers involved in an entire domain name lookup.

Yes.  But as I explained in my note to Simon, and Patrik
explained in his earlier note about where and how to do
matching, unless we are going to do label comparison on the
server at query time, a decision has to be made for each pair of
characters as to whether they are "the same" or not and that
decision has to be reflected in mappings that inherently lose
information.  One has to choose somehow and live with the
consequence of those choices.  As Simon points out, for these
cases, the choices were made by a WG years ago.  We could, in
principle, reverse them on a character-by-character basis now.
But doing so would cause incompatibility and ambiguity (more
difficult problems) unless we did a major protocol replacement
and is hence very costly to think about.   

At least from the perspective of a non-speaker of Greek,
somewhat ironic that we've got two different cases: In one,
final sigma was mapped out and some people are unhappy about
that.  In the other, tonus was not mapped out, and some people
are unhappy about it.  The cases are actually different enough
that the combination is reasonable, but probably other
alternatives would have been reasonable too.  The problem is
that one has to have rules that can be applied at the time of
label creation.  Probably there is no way to fully optimize that
choice.

> How much of a load does DNAME place on the various components
> in this picture? What about CNAME? If IDNs start getting used
> heavily, will CNAME and DNAME scale well? Does the
> pre-resolution library scale better? Should any of this have
> an effect on the design of IDNAbis?

You should probably have a look at
draft-ietf-dnsext-rfc2672bis-dname-08.txt because the answer to
the first question depends critically on whether the client
resolver making a query fully supports DNAME.  CNAME is cheap,
but identifies nodes, not subtrees.  How a pre-resolution
library scales is going to depend on what it does, but some of
the answer to your question depends on the relative performance
of client and server machines and even on who is paying the
bills.  

I think the answer to the last question is "I don't think so",
but YMMD.

> I am partly also viewing this from the point of view of
> Google. We do rather a lot of DNS lookups each day. :-)

Yes.  I would recommend the following:

(1) DNAMEs will be more heavily used over time, whether for
IDN-related purposes or otherwise.  If any of your resolvers do
not fully support EDNS0 and DNAME, this would be a good time to
get them updated/fixed.  Tree-synthesis of CNAMEs is obviously
more expensive than not doing that.

(2) You should push, where possible, for URIs and IRIs in the
documents you are indexing to contain final-form names (A-labels
or U-labels).  There really should be very little requirement,
going forward, for URIs or IRIs to contain putative labels that
require mapping (quite independent of what is displayed to the
user).   You might even encourage the use of URIs and A-labels
rather than IRIs and U-labels so as to eliminate the need to do
IRI-> URI mapping and IDN processing entirely.   Note that this
is about education, since you can't compel any of this behavior.

(3) Your pre-lookup DNS processors should probably make at least
a superficial test for U-label conformance (e.g., containing no
NEVER characters), bypassing IDN-specific preprocessing if it
does not appear to be necessary.   Where the tradeoffs lie in
the sophistication of that test versus just doing the
preprocessing is a question that will require more research and
experimentation but, if IDNA200X succeeds and the proportion of
labels that are already in U-label or A-label form increases
over time, simply avoiding that step when you can will almost
certainly turn out to be more efficient than executing it, no
matter how efficient it is.

    john



More information about the Idna-update mailing list