BIND 9.20.22 – Recurring SERVFAIL on Internal Recursive Resolvers

[Amir Sarbaz Ahmed]

Hello everyone,

We're experiencing a recurring DNS resolution issue with *ISC BIND 9.20.22*
and would appreciate some guidance.

We operate a split-horizon DNS environment, with separate internal and
public-facing DNS services. Our internal resolvers use BIND views and
perform recursive resolution for external domains through the standard
root-hints mechanism, without general-purpose DNS forwarding.

Interestingly, our public-facing DNS servers run the same BIND version but
have not exhibited the same behavior.
Issue Description

For several months, we've been experiencing intermittent SERVFAIL responses
for certain external domains, most noticeably yahoo.com and kaspersky.com.

The affected domains generally receive relatively low query volumes,
although we're unsure whether that is relevant.

Resolution initially works as expected, but after some time, certain
domains begin consistently returning SERVFAIL. Executing:

rndc flush

immediately restores normal resolution. Unfortunately, the issue returns
after approximately 24–48 hours, sometimes sooner.

We've been relying on periodic cache flushing as a temporary workaround,
but we'd like to understand what causes this behavior and resolve it
permanently.
Troubleshooting Findings

We've performed several tests while the issue was occurring:

   -

   *Direct authoritative queries:* Queries to the affected domains'
   authoritative nameservers succeed over UDP and TCP, including tests without
   EDNS.
   -

   *Iterative resolution:* Root and TLD nameservers respond correctly and
   provide the expected delegations.
   -

   *Recursive resolution:* Queries through the affected BIND resolvers
   return SERVFAIL, frequently accompanied by EDE: 22 (No Reachable
   Authority).
   -

   *DNSSEC:* Repeating the queries with +cdflag does not resolve the issue,
   suggesting DNSSEC validation is unlikely to be the primary cause.
   -

   *Packet captures:* We've confirmed successful communication with at
   least some of the affected authoritative nameservers.

We've also noticed the following messages in the BIND logs:

recursion loop detected
query failed (failure)
fetch completed: timed out

Additionally, inspecting BIND's Address Database (ADB) revealed that
multiple authoritative nameserver addresses associated with the affected
domains had SRTT values of:

srtt 9000000

These entries also showed significant EDNS timeout counts, despite the
authoritative servers being reachable through direct queries.

This makes us suspect that BIND may be retaining unfavorable
authoritative-server reachability information or encountering an issue with
resolver state over time. However, we have not yet confirmed that this is
the underlying cause.
Questions

We're particularly interested in understanding:

   1.

   Could this behavior be related to how BIND maintains authoritative
   nameserver reachability information in its ADB?
   2.

   Are there any known issues with BIND 9.20.22 that could cause otherwise
   reachable authoritative nameservers to be treated as unavailable?
   3.

   Why would flushing the cache temporarily restore resolution if the
   authoritative nameservers themselves remain accessible?
   4.

   What additional debugging or diagnostic methods would you recommend to
   identify the root cause without clearing the affected resolver state?

We're aware that newer maintenance releases are available and are
considering upgrading. However, given the recurring nature of this issue,
we'd also like to understand whether it originates from BIND's resolver
behavior, our environment, or something else.

We would appreciate any suggestions or insights from the community.

Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20261027/782594e4/attachment.htm>