Re: DNSSec mess with SHA1

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. -- Mark Andrews > On 16 Dec 2023, at 01:09, Scott Morizot wrote: > >  >> On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: >> We do runtime detection at

Re: DNSSec mess with SHA1

On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: > We do runtime detection at startup because it's configurable, build time > would not work properly. > Okay, that makes sense. However, if I understood the scenario correctly, it seems like that configuration should then generate a runtime

Re: DNSSec mess with SHA1

On 15. 12. 23 14:28, Scott Morizot wrote: On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček > wrote: Hello. It smells like a packaging issue to me. Stock BIND (not an obsolete Red Hat-Frankenstein version) should detect this condition and threat domains as

Re: DNSSec mess with SHA1

On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček wrote: > Hello. > > It smells like a packaging issue to me. Stock BIND (not an obsolete Red > Hat-Frankenstein version) should detect this condition and threat > domains as insecure. > And I think that answers the one question I had. I was curious

Re: DNSSec mess with SHA1

Hello. It smells like a packaging issue to me. Stock BIND (not an obsolete Red Hat-Frankenstein version) should detect this condition and threat domains as insecure. If it does not work with stock BIND please report it to us. If it does not work in Red Hat's packages only, well, report it

Re: DNSSec mess with SHA1

The question I have is why you're posting the issue to this list and what you expect the ISC to do? It could be submitted as a bug to the distribution you're using. Or if you want to change the way algorithms are treated, the dnsops list at the IETF would be an appropriate place to start. (There

Re: DNSSec mess with SHA1

Hello, To answer my own question, the following will work: [shadowman-200.png] Chapter 4. Using system-wide cryptographic policies