Fedora DNSSEC default crypto policies and SHA1

Ask Fedora
, , ,
1

Hello everyone,

after upgrading to F41 I noticed that some websites stopped working that were still loading on my mobile or my non-Fedora laptop.

The problem was the following:

➜  ~ resolvectl query fio.cz
fio.cz: resolve call failed: DNSSEC validation failed: failed-auxiliary

We can see the DNSSEC validation issue also with delv

➜  ~ delv fio.cz
;; validating fio.cz/A: no valid signature found
; unsigned answer
fio.cz.			5123	IN	A	92.38.6.11
fio.cz.			5123	IN	RRSIG	A 5 2 7200 20241127134707 20241028131819 48246 fio.cz. A7JoXc676r8aI7FZvK4Ey2HIWiA8/75lbM6ZcN19ayfv+p2bF9iAQplv kLcoCtURKav9e/hpxWv4SqwAidisHaKO6mdBo6K1jWMf2F7R649wlRAG PwsYestUD4J0Z35QDGBUua7+J0M6Is0in6fX6BdHC5v9xH/Nq9AquVs+ s8s=

Now, we can see that bind says “no valid signature found”, however the answer contains a valid RRSIG. I also verified that the signature is indeed valid, but uses an older algorithm RSA/SHA1 (algo number 5).

I figured out that the allowed DNSSEC policies on Fedora are managed by crypto-policies

# update-crypto-policies --show
DEFAULT

I tried setting this to LEGACY and restarting systemd-resolved

# update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
# systemctl restart systemd-resolved.service
#

Now the same query succeeds and the website is loading in the browser.

➜  ~ resolvectl query fio.cz
fio.cz: 92.38.6.11                             -- link: wlo1

-- Information acquired via protocol DNS in 50.2ms.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no
-- Data from: network

My question is, if it was intentional to drop RSA/SHA1 support in the default policy already?

According to RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC the RSA/SHA1 algorithm, while NOT RECOMMENDED to be used for signing, it is still a MUST for validation implementations, so I would still expect it to be working out-of-box in the DEFAULT policy.

2

Distrusting SHA-1 is a scheduled change:

DNSSEC is disabled by default for a reason:

Here’s a possible workaround:

  • Use DNS providers that validate DNSSEC.
  • Disable local DNSSEC validation.
  • Use DoH/DoT for integrity.
1 Like
3

This is a bug in systemd-resolved. Can you please fill both Fedora bug and GitHub - systemd/systemd: The systemd System and Service Manager issue?

It is expected that algorithm 5 and 7 will become insecure. Meaning not DNSSEC validated. But they should not result in failed resolution. That is a bug on systemd side. It should just miss AD bit in response, but otherwise should resolve the same way.

Yes, because the way how openssl enforces SHA-1 validation disabling, we are in violation of RFC 8624. That is known issue we have no good fix for. But systemd-resolved should be fixed to threat 5 and 7 algorithms as unknown, resulting only in AD bit missing.

Try to set negative trust anchor as an workaround. Read how to do it in man dnssec-trust-anchors.d.

Edit: Do not use LEGACY crypto-policy, but use DEFAULT:SHA1 if possible. But the most secure way is using either non-broken resolver (bind, unbound, dnsmasq, knot-resolver, …), or fio.cz.negative file with systemd-resolved.

Yes, that reason is mainly implementation of DNSSEC in systemd-resolved is lacking and buggy. Yes, there are problems with DNS64 and time synchronization, but most described issues are caused by systemd bugs and unwillingness to work on DNSSEC. But they are slowly improving. F41 is the first release, where delv command works in default configuration, with DNSSEC=no in resolved.

2 Likes
4

Yeah, I understand the situation about SHA-1, but on the other hand the standards still state MUST for validation implementation and still some needed websites use it. I emailed this particular website owner about this issue, let’s see if they manage to upgrade the keys.

I don’t think disabling DNSSEC is more secure than DNSSEC with SHA-1 and I would prefer end to end integrity if using DNSSEC, but your third suggestion about relying on DoTLS to secure the link between the client and the validating resolver is actually something I can do since I already enabled DoT recently.

I also found yet another workaround setting the Fedora crypto policy to FEDORA40 as mentioned at https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer#User_Experience - probably better than LEGACY.

Thanks for the quick response. I only wanted to verify if this change did intentionally include DNSSEC and it seems it did, in which case I’ll use the workarounds to fix this on my side.

1 Like
5

Thank you, Petr. I filed the bug F41 systemd-resolved fails to resolve domains with DNSSEC algo 5 and 7 with DEFAULT crypto policy · Issue #35112 · systemd/systemd · GitHub

I’ll try to configure the NTA, it seems it is a better option when there are only a handful of exceptions.

6

I’m not sure if I’m doing this right, I tried to follow the manual which says each line specifies one domain which is the root of a DNS subtree where validation should be disabled.

I have the following:

# ll /etc/dnssec-trust-anchors.d/fio.cz.negative
-rw-r--r--. 1 root root 8 Nov 11 03:58 /etc/dnssec-trust-anchors.d/fio.cz.negative
# cat /etc/dnssec-trust-anchors.d/fio.cz.negative 
fio.cz.

But it won’t work with the DEFAULT policy:

# resolvectl query fio.cz
fio.cz: resolve call failed: DNSSEC validation failed: failed-auxiliary

I tried with and without the dot at the end of the domain name in the NTA file.

7

Thank you. I would not expect a fast fix for it, systemd people consider DNSSEC validation as not production ready, but are afraid writing it clearly into the manual. I just added that NTA entry does not help to your report.

There is nice service to verify algorithms support: https://rootcanary.org/test.html

2 Likes
8

Thanks, Petr. That’s a very useful website, indeed.

So far from my recent experiments with DNSSEC I only encountered the problem with the missing SHA1 support (algo 5 and 7) the rest are probably not that prevalent. And even SHA1 should be eliminated soon (on the .CZ domain less than 3.5% used SHA1 in 2023 - Domain Report 2023).

For now I am fine with the workarounds for DNSSEC with SHA1 as discussed above, there are still a few options with different tradeoffs:

  • use DEFAULT:SHA1 or FEDORA40 crypto policy
  • or use a DNSSEC validating upstream with DoT (or without if not a concern)
  • or use a different local resolver (bind, unbound, etc.)

(or the non-validating stub resolver at 127.0.0.54 also works)

9

I took a second look at the link Vladislav shared about why DNSSEC is disabled by default:

Because Fedora is not prepared to handle an influx of DNSSEC-related bug reports, we will disable this feature altogether. We anticipate that enabling DNSSEC by default will not be possible in the foreseeable future, or perhaps ever. Instead, enabling DNS over TLS (when supported by the DNS server) seems likely in the near future.

I also came across a warning about using DNSSEC in systemd-resolved in the Arch wiki that references a core developer comment that shows some frustration about people complaining about DNSSEC in systemd and calls it an experimental feature, but this is familiar already to Petr it seems from the same thread.

I did not know about this when I decided to give it a try. I think it’s fair if a feature is not considered fully operational and use is discouraged, my only comment would be to perhaps make it a bit more visible.

E.g man systemd-resolved today does not mention any DNSSEC related issues to be aware of or that it is experimental:

systemd-resolved is a system service that provides network name resolution to local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR and MulticastDNS resolver and responder.

man resolved.conf also does not mention issues and does not recommend to turn it off (just mentions it is off by default):

It is recommended to set DNSSEC= to true on systems where it is known that the DNS server supports DNSSEC correctly, and where software or trust anchor updates happen regularly. On other systems it is recommended to set DNSSEC= to “allow-downgrade”.

But regarding my own use case, the easiest for me now is to rely on DoT with a DNSSEC validating upstream as suggested - or setup unbound if feeling more adventurous.

1 Like