[DNSOP] Re: A question regarding DNSSEC validation

[Cathy Zhang <[e-mail]>]

Hi Edward,


Thank you very much for your detailed and insightful answer. This is precisely why I raised this question.


If the resolver does not continue waiting, even though a forged response would mostly be discarded due to validation failure, it could still effectively prevent the legitimate response from being accepted and processed. In other words, although cache poisoning is unsuccessful, the resolver would no longer handle valid responses from the correct authoritative servers.


It seems that querying all available authoritative servers can mitigate the impact of forged responses that arrive earlier, unless queries sent to every authoritative server are all preempted by forged replies.


Ignoring such invalid responses and continuing to wait for valid ones until timeout appears to be a better design. It seems that, except for replay attacks involving negative responses, missing or invalid signatures would not prevent the resolver from processing correct responses.


I would greatly appreciate your insight on whether DNS implementations such as BIND, Unbound, and PowerDNS actually adopt this kind of behavior.


BR,
Cathy











在 2026-04-20 09:19:57，"Edward Lewis" <[e-mail]> 写道：

On Apr 17, 2026, at 13:15, 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 don’t see why not...


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.

I’d treat a response that fails validation as a non-response (“it didn’t happen”).  After issuing a query, wait until a valid response is received or the timeout is reached.  If the timeout is reached, act like nothing ever arrived.


In the original DNSSEC problem statement, a concern was that a query would be issued and an adversary could forge and send a response quickly enough to beat the true response.  An adversary could anticipate the query or see the query (if on path) and get a head start, nevertheless, the query could (also) get to the intended source.  The intended source could still answer, it’d be a shame to have given up because of the forged response.


It’d be forgivable (in that the code is simpler) to kill the query upon receiving the bad response, but to be more resilient, wait until the timeout for a potential good (validated) response.


Ed Lewis