<div dir="ltr"><div dir="ltr">On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček <<a href="mailto:pspacek@isc.org">pspacek@isc.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We do runtime detection at startup because it's configurable, build time <br>
would not work properly.<br></blockquote><div><br></div><div>Okay, that makes sense. However, if I understood the scenario correctly, it seems like that configuration should then generate a runtime error or at least report that DNSSEC validation has been disabled. The description involved removing support for SHA1 entirely from the underlying system configuration. If that's the case then I don't see how DNSSEC validation can be reliably performed at all. It's not like introducing a new DNSSEC algorithm or removing support for an older DNSSEC algorithm. SHA1 is used to generate the hash label in NSEC3. I know that's been discussed on dnsops, but it hasn't changed. And from algorithm 8 on, there haven't been separate algorithms with and without NSEC3. Rather it's an option that can be configured for signing on a zone by zone basis. So if SHA1 isn't available, I don't see how any of the DNSSEC algorithms could truly be considered supported on the system.</div><div><br></div><div>That's making me curious enough that I might see if I can set up a system where I could reproduce that scenario and see what happens. Unless it's already part of your test suite and you know the answer, of course.</div><div><br></div><div>Scott</div></div></div>