CNAME, DNAME, NS, A

Erik van der Poel erikv at google.com
Thu Jan 31 14:59:23 CET 2008


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

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

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.

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.

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?

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

Erik


More information about the Idna-update mailing list