mirror of
https://github.com/systemd/systemd-stable.git
synced 2025-02-28 17:57:25 +03:00
201d99584e
Some domains (such as us.ynuf.alipay.com) almost appear as if they actively want to sabotage our DNSSEC work. Specifically, they unconditionally return SERVFAIL on SOA lookups and always only after a 1s delay (at least). This is pretty bad for our validation logic, as we use SOA lookups to distuingish zones from non-terminal names. Moreover, SERVFAIL is an error that is typically returned if we send requests a server doesn't grok, and thus is reason for us to downgrade our protocol and try again. In case of these zones this means we'll accept the SERVFAIL response only after a full iterative downgrade to our lowest feature level: TCP. In combination with the 1s delays this has the effect of making us hit our transaction timeout way to easily. As first attempt to improve the situation: let's start caching SERVFAIL responses in our cache, after the full downgrade for a short period of time. Conceptually this is exposed as "weird rcode" caching, but for now we only consider SERVFAIL a "weird rcode" worthy of caching. Later on we might want to add more.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the HACKING file for information 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 or join our IRC channel.