<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Folks,
<div><br>
</div>
<div>Many thanks for you feedback and insights.</div>
<div><br>
</div>
<div>I didn’t wanted to say that this is an ISC issue or something I expected someone to fix.</div>
<div>I just wanted to get your opinions and maybe provide a solution as I am not the only one facing that challenge ;-)</div>
<div><br>
</div>
<div>Yes, it may be a distribution packing or installation issue outside of BIND but nevertheless it’s impacting DNS resolution in a negative way.</div>
<div><br>
</div>
<div>Anyway, the easy solution to get it working without creating DNSSEC exceptions lists is:</div>
<div><br>
</div>
<div>
<div style="caret-color: rgb(0, 0, 0);"><font color="#205bff">update-crypto-policies --set LEGACY</font></div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br>
</div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">… but I still think the right way would be getting people signing their zones with <span style="font-family: monospace;">ED25519 or </span><span style="font-family: monospace;">ED448 as mentioned
 by Scott.</span></div>
</div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br>
</div>
<div style="caret-color: rgb(0, 0, 0);"><font color="#205bff"><br>
</font></div>
<div style="caret-color: rgb(0, 0, 0);"><font color="#205bff"> The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA].<br>
<br>
 <font face="monospace">  +--------+--------------------+-----------------+-------------------+<br>
   | Number | Mnemonics          | DNSSEC Signing  | DNSSEC Validation |<br>
   +--------+--------------------+-----------------+-------------------+<br>
   | 1      | RSAMD5             | MUST NOT        | MUST NOT          |<br>
   | 3      | DSA                | MUST NOT        | MUST NOT          |<br>
   | 5      | RSASHA1            | NOT RECOMMENDED | MUST              |<br>
   | 6      | DSA-NSEC3-SHA1     | MUST NOT        | MUST NOT          |<br>
   | 7      | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST              |<br>
   | 8      | RSASHA256          | MUST            | MUST              |<br>
   | 10     | RSASHA512          | NOT RECOMMENDED | MUST              |<br>
   | 12     | ECC-GOST           | MUST NOT        | MAY               |<br>
   | 13     | ECDSAP256SHA256    | MUST            | MUST              |<br>
   | 14     | ECDSAP384SHA384    | MAY             | RECOMMENDED       |<br>
   | 15     | ED25519            | RECOMMENDED     | RECOMMENDED       |<br>
   | 16     | ED448              | MAY             | RECOMMENDED       |<br>
   +--------+--------------------+-----------------+-------------------+</font></font></div>
<div><br>
</div>
<div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I still puzzled why root zones can’t get it done to re-singn their zones with a decent algorithm and that organisations like NIST are still on SHA1…</span></div>
<div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br>
</span></div>
<div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Cheers and many </span><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">thanks,</span></font></div>
<div><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">Wolfgang</span></font></div>
<div>
<div><br>
<blockquote type="cite">
<div>On 15. Dec 2023, at 23:11, Mark Andrews <marka@isc.org> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="auto">They haven’t removed sha1 they have removed certain uses of sha1.  If they ever remove sha1 we will just add an implementation for sha1. 
<div>
<div>
<div dir="ltr">-- 
<div>Mark Andrews</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On 16 Dec 2023, at 01:09, Scott Morizot <tmorizot@gmail.com> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<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>
<span>-- </span><br>
<span>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list</span><br>
<span></span><br>
<span>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.</span><br>
<span></span><br>
<span></span><br>
<span>bind-users mailing list</span><br>
<span>bind-users@lists.isc.org</span><br>
<span>https://lists.isc.org/mailman/listinfo/bind-users</span><br>
</div>
</blockquote>
</div>
</div>
</div>
-- <br>
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br>
<br>
<br>
bind-users mailing list<br>
bind-users@lists.isc.org<br>
https://lists.isc.org/mailman/listinfo/bind-users<br>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>