DNSSEC records signed with RSASHA1 and NSEC3RSASHA1 fail to verify
Environment
- Red Hat Enterprise Linux 9
- bind or unbound packages
Issue
DNSSEC records signed with the SHA-1 digest algorithm will fail to verify in Red Hat Enterprise Linux 9. The SHA-1 digest algorithm is no longer considered secure and it is deprecated in Red Hat Enterprise Linux 9.
Resolution
If your infrastructure depends on using DNSSEC records signed with SHA-1, it is recommended to upgrade to a different signature algorithm, such as RSASHA256 or elliptic curves keys.
The DNSSEC resolvers follow crypto-policy in Red Hat Enterprise Linux 9. As a last resort, you can temporarily change the system-wide crypto policy to SHA1 on top of DEFAULT crypto policy and reboot:
# update-crypto-policies --set DEFAULT:SHA1
Alternatively, you can switch the system-wide crypto policies to the LEGACY policy. The LEGACY crypto-policy also re-enables the SHA1 algorithm among other, no longer recommended, algorithms. This option is not recommended by Red Hat though.
Root Cause
DNSSEC provides cryptographic security for DNS replies, which are otherwise unauthenticated and therefore prone to spoofing.
The SHA1 signatures with RSA keys are used in RRSIG records. They are used for signing the resource records (RR) containing the actual DNS replies.
All domains signed with SHA-1 based signatures will be affected (algorithms number 5 and 7). It is not possible to list all of them, but all names ending with following top level domains will become insecure:
- aco.
- adac.
- am.
- apple.
- audio.
- auto.
- beats.
- blackfriday.
- car.
- cars.
- case.
- click.
- creditunion.
- cyou.
- deloitte.
- dhl.
- diet.
- flowers.
- frl.
- game.
- gd.
- gea.
- gent.
- gift.
- guitars.
- help.
- hiphop.
- hiv.
- hosting.
- christmas.
- int.
- juegos.
- kg.
- kpn.
- ky.
- la.
- lidl.
- link.
- lk.
- llp.
- lol.
- lpl.
- lplfinancial.
- mom.
- monster.
- na.
- photo.
- pics.
- property.
- samsung.
- sexy.
- sfr.
- schwarz.
- sl.
- storage.
- tattoo.
- vg.
- xn--cg4bki. (삼성.)
- xn--fzc2c9e2c. (ලංකා.)
- xn--l1acc. (мон.)
- xn--mgbai9azgqp6j. (پاکستان.)
- xn--q7ce6a. (ລາວ.)
- xn--xkc2al3hye2a. (இலங்கை.)
- xn--y9a3aq. (հայ.)
The DNS resolvers in RHEL 9 (bind, unbound, ldns, systemd-resolved, …) no longer verify SHA1-based signatures so instead of returning the AD (Authenticated Data) bit for these domains, insecure DNS records.
Additionally, in FIPS mode, the verification of signatures made with RSA keys is allowed on key sizes 1024, 1280, 1536, 1792 and greater or equal to 2048 bits only. ED25519 and ED448 algorithms are also unavailable in FIPS mode.
Diagnostic Steps
Using the delv tool from bind-utils, you can manually verify DNSSEC signatures for any domain. For example the domain secure.d4a5n1.rootcanary.net is signed using RSA-SHA1 signature mechanism and fails with similar error:
# delv @127.0.0.1 secure.d4a5n1.rootcanary.net
;; EVP_VerifyFinal failed (verify failure)
;; error:03000098:digital envelope routines::invalid digest:crypto/evp/pmeth_lib.c:959:
;; EVP_VerifyFinal failed (verify failure)
;; error:03000098:digital envelope routines::invalid digest:crypto/evp/pmeth_lib.c:959:
;; validating d4a5n1.rootcanary.net/DNSKEY: no valid signature found
;; insecurity proof failed resolving 'd4a5n1.rootcanary.net/DNSKEY/IN': 192.168.1.1#53
;; broken trust chain resolving 'secure.d4a5n1.rootcanary.net/A/IN': 192.168.1.1#53
;; resolution failed: broken trust chain
Notes:
The dnsmasq is not affected right now, because it is using nettle directly, which does not follow crypto-policies. This will change when This content is not included.this bug will be resolved.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.