The RFC or the reason why you can not create CNAME record for the "root record"

[Kevin Darcy]

phil-news-nospam at ipal.net wrote:

>On Mon, 29 Mar 2004 05:12:06 -0500 Barry Margolin <barmar at alum.mit.edu> wrote:
>
>| RFC 1034 says: "The domain system provides such a feature [aliases] 
>| using the canonical name (CNAME) RR.  A CNAME RR identifies its owner 
>| name as an alias, and specifies the corresponding canonical name in the 
>| RDATA section of the RR.  If a CNAME RR is present at a node, no other 
>| data should be present; this ensures that the data for a canonical name 
>| and its aliases cannot be different."
>| 
>| Since a delegated zone name is required to have SOA and NS records, if 
>| it also had a CNAME record it would violate the restriction in the last 
>| sentence.
>
>So how do we fix this?  I think a hack/patch is the only way.  But I see
>two different ways to approach that.  Which one is likely to work in most
>cases?
>
Look, the fundamental issue that the "CNAME and other data" prohibition 
addresses is the scenario of a "stranded" CNAME in a cache. Imagine that 
a caching resolver has a CNAME "foo.com IN cname bar.com" in its cache, 
but the "bar.com" records have expired from its cache. Assume that no 
relevant negative-caching records exist. This is what I mean by 
"stranded CNAME". Now it gets an A-record query for "foo.com". What does 
it do? With the "CNAME and other data" prohibition in place, it has only 
one place to look for the answer: the authoritative servers for bar.com, 
the target of the alias. If we remove the "CNAME and other data" 
prohibition, it now has to look in *two* different places: the bar.com 
auth servers (as before) and *also* the foo.com auth servers (because 
there might be an foo.com A record there too, co-existing with the 
cached CNAME record). So you've just roughly doubled the work that 
caching resolvers everywhere have to perform in these scenarios. The 
Denial of Service potential alone, boggles the mind. And don't for a 
moment think that this scenario is "unlikely" or "obscure", since 
A-record TTLs tend to be lower than TTLs of other record types, 
including CNAMEs, therefore in any response containing a CNAME/A pair, 
it's quite common for the A-record to time out before the CNAME does.

                                                                         
                                                                       - 
Kevin