Subject: [DNSOP] RCODE and CNAME chain

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 5 Apr 2017 11:13:38 +0530

Evan just pointed out a case due to a system test failure that is
interesting.. it's not clear what the behavior should be in this case,
so please discuss:

There's a nameserver that's authoritative for 2 zones example.org. and
example.com.

In the example.org. zone, foo.example.org. is CNAME to bar.example.com.

In the example.com. zone, the name bar.example.com. doesn't exist (NXDOMAIN).

A query for "foo.example.org./A" is answered by the nameserver. It adds
the foo.example.org. CNAME bar.example.com. in the answer section, and
then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to
"bar.example.com" and looks into the "example.com" zone for
"bar.example.com.". It is not found.

The question is: what is the expected reply RCODE for this?

1. Is it NOERROR (0) because there is an answer section with the CNAME?

2. Is it NXDOMAIN (3) because the CNAME target was not found?

3. Does it not matter if it is either?

It seems to me that it should be NOERROR(1) because RFC 1035 defines
NXDOMAIN as "this code signifies that the domain name referenced in the
query does not exist" which in my interpretation doesn't match the
modified QNAME when following the CNAME change.

Also, if a resolver caches the NXDOMAIN against the question section
name (foo.example.org.) , then a follow-up query to the resolver for
"foo.example.org./CNAME" will return an NXDOMAIN from cache.

It seems BIND currently returns NXDOMAIN in this case, and the change in
behavior between looking-into-other-zones and
not-looking-into-other-zones in the nameserver algorithm caused a system
test failure, hence the question.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 5 Apr 2017 11:17:23 +0530

> It seems to me that it should be NOERROR(1) because RFC 1035 defines

s/NOERROR(1)/NOERROR(0)/

> modified QNAME when following the CNAME change.

s/CNAME change/CNAME chain/

		Mukund

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 05 Apr 2017 09:03:43 +0200

Hello Mukund,

> 2. Is it NXDOMAIN (3) because the CNAME target was not found?

NXDOMAIN is correct. The text on this on 103x is a bit weak but 2308 2.1 clarifies this.

> 3. Does it not matter if it is either?

2308 does say
“
Some name servers fail to set the RCODE to NXDOMAIN in the presence
of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
answer is required in this case the resolver must query again using
the QNAME as the query label.
“

but not all resolvers honour this. So I’d say it does matter.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Apr 2017 17:14:15 +1000

> modified QNAME when following the CNAME change.

No. The RCODE references the end of the CNAME/DNAME chain.
 
> "foo.example.org./CNAME" will return an NXDOMAIN from cache.

Then the resolver is broken.
 
> test failure, hence the question.

If the qtype is CNAME or ANY the answer is NOERROR as the CNAME is
not followed.

If the qtype isn't CNAME or ANY the answer is NXDOMAIN as the CNAME
is followed.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Apr 2017 13:34:34 +0000

>test failure, hence the question.

I don't think there is one right answer.  There may be a more efficient answer (in terms of some metric).  The goal of the RFCs was interoperability, keep that in mind.

You allude above to an implementation changing its behavior (answering from all available data vs. sticking to one zone).  This is not something that is explicitly dealt with in the original RFCs, perhaps in later ones.  Both choices have merit, have downsides, still the two are interoperable.  As far as the protocol matters, either is a valid choice, and one that influences whether the query in question results in NOERROR/CNAME chain or NXDOMAIN.

In this case, I think you don't need to worry about the querier.  Rules seem to be explicit about caching responses here.

If anything, make sure your test script is accurate.  (Back in the day of DNSSEC protocol/code development, 1 out of 3 times DNSSEC had a protocol bug, 1 out of 3 times it was a software bug, and 1 out of 3 times everything was right but the tester - me - was expecting the wrong result.)

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 05 Apr 2017 13:54:09 +0000

See RFC 6604.

Donald

from iPhone

On Wed, Apr 5, 2017 at 09:34 Edward Lewis <[email-masked]> wrote:

> On 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" <
> [email-masked] on behalf of [email-masked]> wrote:
>
> I don't think there is one right answer.  There may be a more efficient
> answer (in terms of some metric).  The goal of the RFCs was
> interoperability, keep that in mind.
>
> You allude above to an implementation changing its behavior (answering
> from all available data vs. sticking to one zone).  This is not something
> that is explicitly dealt with in the original RFCs, perhaps in later ones.
> Both choices have merit, have downsides, still the two are interoperable.
> As far as the protocol matters, either is a valid choice, and one that
> influences whether the query in question results in NOERROR/CNAME chain or
> NXDOMAIN.
>
> In this case, I think you don't need to worry about the querier.  Rules
> seem to be explicit about caching responses here.
>
> If anything, make sure your test script is accurate.  (Back in the day of
> DNSSEC protocol/code development, 1 out of 3 times DNSSEC had a protocol
> bug, 1 out of 3 times it was a software bug, and 1 out of 3 times
> everything was right but the tester - me - was expecting the wrong result.)
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
Sent from Gmail Mobile

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 5 Apr 2017 19:47:42 +0530

> See RFC 6604.

This clears it up. Thank you.

		Mukund

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Apr 2017 14:33:14 +0000

Since you mentioned RFC 6604 "xNAME RCODE Clarification", here's a relevant quote from Section 3 ("RCODE Clarification"):

>When an xNAME chain is followed, all but the last query cycle necessarily had no error.  The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response.  If the xNAME chain was terminated by an error, it will be that error code.  If the xNAME chain terminated without error, it will be zero.

I tried a small set up, zone example with two CNAME sets.  name1 CNAME name.example.com (zone also on the server, with nothing at name.example.com) and name2 CNAME name.example.xx (zone not on the server) and recursion disabled.

dig for name1.example. returns the single CNAME record in the Answer, the AA bit, SOA in Authority, and NXDOMAIN in the RCODE.

dig for name2.example. returns the single CNAME record in the Answer, the AA bit, no SOA, and NOERROR in the RCODE.

The first is a "final" answer - NXDOMAIN looking for the last name in the chain.  There's also an SOA record in the Authority indicating the negative TTL to use.  The latter is a non-final answer (i.e., it's up to the querier to keep asking), a "CNAME referral" - no SOA record and no hints as to where to go because it's outside any domain of the name server (or that it is willing to admit to having).

The two (final and CNAME referral) are rather hard to tell apart, it's possible to determine that is the "last query cycle" as mentioned in the RFC, but it takes a trained eye.  How?  Well, a querier ought to realize that, if it didn't ask for a CNAME set and there's no error (yet), you simply haven't gotten a final answer yet.

On 4/5/17, 09:54, "DNSOP on behalf of Donald Eastlake" <[email-masked] on behalf of [email-masked]> wrote:

See RFC 6604.

Donald

from iPhone

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

-- 

Sent from Gmail Mobile

---

From: Jan Včelák <[email-masked]>
Date: Thu, 27 Apr 2017 00:32:44 +0200

Hello,

sorry for resurrecting this thread, but this really caught my attention.

> NXDOMAIN is correct. The text on this on 103x is a bit weak but 2308 2.1 clarifies this.

I actually think NOERROR is correct. The target of the CNAME
(bar.example.com) is not in the bailiwick of the zone (example.org).
So the authoritative server should stop processing the CNAME chain at
this point and send the response with RCODE=NOERROR.

Or can we at least agree that both RCODEs are correct? :-)

Jan

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Apr 2017 09:04:17 +1000

In message <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=[email-masked]>
> this point and send the response with RCODE=NOERROR.

Well RFC 1034 doesn't say stop processing the CNAME chain when it
points outside the original zone.  You go back to step 1 on a CNAME
(and DNAME) and look for the target zone of the *new* QNAME.

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

And this whole issue was discussed and debated 2 decades ago.  RFC
1034 has a number of errors in it.  Other documents update it
including RFC 2308.

If you get to the end of the CNAME chain and the QNAME as it is at
that point does not exist you return NXDOMAIN.

If you don't get to the end of the CNAME chain then you return
NOERROR and a referral if you have one to return.  This introduces
ambiguity.

We really should allow NXRRSET to be returned for QUERY to remove this
ambiguity.  This requires that the server knows that the client supports
NXRRSET with QUERY.  Bumping the EDNS version number would be one way to
signal this.

Mark

---

From: Jan Včelák <[email-masked]>
Date: Thu, 27 Apr 2017 11:13:46 +0200

> NOERROR and a referral if you have one to return.  This introduces

Mark, you are absolute right if you interpret the RFCs word-for-word.
But these documents were written before we knew or cared about cache
poisoning attacks. And when the resolvers started to ignore
out-of-bailiwick records, authoritative server should have been
updated as well and should have stopped sending out-of-bailiwick
records. Because anything out-of-bailiwick is potentially dangerous.
My advocacy for NOERROR is based on that even though we don't have a
document that would specify that.

> NXRRSET with QUERY.  Bumping the EDNS version number would be one way to

Yes, that would be more explicit. But I don't think this is worth the
effort. Resolvers can deal with this ambiguity already.

Jan

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Apr 2017 19:31:50 +1000

In message <CAM1xaJ-+mUhqiE=[email-masked]>
> document that would specify that.

If you want to advocate for changes to behaviour that is fine, but
advocate for that.  Just saying "shouldn't the rcode be NOERROR"
isn't doing that.  Then there is DNSSEC.  If the target zone is
signed and DO=1 is set in the query should you include the data
from the target zone?

You also have to deal with recursive servers that should always
follow the entire chain.  Remember there is nothing wrong with
recursive server having authorative content.

Mark

---

From: Florian Weimer <[email-masked]>
Date: Thu, 27 Apr 2017 12:53:35 +0200

> signed and DO=1 is set in the query should you include the data

Do you suggest to use data which is impossible to use under the trust 
rules because it is cryptographically signed?

This would mean that many DNSSEC validation bugs turn into critical 
cache poisoning bugs because they can be used by off-path attackers to 
poison caches.  (Usually, a single query for an attacker-controlled name 
would be enough, and it could likely be a PTR query.)  I'm not sure if 
saving a server round-trip is worth it.  In particular since the 
recursive resolver already has the infrastructure records for the target 
in cache if it can do cryptographic validation, it should know exactly 
where to fetch the target record anyway.

In general, cryptography as the single line of defense is a very, very 
bad idea because it almost never works correctly.

Thanks,
Florian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Apr 2017 21:12:34 +1000

> rules because it is cryptographically signed?

Yes.  DNSSEC validators do it all the time.  DNSSEC does not
care who supplies the data.
 
> poison caches.

And in the last decade how many DNSSEC validation bugs have there
been that have marked answers as secure when they haven't been? 

B.T.W. named has been returning additional as answer if the RRset
validates as secure for about a decade now.

I devised the trust rules for named 20+ years ago now.  They are
designed for dealing with answers that can't be cryptographically
verified.

> (Usually, a single query for an attacker-controlled name