BIND 9.18.6 disables RSASHA1 at runtime?

Mark Andrews marka at isc.org
Mon Sep 5 09:16:14 UTC 2022



> On 5 Sep 2022, at 18:41, Bjørn Mork <bjorn at mork.no> wrote:
> 
> Petr Menšík <pemensik at 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 at 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: marka at isc.org



More information about the bind-users mailing list