Christian Glombek
f9185464bb
Serving stale cache data on a retry is a resilience feature for unicast DNS: when the configured server does not respond, an expired answer beats no answer. The gate in dns_transaction_go() that switches the cache lookup into serve-stale mode from the second attempt on only checks StaleRetentionSec=, not the scope's protocol, so it applies to mDNS and LLMNR scopes as well. There it is wrong twice over: * With StaleRetentionSec= set, a query for a peer that has left the network misses the cache on the first attempt (the record's TTL has expired), gets no reply, and is then answered from the expired but retained record on the retry — for as long as the retention window lasts. On the link-local protocols a retry means that no peer answered, not that some server is unreachable, and RFC 6762 treats TTL expiry as a presence signal: a host whose records lapse is gone. * Independently of whether anything stale is cached, a cache hit made in serve-stale mode is reported with its TTL clamped to 30s (see dns_cache_lookup()) and counted in the served-stale statistics. mDNS transactions are retried at 1s, 2s, 4s, ... whenever nobody answers, so a record announced or learnt from another transaction in between is handed to the client with a 30s TTL instead of its real remaining TTL, and logged as a "Serve Stale response" although it never was stale. Hence only enter serve-stale mode on unicast DNS scopes. This is the lookup-side counterpart of the cache-side change that stops link-local records from being retained past their TTL at all.
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