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

[John C Klensin]

--On Wednesday, December 31, 2008 9:10 AM -0500 Andrew Sullivan 
<ajs at shinkuro.com> wrote:

>...
> 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.

And, if you think that is clear to a non-specialist, I look 
forward to IETF Last Call :-(

>> 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.

If I correctly understand Vaggelis's concern, the problem isn't 
(only) the A RRs, but the MX RRs and anything else that happens 
to be lying around the zone apex/ tree location of the DNAME RR 
itself(SRV, AAAA, NAPTR, etc.).

I guess that, if I were a zone administrator making a practice 
of this, especially within the same zone (e.g., trying to point 
one or more IDNs in a zone to an ASCII tree note), I'd be 
looking into some editing tools or zone file (or equivalent) 
macros that would copy the relevant records and keep them 
synchronized.  Not a lot of fun, but better than treating this 
on a case-by-case basis.

That said, if practices are evolving so that the handling of 
IDNs as Vaggelis describes it in .GR becomes more general and/or 
DNAMEs are used to manage variant bundles, it might behoove 
DNSEXT to understand that, in this very special case in which 
the tree node containing the DNAME RR and the tree node 
containing its target are both in the same zone, most of all of 
the considerations that required DNAMEs to apply to subordinate 
nodes only do not apply.  If that case is going to be common 
enough, it is time to invent a third alias type that, for that 
limited circumstance, does what people keep wanting and 
expecting DNAME to do.

     john