diff options
author | Lennart Poettering <lennart@poettering.net> | 2016-06-23 23:24:38 +0200 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2016-06-23 23:24:38 +0200 |
commit | d001e0a3afb4c31486870e36e0c3a4bfcde20f0d (patch) | |
tree | 3cd8acea0e41e642cf7d4c7e9ba9ae03c3044504 /system-preset | |
parent | de2edc008a612e152f0690d5063d53001c4e13ff (diff) |
resolved: rework SERVFAIL handling
There might be two reasons why we get a SERVFAIL response from our selected DNS
server: because this DNS server itself is bad, or because the DNS server
actually serving the zone upstream is bad. So far we immediately downgraded our
server feature level when getting SERVFAIL, under the assumption that the first
case is the only possible case. However, this meant we'd downgrade immediately
even if we encountered the second case described above.
With this commit handling of SERVFAIL is reworked. As soon as we get a SERVFAIL
on a transaction we retry the transaction with a lower feature level, without
changing the feature level tracked for the DNS server itself. If that fails
too, we downgrade further, and so on. If during this downgrading the SERVFAIL
goes away we assume that the DNS server we are talking to is bad, but the zone
is fine and propagate the detected feature level to the information we track
about the DNS server. Should the SERVFAIL not go away this way we let the
transaction fail and accept the SERVFAIL.
Diffstat (limited to 'system-preset')
0 files changed, 0 insertions, 0 deletions