Bind 9.9rc2 notification gone wild

Michael Graff mgraff at isc.org
Wed Feb 1 17:33:18 UTC 2012


Key management (and how BIND 9 in the form of named handles issues like this) is likely too large a topic to address before 9.9.0 is out.  I don't think the management has gotten worse from 9.8 to 9.9 though.

We're hoping to make key management the next major focus area in bind 9, now that we have inline signing.  That would help round-out the dnssec offering.

--Michael

On Feb 1, 2012, at 11:23 AM, Spain, Dr. Jeffry A. wrote:

>>> I can install bind 9.9.0rc2 tomorrow and test with both nsupdate and 
>>> rndc reload. I would also like to test DNSSEC automatic key rollover 
>>> with inline signing again. I imagine this will be fixed in rc2, given 
>>> the success of the patch you provided earlier. My next ZSK activation 
>>> date is 3/10/2012 with inactivation of the previous key on 3/11 and deletion 
>>> on 4/15. I will move those dates up 5 weeks on one of the zones in the 
>>> hope of getting test results sooner, although ultimately the timing 
>>> depends on individual signature expiration dates.
> 
>> Thank you.  9.9.0rc2 is now available to BIND Forum members for initial testing before we roll it out to the public tomorrow.
> 
> I created a comedy of errors modifying the key metadata for the test described above. Bind's behavior in the face of this may or may not be something you want to address in the run-up to the bind 9.9.0 release, but I think it does also demonstrate that the problem with expired signatures in inline-signed zones in 9.9.0rc1 has been fixed. Here's what happened.
> 
> I made metadata changes to two keys using dnssec-settime yesterday morning. Yesterday evening, as previously posted, I discovered that bind couldn't read the private key files due to the mode change to 0600 made by dnssec-settime. The syslog contained a series of helpful messages in this regard:
> 
> Jan 31 11:52:52 nstest named[845]: dns_dnssec_keylistfromrdataset: error reading private key file jaspain.us/RSASHA1/55158: permission denied
> Jan 31 11:52:52 nstest named[845]: dns_dnssec_keylistfromrdataset: error reading private key file jaspain.us/RSASHA1/30795: permission denied
> Jan 31 11:52:52 nstest named[845]: dns_dnssec_findmatchingkeys: error reading key file Kjaspain.us.+005+55158.private: permission denied
> Jan 31 11:52:52 nstest named[845]: dns_dnssec_findmatchingkeys: error reading key file Kjaspain.us.+005+30795.private: permission denied
> 
> These were repeated hourly with each "next key event". Yesterday evening I fixed the permissions on the private keys and a new series of errors began to appear. It turns out that by mistake I had set the currently active key (55158) to become inactive 24 hours before its published successor (30795) was due to be made active. This resulted in the following series of log messages, also very helpful and informative:
> 
> Feb  1 06:19:17 nstest named[845]: zone jaspain.us/IN (signed): Key jaspain.us/RSASHA1/55158 missing or inactive and has no replacement: retaining signatures.
> Feb  1 06:19:17 nstest named[845]: zone jaspain.us/IN (signed): sending notifies (serial 2011111512)
> Feb  1 06:19:52  named[845]: last message repeated 7 times
> Feb  1 06:20:53  named[845]: last message repeated 12 times
> Feb  1 06:21:53  named[845]: last message repeated 12 times
> Feb  1 06:22:53  named[845]: last message repeated 12 times
> ... and many more such.
> 
> Apparently bind found the need to update some signatures on the signed zone jaspain.us but could not do so without an active ZSK. Despite its inability to update the signed zone and despite no increment in the serial number, it started sending notifies to its slave server every five seconds. Looking at the slave server logs confirms this, with entries like the following being present every five seconds:
> 
> Feb  1 06:19:52 nstest2 named[735]: client 2001:4870:20ca:158:4423:f19d:4ead:5c20#29061/key nstest-nstest2.countryday.net: received notify for zone 'jaspain.us': TSIG 'nstest-nstest2.countryday.net'
> Feb  1 06:19:52 nstest2 named[735]: zone jaspain.us/IN: notify from 2001:4870:20ca:158:4423:f19d:4ead:5c20#29061: zone is up to date
> 
> When I observed this behavior this morning, I corrected the key metadata making ZSK 30795 active at 8:30 a.m. Almost immediately afterwards the master server made some modifications to the signed zone, incremented its serial number, sent another notify, and transferred the zone:
> 
> Feb  1 08:30:03 nstest named[845]: zone jaspain.us/IN (signed): sending notifies (serial 2011111513)
> Feb  1 08:30:03 nstest named[845]: client 2001:4870:20ca:9:1890:f431:72c9:caaf#37863/key nstest-nstest2.countryday.net (jaspain.us): transfer of 'jaspain.us/IN': IXFR started: TSIG nstest-nstest2.countryday.net
> Feb  1 08:30:03 nstest named[845]: client 2001:4870:20ca:9:1890:f431:72c9:caaf#37863/key nstest-nstest2.countryday.net (jaspain.us): transfer of 'jaspain.us/IN': IXFR ended
> 
> The slave's log also shows that this transfer was successful:
> 
> Feb  1 08:30:03 nstest2 named[735]: client 2001:4870:20ca:158:4423:f19d:4ead:5c20#32186/key nstest-nstest2.countryday.net: received notify for zone 'jaspain.us': TSIG 'nstest-nstest2.countryday.net'
> Feb  1 08:30:03 nstest2 named[735]: zone jaspain.us/IN: Transfer started.
> Feb  1 08:30:03 nstest2 named[735]: transfer of 'jaspain.us/IN' from 2001:4870:20ca:158:4423:f19d:4ead:5c20#53: connected using 2001:4870:20ca:9:1890:f431:72c9:caaf#37863
> Feb  1 08:30:03 nstest2 named[735]: zone jaspain.us/IN: transferred serial 2011111513: TSIG 'nstest-nstest2.countryday.net'
> Feb  1 08:30:03 nstest2 named[735]: transfer of 'jaspain.us/IN' from 2001:4870:20ca:158:4423:f19d:4ead:5c20#53: Transfer completed: 1 messages, 14 records, 2014 bytes, 0.028 secs (71928 bytes/sec)
> 
> Since then the logs have been quiet.
> 
> Examining the signed zone with named-checkzone shows a number of signatures by the newly activated ZSK 30795. In fact all of the old signatures by ZSK 55158 that were due to expire on or before February 8 were updated. This supports the idea that the problem with expired signatures in inline-signed zones in 9.9.0rc1 has been fixed.
> 	
> The storm of notifications every five seconds when signature updates are required and no active key is available is obviously an outlier condition to some degree. Interesting none the less.
> 
> Jeffry A. Spain
> Network Administrator
> Cincinnati Country Day School
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users




More information about the bind-users mailing list