<div dir="ltr"><div dir="ltr"></div><div>Hi,</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 9, 2021 at 8:35 PM Dave Lawrence <<a href="mailto:tale@dd.org">tale@dd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Paul Vixie writes:<br>
> On Sun, Aug 08, 2021 at 03:20:24PM +0530, Shreyas Zare wrote:<br>
> > ... The resolver I have does restart for the last CNAME regardless<br>
> > of the RCODE but, the negative cache implementation based on RFC2308 and<br>
> > RFC8020 caused the NXDOMAIN response to get cached causing the issue.<br>
> <br>
> that's exactly what should happen.<br>
<br>
Unfortunately, with a single rcode covering a response but cnames<br>
causing query restarts and effectively making multiple implicit<br>
responses, we can't have just one proper rcode for the whole lot; it<br>
isn't well-defined.  <br></blockquote><div><br></div><div>The problem is that this is well defined in 
RFC2308 Section 2.1 that too with example responses containing CNAME and recommended to use Type 2 response to indicate correct NXDOMAIN response. The text quoted below from there is also quite clear:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<pre class="gmail-newpage">   Note, in the four examples of NXDOMAIN responses, it is known that
   the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
   The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
   exist.  On the other hand, in the referral example, it is shown that
   "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
   known one way or the other about the existence of "TRIPPLE.XX", other
   than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
   obtaining information about it.

   Where no CNAME records appear, the NXDOMAIN response refers to the
   name in the label of the RR in the question section.</pre>

</div></blockquote><div><br></div><div>The original issue with the response for "<a href="http://www.uber.com">www.uber.com</a>" matches exactly with the Type 2 example. And all of the 3 CNAME records are within the zone cut for the received SOA. To make the resolver work with this issue, the negative cache implementation had to be removed for CNAMEs with NXDOMAIN case.<br></div><div><br></div><div>
Regards,<br clear="all"></div><div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><b>Shreyas Zare</b><br><a href="https://technitium.com" target="_blank">Technitium</a><br></div></div></div></div></div></div></div></div></div></div>

</div></div></div></div>