ad flag missing, but no error messages

Unbound
1

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:

[root@seawitch ~]# dig TLSA +dnssec 25.tcp.open.nlnet.nl

; <<>> DiG 9.16.23-RH <<>> TLSA +dnssec 25.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. IN TLSA

;; ANSWER SECTION:

25.tcp.open.nlnet.nl. 3400 IN TLSA 3 1 1 4B70D5B3226B7D7C5D09FE40C4D2B7534F9BDBAD6735FBA388C8BBF9 2C4446AC

25.tcp.open.nlnet.nl. 3400 IN RRSIG TLSA 8 5 3600 20241116121646 20241017121646 38979 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, and as a result DANE fails.

[root@seawitch ~]# dig TLSA +dnssec 25.tcp.aurora.sharp.fm

; <<>> DiG 9.16.23-RH <<>> TLSA +dnssec 25.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. IN TLSA

;; ANSWER SECTION:

25.tcp.aurora.sharp.fm. 30 IN TLSA 3 1 0 3076301006072A8648CE3D020106052B810400220362000421C2B37A C32039564CC3028EC8F1011D033B9CC6024234902F1EAE7923ED908B 7DF1939EC97F46D26B0EA8EBAC4A85412EAD4F4C67292E84FB77A5A5 7ECD5AD019777C6FA86E609C099C4383C534E59EA5C4BC8C9C1AD3B0 C85EA382DE3A1E55

25.tcp.aurora.sharp.fm. 30 IN RRSIG TLSA 7 5 300 20241111184324 20241028171005 11022 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/ 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

2

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

3

I suspected this to be true, and have requested that our DNSSEC provider fix this for us.

This doesn't explain where the diagnostics are though.

For this to be deployed into production, when it breaks, our ops people need error messages. Right now, the only clue is the extremely subtle lack of an ad flag, which in turn results in postfix reporting the misleading error "non DNSSEC destination", meaning DNSSEC isn't supported at all, when it actually is it just failed validation.

What I'm worried about is the next outage will result in lots of confusing wild goose chases and the client getting fed up and telling us "just switch security off".

Is there an option that is off that I should be switching on? Neither ede nor val-log-level appear to do anything that affects syslog or journalctl.

Regards,
Graham

4

Went back to check this, and the current setting on the machine is LEGACY, so in theory SHA1 should still work.

[root@seawitch unbound]# update-crypto-policies --show

LEGACY

I then tried to build a completely vanilla unbound v1.22.0, yet this version fails to start complaining about:

fatal error: could not open autotrust file for writing, /root.key.10018-0-16059b0: Permission denied

The path /root.key.10018-0-16059b0 is weird - I would have expected it to be relative to the “/usr/local/etc/unbound/root.key” value, but somehow “/” is hardcoded somewhere in the code.

Regards,
Graham