[dns-operations] NXDOMAIN status, with answers?

[Anthony Lieuallen]

On Mon, Feb 8, 2021 at 9:39 AM Roy Arends <roy at dnss.ec> wrote:

> * Is this (NXDOMAIN status, but CNAME and RRSIG in the answer) valid, per
> the spec?
>
> Yes. The canonical name (the right-hand side of the CNAME, the name in the
> rdata) does not exist. That is, the alias points to something that doesn’t
> exist. Is the canonical name in the same zone as the owner name of the
> CNAME record?
>

Thanks for noticing my little X-Y problem buried here:  Yes, in this
example the right hand side of the CNAME is to a different domain, for
which the server producing this response is not authoritative.  The name
does exist, but this server doesn't know it.  In another simpler example:

$ dig @ns1.ams1.afilias-nst.info. www.ietf.org. A
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10420
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
www.ietf.org.           1800    IN      CNAME
www.ietf.org.cdn.cloudflare.net.
...
$ dig @ns1.ams1.afilias-nst.info. www.ietf.org.cdn.cloudflare.net. A
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 8757
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...

This is how most servers in such a state seem to behave: NOERROR, even
though *this *server doesn't know whether the CNAME target exists or not
(in fact, it will REFUSE such a query).  The server that made me start this
thread serves NXDOMAIN for both the name it is and is (and has a CNAME) and
is not (where the CNAME points) authoritative for.

On Mon, Feb 8, 2021 at 9:43 AM Blacka, David <davidb at verisign.com> wrote:

> > * Is this (NXDOMAIN status, but CNAME and RRSIG in the answer) valid,
> per the spec?
> > * Either way, how should a recursive handle such an authoritative
> response?
>
> The best resource for this is RFC 6604.  In particular it says in section
> 3:
>
>    When there is an xNAME chain, the RCODE field is set as follows:
>
>       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.
>
> Yes, this type of response is valid.


This seems pretty clear, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210208/e593f92e/attachment.html>