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 has been a fair amount of discussion there on algorithms, but I admit I haven't been following it closely and it has mostly been focused on the signing side.)
As far as I know, RFC 8624 from 2019 remains the last published standards track instruction to validators. Here's the table from it. The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA]. +--------+--------------------+-----------------+-------------------+ | Number | Mnemonics | DNSSEC Signing | DNSSEC Validation | +--------+--------------------+-----------------+-------------------+ | 1 | RSAMD5 | MUST NOT | MUST NOT | | 3 | DSA | MUST NOT | MUST NOT | | 5 | RSASHA1 | NOT RECOMMENDED | MUST | | 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT | | 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST | | 8 | RSASHA256 | MUST | MUST | | 10 | RSASHA512 | NOT RECOMMENDED | MUST | | 12 | ECC-GOST | MUST NOT | MAY | | 13 | ECDSAP256SHA256 | MUST | MUST | | 14 | ECDSAP384SHA384 | MAY | RECOMMENDED | | 15 | ED25519 | RECOMMENDED | RECOMMENDED | | 16 | ED448 | MAY | RECOMMENDED | +--------+--------------------+-----------------+-------------------+ Algorithms 5 and 7 are not recommended for signing but remain valid options until they are moved to MUST NOT. And as long as they are valid options, DNSSEC validation has to remain MUST. ISC BIND functions in part as the reference implementation for the DNS standards as published through the IETF. If your distribution removed the libraries for an algorithm (and openssl is a separate project) on which BIND depends for validating those algorithms and it's the only algorithm available I'm not sure what other result BIND can legitimately return. Yes, there's a statement in the validation portion of RFC 4035 that if the resolver doesn't support any of the algorithms in the delegation, it should treat the zone as unsigned. But that doesn't apply here from what I can tell. The DNSSEC algorithm itself (algorithm 7 in this instance) is supported in the resolver and must be supported for validation to be standards conformant. Support for the hash algorithm used by the supported algorithm has been removed from the operating system. I don't see anywhere that BIND is returning the wrong result. In that situation, it looks like the only option. The ISC has no control over those building distributions nor does it have any control over what NIST, Apple, and others choose to use within the standards to sign their zones. Yes, it's a problem and the ISC can and likely will weigh in on it in the appropriate places. Since one of their objectives with BIND has always been to be a reference implementation for the standards, they can't really arbitrarily decide not to follow them. Anyway, those are the main thoughts I had while reading the discussion. I don't speak for anyone but myself so the ISC might have an entirely different take on the issue. Scott On Fri, Dec 15, 2023 at 5:47 AM Wolfgang Riedel via bind-users < [email protected]> wrote: > Hello Petr, > > The issue is not just BIND local, as you can see on dnsviz.net. > The whole chain of trust is broken. > > nist.gov <https://dnsviz.net/d/nist.gov/dnssec/> > dnsviz.net <https://dnsviz.net/d/nist.gov/dnssec/> > [image: logo_16x16.png] <https://dnsviz.net/d/nist.gov/dnssec/> > <https://dnsviz.net/d/nist.gov/dnssec/> > > My question is more how you all deal with the fact on current and updates > systems??? >
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
