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

[Barry Margolin]

In article <mailman.464.1458924548.73610.bind-users at lists.isc.org>,
 John Wobus <jw354 at cornell.edu> wrote:

> On Mar 18, 2016, at 6:28 AM, Barry Margolin <barmar at alum.mit.edu> wrote:
> > In article <mailman.384.1458255932.73610.bind-users at lists.isc.org>,
> > Mark Andrews <marka at 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?

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.

-- 
Barry Margolin
Arlington, MA