ad flag missing, but no error messages

[Yorgos Thessalonikefs]

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 at 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 at 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
> --