Implementation questions (digressing from...) / A DNAME issue

[Andrew Sullivan]

On Wed, Dec 31, 2008 at 12:44:37PM +0200, Vaggelis Segredakis wrote:

> ***NOT*** the same with user at name2.gr. This seems to happen because the tree
> of name1.gr subdomains equals the tree of name2.gr subdomains below the
> initial DNAMEing level only!

Yes.  Please see the DNAME specification.  There's also a DNAME
clarification draft working its way (currently slowly, because of me)
through the DNSEXT working group.
 
> >From this you can assume that the DNAME solution proposed is not a simple
> one but instead it can lead to further problems.

It's by no means ideal.  What would obviously be ideal is to have
something that aliases everything at example.tld to otherexample.tld.
A record like this:

  example.tld 86400 IN CNAME otherexample.tld

substitutes otherexample.tld for example.tld during the CNAME
processing.  But the same is not true for a similar DNAME.  To quote
draft-ietf-dnsext-rfc2672bis-dname-14, 

> 2.3. DNAME Apex not Redirected itself


>    Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
>    owner name; the owner name of a DNAME is not redirected itself.  The
>    domain name that owns a DNAME record is allowed to have other
>    resource record types at that domain name, except DNAMEs or CNAMEs.
>    This means that DNAME RRs are not allowed at the parent side of a
>    delegation point but are allowed at a zone apex.

>    The reason for this decision was that one can have a DNAME at the
>    zone apex.  There still is a need to have the customary SOA and NS
>    resource records at the zone apex.  This means that DNAME does not
>    mirror a zone completely, as it does not mirror the zone apex.

>    These rules also allow DNAME records to be queried through RFC 1034
>    [RFC1034] compliant, DNAME-unaware caches.

 
> In our registry we have been using this solution knowing the problems and
> pointing them out to our registrants when they decide to set up their domain
> name zones. However, if you wish this protocol to move forward and be
> successful with the use of email as well, you should not impose on
> registries to DNAME names. Instead, it would be useful each transformation
> or mapping to exist in the protocol itself.

Nobody is imposing DNAMEs on anyone; it's merely an option available
to operators.  Note that you can have other RRs at the domain name.
Therefore, if you _really_ want to support A records at the DNAME node
name, you could bundle the DNAMEd names in your registry database
somehow, and then when the A record for one of the hostnames was
updated, you could update all of them.  I think this is ugly, but we
don't have an RRTYPE that can mirror a zone completely.  It would be
nice were there one, but there isn't, and we have to cobble together
something that will work using the parts we have.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.