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

[Ron]

On Thu, Mar 17, 2016 at 2:51 PM, Barry S. Finkel <bsfinkel at att.net> wrote:

> On 3/17/2016  12:36:31 +0100 Ron<ron.arts at gmail.com> wrote:
>
> Can bind be configured to not drop RR's from the cache when
>>> the upstream DNS server is unresponsive?
>>>
>>
> Hi,
>>
>> subject says all. Read manpages, could not find this in the FAQ's.
>> Hope this is possible. If not does anyone know of other name servers
>> that offer this option?
>>
>> Thanks,
>> Ron Arts
>>
>
> It seems to me that one task of the BIND process is periodically
> to scan the cache to find entries whose TTL has expired.  That
> process, per the DNS RFCs, will remove all entries whose TTL has
> expired.  The process should not check to ensure that at least
> one of the upstream DNS servers is responsive, as by definition
> the record has expired and should not remain in DNS.  It is the
> owner of the record who sets the TTL, and if the TTL is too short
> AND all of the DNS servers that serve that record are inaccessible,
> then the owner of the record has a problem.
>
> --Barry Finkel
>

According to the BIND9 docs:

cleaning-interval This interval is effectively obsolete. Previously, the
server would remove expired resource records from the cache every
cleaning-interval minutes. BIND 9 now manages cache memory in a more
sophisticated manner and does not rely on the periodic cleaning any more.
Specifying this option therefore has no effect on the server’s behavior.

 But you might still be right that my question goes against the principle
of caching.

-- Ron


> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160317/041083d5/attachment.html>