<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 25, 2016 at 12:49 PM John Wobus <<a href="mailto:jw354@cornell.edu">jw354@cornell.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mar 18, 2016, at 6:28 AM, Barry Margolin <<a href="mailto:barmar@alum.mit.edu" target="_blank">barmar@alum.mit.edu</a>> wrote:<br>
> In article <<a href="mailto:mailman.384.1458255932.73610.bind-users@lists.isc.org" target="_blank">mailman.384.1458255932.73610.bind-users@lists.isc.org</a>>,<br>
> Mark Andrews <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>> wrote:<br>
><br>
>> How do you actually expect this to ever work in real life?<br>
><br>
> I'm pretty sure Google DNS does this. Other resolver operators often get<br>
> complaints about "Why can't I look up <whatever> through your DNS<br>
> servers when I can do it through Google DNS?"<br>
<br>
I’d guessed Google just re-queries before it needs to, which has benefits but<br>
requires a more complex “clean out very-seldom-used records” strategy. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I’d imagine they'd use a somewhat-random amount of time to pre-query<br>
as one of their measures against cache poisoning.<br></blockquote><div><br></div><div><div>A few years back a number of us wrote draft-wkumari-dnsop-hammer ("Highly Automated Method for Maintaining Expiring Records").</div><div><br></div><div>My motivations for working on this were:</div><div><br></div><div>1: to keep often used information in the cache, avoiding the periodic spikes in latency as things age out and need to be refetched (not for cache poisoning protection or TTL stretching). </div></div><div><br></div><div>2: (equally, or more  important) to be able to get "Stop! Hammer time" into a document: "If the original TTL of the RR is less than STOP *</div><div>HAMMER_TIME then the cache entry should be marked with a "Can't touch</div><div>this" flag, and the described method should not be used."</div><div><br></div><div>Many implementations (including Unbound, OpenDNS, and ISC BIND) now do something like this, but sadly call it something like "prefetch" or something equally boring. I keep meaning to go back push the document again.</div><div><br></div><div>W</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This would be a good nameserver feature, e.g. when a response is given<br>
from the cache, a secret (shorter) ttl is adjusted to help assure continuity.<br>
Or other variants.  Such a feature might address Ron’s concern.<br>
(I believe I recall discussions on this or another list, perhaps even<br>
a feature in the wings.)<br>
<br>
In any case, I cringe at the thought of overriding TTLs.  They’re there<br>
for a reason.  In some instances, overriding could “help”, but in others, it<br>
would be really, really bad. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
John Wobus<br>
Cornell University IT<br>
_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a></blockquote></div></div>