Re: [DNSOP] RCODE and CNAME chain

[Jan Včelák <[e-mail]>]

On Thu, Apr 27, 2017 at 1:04 AM, Mark Andrews wrote:
>
> In message <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=[e-mail]>
> , =?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