In article <mailman.481.1459014144.73610.bind-us...@lists.isc.org>, Ron <ron.a...@gmail.com> wrote:
> 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. And only useful for names you know ahead of time that you're going to need. -- 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