[dns-operations] NS records pointing to names with CNAME records

[Paul Vixie]

> Date: Thu, 25 Jun 2009 10:16:27 -0700
> From: Matthew Dempsky <matthew at dempsky.org>
> 
> But I'm not arguing that caches should allow this; I'm just interested
> in knowing how existing caches handle situations like this.  Thanks to
> you and Mark for explaining BIND's behavior.

i don't know bind's current behaviour.  i'm speaking from very old bind,
and from other unpublished non-bind software, and from the rfc's themselves.
more on this below, but plz don't treat what i said as authoritative about
current bind.  marka's up on that stuff, i am not.

> > as a result, i know of no implementation that follows CNAME in these
> > two cases.
> 
> I don't know of any implementation that includes CNAME records in
> additional section processing, but dnscache and GbDns follow CNAME
> records when determining which IP addresses to send queries to.

yow.  thanks for the info.  someone told me that djb's smtp software
follows mx -> cname -> a/aaaa chains, which also expands upon the
requirements given in the related rfc's.  perhaps there's a pattern.

> >                ... CNAME chains should be followed and CNAME loops
> >        signalled as an error.
> 
> Right, the spec says caches "should" handle CNAME chains, but also
> that CNAME chains "should" not happen (see the other text you quoted).

anything that must be allowed will be used, so the other text was never
meaningful and is not today meaningful.  you were using cname chains as an
example of something else like ns -> cname -> a/aaaa that wasn't
specifically prohibited, and i was able to distinguish them by the fact
that cname chains are explicitly allowed (with a meaningless and weightless
recommendation) whereas ns -> cname -> a/aaaa is only mentioned implicitly
by exclusion.

---

non-bind implementation experience, as promised inline above.  at least one
a/aaaa rr has to be in cache before forwarding is attempted.  if none are in
cache, try to fetch all of them.  if before/after such fetching all such rrs
are in negative cache, fail the transaction.  at the heart of dns_addglue()
we see a call to dns_cache_findtype() for the rrtype (a or aaaa).  that
function does not follow cnames other than to say that if a cname exists
at that dns name then there's no reason to search for any other type.  this
nameserver would treat ns -> cname -> a/aaaa as ns -> nosuchtype.  earlier
there was a call to dns_adddom() for each ns/mx in the answer/authority
sections, which had called dns_cache_search(), which is cname-ignorant.
both dns_cache_search() and dns_cache_findtype() are negative-cache aware.

the logic to follow cname is present only in dns_request() which builds up
an answer section that may contain some cname rr's before the target rrset.

it's plain from rereading this source code that the entire design assumes no
possibility of interior cname's on ns targets or in additional data work.

===