No DNS with DNSSEC=yes
#8451
Labels
dnssec
needs-reporter-feedback ❓
There's an unanswered question, the reporter needs to answer
resolve
Comments
|
Oh, and the DNS server works, when queried directory, so no idea, what problem systemd-resolved has. |
|
To me it sounds a little bit like issue #7040 is still not fixed. |
|
After restarting systemd-resolved (to enable debugging), the issues is gone for now. |
|
With debug enabled, the messages below are show right before the failed look up. |
|
(Talking about the same failure event as my colleague Paul) [ EDIT: Not necessarily herokussl.com to blame for the bad dns replies, it looks like some "Intrusion Prevention System" messed with it ] I think the problem is, that systemd-resolved blames/downgrades the configured forwarding server (here: 141.14.16.1) for failures of third-party servers. It looks like some servers of herokussl.com were seriously broken and return invalid answers (swapping TYPE and CLASS). I've seen this directly from these servers but only have a typescript of such a reply from the cache of a Google server: In our systemd-resolved log you see, that 141.14.16.1 is 'downgraded' as a result of failures to resolve these specific names. Lines from the log which I think are relevant to this issue with some blank lines added for visibility: Additionally (minor), the forwarding server lost the "LARGE" feature before due to failures of the third-party servers. Maybe the timeouts are incompatible, because the forwarder is returning the first "SERVFAIL" after 10 seconds, when systemd-resolved has taken action long before. Maybe the external servers do answer, but with bogus data which is not forwarded: |
|
Hmm, @paulmenzel and @buczek you are using the same DNS server? So it appears your DNS servers are flaky, and can't do DNSSEC reliably, hence the behaviour you are seeing is expected, no? |
poettering
added
the
needs-reporter-feedback
|
Yes, we are using the same DNS server. We are talking about the same failure on the same system. The configured nameserver 141.14.16.1 is assumed to be stable by itself. However, as 141.14.16.1 has to query external servers, an individual query might take long. In the logs above you see 141.14.16.1 return a SERVFAIL after 10 seconds, because of some external nameserver failure (while at the same time promptly replying to other queries, which were omitted from the quoted log). I suspect, that because of the delay, it was "downgraded" by systemd-resolved, maybe up the point when it was no longer considered for DNSSEC and all further name resolutions failed. |
|
Related to #7974 ( 10s timeout of the bind server ). |
|
@bubeck I agree. |
|
@bubeck @paulmenzel I provided a patch that addressed #7974 and it was integrated into v239. Perhaps this version lessens the problem for you. |
|
Sorry for not replying for so long. We are on v242 now and the general problem is still there. I've delegated a zone to a non-answering ip-address. Our configuration for systemd-resolved includes "FallbackDNS=141.14.16.1" and "DNSSEC=yes". Querying for a name in the invalid zone will downgrade 141.14.16.1 , although this server behaves perfectly well and replies with SERVFAIL after the usual 10 second timeout. now everything repeats for the SOA query... |
|
This bug could partially be caused by the mixed cache bug. success when using: failure using: |
|
@letoams: Thanks. But the problem you describe can't be reproduced on our site: |
|
On Mon, 2 Nov 2020, molgen-edv wrote:
@letoams: Thanks. But the problem you describe can't be reproduced on our site:
Ahh, perhaps this only breaks when DNSSEC=no (the fedora 33 default)
Paul
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Submission type
systemd version the issue has been seen with
Used distribution
In case of bug report: Unexpected behaviour you saw
In case of bug report: Steps to reproduce the problem
The text was updated successfully, but these errors were encountered: