[dns-operations] DNSSEC and FIPS-140

[James Stevens]

>> The reason for the confusion is that PowerDNS is unable to return
>> a RRSIG for NSEC or NSEC3 if MD5 is disabled at the O/S level.
>> It just  crashes.

>> But I have no idea why it would need it??
>>
>> I need to look at the source.
> 
> I think you need to take this discussion to a PowerDNS forum/mailing
> list. What you're saying doesn't seem possible. It's highly unlikely a
> query will cause a DNS server to crash because "MD5 is disabled at the
> O/S Level" (whatever you mean by that). However if your OS has a mangled
> SSL library, all bets are off.

Thanks, Jim. Sounds like you're right.

I was just trying to figure out if there was *any* reason why a zone 
signed NSEC or NSEC3, using ECDSA256 keys, would ever /legitimately/ 
need MD5.

The answer seems to be "no".
If so, this can only be an issue for PowerDNS.



We're running a PowerDNS Master on RHEL 7 installed with FIPS compliance,

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations

... which (I believe) installs the FIPS OpenSSL module - 
https://www.openssl.org/docs/fips.html


RHEL/FIPS enforces FIPS compliance at the O/S level. e.g. it disables 
all non-FIPS-140 compliant algorithms (inc MD5) within OpenSSL, so they 
can't be used for any reason whatsoever.


On a PowerDNS master, with "exmaple.com" signed NSEC or NSEC3 with 
ECDA256 KSK & ZSK, this query works fine ...

$ dig @127.0.0.1 example.com soa

... but this query will crash PowerDNS ...

$ dig +dnssec @127.0.0.1 example.com soa


By "crash" I mean PowerDNS core-dumps - interestingly with signal 6, 
SIGABRT - so sounds like some kind of assertion has failed - like you 
said, looks like this needs to be taken up elsewhere.



James