On Fri, Mar 25, 2016 at 12:49 PM John Wobus <jw...@cornell.edu> wrote:
> On Mar 18, 2016, at 6:28 AM, Barry Margolin <bar...@alum.mit.edu> wrote:
> > In article <mailman.384.1458255932.73610.bind-us...@lists.isc.org>,
> > Mark Andrews <ma...@isc.org> wrote:
> >
> >> How do you actually expect this to ever work in real life?
> >
> > I'm pretty sure Google DNS does this. Other resolver operators often get
> > complaints about "Why can't I look up <whatever> through your DNS
> > servers when I can do it through Google DNS?"
>
> I’d guessed Google just re-queries before it needs to, which has benefits
> but
> requires a more complex “clean out very-seldom-used records” strategy.
I’d imagine they'd use a somewhat-random amount of time to pre-query
> as one of their measures against cache poisoning.
>
A few years back a number of us wrote draft-wkumari-dnsop-hammer ("Highly
Automated Method for Maintaining Expiring Records").
My motivations for working on this were:
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).
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 *
HAMMER_TIME then the cache entry should be marked with a "Can't touch
this" flag, and the described method should not be used."
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.
W
>
> This would be a good nameserver feature, e.g. when a response is given
> from the cache, a secret (shorter) ttl is adjusted to help assure
> continuity.
> Or other variants. Such a feature might address Ron’s concern.
> (I believe I recall discussions on this or another list, perhaps even
> a feature in the wings.)
>
> In any case, I cringe at the thought of overriding TTLs. They’re there
> for a reason. In some instances, overriding could “help”, but in others,
> it
> would be really, really bad.
> John Wobus
> Cornell University IT
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
