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

[phil-news-nospam at ipal.net]

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.

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.

A stranded CNAME won't impact the intended usage; I have no need to combine
CNAME with A.  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.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------