Description of problem: In /etc/crypto-policies/config I set "FUTURE" instead of "DEFAULT" and BIND fails to start Version-Release number of selected component (if applicable): crypto-policies-20160921-2.git75b9b04.fc25.noarch bind-9.10.4-4.P5.fc25.x86_64 How reproducible: Every time Steps to Reproduce: 1. Set keyword "FUTURE" instead of "DEFAULT" in /etc/crypto-policies/config 2. update-crypto-policies 3. systemctl restart named Actual results: BIND will not start; in journal there is: Feb 13 22:10:46 hostname systemd[1]: Starting Berkeley Internet Name Domain (DNS)... Feb 13 22:10:47 hostname bash[1497]: /etc/crypto-policies/back-ends/bind.config:4: invalid algorithm 'NSECRSASH Feb 13 22:10:47 hostname bash[1497]: /etc/crypto-policies/back-ends/bind.config:9: invalid digest type 'SHA1' Feb 13 22:10:47 hostname systemd[1]: named.service: Control process exited, code=exited status=1 Expected results: BIND should start Additional info: /etc/crypto-policies/back-ends/bind.config with FUTURE: disable-algorithms "." { RSAMD5; RSASHA1; NSECRSASHA1; DSA; }; disable-ds-digests "." { GOST; SHA1; }; /etc/crypto-policies/back-ends/bind.config with DEFAULT: disable-algorithms "." { RSAMD5; }; disable-ds-digests "." { GOST; };
Would that work if SHA1 is disabled with SHA-1?
s/disabled/replaced
Changing the line "SHA1;" to "SHA-1;" and commenting out "NSECRSASHA1;" allows BIND to start. The value "NSECRSASHA-1;" is not accepted. Sorry, I see from my original report that the log line for that is truncated; it should be: Feb 13 22:10:47 hostname bash[1497]: /etc/crypto-policies/back-ends/bind.config:4: invalid algorithm 'NSECRSASHA1'
The NSECRSASHA1 is directly from the page of named.conf. I'm adding the maintainer of bind. http://www.zytrax.com/books/dns/ch7/security.html
crypto-policies-20160921-3.gitf3018dd.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-574a4dff1a
Thanks - with that update, BIND now starts. However, from reading around I'm not 100% sure that NSEC3RSASHA1 (now excluded) is the same as NSECRSASHA1 - I *think* it may be a later version of the standard. I may well be wrong, but is someone cleverer than me able to confirm? I also have an issue where a lot of lookups are now failing, I *guess* because the DNSSEC signatures are using an algorithm that's disallowed under FUTURE. uk.pool.ntp.org is one such. I have a *lot* of errors in the journal such as: Feb 14 14:39:59 hostname named[21197]: validating dlv.isc.org/SOA: no valid signature found Feb 14 14:39:59 hostname named[21197]: validating kolab.ag.dlv.isc.org/NSEC: no valid signature found Feb 14 14:39:59 hostname named[21197]: validating dlv.isc.org/SOA: no valid signature found Feb 14 14:39:59 hostname named[21197]: validating chipmunk.aero.dlv.isc.org/NSEC: no valid signature found Feb 14 14:39:59 hostname named[21197]: validating dlv.isc.org/SOA: no valid signature found Feb 14 14:39:59 hostname named[21197]: validating dlv.isc.org/NSEC: no valid signature found Feb 14 14:39:59 hostname named[21197]: no valid RRSIG resolving 'aero.dlv.isc.org/DS/IN': 212.23.3.100#53 Feb 14 14:39:59 hostname named[21197]: validating dlv.isc.org/SOA: no valid signature found Feb 14 14:39:59 hostname named[21197]: validating dlv.isc.org/NSEC: no valid signature found Feb 14 14:39:59 hostname named[21197]: no valid RRSIG resolving 'aero.dlv.isc.org/DS/IN': 2a02:8010:1:0:212:23:3:100#53 Feb 14 14:39:59 hostname named[21197]: validating dlv.isc.org/SOA: no valid signature found Feb 14 14:39:59 hostname named[21197]: validating dlv.isc.org/NSEC: no valid signature found Is that a separate bug?
Further failures with FUTURE (even if I comment out NSEC3RSASHA1): Feb 14 15:02:10 hostname named[22727]: validating alt2-mtalk.google.com/CNAME: bad cache hit (alt2-mtalk.google.com.dlv.isc.org/DLV) Feb 14 15:02:10 hostname named[22727]: broken trust chain resolving 'alt2-mtalk.google.com/A/IN': 212.23.6.100#53 Feb 14 15:02:10 hostname named[22727]: validating m.facebook.com/CNAME: bad cache hit (m.facebook.com.dlv.isc.org/DLV) Feb 14 15:02:10 hostname named[22727]: broken trust chain resolving 'm.facebook.com/A/IN': 212.23.6.100#53 Back on DEFAULT, and the errors stop. Given the nature of Google and Facebook, I think the definition of FUTURE might be a little bit over-zealous here. Any thoughts? New bug needed?
The only difference between DEFAULT and FUTURE for bind is the disabling of SHA1. I guess the servers you are connecting do use SHA1 for DNS. Is there some way to verify that?
Supported values in bind are defined in bind source at lib/dns/rcode.c NSECRSASHA1 is invalid, "RSASHA1" is sufficient. SHA1 is invalid digest, "SHA-1" should be used instead. On linked page, example is invalid, but supported values below it are correct.
Thanks guys. I'll be happy to test an updated build with NSECRSASHA1/NSEC3RSASHA1 removed entirely (since RSASHA1 is already excluded for FUTURE). However http://dnssec-debugger.verisignlabs.com/alt2-mtalk.google.com and http://dnssec-debugger.verisignlabs.com/m.facebook.com say both are SHA-256 throughout (there are other validation issues, but I don't think it's relevant here). I'm beyond the limits of my DNSSEC knowledge here, but it doesn't look like BIND is behaving as it should, in that disabling SHA-1 appears to also break SHA-256 signatures. http://dnssec-debugger.verisignlabs.com/uk.pool.ntp.org *does* show SHA-1 in the validation for .org (if I'm reading this right). If enabling FUTURE is going to block .org lookups I think we might be in trouble here though!
NSEC3 is added later. But not because NSEC itself is not secure itself. NSEC has disadvantage that every domain record in zone will be public. NSEC record contains name of next signed record, if you ask for non-existent record. If you iterate over domain, you can get all records it contains. NSEC3 allows you to hide some hosts by providing signed hash instead and have it signed. But it is a bit larger and not always used/needed. It just uses one more digest. As for disabling SHA-1 now, it is far too early. org and info TLD are signed by this algorithm, so any subdomain under that would fail to validate. That domain would be available only if you do not validate on that server or dig +cd is used. If you use $ delv org DNSKEY it will show you algorithm used. It should treat it as insecure, if it is signed with disable algorithm. But I did not test it much. It does not seem to be broken completely with RSASHA1 disabled.
I tested with SHA-1 allowed and RSASHA1 disabled, and immediately got *loads* of lookup failures, with "broken trust chain" in the journal. This was all the names tested above, a load more common ones, and bugzilla.redhat.com :-) In case it's something unusual in my setup... in named.conf I have: dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; If there's nothing special about that (short of time to check now - it's Valentine's day!), then we're left with bind.conf for FUTURE either the same as the one for DEFAULT, or with only the addition of "DSA" in the disabled-algorithms (I don't know how safe that is to leave in).
crypto-policies-20160921-3.gitf3018dd.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-574a4dff1a
crypto-policies-20160921-3.gitf3018dd.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Whilst the original bug is now "fixed" (i.e. BIND no longer fails to start), I don't think this is the right solution as it stands. * As per comment 9 and comment 11 "NSEC3RSASHA1" is not the right thing to disable (it's not the same as "NSECRSASHA1" which was disabled before). * As per comment 11 it's too early to be disabling SHA-1 anyway (even in a "FUTURE" policy), if it's going to break large portions of the internet (.org and .info) Re-opening.
Hi Russell, NSECRSASHA1 was a typo, and NSEC3RSASHA1 was the correct algorithm intended to be used. In addition it is also used as a synonym to RSASHA1 in the policy. For the comment about SHA1, that's the intention of the FUTURE policy (and hence its name). The default is what you should be using for compatibility. Nevertheless, a bugzilla is not a forum of discussion. If you'd like to discuss it further please bring it on fedora security mailing list.