<div dir="ltr"><div dir="ltr">On Mon, Feb 8, 2021 at 9:39 AM Roy Arends <<a href="mailto:roy@dnss.ec">roy@dnss.ec</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div dir="ltr"><div>* Is this (NXDOMAIN status, but CNAME and RRSIG in the answer) valid, per the spec?<br></div></div></blockquote><div>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?<br></div></div></div></blockquote><div><br></div><div>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:<br></div><div><br></div><div>$ dig @<a href="http://ns1.ams1.afilias-nst.info">ns1.ams1.afilias-nst.info</a>. <a href="http://www.ietf.org">www.ietf.org</a>. A<br>...</div><div>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10420<br>;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1<br>...<br>;; ANSWER SECTION:<br><a href="http://www.ietf.org">www.ietf.org</a>.           1800    IN      CNAME   <a href="http://www.ietf.org.cdn.cloudflare.net">www.ietf.org.cdn.cloudflare.net</a>.<br>...</div><div>$ dig @<a href="http://ns1.ams1.afilias-nst.info">ns1.ams1.afilias-nst.info</a>. <a href="http://www.ietf.org.cdn.cloudflare.net">www.ietf.org.cdn.cloudflare.net</a>. A<br>...</div><div>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 8757<br></div>;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1<br><div>...</div><div><br></div></div><div dir="ltr">This is how most servers in such a state seem to behave: NOERROR, even though <i>this </i>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.</div><div dir="ltr"><br></div><div dir="ltr">On Mon, Feb 8, 2021 at 9:43 AM Blacka, David <<a href="mailto:davidb@verisign.com">davidb@verisign.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> * Is this (NXDOMAIN status, but CNAME and RRSIG in the answer) valid, per the spec?<br>
> * Either way, how should a recursive handle such an authoritative response?<br>
<br>
The best resource for this is RFC 6604.  In particular it says in section 3:<br>
<br>
   When there is an xNAME chain, the RCODE field is set as follows:<br>
<br>
      When an xNAME chain is followed, all but the last query cycle<br>
      necessarily had no error.  The RCODE in the ultimate DNS response<br>
      MUST BE set based on the final query cycle leading to that<br>
      response.  If the xNAME chain was terminated by an error, it will<br>
      be that error code.  If the xNAME chain terminated without error,<br>
      it will be zero.<br>
<br>
Yes, this type of response is valid.</blockquote><div><br></div><div>This seems pretty clear, thanks! </div></div></div>