Description of problem: Because default value for DNSSEC is still no, even improvement Version-Release number of selected component (if applicable): systemd-248~rc4-4.fc35.x86_64 How reproducible: always Steps to Reproduce: 1. for NS in $(resolvectl | grep 'DNS Servers:' | cut -d: -f2-); do dig +dnssec @$NS | grep -i RRSIG; done # Ensure upstream forwarders are able to process DNSSEC 2. Ensure DNSSEC in /etc/sytemd/resolved.conf is commented out, at default value 3. dig +dnssec @127.0.0.53 | grep -i RRSIG Actual results: # for NS in $(resolvectl | grep 'DNS Servers:' | cut -d: -f2-); do dig +dnssec @$NS | grep -i RRSIG; done . 43298 IN RRSIG NS 8 0 518400 20210412050000 20210330040000 42351 . AtIn+4etW9M7KKvpaCmY4J8CPb2Xq5rOEadJ1EX3xnRH6qNWYLsIf4uT ycDTS2Pnp7VhRM+SAveXq6eDWlbWZzDk4+TI2laJMjpXF5/N2PlETU0E rGSWAAGjbjqDfdyNw8/QZr0Y5hiJ+xchtR4whqmtek5GeiU28t+BKmEI fsPKAv1+AbRS36ct+9AYxsjQYD6oYI7HoA82PoieGkHT/W7jstyBPL// tGyDpiM3FiNdFU3NtXtg42jLNSzwG7VXMOIDxBrFjoUxYQhpMRA0uFOV iPAus2+uK6pIH7lwKrUHCAhZmyUebwcC89I/pum9hB887HENQLmbTHdl 0N88Ew== # dig +dnssec @127.0.0.53 | grep -i RRSIG Expected results: # dig +dnssec @127.0.0.53 | grep -i RRSIG . 43298 IN RRSIG NS 8 0 518400 20210412050000 20210330040000 42351 . AtIn+4etW9M7KKvpaCmY4J8CPb2Xq5rOEadJ1EX3xnRH6qNWYLsIf4uT ycDTS2Pnp7VhRM+SAveXq6eDWlbWZzDk4+TI2laJMjpXF5/N2PlETU0E rGSWAAGjbjqDfdyNw8/QZr0Y5hiJ+xchtR4whqmtek5GeiU28t+BKmEI fsPKAv1+AbRS36ct+9AYxsjQYD6oYI7HoA82PoieGkHT/W7jstyBPL// tGyDpiM3FiNdFU3NtXtg42jLNSzwG7VXMOIDxBrFjoUxYQhpMRA0uFOV iPAus2+uK6pIH7lwKrUHCAhZmyUebwcC89I/pum9hB887HENQLmbTHdl 0N88Ew== Additional info: Fixing DNSSEC fallback would be better. Fedora 32 had it fully working without any manual tuning. It would be nice if it were enabled by default if network infrastructure allows it. This was broken by Fedora 33, where systemd-resolved were first enabled by default. It is still broken in Fedora 34, unless DNSSEC=yes is configured. I don't think validation status should affect DNSSEC responses available to local clients, if they are able to validate themselves (like delv does). Ensure non-DNSSEC cached record does not return if DNSSEC were requested. Unless current DNS server is not able to provide DNSSEC response, of course. Command sequence: dig fedoraproject.org dig +dnssec fedoraproject.org should return RRSIG for the second command, even if the first requested non-DNSSEC query.
... even improvement in DNSSEC=yes state(bug #1879028) is not enabled automatically for every user. Configuration changes are required for working state, which was default in Fedora 32. Got carried away from finishing description by Steps to Reproduce.
Upstream report?
I am not sure it is directly related to upstream, because change to DNSSEC=no is done downstream. It would work somehow with DNSSEC=allow-downgrade AFAIK. But attaching feature request on upstream anyway, it might be improved that way regardless any default used on Fedora.
We are definitely not changing DNSSEC=no in Fedora anytime soon. (Check back in 2030 maybe.) So if you want this working by default in Fedora without requiring modifications to /etc/systemd/resolved.conf, then it needs to happen even with DNSSEC=no. (I don't have a strong opinion on whether or not this should happen.) (Of course, Fedora downstreams could use a different default value for the DNSSEC= setting if desired.)
Is it documented, why DNSSEC=no is required in Fedora? Specific tickets or use cases? Specific broken implementations that cannot handle DNSSEC=allow-downgrade? Is it documented in a specific bug I can link to?
I found just notes on https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC, which is only a little specific. Not a bug report usable to fix current state or verify it improved recently. One just mentions fritz.box name breakage, which can be just fixed by simple NTA. Can we create blocker bug, which would evaluate requirement for turned off validation on Fedora by default? With a links to upstream issues for evaluation and/or fixing?
Honestly I don't know the specifics. In theory, DNSSEC=allow-downgrade would work reliably and we could use it. But Lennart says it doesn't, so we don't. I wonder if he would know of any upstream bug reports we could point to. What's an NTA?
NTA is Negative Trust Anchor, man 5 dnssec-trust-anchors.d for more details on resolved. It allows listing of domains, where failures on verification are expected and ignored.
I'm not sure what you suggest should be done with negative trust anchors, but note that box. exists and is signed, and registrars are accepting pre-registrations. An actual registered fritz.box could exist at some point, and Fedora shouldn't by default contribute to breaking things for the legitimate holder of such a future domain.
(In reply to Björn Persson from comment #9) > I'm not sure what you suggest should be done with negative trust anchors, > but note that box. exists and is signed, and registrars are accepting > pre-registrations. An actual registered fritz.box could exist at some point, > and Fedora shouldn't by default contribute to breaking things for the > legitimate holder of such a future domain. Should we instead disable DNSSEC validation for all domains? Should we prevent DNSSEC validation in default configuration to prevent such failures? I admit we should not reserve unregistered domain name, but first I would like to know reasons, why DNSSEC default is no on Fedora, unlike upstream project. Domain-specific NTA seems like a better solution than global settings. @mcatanza why did you say DNSSEC cannot change anytime soon? Can you name few use cases, when it needs to be turned off?
(In reply to Petr Menšík from comment #10) > Should we instead disable DNSSEC validation for all domains? Yes, by default we do not want any automatic DNSSEC validation for any domains. This most likely will not change unless Windows or macOS starts doing DNSSEC validation first. > Should we > prevent DNSSEC validation in default configuration to prevent such failures? I don't know. I don't see any strong reason to prevent applications from performing their own DNSSEC validation if they want to do so. But currently that would require that upstream agree to changes in https://github.com/systemd/systemd/issues/19227. On the other hand, I understand this would be a hard requirement for RHEL should systemd-resolved ever be used there. If upstream doesn't want to change behavior, then we would need to default to DNSSEC=yes or DNSSEC=allow-downgrade. > I admit we should not reserve unregistered domain name, but first I would > like to know reasons, why DNSSEC default is no on Fedora, unlike upstream > project. Domain-specific NTA seems like a better solution than global > settings. > > @mcatanza why did you say DNSSEC cannot change anytime soon? Can > you name few use cases, when it needs to be turned off? Well I'm not an expert on DNSSEC, but I understand that to enable DNSSEC validation by default, it would need to be supported by (a) all major ISPs in almost all countries, (b) almost all consumer routers, (c) almost all captive portals (a particularly thorny problem: how could it possibly not break captive portals?). I really only see two plausible paths forward: Windows starts requiring it, or macOS starts requiring it. Otherwise, infrastructure is not going to be fixed....
No, I am not requesting to enable DNSSEC always for everyone. I know we are not ready for that (yet). I think 3 main states have to be considered on (auto)configured forwarders: 1) No support for DNSSEC at all. This is quite easy to detect, just send out requests with DO flag and watch reply. It it does not contain signatures even for root, where it always should be. This situation is easy to detect and switch off DNSSEC support. I guess this is what DNSSEC=allow-downgrade is about. This is for example true on any Mikrotik device. 2) Partial or broken support for DNSSEC. This might include dnsmasq 2.79 and lower for example. In this case, it can deliver signatures in replies SOMETIMES. I have seen this problem on Ubiquity devices. In case of dnsmasq, it is broken, because the cache does not distinguish between DNSSEC and non-DNSSEC replies, even when queries differ in DO bit. 3) Full support at the forwarder. DNSSEC=yes would work with this forwarder, because it can distinguish DNSSEC OK queries and return always signatures on them. Also it knows how to omit them. This is standard on most of seriously provided DNS service and would work on all bigger services, like dns.google or 1.1.1.1, 9.9.9.9 or similar. It seems to me case 2) is difficult to distinguish from 3). Detecting 1) or 3) is easy. I am not sure how common that case is. It should be possible to handle validation different way during captive portal detection. The case 2) is the only problem with automatic configuration, because detecting such cases is not always easy. It does not have to be supported by every device. It just have to be clear whether it supports DNSSEC or not. DNS community maintains a good sets of data about authoritative servers support for secure DNS. I think we do not have any relevant data for support on last-hop devices. It is question, how usual broken resolvers are and whether we can reliably detect them. If detection is improved, automatic configuration could work. I see the only problem with case 3) - local unsigned zones, which do not exist in signed public dns tree. Validation reports NXDOMAIN on them, even when local servers serves them. That includes lan. or home. Those examples are already covered by predefined Negative Trust Anchors, other are easy to add later. It seems to me support for per-connection setting would be nice, because problems with validation on bahn.de network might be always seen. But home or work network might always work, reconfiguring it always by hand is not user-friendly.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
Still present even on Rawhide. Increasing severity because long standing regression compared to state before f33.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
Reopening again. The issue is still present and breaking my tests, because it is enabled by default. It breaks my testing often, I have to do special hacks to pass my tests correctly on Fedora. While I admit it should be solved at upstream it is deployment of features on Fedora. Like gpgkey_dns_verification option in dnf. Which does not require systemd-resolved to have validation enabled by default, but needs to propagate DNSSEC enabled requests.
I had to deploy special workarounds for testing proper dnsmasq support. I don't think this should be necessary if the infrastructure provides everything needed. https://src.fedoraproject.org/tests/dnsmasq/c/530c6e677de218653fbb5c79b148bd68feff1674?branch=main
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26. Fedora Linux 39 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.