<div dir="ltr">Thanks, Mark. <div><br></div><div>It looks like two resolvers make a forward-first policy on each other. The loop of forwarding is the potential cause which is rare. I think it is not configured by one operator but may produce the forwarding loop by accident between two operators.<div><br></div><div>Davey</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 1, 2022 at 12:53 PM Mark Andrews <<a href="mailto:marka@isc.org">marka@isc.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">If you have 2 recursive servers each talking to each other and falling back<br>
to iterative lookups say after 10ms or so or does non-recursive queries of the<br>
other server.  If both servers cache negative responses w/o SOA records then<br>
if the queries come in the right pattern server A will learn the -ve response<br>
from server B then before the “cached” response on A has timed out, server B<br>
will learn the “cached” response from server A. If the zone is then updated<br>
the recursive servers may never go back to it.<br>
<br>
No cached data<br>
<br>
A  <a href="http://example.com/A" rel="noreferrer" target="_blank">example.com/A</a> RD=0 -> B referral (best NS RRset) -> A -> iterative query<br>
<br>
Cached example<br>
<br>
B has “cached" a NOSOA / NODATA for <a href="http://example.com/A" rel="noreferrer" target="_blank">example.com/A</a> for 10 sec at T=0<br>
<br>
At T=5<br>
A <a href="http://example.com/A" rel="noreferrer" target="_blank">example.com/A</a> RD=0 -> B NODATA/N -> A “cached" NOSOA/NODATA for 10 secs<br>
<br>
At T=11<br>
B <a href="http://example.com/A" rel="noreferrer" target="_blank">example.com/A</a> RD=0 -> A NODATA/N -> B “cached" NOSOA/NODATA for 10 secs<br>
<br>
Mark<br>
<br>
> On 1 Sep 2022, at 13:59, Davey Song <<a href="mailto:songlinjian@gmail.com" target="_blank">songlinjian@gmail.com</a>> wrote:<br>
> <br>
> Hi folks, <br>
> <br>
> We found there are Negative responses without SOA records exist in the <br>
> Internet. I noticed that RFC2308 suggests not caching Negative responses <br>
> without SOA records to avoid a loop. <br>
> <br>
> So I'm wondering what the loop or circle is. Does it mean the resolver may <br>
> cache the Negative response forever by resetting the TTL? I think it is largely<br>
> dependent on how the resolver implements it. Or are there other risks of <br>
> looping I may miss?<br>
> <br>
> In section 5 of RFC2308 it says:<br>
> <br>
>    Negative responses without SOA records SHOULD NOT be cached as there<br>
>    is no way to prevent the negative responses looping forever between a<br>
>    pair of servers even with a short TTL.<br>
> <br>
>    Despite the DNS forming a tree of servers, with various mis-<br>
>    configurations it is possible to form a loop in the query graph, e.g.<br>
>    two servers listing each other as forwarders, various lame server<br>
>    configurations.  Without a TTL count down a cache negative response<br>
> <br>
>    when received by the next server would have its TTL reset.  This<br>
>    negative indication could then live forever circulating between the<br>
>    servers involved.<br>
> <br>
> <br>
> Best regards,<br>
> Davey<br>
<br>
-- <br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: +61 2 9871 4742              INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
<br>
</blockquote></div>