StaleRetentionSec= is a resilience feature for unicast DNS: when the configured servers are unreachable, answering from an expired cache entry beats answering nothing at all. That rationale does not carry over to the link-local protocols, where there is no configured server that could be unreachable -- peers simply come and go, and a record's TTL is the only thing bounding how long a departed peer is still answered for. For mDNS the mismatch goes further. RFC 6762 treats record expiry as a presence signal -- a host or service whose records lapse is to be considered gone (section 10.1 goodbye packets even force this early by publishing TTL=0), and the section 5.2 cache maintenance scheme exists precisely so that expiry happens on time. Retaining expired mDNS records for StaleRetentionSec= contradicts that: vanished peers linger in the cache for the whole retention window, are served to clients as if still present, and DNS-SD browsers do not see their services disappear when the records' TTL lapses. Beyond lingering entries, retention also swallows goodbyes outright, as noted in review of the goodbye re-arm fix [1]: dns_cache_prune() and dns_cache_expiry_in_one_second() key on the retention-extended "until", so with StaleRetentionSec= set a goodbye's TTL=1 rewrite lands a full retention window out -- the one-second prune of RFC 6762 section 10.1 then drops nothing, nothing re-arms, and the withdrawn service stays listed for the whole window. LLMNR has no goodbye mechanism, so only the lingering half applies to it, but it does apply: dns_transaction_cache_answer() passes the retention through for LLMNR replies just like for unicast DNS, and the stale-serving gate in the transaction code does not look at the protocol, so a departed LLMNR peer keeps being answered from cache for the whole window as well. Zero the retention centrally in dns_cache_put() for everything but unicast DNS, which covers both put paths: transaction replies and the mDNS packets cached directly by on_mdns_packet(). Add tests pinning both directions, including the goodbye rewrite of an existing mDNS entry. [1] https://github.com/systemd/systemd/pull/43259#discussion_r3809488076
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
