<div dir="ltr">Sometimes the long time stale response is caused by a sensitive "use stale response when encounter timeout or servfail to authoriative nameserver" policy.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Paul Hoffman <<a href="mailto:phoffman@proper.com">phoffman@proper.com</a>> 于2019年4月8日周一 下午10:09写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It sounds like you are saying "some resolver operators extend the TTLs <br>
given in DNS responses, and this causes problems". If so, we agree.<br>
<br>
If, however, you are saying "some resolver operators extend the TTLs <br>
given in DNS responses, and this causes problems that the rest of the <br>
DNS community should solve", we disagree. The customers of that resolver <br>
will have problems like the one you listed, and that is fully the fault <br>
of the resolver operator.<br>
<br>
On 7 Apr 2019, at 21:26, Davey Song wrote:<br>
<br>
>  Local resolver has policy/strategy to set a larger TTL to reduce the<br>
> upstream traffic, in order to increase the cache hit rate and response<br>
> time. Some times, local resolver has policy to serve stale data in <br>
> case of<br>
> network failure after TTL timeout. There may be others situation cause <br>
> the<br>
> cache serve stale data.<br>
<br>
This is a misconfiguration on the part of the resolver operator.<br>
<br>
> If any intentional operation, or software bug, or manual <br>
> misconfiguration<br>
> on resolver will cause the serve-stale situation which will become a<br>
> problems for names changing their records like NS, A/AAAA during the <br>
> period<br>
> of stale data in the cache but not others keep unchanged.<br>
><br>
> The recent event happened last week was a name of CCTV VOD services, <br>
> people<br>
> call in complaining they can not open the video. It was found that in <br>
> Gang<br>
> Zhou City, the DNS of a local broadband service provider served stale <br>
> data<br>
> for that name for hours. It is not clear which conflict or bug make <br>
> the<br>
> trouble, but the fact is cache of that local ISP and downstream <br>
> forwarder's<br>
> cache got impact. It takes time to purge that cache.<br>
<br>
Exactly right. That resolver operator should investigate the bug (most <br>
likely in their configuration, possibly in the unnamed resolver software <br>
they are using, and prevent it from happening in the future.<br>
<br>
> I did it in the above. It does not sound like an exaggeration, I <br>
> think. If<br>
> you are talking with CDN/Cloud people, this is a typical operation <br>
> issue<br>
> they need to face.<br>
<br>
It is not "typical": we rarely hear of this problem.<br>
<br>
>  No. DNS in ISP and Teleco did something wrong.<br>
<br>
One which can be fixed.<br>
<br>
> As you are one author of<br>
> DOH, you must konw how name owners want to bypass the DNS in the <br>
> middle.<br>
<br>
This makes no sense. DoH was developed so that applications can use <br>
resolvers securely using HTTP semantics; that's completely unrelated to <br>
what you have said above.<br>
<br>
--Paul Hoffman<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
dns-operations mailing list<br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>