> Could you provide more details as to what specifically caused the fault? > Perhaps then other dns admins may learn something new to look for when > having to troubleshoot a similar problem. I know it would help me > further understand.
As I understand it (and I wasn't involved in diagnosing the problem, so I'm going by second-hand reports): ISC's signatures are kept up to date by a script. The private keys are stored offline for security, signatures are periodically generated by an internal, firewalled machine and then scp'd into place on the master server. The script that does all this failed, due to an unexpected variation in the input format, with the result that dnssec-signzone was run without all of the private keys in place. Signing with a subset of the private keys is legal, so dnssec-signzone didn't issue an error message. Unfortunately in this case it was also wrong, and it caused a temporary break in the chain of trust. Oops. Sorry. Lessons learned: The script is being improved, and we ourselves are more vigilant; this particular failure won't occur again. And we were already in the process of making dlv.isc.org substantially more robust, so hopefully any similar breakages that might have come along in the future will be stopped before they happen. I expect this to influence future BIND development too (for example, dnssec-signzone will probably be learning to print a few more warning messages when it sees legal-but-weird input.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users