On 08 Nov 2024, at 13:34, Yorgos Thessalonikefs via Unbound-users <unbound-users@lists.nlnetlabs.nl> wrote:
> 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. 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 --
