Recent experiments on the Internet brought up a question regarding 
the handling of CNAME and DNAME answers that lead to negative 
responses.  This is an old issue, nothing new, but it seems that 
there's some confusion among popular implementations.

Citing the oldest text, RFC 1034/4.3.2:

             If the "*" label does not exist, check whether the name
             we are looking for is the original QNAME in the query
             or a name we have followed due to a CNAME.  If the name
             is original, set an authoritative name error in the
             response and exit.  Otherwise just exit.

This says that if a CNAME chain leads to a non-existent name, the 
RCODE reflects that the original name's status, not the end.  This 
rule applies to authoritative servers.

In RFC 2308 (NCACHE), section 2.1, caches are instructed to set the 
RCODE to NXDOMAIN if the target of the CNAME chain does not exist. 
This is not a contradiction because this pertains to recursive 
servers.

Now with DNSSEC on-board we have another angle of confusion.  When 
the target does not exist, there's the matter of the NSEC/NSEC3 
record sets needed.  This is in addition to the SOA record and RCODE 
setting.

And to further twist this, in accordance with the real life situation 
that launched this quest, the QNAME owning the CNAME/DNAME is in an 
different zone than the target but the name servers for both zones 
are the same.

With the help of Olafur, I've set up a test case unconnected to the 
live situation to help illustrate this.  The reason for this level of 
misdirection is that I'm in now way connected to the real example and 
I don't want to finger point, especially because I think the "fault" 
here lies in the implementations and not in the operator's actions.

What I'm asking for is people to issue these two digs and look at the 
output.  I believe the output, which differ from each other, should 
have an RCODE of No Error, an Answer Section with the CNAME and 
signature, and an Authority section with an NSEC and RRSIG(NSEC) to 
prove why a wildcard is consulted.  One answer has that plus NSEC3 
records showing that the targer does not exist. The other answer has 
that plus the SOA and SOA RRSIG with the RCODE set to Name Error.

If you ask a recursive server for this (in the real example), the 
latter response is correct.  But the servers being asked here are 
(acting as) authorities.

dig @geysir.ogud.com www.dnametest.nseczone.dstestdomain092811.us. AAAA +dnssec

dig @stora.ogud.com www.dnametest.nseczone.dstestdomain092811.us. AAAA +dnssec

The real situation involves DNAME, not CNAME, but I chose to test on 
CNAME because it's more clearly documented in the text.  I haven't 
found the "smoking gun" passage that says the NXDOMAIN rule for CNAME 
applies to DNAME but common sense say it does.

I'd like to know of these two implementations "go to far" in 
generating the answer, according to the specifications.  The answers 
are both right and do not cause an operational interruption.

I'll leave off identifying the implementations.  They might be 
discoverable via the usual methods, I don't think any steps were 
taken to stop that.  But for the sake of this little experiment, it's 
good to not know at first.  I'll say the two are very popular and you 
probably can guess them before I finish this paragraph.

I just checked - yes, the versions are visible. ;)

PS - the test zone here is properly delegated but not to Olafur's 
servers, so you need the "@nameserver" to hit them.  If you leave 
that off you hit our servers, which have nothing to do with the test. 
(I.e., I'm not trying to compares ours to the open source ones.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"