Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

Ron ron.arts at
Sat Mar 26 17:41:59 UTC 2016


On Sat, Mar 26, 2016 at 3:13 AM, Barry Margolin <barmar at> wrote:
> In article <mailman.464.1458924548.73610.bind-users at>,
>  John Wobus <jw354 at> wrote:
>> On Mar 18, 2016, at 6:28 AM, Barry Margolin <barmar at> wrote:
>> > In article <mailman.384.1458255932.73610.bind-users at>,
>> > Mark Andrews <marka at> 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..


> --
> Barry Margolin
> Arlington, MA
> _______________________________________________
> Please visit to unsubscribe from this list
> bind-users mailing list
> bind-users at

More information about the bind-users mailing list