Hi Graham,
I **think** you are hitting the system wide policies in RH9 that SHA1 is
disabled by default.
Can you try the suggestion on this link to bring it back?
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#proc_re-enabling-sha-1_using-the-system-wide-cryptographic-policies
Since the zone is only signed with algorithm 7 (RSASHA1-NSEC3-SHA1),
Unbound cannot validate it and instead treats it as insecure.
That is why you get all the records back and no AD bit.
Best regards,
-- Yorgos
On 08/11/2024 13:51, Graham Leggett via Unbound-users wrote:
Hi all,
I have a vanilla, standalone, unbound v1.16 installation as packaged on
RHEL9 on localhost, and this is successfully verifying DNSSEC for the
domain nlnet.nl <http://nlnet.nl/>:
[root@seawitch ~]# dig TLSA +dnssec _25._tcp.open.nlnet.nl <http://
tcp.open.nlnet.nl/>
; <<>> DiG 9.16.23-RH <<>> TLSA +dnssec _25._tcp.open.nlnet.nl <http://
tcp.open.nlnet.nl/>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24103
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;_25._tcp.open.nlnet.nl <http://tcp.open.nlnet.nl/>.INTLSA
;; ANSWER SECTION:
_25._tcp.open.nlnet.nl <http://tcp.open.nlnet.nl/>.3400INTLSA3 1 1
4B70D5B3226B7D7C5D09FE40C4D2B7534F9BDBAD6735FBA388C8BBF9 2C4446AC
_25._tcp.open.nlnet.nl <http://tcp.open.nlnet.nl/>.3400INRRSIGTLSA 8 5
3600 20241116121646 20241017121646 38979 nlnet.nl <http://nlnet.nl/>.
CbZ5jQNU21Ne9N2cY4BLowAA6vXuRyueTZPHFtk6ZD6m4jStHJPfOgSF
QN+3pGhqnf1qGQUQeQvfrETzjFz7vN1StMVpA+dv/WTaAwtMCtm/aIl+
8/0WmB0SVAxRFfmZsEnV4RKymZjDhlz207wK8LyvNjdKWx5EJxwLfVqI 4Ts=
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Nov 08 11:09:44 SAST 2024
;; MSG SIZE rcvd: 266
The exact same localhost unbound server returns no ad flag on a request
for sharp.fm <http://sharp.fm/>, and as a result DANE fails.
[root@seawitch ~]# dig TLSA +dnssec _25._tcp.aurora.sharp.fm <http://
tcp.aurora.sharp.fm/>
; <<>> DiG 9.16.23-RH <<>> TLSA +dnssec _25._tcp.aurora.sharp.fm
<http://tcp.aurora.sharp.fm/>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60479
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;_25._tcp.aurora.sharp.fm <http://tcp.aurora.sharp.fm/>.INTLSA
;; ANSWER SECTION:
_25._tcp.aurora.sharp.fm <http://tcp.aurora.sharp.fm/>. 30INTLSA3 1 0
3076301006072A8648CE3D020106052B810400220362000421C2B37A
C32039564CC3028EC8F1011D033B9CC6024234902F1EAE7923ED908B
7DF1939EC97F46D26B0EA8EBAC4A85412EAD4F4C67292E84FB77A5A5
7ECD5AD019777C6FA86E609C099C4383C534E59EA5C4BC8C9C1AD3B0 C85EA382DE3A1E55
_25._tcp.aurora.sharp.fm <http://tcp.aurora.sharp.fm/>. 30INRRSIGTLSA 7
5 300 20241111184324 20241028171005 11022 sharp.fm <http://sharp.fm/>.
cmsFz4QPB4eUh9IVM3TOiAN182zurMUU7u1a4e7EPmlvwjUxpYhDUqR8
ob+MCfplOl6YtpdeaMR1XgXf3OULKVlc54JLTD7AQdeIINHJUjXGCtzM
JvXltFwwcoPzcUq/HqdAcJixJvqbq1kysReq2pGK0SLUXwZjYAgf+253 Q9I=
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Nov 08 11:36:34 SAST 2024
;; MSG SIZE rcvd: 356
If I use the http://unboundtest.com/ <http://unboundtest.com/> checker
with logs of debug logging, I get no warnings, and no errors, just no ad
flag as before.
What I need is some kind of diagnostic message to tell us why the ad
flag is missing / validation of DNSSEC has failed, but I am not seeing
this anywhere.
Obviously answering the question "why doesn't this particular thing
work" is a short term goal, but in the longer term our ops people are
going to have to debug this if it goes wrong, and right now there seems
no diagnostics to go on.
Does this make sense?
Regards,
Graham
--
