Barry, On Sat, Mar 26, 2016 at 3:13 AM, Barry Margolin <bar...@alum.mit.edu> wrote: > In article <mailman.464.1458924548.73610.bind-us...@lists.isc.org>, > 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. > > When I was at Akamai we called this "prefresh". > > But it doesn't help much if the auth server doesn't respond, the record > will still expire. >> >> 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. > > The main purpose of TTLs is to ensure that when the record is changed, > the new value replaces the obsolete value within the specified window. > But if the server isn't responding, clients aren't going to get the new > value anyway. Which is more useful for end users, returning the old > record past its TTL, or reporting an error saying that the name doesn't > exist? >
I think this touches on the heart of the matter. We have implemented an ansible-driven emergency plan, where we put entries in /etc/hosts files whenever a situation like this happens. Not an ideal solution. > A secondary value of TTLs is that they'll keep the cache from filling up > with names from domains that have been abandoned completely. That's why > I suggested that there should be a cap on how long it should keep > returning these old, cached records. An extra day should be plenty of > time for the server operator to fix their problem. > I would like that to be configurable... 'plenty' is relative.. Ron > -- > Barry Margolin > Arlington, MA > > _______________________________________________ > 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
