DNSSEC validation in CentOS Stream 9

Hello everyone,
maybe this will be obvious to some, but I have been scratching my head
about this since yesterday.

In CentOS Stream 9, when unbound installed from Appstream, I see that
unbound returns insecure replies to clients. Which is not what I want,
nor what I am used to. I am thinking this might be a packaging bug,
compile option or config setting, but I can not figure out which and
where. I am testing with untouched rpm package config.

CentOS Stream 9 example:
[root@18 ~]# dig sigfail.verteiltesysteme.net @127.1 +short
134.91.78.139
[root@18 ~]# unbound-host -C /etc/unbound/unbound.conf -v
sigfail.verteiltesysteme.net
Sep 08 08:36:33 libunbound[9948:0] notice: init module 0: ipsecmod
Sep 08 08:36:33 libunbound[9948:0] notice: init module 1: validator
Sep 08 08:36:33 libunbound[9948:0] notice: init module 2: iterator
sigfail.verteiltesysteme.net has address 134.91.78.139 (insecure)
sigfail.verteiltesysteme.net has IPv6 address 2001:638:501:8efc::139 (insecure)
sigfail.verteiltesysteme.net has no mail handler record (insecure)
[root@18 ~]# unbound-host -C /etc/unbound/unbound.conf -v
sigok.verteiltesysteme.net
Sep 08 08:36:37 libunbound[9951:0] notice: init module 0: ipsecmod
Sep 08 08:36:37 libunbound[9951:0] notice: init module 1: validator
Sep 08 08:36:37 libunbound[9951:0] notice: init module 2: iterator
sigok.verteiltesysteme.net has address 134.91.78.139 (insecure)
sigok.verteiltesysteme.net has IPv6 address 2001:638:501:8efc::139 (insecure)
sigok.verteiltesysteme.net has no mail handler record (insecure)
[root@18 ~]# unbound -V
Version 1.16.2

Configure line: --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-pythonmodule --with-pyunbound
PYTHON=/usr/bin/python3 --enable-dnstap --with-libnghttp2
--with-libevent --with-pthreads --with-ssl --disable-rpath
--disable-static --enable-relro-now --enable-pie --enable-subnet
--enable-ipsecmod --with-conf-file=/etc/unbound/unbound.conf
--with-pidfile=/run/unbound/unbound.pid --enable-sha2 --disable-gost
--enable-ecdsa --with-rootkey-file=/var/lib/unbound/root.key
--enable-linux-ip-local-port-range --disable-sha1
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.1 14 Dec 2021
Linked modules: dns64 python ipsecmod subnetcache respip validator iterator

BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or
https://github.com/NLnetLabs/unbound/issues
[root@18 ~]# cat /etc/os-release
NAME="CentOS Stream"
VERSION="9"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="9"
PLATFORM_ID="platform:el9"
PRETTY_NAME="CentOS Stream 9"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:centos:centos:9"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"

[root@18 ~]# dig www.dnssec-failed.org @127.1 +short
69.252.193.191
68.87.109.242

[root@18 ~]# cat /var/lib/unbound/root.key
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1662618997 ;;Thu Sep 8 08:36:37 2022
;;last_success: 1662618997 ;;Thu Sep 8 08:36:37 2022
;;next_probe_time: 1662660868 ;;Thu Sep 8 20:14:28 2022
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
. 172800 IN DNSKEY 257 3 8
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0
;;lastchange=1662618437 ;;Thu Sep 8 08:27:17 2022

Hello Josef,

Hello everyone,
maybe this will be obvious to some, but I have been scratching my head
about this since yesterday.

In CentOS Stream 9, when unbound installed from Appstream, I see that
unbound returns insecure replies to clients. Which is not what I want,
nor what I am used to. I am thinking this might be a packaging bug,
compile option or config setting, but I can not figure out which and
where. I am testing with untouched rpm package config.

CentOS Stream 9 example:
[root@18 ~]# dig sigfail.verteiltesysteme.net @127.1 +short
134.91.78.139
[root@18 ~]# unbound-host -C /etc/unbound/unbound.conf -v

[...]

sigok.verteiltesysteme.net has address 134.91.78.139 (insecure)
sigok.verteiltesysteme.net has IPv6 address 2001:638:501:8efc::139 (insecure)
sigok.verteiltesysteme.net has no mail handler record (insecure)
[root@18 ~]# unbound -V
Version 1.16.2

Red Hat removed (almost all) SHA1 support from RHEL 9 (including CentOS), which makes DNSSEC zones signed with RSASHA1 treated as insecure:

<https://access.redhat.com/solutions/6955455&gt;

This affects the Red Hat build versions of Unbound and BIND 9 (as a resolver).

SHA1 for DNSSEC use is on its path to be deprecated <https://www.ietf.org/archive/id/draft-hardaker-dnsop-must-not-sha1-00.html&gt;, but there are still zones that have not migrated to stronger DNSSEC algorithms.

See the discussion on this mailing list for some background <https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html&gt;

Greetings

Carsten

Thanks! I now remember, I have seen Petr discussing something similar
on the Bind Users mailing list.

Josef

You can run: sudo update-crypto-policies --set LEGACY

That will enable SHA1 again to be useful for validation.

It will unfortunately also enable SHA1 for other things like sshd.

I tried to communicate this to Red Hat but they weren't willing
to budge and allow sha1 for dnssec, thereby reducing people's
security from "attacking sha1" to "just spoof it" :confused:

Luckilly, only like 0.08% of dnssec signed zones is still using sha1
and we have a draft underway at IETF to push people further away
from sha1.

https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-rfc8624-bis

Paul