In message <CAM1xaJ-+mUhqiE=tzpb_uy91bf9sxntukd+ds019qrvvado...@mail.gmail.com> , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= writes: > On Thu, Apr 27, 2017 at 1:04 AM, Mark Andrews wrote: > > > > In message <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=4xsP3FWyQGFt36H1g@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.
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 > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
