Skip Menu |
Report information
The Basics
Id: 46650
Status: new
Priority: 0/
Queue: bind9-public

People
Owner: Nobody in particular
Requestors: Brian Conry <bconry@isc.org>
Cc:
AdminCc: support-comment <support-comment@isc.org>

Bug Information
Version Fixed: (no value)
Version Found: (no value)
Versions Affected: (no value)
Versions Planned: (no value)
Priority: (no value)
Severity: (no value)
CVSS Score: (no value)
CVE ID: (no value)
Component: (no value)
Area: feature

Dates
Created:Tue, 21 Nov 2017 17:52:04 +0000
Updated:Wed, 23 Oct 2019 10:29:36 +0000
Closed:Not set



Date: Tue, 21 Nov 2017 17:52:04 +0000
Subject: options/configuration to exempt queries/records from serve-stale?
To: bind9-public@isc.org
From: bconry@isc.org
Download (untitled) / with headers
text/plain 1.3KiB
While being generally useful in preserving user functionality as much as possible during certain types of DNS-impacting events, the automatic serving of stale records complicates the task of properly monitoring resolvers. Specifically, it is common to have a name with a very short TTL that is used only for health checks designed to verify that a resolver is capable of performing recursion and getting responses. With serve stale getting an answer to these queries no longer accomplishes that purpose. In some circumstances, such as when the TTL used for stale records is larger than the original TTL on the records, it may be possible to infer that the record is stale by looking at the details of the packet, but this is not a particularly robust solution. Further, there are some appliances that perform health checks (among other features) and they cannot be taught to make decisions based on the TTL of the received response. Therefore it seems that it would be desirable for an operator to be able to configure the resolver to either exempt certain records (by name) from being served stale, or to exempt certain clients (by ACL) from receiving stale responses. Views are not a complete solution to this because there are several types of resources and data stores (notably the ADB) that are never shared between views that may affect whether or not the resolver for a view can perform iteration.