[DNSOP] Re: A question regarding DNSSEC validation

[Shumon Huque <[e-mail]>]

On Fri, Apr 17, 2026 at 1:16 PM Libor Peltan <libor.peltan=
[e-mail]> wrote:

> First of all, I think this mailing-list is not an optimal channel to ask
> such quetsions.
>
I think this is a reasonable channel for this discussion.

The DNS protocol specs do not in my view adequately describe robust retry
and failover, and I think they should. From time to time I encounter
resolvers that do not do this properly and lead to availability issues,
such as failing immediately on an unvalidatable DNSSEC response from a
single nameserver for the zone and causing an outage for the application
involved. We often have to spend a bunch of time tracking down what is
broken in the customer's resolver infrastructure - sometimes it is the DNS
resolver implementation, and more infrequently it is some security
appliance in their local network that interfered with the DNS resolver's
ability to retry. If we can identify the resolver service or
implementation, we generally have success instructing the customer to stop
using it, but this again takes effort.

It would be nice if I could concretely point people to a specification
document that says how to do this correctly.

But I feel a need to slightly correct Ben: in most cases, if a resolver
> receives a DNSSEC response that fails to validate (so called BOGUS) for any
> reason (e.g. missing or invalid RRSIG), it tries to query another
> authoritative nameserver for that zone. Only after all are tried and all
> are BOGUS or unreachable (or erroneous in other ways), the resolver will
> conclude SERVFAIL to the client. Of course there are many exceptions when
> the described is not entirely true. But I guess no sane resolver would
> re-try querying the same authoritative nameserver after a while.
>

Yes, I agree. By and large, I think most of the open source resolvers
(Unbound, BIND, Knot) do this correctly.

I agree with Philip's later comments on the thread that "attacks" that
attempt to falsify responses appear to be relatively rare (though how can
we know for sure, because they are often very targeted). But attacks are
not the only reason resolvers need robust retry and failover behavior. DNS
server infrastructure deployed in the field very frequently has broken
servers or other components. I've lost track of how many times I've seen a
subset of name servers for a zone giving out some form of bad responses
(bad signatures, missing signatures, expired signatures, error response
codes, etc), and DNS resolvers should be able to deal with this reality.

In draft-zhang-dnsop-ns-selection (now expired) we attempted to address
this topic with the following text:

5.5  Proper Retry and Failover

   To avoid leading to another issue: lack of availability and
   robustness, we re-emphasize here the importance of appropriate
   retries and failovers. All DNS resolvers should automatically retry
   and failover to other nameservers for a DNS zone when they encounter
   a nameserver that is unresponsive or providing an erroneous response.
   Not only must resolvers have a robust retry and failover algorithm,
   but no middlebox or network appliance interposed in the local traffic
path
   of resolvers should interfere with their ability to perform retry and
   failover.  Experience has shown that there is a small percentage of
   deployed DNS resolvers in the field that do not robustly failover to
   alternate name servers leading to availability issues.  Importantly,
   the retry and failover mechanism needs to be balanced with the
   requirement to bound the resolver's work (R4).

   A proper retry and failover design also makes resolvers robust
   against attacks where an adversary is attempting interfere with DNS
   responses from authoritative servers in an attempt to cause an outage
   (e.g. by blocking responses), or in an attempt to redirect clients
   (e.g. by modifying responses that could be detected with DNSSEC
   validation).  As long as the attacker is not able inject these
   attacks along the traffic path to all or most of the authoritative
   servers for a zone, a resolver with robust retry and failover
   behavior should be able to successfully resolve names within that
   zone.

   Some of the specific conditions under which a DNS resolver should
   retry other nameservers for a zone include an unresponsive
   name server, a nameserver giving an erroneous response (any response
   code other than NOERROR or NXDOMAIN), a nameserver giving responses
   that cannot be authenticated, such as responses with missing DNSSEC
   signatures when they were expected to be signed, responses with bogus
   or expired signatures, etc.

I look forward to feedback on this text.

Shumon.