New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
systemd-resolved: "DNSSEC=allow-downgrade" still fails #32570
Comments
I have edited the issue above since I have since upgraded my kernel to a new version and installed systemd 255.5-3 from Arch Linux's official repositories. The bug still persists. |
Could you share a sd-resolved debug log? |
How do I do that? What exactly is an sd-resolved debug log? Is it in any way different from the log messages of systemd-resolved that one finds in journalctl? |
|
I seem to be encountering the same issue, at least on my home network (with an ISP-provided router). My workaround thus far has been to switch to Cloudflare's DNS, via Debug log
|
Okay, hopefully this is what was meant by an sd-resolved debug log. I have attached to this comment my logs for systemd-resolved in various formats (with DNS server IP addresses redacted) after setting "DNSSEC=allow-downgrade" in "[Resolve]", running |
Ok, seems like sd-resolved isn't succesfully downgrading these servers that don't support dnssec. I'll look into it. |
Yeah, the downgrading part of allow-downgrade was kinda broken. If you are able, please try #32598. |
About to try backporting #32598 into Arch's package and building it. Will report on my findings. |
I backported it into Arch Linux's systemd package and it seems to have fixed the bug, assuming I did things correctly. The way I did it was by modifying the Arch package's PKGBUILD file to patch the commit from pull request #32598 into the systemd source code that makepkg downloads before building systemd. I have attached a zip archive of my files for the Arch package. The patch to apply the commit from pull request #32598 is in the file resolve.patch. To build the Arch package, you may need to run makepkg with the "--skippgpcheck" option. For the sake of completeness, I have also attached a debug log for sd-resolved in various formats. Any other Arch users, and any other users of systemd 255.5 in general, please confirm my findings. |
Good to hear, thanks for testing it. |
systemd version the issue has been seen with
255.5-3
Used distribution
Arch Linux
Linux kernel version used
6.8.8-arch1-1
CPU architectures issue was seen on
x86_64
Component
systemd-resolved
Expected behaviour you didn't see
This bug report is a repeat of issue #32561, issue #32531, and (I think) also issue #32546. As I understand it, commit d840783 (the associated pull request is #32552) was intended to fix the bug identified by those issues. Arch Linux has backported that fix into its package for systemd 255.5, which, on Arch Linux, is identified by the version 255.5-3. Naturally, I expected the bug to have been fixed.
Unexpected behaviour you saw
Despite commit d840783 / pull request #32552, the bug persists.
Steps to reproduce the problem
I do not know much about networking, so I apologize if I use widely incorrect terminology here or if these steps are wrong.
In case it matters, I use NetworkManager with wpa_supplicant for my WiFi.
Additional program output to the terminal or log subsystem illustrating the issue
I have attached my logs for systemd-resolved in different formats for your convenience. Do notify me if you would like me to provide any additional log files or information.
json-pretty.log
short-full.log
verbose.log
The text was updated successfully, but these errors were encountered: