resolved: never go below DNSSEC feature level in DNSSEC strict mode
authorLennart Poettering <lennart@poettering.net>
Thu, 12 Nov 2020 15:05:15 +0000 (16:05 +0100)
committerLennart Poettering <lennart@poettering.net>
Tue, 16 Feb 2021 17:44:01 +0000 (18:44 +0100)
commitfba3e94df552b4fb6dd53b5e605259be42a27f4e
tree6929b1844273bea8c7941f3790d484ccb7e0bac7
parentd8592a4e2ff31610b3029a3067c8207a124f284a
resolved: never go below DNSSEC feature level in DNSSEC strict mode

This adjusts our feature level handling: when DNSSEC strict mode is on,
let's never lower the feature level below the lowest DNSSEC mode.

Also, when asking whether DNSSEC is supproted, always say yes in strict
mode. This means that error reporting about transactions that fail
because of missing DNSSEC RRs will not report "incompatible-server" but
instead "missing-signature" or suchlike.

The main difference here is that DNSSEC failures become local to a
transaction, instead of propagating into the feature level we reuse for
future transactions. This is beneficial with routers that implement
"mostly a DNS proxy", i.e. that propagate most DNS requests 1:1 to their
upstream servers, but synthesize local answers for a select few domains.
For example, AVM Fritz!Boxes operate that way: they proxy most traffic
1:1 upstream in an DNSSEC-compatible fashion, but synthesize the
"fritz.box" locally, so that it can be used to configure the router.
This local domain cannot be DNSSEC verified, it comes without
signatures. Previously this would mean once that domain was resolved
feature level would be downgraded, and we'd thus fail all future DNSSEC
attempts. With this change, the immediate lookup for "fritz.box" will
fail validation, but for all other unrelated future ones that comes
without prejudice.

(While we are at it, also make a couple of other downgrade paths a bit
tighter.)

Fixes: #10570 #14435 #6490
src/resolve/resolved-dns-server.c
src/resolve/resolved-dns-server.h