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.