Subject: [dnsext] CNAME/DNAME and NXDOMAIN

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Nov 2011 11:31:09 -0400

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"

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Sat, 05 Nov 2011 10:17:15 +1100

Both answers are self consistant and neither should cause a problem.

Following CNAME records, when not recursing for the client, is a
security issue as the target of the CNAME may not be delegated to
the same machine leading to potential, accidental, cache poisioning.
We (ISC) have looked at not following CNAME records when generating
such replies.  We already discard the rest of the response and
requery for the target of the CNAME.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 14 Nov 2011 11:42:43 +0100

> the same machine leading to potential, accidental, cache poisioning.

An authoritative server should follow CNAME records while the target is
actually being served. If it is delegated to another machine, you return
the chain of CNAMEs until then. The recursive name server can continue
recursing.

> requery for the target of the CNAME.

So you would query the same machine, despite that server is giving you a
chain?

Refocusing on Ed Lewis initial question, regarding the RCODE. One server
is giving NXDOMAIN, the other NOERROR. Given the fact that CNAME records
where followed, the status code should not be switched to NXDOMAIN. This
is conform the server algorithm in RFC2672.

Also, it was questioned if this should be changed in the dname-bis document:

    http://www.ietf.org/mail-archive/web/dnsext/current/msg09224.html

Although the response was minimal, the suggestion was to make no change.

For NSD, because it is not considered an NXDOMAIN response (following
step 3c of the server algorithm), the SOA record is not added to the
Authority Section. Though, the target does not exist, so the NSEC3
records are still added.

I don't know if adding the NSEC3 records is the right thing to do, I
seem to be unable to find the text what to do in this specific case.
Although, both NSD and BIND seem to be in some sort of agreement that
the records are needed.

Best regards,
  Matthijs

---

From: Evan Hunt <[email-masked]>
Date: Mon, 14 Nov 2011 19:06:06 +0000

> So you would query the same machine, despite that server is giving you a

A server may claim, through misconfiguration or malice, to
be authoritative for the target of a CNAME when it isn't.
For example, suppose 'cname.example.com' points to
'target.example.com', but 'target.example.com' is actually a
zone cut and is delegated to some other server entirely.  The
only way to find out is to with a followup query.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 14 Nov 2011 11:17:49 -0800

> only way to find out is to with a followup query.

There's three main themes we've seen with netalyzr:

a)  Requery regardless

b)  Accept when the name is internal or equal (eg, the system is authoritative for foo.com, and the cname refers to anything.{optional}.foo.com)

c)  Accept when the server has already been identified as the authority for the target domain (eg, the system is authoritative for foo.com AND bar.com, the resolver knows this by previous queries, and the CNAME is in the form example.foo.com CNAME example.bar.com, example.bar.com A 1.2.3.4).

Notably Google Public DNS does C.