Closed mind04 closed 4 years ago
Ah so there is an issue introduced by my MR. Will take a look.
...Did the patch really work?
https://builder.powerdns.com/#/builders/99/builds/1219
Mar 16 17:05:26 clover pdns_server[16331]: PowerDNS Authoritative Server 4.4.0-alpha0.89.master.g148a1b87a (C) 2001-2020 PowerDNS.COM BV
$ dig +dnssec +norecurse @ns10.mattnordhoffdns.org unpublished.mattnordhoffdns.work dnskey
; <<>> DiG 9.16.0 <<>> +dnssec +norecurse @ns10.mattnordhoffdns.org unpublished.mattnordhoffdns.work dnskey
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61919
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;unpublished.mattnordhoffdns.work. IN DNSKEY
;; AUTHORITY SECTION:
unpublished.mattnordhoffdns.work. 3600 IN SOA pdns0.mattnordhoff.net. rname.mn0.us. 2020031300 1800 900 2678400 3600
unpublished.mattnordhoffdns.work. 3600 IN RRSIG SOA 13 3 3600 20200326000000 20200305000000 4819 unpublished.mattnordhoffdns.work. JU9ViMj3YUDk6PjB9DFT1CN0JJVvvbVbh9TuKzppETC2wkTXtOwa8WiR RanDqQ2R1g/lK1ZTqc9oGwgNIWq/Hw==
unpublished.mattnordhoffdns.work. 3600 IN NSEC unpublished.mattnordhoffdns.work. NS SOA RRSIG NSEC DNSKEY CDS CDNSKEY
unpublished.mattnordhoffdns.work. 3600 IN RRSIG NSEC 13 3 3600 20200326000000 20200305000000 4819 unpublished.mattnordhoffdns.work. Uz41XF1Pg9etKDIPMUYo/rCC8twhRTUQ9zBzmdiXT5nciFBXroeRghRa VyTR7g1tINqsr9r/MVKXhVxsVLbzsA==
;; Query time: 3 msec
;; SERVER: 2600:3c00::2:b422#53(2600:3c00::2:b422)
;; WHEN: Mon Mar 16 17:09:45 UTC 2020
;; MSG SIZE rcvd: 443
I am confuse.
Reopened for investigation. I've decided to not brown bag 4.3.0-RC2 over a small bug in a new feature.
The code is checking if !keyset.empty()
, but I think DNSSECKeeper::getKeys
returns every key, whether it's published or not?
In which case it would be necessary to loop over keyset
and check the published
attributes of each DNSSECPrivateKey
or KeyMetaData
or whatever.
Yes indeed, I made a derp. I will create a fix and add some test case tomorrow for this.
In a zone with active keys but without published keys the NSECx for the apex is including the DNSKEY type
Environment
Steps to reproduce
Expected behaviour
A denial without DNSKEY at apex
Actual behaviour
This issue is also present in the axfr output
Other information
It is unlikely this will result in operational issues since the zone is technically not signed when this is happening.