summaryrefslogtreecommitdiff
path: root/src/resolve/test-dns-packet.c
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2016-06-23 23:24:38 +0200
committerLennart Poettering <lennart@poettering.net>2016-06-23 23:24:38 +0200
commitd001e0a3afb4c31486870e36e0c3a4bfcde20f0d (patch)
tree3cd8acea0e41e642cf7d4c7e9ba9ae03c3044504 /src/resolve/test-dns-packet.c
parentde2edc008a612e152f0690d5063d53001c4e13ff (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 'src/resolve/test-dns-packet.c')
0 files changed, 0 insertions, 0 deletions