On Thu, Apr 27, 2017 at 1:04 AM, Mark Andrews wrote: > > In message > <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=4xsp3fwyqgft36...@mail.gmail.com> > , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= writes: >> Hello, >> >> sorry for resurrecting this thread, but this really caught my attention. >> >> On Wed, Apr 5, 2017 at 9:03 AM, Peter van Dijk wrote: >> > On 5 Apr 2017, at 7:43, Mukund Sivaraman wrote: >> >> 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? >> > >> > 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. > > 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.
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. > 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. Yes, that would be more explicit. But I don't think this is worth the effort. Resolvers can deal with this ambiguity already. Jan _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
