> On 5 Sep 2022, at 18:41, Bjørn Mork <bj...@mork.no> wrote: > > Petr Menšík <pemen...@redhat.com> writes: > >> It is suitable for all other algorithms so I disagree that >> without algorithms 5 and 7 it is not usable at all. Majority of >> secured domains use stronger algorithms already. > > Would it be the same if it worked for a majority of TLDs? Say "nz" as > an arbitrary example. Would still work fine for a majority of users. It > would probably take me some time before I noticed. After all, I rarely > have a need to look up "nz" domains. And when it occasionally failed I'd > probably never would have blamed Redhat. > > IMHO BIND without RSASHA1 is useless as a validating resolver as long as > there are RSASHA1 signed zones out there. At least as long as this is > still allowed. And it is. Hence the MUST validate.
It does validate. Remember the results of validation are secure, insecure, or bogus. The point of the change is ensure that lookups DO NOT FAIL because the OS has removed / disabled support for RSASHA1. Without the change lookups failed with SERVFAIL unless you explicitly said to disable RSASHA1 and NSEC3RSASHA1. With the change they validate as insecure. > The classical example of a failing domain is > https://dnsviz.net/d/paypal.com/dnssec/ > Maybe acceptable for you? Definitely not for me or my customers. I > want DNSSEC validation on that domain. I'd certainly prefer a stronger > algorithm. But that's not an option, is it? What records in paypal.com do you or your customers actually depend upon being signed? Paypal’s web servers depend on CAs not the DNS to provide trust anchors. It's not their SMTP servers as paypalcorp.com is not signed. Yes, I’d like Paypal to have moved to something that is not RSASHA1 based for DNSSEC but at the moment, for all practical uses, whether the zone validates as secure or insecure doesn’t matter. > So, yes, I prefer to be forced to acknowledge this issue. And refusing > to start without some form of explicit adminstrator action is the only > way that works in my experience. Not enough admins read logs ;-) > > > > Bjørn > -- > 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 > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
