I’ve seen cases where name servers are configured to selectively
timeout queries. In one case, multiple zones were delegated to the
same set of authoritative name servers where the name servers were
configured to permanently timeout queries for one zone and respond
to queries for the other zones. It seems that the timeouts for the
zone configured to timeout caused unbound to stop providing answers
and respond with SERVFAIL for the other zones because all of the name
servers were in the blocking regime. In another case, the authoritative
name servers would permanently timeout queries for non-existent records
in a zone and respond to queries for records that do exist in the
same zone. Again, all of the name servers ended up in the blocking
regime. For these cases, is there any setting that would allow unbound
to continue trying the name servers for the zones and/or records
where the name servers do respond ?
In one case, multiple zones were delegated to the
same set of authoritative name servers where the name servers were
configured to permanently timeout queries for one zone and respond
to queries for the other zones. It seems that the timeouts for the
zone configured to timeout caused unbound to stop providing answers
and respond with SERVFAIL for the other zones because all of the name
servers were in the blocking regime.
This is correct, unbound detected a server is not available and therefore reduces the number of queries to the server to avoid overloading it.
This behaviour solves the unfortunate problem that when you are a victim of a real DDoS attack your legitimate traffic will often tend to retry too such that without an exponential back-off in place or some other mechanism to slow down and randomize the incoming requests, when the DDoS ends the real backlogged requests will slam the server and effectively extend the outage.
In another case, the authoritative
name servers would permanently timeout queries for non-existent records
in a zone and respond to queries for records that do exist in the
same zone.
Yup, they really need to fix their authoritative DNS, if they intend on running authoritative DNS. Frankly, it sounds like maybe they don't have the technical understanding to do so.