There are no DNSKEY records in that zone. CDS and CDNSKEY must be signed for the parent to accept them. There must be DNSKEY records present for them to be signed. Add a DNSKEY record to that test zone and it will load.
For inline zone just copy the final DNSKEY RRset from the signed version of the zone to the raw zone when adding the deletion CDS and CDNSKEY records. Wait for the parent zone to remove the DS records, then remove the CDS, CDNSKEY, and DNSKEY records from the raw zone. Mark > On 21 Feb 2020, at 18:31, Tom <li...@verreckte-cheib.ch> wrote: > > Hi Mark > > Thank you for your answer. BIND is definitely running the current version: > > $ rndc status > version: BIND 9.16.0 (Stable Release) <id:6270e60> () > running on server: Linux x86_64 3.10.0-1062.4.3.el7.x86_64 #1 SMP Wed Nov 13 > 23:58:53 UTC 2019 > boot time: Thu, 20 Feb 2020 16:30:15 GMT > last configured: Thu, 20 Feb 2020 16:31:25 GMT > configuration file: /etc/named/named.conf > (/opt/chroot/bind/etc/named/named.conf) > CPUs found: 4 > worker threads: 4 > UDP listeners per interface: 4 > number of zones: 110 (98 automatic) > debug level: 0 > xfers running: 0 > xfers deferred: 0 > soa queries in progress: 0 > query logging is OFF > recursive clients: 0/900/1000 > tcp clients: 2/150 > TCP high-water: 103 > server is up and running > > > I've removed the CDS/CDNSKEY records from the zone with dnssec-settime -K > [key-directory] -D sync now Kexample.com... > > So the CDS/CDNSKEY are no more longer existing in the zone and are no longer > queryable with dig -> as expected: > $ dig @127.0.0.1 +noall +answer cds example.com -> No output > $ dig @127.0.0.1 +noall +answer cdnskey example.com -> No output > > So from my point of view, I have now a clear starting point where no longer > CDS/CDNSKEY records are published. > > When I now configure the explicit deletion record(s) within the zone for > "CDS" and/or "CDS/CDNSKEY", then BIND is still failing with the mentioned > error. > > The zonefile looks like this: > -------- SCHNIPP -------- > $TTL 3600 > example.com. IN SOA ns1.example.com. dnsadmin.example.com. ( > 2020022104 > 10800 > 3600 > 1209600 > 3600 ) > > example.com. IN NS ns1.example.com. > example.com. IN NS ns2.example.com. > > @ IN CDS 0 0 0 00 > @ IN CDNSKEY 0 3 0 AA== > -------- SCHNAPP -------- > > > 21-Feb-2020 08:13:40.939 general: error: zone example.com/IN (unsigned): > CDS/CDNSKEY consistency checks failed > 21-Feb-2020 08:13:40.939 zoneload: error: zone example.com/IN (unsigned): not > loaded due to errors. > > > Thank you. > > Kind regards, > Tom > > > > On 20.02.20 19:41, Mark Andrews wrote: >> Tom, >> I would run ‘rndc status’ or ‘dig ch txt version.bind @server’ and >> confirm >> that you have restarted named with the new code. I’ve had hundreds of 'bug >> reports’ about non fixed bugs that where operators failing to restart named >> after >> installing the new version. The new code is in 9.16.0, 9.14.11, and 9.11.16. >> I would check that the *only* CDS record is a deletion record is present. >> A CDS deletion record and a non CDS deletion record is a error. Similarly >> for CDNSKEY. A CDS/CDNSKEY deletion record and other CDS/CDNSKEY records >> in a RRset make no sense. You are either deleting all DS records or >> replacing >> all the DS records with the CDS records, or generating a new set of DS >> records >> from the CDNSKEY records. You can't do both at once. >> Mark >>> On 21 Feb 2020, at 03:54, Ondřej Surý <ond...@isc.org> wrote: >>> >>> Hi Tom, >>> >>>> On 20 Feb 2020, at 17:42, Tom <li...@verreckte-cheib.ch> wrote: >>>> >>>> Hi >>>> >>>> With 9.16.0, the CDS deletion >>>> (https://gitlab.isc.org/isc-projects/bind9/issues/1554) is still not >>>> working and is ending with the same error as bind-versions before: >>>> >>>> 20-Feb-2020 17:31:25.381 general: error: zone example.com/IN (unsigned): >>>> CDS/CDNSKEY consistency checks failed >>>> 20-Feb-2020 17:31:25.381 zoneload: error: zone example.com/IN (unsigned): >>>> not loaded due to errors. >>>> >>>> In which version will this issue be fixed? >>> >>> it will be included in the next version when the issue in question gets >>> picked up by a developer, >>> be triaged, test written and code fixed. I can’t really say when this will >>> happen, our developer >>> resources are thin and there are more issues that require our attention. >>> That said - this is open >>> source and we happily accept external contributions in a form of merge >>> request in our gitlab instance >>> (you need to ask for a permission to fork the project) or as a patch. This >>> seems to be fairly trivial >>> bug that might be a good start if anybody wants to help fix bugs in BIND 9. >>> >>> Cheers, >>> Ondrej >>> -- >>> Ondřej Surý >>> ond...@isc.org >>> >>> _______________________________________________ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> 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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
