search

PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.73k stars 914 forks source link

Issue with pre-signed slave zones in pdns-server 4.0.0 ? #4223

Closed sndrsmnk closed 8 years ago

sndrsmnk commented 8 years ago

There might be an issue with pdns-server 4.0.0 and the slaving of DNSSEC pre-signed zones.

Once 4.0.0 AXFRs the zone, the RRSIG-records for the pre-signed data are no longer served by the authoritative servers. Downgrading to 3.4.8 and AXFRing again fixes the situation and the RRSIG-records once again appear on the authoritative servers.

Setup is as follows:

The zone (configured as type MASTER) on ns1.freshdot.net is 'live signed' by PowerDNS. The RRSIG-records are verified to be present in the database used by nsauth1.bit.nl after nsslave.bit.nl AXFR'ed the zone.

The show-zone output on nsauth1.bit.nl is not as verbose (v3.4.8):

# pdnssec show-zone bokhard.nl
Zone is presigned
No keys for zone 'bokhard.nl'.

But on nsslave.bit.nl (v4.0.0) it looks perfectly sane:

# pdnsutil show-zone bokhard.nl
This is a Slave zone
Master: 213.154.236.182:53 
Last time we got update from master: Fri 2016-07-22 15:29:19
SOA serial in database: 2016070601
Refresh interval: 7200 seconds
Metadata items: None
Zone is presigned
Zone has hashed NSEC3 semantics, configuration: 1 0 10 7f48bd
keys: 
KSK, tag = 42064, algo = 8, bits = 2048
DNSKEY = bokhard.nl. IN DNSKEY 257 3 8 AwEAAbRIXrIUB9iBDoaH5rkzn0zrENUdHdQWvaOpqd1VJY4BCatqcGI+8IvCn1JsuFI5BEXTxDLKNAsvTCVTrfDumlzbQIs+fb85C0hfXOgvRtl4KuVenmCnZachkJd5wpeYXQ4t8gzW4IB29U68Io5Ciz2JUZqBBbx9CBFWCRoeWzqXYh/NrUbKf6jzZiZlhHECSGBmg/1Cq9WK6cKUAYXyzbTRjSx7ZLFAN8c8BuCcIIaMu8bJiQcU5hxaSAoAx/iCki1LljSvxxYo4fo1wAvMKannfUaV6Lh8/xxeN6OhA4Y9e/xzBn3ayZgaLjTKOqc9pn5eYtOeikIiZFbAF+hnefs=; ( RSASHA256 ) 
DS = bokhard.nl. IN DS 42064 8 1 2336a02b5a7cc2d219f947454950b9a76c62ceb0 ; ( SHA1 digest )
DS = bokhard.nl. IN DS 42064 8 2 989c5cfc02e7151a99a0b8e2f4fd4d4e29fc07063dc77993a3586f52f7323dd0 ; ( SHA256 digest )
DS = bokhard.nl. IN DS 42064 8 3 a864589e0fe56378914083fa091c1d94fcf3b5834eaf9f951dfe2c4d99192c99 ; ( GOST R 34.11-94 digest )
DS = bokhard.nl. IN DS 42064 8 4 e38c2ecb6cf39f9be69172e5ef8ad11ce148af47e38c0c42463adb67da5a7b826d3ae0ab956992fccb1a086b5c947c8a ; ( SHA-384 digest )
ZSK, tag = 6471, algo = 8, bits = 1024
DNSKEY = bokhard.nl. IN DNSKEY 256 3 8 AwEAAc0nCGZkRF1MW5Q+lQOHz7VPa7jyyxfFWDfl3basA11F3PmNGSzglGI3PpvNdoV4ilDEya5do0j6iNCCh1L9OOxCS5YAsIXEXquVem/LO1dkkCj+60YPE3idcaHzLWoPHfBVs1Eb7DjVOjugTdN9XfE/loTmDJiSwWCNcPOdnD6N; ( RSASHA256 )

Our resolver logs:

validation failure <bokhard.nl. NS IN>: no signatures from 2001:7b8:3:2c::53 for key bokhard.nl. while building chain of trust

Querying the auth server itself only returned the RRset queried, no RRSIGs, despite the '+dnssec' to dig.

Note: at this moment the situation is normal/working again since i've downgraded nsslave to v3.4.8. It is a production machine and i can't keep it in a broken state for too long. ;)

pieterlexis commented 8 years ago

Reproduced the infrastructure (4.0.0 signing master, 4.0.0 slave, 3.4.8 auth) where the auth uses the same database as the slave (but has slave=no set).

When transferring the zone, RRSIGs end up in the database:

pdns-slave=> select count(*) from records where type='RRSIG';
 count 
 -------
      9

And get served when querying for them:

lieter $ dig @127.0.0.1 -p5301 lieter.nl +dnssec +short
A 13 2 3600 20160804000000 20160714000000 5721 lieter.nl. joFl6uT3/I7AJAJsfuxNyZXzxAA+ADnWHxFnw9L59QMXVCbTfBDzAXfS HVNeXSTGLkFyq1ctSrKEYdv88YemAA==
1.2.3.4

Could you supply us with master and slave logs of the XFR and run pdnsutil check-zone on the master and the slave.

NB: the lack of output for pdnssec is expected. Output was extended for 4.0.0

sndrsmnk commented 8 years ago

I can reproduce this.

[sanders@haze:~] % dig @213.136.12.51 bokhard.nl +dnssec +short
213.154.236.176
A 8 2 300 20160804000000 20160714000000 6471 bokhard.nl. LIP6sgksEQY/o8J98RIAlvjC/LUKjizL4rnlWiq7yShGfm7tSaAcLlGN vcJPd3hucKiyWE64WlH2xzRQNbFMSymBVi2jV+cWH5uZj52WqQHDxLwB WkYe8h1tb6/xJgsa6r6goOF82j07UT0MeNOPzJmMU98f+liBP5zUqXP8 sso=
Jul 22 22:55:48 nsslave systemd[1]: Starting PowerDNS Authoritative Server...
[ .. ]
Jul 22 22:55:48 nsslave pdns_server[14330]: Jul 22 22:55:48 Done launching threads, ready to distribute questions
Jul 22 22:55:56 nsslave pdns_server[14330]: Jul 22 22:55:56 Initiating transfer of 'bokhard.nl' from remote '213.154.236.182'
Jul 22 22:55:56 nsslave pdns_server[14330]: Jul 22 22:55:56 Starting AXFR of 'bokhard.nl' from remote 213.154.236.182:53
Jul 22 22:55:56 nsslave pdns_server[14330]: Jul 22 22:55:56 AXFR started for 'bokhard.nl'
Jul 22 22:55:56 nsslave pdns_server[14330]: Jul 22 22:55:56 AXFR of 'bokhard.nl' from remote 213.154.236.182:53 done
Jul 22 22:55:56 nsslave pdns_server[14330]: Jul 22 22:55:56 Backend transaction started for 'bokhard.nl' storage
Jul 22 22:55:56 nsslave pdns_server[14330]: Jul 22 22:55:56 AXFR done for 'bokhard.nl', zone committed with serial number 2016070601
Jul 22 22:56:10 nsslave pdns_server[14330]: Jul 22 22:56:10 32 slave domains need checking, 0 queued for AXFR
Jul 22 22:55:56 services pdns_server[6834]: Jul 22 22:55:56 AXFR of domain 'bokhard.nl' initiated by 127.0.0.1
Jul 22 22:55:56 services pdns_server[6834]: Jul 22 22:55:56 AXFR of domain 'bokhard.nl' allowed: client IP 127.0.0.1 is in allow-axfr-ips
Jul 22 22:55:56 services pdns_server[6834]: Jul 22 22:55:56 AXFR of domain 'bokhard.nl' to 127.0.0.1 finished

(i have dnsdist in front of the master, i've had dnsdist out of the chain, same result, it's not dnsdist)

[sanders@haze:~] % dig @213.136.12.51 bokhard.nl +dnssec +short
213.154.236.176
root@nsslave:~# pdnssec check-zone bokhard.nl
Checked 24 records of 'bokhard.nl', 0 errors, 0 warnings.

While digging deeper, i found that in a working state, the fqdns in the database have a traling dot and in the non-working state they do not. Perhaps this is relevant in some way.

| RRSIG | NSEC3 8 3 86400 20160804000000 20160714000000 6471 bokhard.nl sVKQYqd... | RRSIG | NSEC3 8 3 86400 20160804000000 20160714000000 6471 bokhard.nl. sVKQYqd...

mind04 commented 8 years ago

The issue title is wrong. 3.4.8 is unable to serve a 4.0.0 presigned db (without the trailing dots)

My observations are: 4.0.0 is not adding dots, but has no problem if they are there 3.4.8 is adding dots, and is failing, as described above, if they are not there

pieterlexis commented 8 years ago

Fixed in #4229