[dns-operations] Adding CNAME for the root domain issue

[Paul Vixie]

Tony Finch wrote:
> John Levine<johnl at taugh.com>  wrote:
>> It would be nice to hear from people who were there at the time, but
>> until then, RFC 1033 says:
>
> It's worth looking at RFC 882 and RFC 973 for the pre-standard history.
> CNAME was originally a fallback, so the canonical/target name was only
> used if the queried type was missing at the alias/owner name. This was
> changed because:
>
>        The specification allows CNAME RRs to exist with other RRs at the
>        same node.  This creates difficulties since the other RRs stored
>        with the CNAME at the alias might not agree with the RRs stored at
>        the primary name.
>
>        If a node has a CNAME RR, it should have no other RRs.
>
> The pre-standard logic would have worked nicely for CNAME-at-apex.

what's missing from this text is that with cname in its present form as 
a fallback, it's uncacheable. a cache having some RRsets at a name, upon 
hearing a query for a type it doesn't have, would always have to forward 
to the authority. the cache would then hold synthesized rrsets. probably 
these would have to be sent from the authority with TTL=0.

so, i disagree with your term, "nicely".

>
>> RFC 1912 says: [...]
>>
>> It then describes workarounds for CNAME related bugs in BIND which I hope
>> have been fixed in the intervening 20 years.
>
> The paragraph that mentions BIND (quoted below) talks about NS records
> pointing at CNAME aliases, which are still deliberately ignored by BIND.

not just bind, and not just ns -- see also mx. the NSDNAME is defined as 
the canonical name, specifically and deliberately, to avoid iteration 
during delegation. this is in keeping with CNAME's purpose as 
transitional, for renaming events. only a QNAME can be an alias.

-- 
P Vixie