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.
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
> Or can we at least agree that both RCODEs are correct? :-)
>
> Jan
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
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
