On Sat, Jan 29, 2011 at 10:30:47AM +0100, Christof Meerwald wrote: > On Sat, 29 Jan 2011 00:38:12 +0100, Christof Meerwald wrote: > > That's really excellent news - I have just migrated my 2 nameservers > > to SVN revision 1928 and signed one of the zones (btw, the setup is: > > master using bind backend for the zone data and gsqlite3 for the key > > data - slave is using gsqlite3 and AXFR from master). Let's see what > > happens... > > Hmm, I still don't understand DNSSEC well enough to really make some > sense of it all, but there are certainly some strange things here:
Indeed. > The zone I am testing with is cmeerw.priv.at, master dns is > ns.cmeerw.net and slave is ns2.cmeerw.net (and trying to use nsec3). Ok, so the setup is that both ns and ns2 have all the keying materials, and ns serves a pre-signed zone over AXFR. ns2 receives this AXFR, should rectify it and serve it using its knowledge of the private keying material. Note: what HAS been tested is where the slave has no keying material, and serves the zone in 'pre-signed' mode. This is not what you are doing, but it should still work! > Requesting the SOA record appears to work fine on both servers: > > dig +dnssec -t SOA cmeerw.priv.at @ns.cmeerw.net > dig +dnssec -t SOA cmeerw.priv.at @ns2.cmeerw.net Looks good. > But if I try to query for NS, I get some RRSIG records in the > additional section, but only from ns.cmeerw.net: > > ;; ADDITIONAL SECTION: > ns2.cmeerw.net. 28800 IN A 80.190.133.60 > ns2.cmeerw.net. 28800 IN RRSIG A 8 3 28800 > 20110210000000 20110127000000 35080 cmeerw.priv.at. > mKFWS0sPy8sFs4kWGgs0dvniiDAGzpgxPw/LgsCZ88r/k9Lc/+6pHK8k > nkh9QzshTFkHKfIsM5NBr8ABRMPSligLc+t6Qb2B3P+Sfz3kVoW1baoS > VTJAjkbMzTa5uD/HD6C0qX3KdMy4wxOq8YZAHislWkuNydCcM+/vGmBt fvo= > ns.cmeerw.net. 28800 IN A 84.200.12.152 > ns.cmeerw.net. 28800 IN RRSIG A 8 3 28800 > 20110210000000 20110127000000 35080 cmeerw.priv.at. > kfoB3v8GYzdKJ6afJR81msJ2AKGNQ/7HIsS50ISphbWqUK5UrLDe5kno > s1L8JoshcXxUyxcMl2s4SaJX3h+ImFsact8Xunl8fl+AwSJJrbHd4Dsb > M1OhxfpTaEHzvBgX/nR0Xam52xBm5ruqOL26mRZjjhbUqlSI21IbP9O6 UEY= This is a bug, which will be fixed in the next commit. PowerDNS does not realize it should not be signing stuff added to a record from an insecure zone. > not from ns2.cmeerw.net: > > ;; ADDITIONAL SECTION: > ns.cmeerw.net. 28800 IN A 84.200.12.152 > ns2.cmeerw.net. 28800 IN A 80.190.133.60 > > Note that both servers are authoritative for cmeerw.net, but the zone > is not signed. I bet ns.cmeerw.net has not been rectified on ns2.cmeerw.net. Even unsigned zones should be rectified! This should be automated in some way perhaps. > And finally, if I try to query a non-existing record, the response > seems reasonable from ns.cmeerw.net: > > ;; AUTHORITY SECTION: > cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. > domain.cmeerw.net. 2010080601 3600 900 1814400 3600 > cmeerw.priv.at. 28800 IN NSEC3 1 0 1 AB SO====== RRSIG No, this means that you have an NSEC3 configuration, but the 'order' field from the database has not been filled out. This is very weird since you tell me that ns.cmeerw.net runs with the BIND backend, which should do all that automatically. This smells like a separate bug. Can you confirm that ns.cmeerw.net has the cmeerw.priv.at zone in BIND, and can you show the output of 'pdnssec show-zone cmeerw.priv.at'? > but very strange from ns2.cmeerw.net: > > ;; AUTHORITY SECTION: > cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. > domain.cmeerw.net. 2010080601 3600 900 1814400 3600 > 8b40po8goooqdt13tad1l7j5oht0puo3.cmeerw.priv.at. 7200 IN NSEC3 1 0 1 AB > RRSIG=== NSEC3 This looks about as strange. This might be a follow-up bug fom what you see on ns.cmeerw.at, let's focus on that first. Bert _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users