Axel RasmussenandManuel
fdffa2a8f6
A server's feature level can drop below DO without the server being marked as DNSSEC-incapable, e.g. after packet loss before any level was verified, or when a retry at a reduced level made a SERVFAIL go away. dns_transaction_dnssec_supported() only looked at the server's capabilities, so every unsigned reply was still validated, and failed for every name in a signed zone with DNSSEC_NO_SIGNATURE, even in allow-downgrade mode. Nothing marks the server either, since dns_server_packet_rrsig_missing() ignores replies received below DO, hence only a restart or "resolvectl reset-server-features" helped. Check the transaction's own feature level too: a query sent without DO cannot get RRSIGs back, so treat the reply like one from a server without DNSSEC, which allow-downgrade mode accepts as unsigned. Strict mode keeps validating it as before, since unsigned data is only an error there if it needed signing. Don't log the DNSSEC downgrade notice for this, the server may well support DNSSEC, and ignore answers that did not come from the network, whose feature level is stale. Bypass transactions forward the client's packet as is, so look at the client's DO bit for them instead. Don't cache replies that could not be validated merely for lack of DO, e.g. replies to bypass queries without DO or to queries sent while the server was degraded, as later lookups may send DO and validate them. A retry after a timeout reuses the transaction ID and connection, so use new ones if the feature level changed meanwhile, lest a late reply to an earlier attempt with a different DO bit pass for a reply to the retry. Fixes #36681 Co-authored-by: Manuel <16595697+kaeferfreund@users.noreply.github.com>
System and Service Manager
Details
Most documentation is available on systemd's website.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release