Ronan Pigott
abcc94b351
The name resolver.arpa is reserved for RFC9462 "Discovery of Designated Resolvers" (DDR). This relies on regular dns queries for SVCB records at the special use domain name _dns.resolver.arpa. Unfortunately, older nameservers (or broken ones) won't know about this SUDN and will likely return NXDOMAIN. If this is cached, the cache entry will become an impediment for any clients trying to discover designated resolvers through the stub-resolver, or potentially even sd-resolved itself, were it to implement DDR. The RFC recommendation is that "clients MUST NOT perform A or AAAA queries for resolver.arpa", and "resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa. with NODATA and queries of any type for any domain name under resolver.arpa with NODATA." which should help avoid potential compatibility issues. This enforces that condition within sd-resolved, and avoids caching any such erroneous NXDOMAIN. The RFC also recommends requests for this domain should never be forwarded, to prevent authentication failures. Since there isn't much point in establishing secure communication to the local stub, we still allow SVCB to be forwarded from the stub, in case the client cares to implement some other authentication method and understands the consequences of skipping the local stub. Normal clients are not expected to implement DDR, but this change will protect sd-resolved's own caches in case they try. Although A and AAAA are prohibited, I think validating resolvers might reasonably query for dnssec records, even though the resolver.arpa zone does not exist (it is declared to be a locally served zone). For this reason, I have also added resolver.arpa to the builtin dnssec NTA.
System and Service Manager
Details
Most documentation is available on systemd's web site.
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.