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 Tue, 01 Jun 2004 20:00:48 -0400 Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>
>| 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.
>
>I know all about the protocol.  I've dealt with it, and its shortcomings,
>for years.  I'm simply revisiting a setup I've used in the past (it used
>to work in an old BIND, whether intended or not, and still works in some
>DNS services), but now with capabilities frequently requested by customers
>because other providers do offer it.
>
Just because BIND was once broken in this regard is no excuse to 
re-break it.

>I only need to get the resolving name server to re-query with the new name.
>If it queries for SOA, it doesn't really matter to me whether it gives it a
>real SOA answer, or just the CNAME.
>
But the point remains, regardless of whether the QTYPE is A or SOA, in a 
stranded-CNAME situation, and assuming aliasing is enabled for all 
QTYPEs, the caching resolver has to look in two different places 
(foo.com and bar.com), roughly doubling the work it must perform, and 
creating roughly twice as many potential points of failure. And it might 
find SOA records in *both* places. So how should it answer in that 
scenario? Arbitrarily give preference to one SOA over the other? Or just 
mix them together in the same answer?

The bottom line of the stranded-CNAME scenario is: if you want to 
preserve the ability to alias all record types, then allowing CNAMEs to 
co-exist with other record types puts an intolerable burden on 
intermediate caching servers, and adds a significant amount of 
additional complexity. It has been decided that the drawbacks outweigh 
the benefits, so "CNAME and other data" has been forbidden. This 
decision holds true as much today as it did 17 years ago.

>A stranded CNAME won't impact the intended usage; I have no need to combine
>CNAME with A.  
>
I only used QTYPE=A as an example. Unless you're going to selectively 
disable aliasing for certain QTYPEs (which I addressed in another 
message), the same problem exists for all QTYPEs, excluding perhaps 
QTYPE=* (depending on how one interprets the RFCs wrt that QTYPE).

>The only desire to get CNAME in with SOA/NS is to satisfy a
>requirement of BIND and the RFC (despite the conflict).  If I can get it to
>work by leaving out SOA/NS, I'll do that (unless there is a better way).
>
>An alternative is to make BIND appear authoritative while performaing as
>a resolver/translator.  Maybe you have a patch to make it do this?  What
>it would do is have a configuration entry that identifies another domain
>for a given domain.  When a query comes in for the configured domain, it
>looks up the information in the mapped-to domain and caches it, translating
>it as authoritative data.  Do you think that would be better?  It would be
>a more complex patch.
>
I think djbdns has a notion of a "server-side alias" which doesn't 
involve CNAMEs. Trouble is, such server-side aliases do not propagate 
via AXFR/IXFR from masters to slaves (so you have to sign on to 
something like the whole DJB rsync-over-ssh hive-mind replication meme), 
and because it is *server-side*, none of the aliasing work can be done 
by intermediate caching servers, thus putting all of the load on the 
authoritative servers.

                                                                         
                                                      - Kevin