Somebody asked me whether it would be possible to be notified (no pun intended) of new DNSSEC keys as they are published in a zone, and I referred them to Stéphane Bortzmeyer's key-checker which I mentioned when I talked about RFC 5011 with OpenDNSSEC, BIND, and Unbound recently. They wanted something more "live", as in "tell me now!", so I thought I'd give it a shot.
OpenDNSSEC has a
DelegationSignerSubmitCommand which is invoked when a new KSK is created. This command is fed a DNSKEY resource record (RR) on stdin, and it's intended to construct a DS record set and submit that to a parent zone. As far as I can tell, it's only invoked for new KSKs, so I had to go a different route because, say, revoked keys wouldn't be passed to the
It occurred to me to re-use some of the ideas developed for automatic provisioning of slave DNS servers, in which I used a bit of
Net::DNS::Nameserver to listen for DNS
NOTIFY packets. Unfortunately dnspython doesn't have any of that, so I had to fall back on Perl.
The OpenDNSSEC signer uses DNS adapters to NOTIFY a bunch of NSD name servers that a zone is ready for transfer. These in turn slave the zone and make it available to the world. In addition, when NSD transfers a DNSSEC-signed zone, I've configured it to send a DNS
NOTIFY to a small utility called
key-listen which runs on port 5353 of 127.0.0.1 on one of the NSD hosts:
zone: name: "d1.aa" zonefile: "d1.aa.zone" allow-notify: 192.168.1.110 NOKEY request-xfr: 192.168.1.110 NOKEY notify: 127.0.0.1@5301 NOKEY # for key-listen.pl
key-listen utility does it to set up a handler for DNS NOTIFYs which contain the source address and the zone being notified. When NSD is notified from OpenDNSSEC, it does its transfer thing, and then notifies
key-listen. The program then "turns around" to query the DNSKEY RRset for the zone from NSD and dumps it into a file for logging purposes. This is what the program writes:
d1.aa. 300 IN DNSKEY 257 3 8 AwEAAc ... MjdPG6P4Ex8= ; Key-ID 9562 d1.aa. 300 IN DNSKEY 385 3 8 AwEAAc ... L5P8LKFEVKs= ; Key-ID 13008
In addition it records the key id (keytag) and the flags of the keys we're interested in.
So far so good, but how to "notify" the user? I suppose any sort of monitoring solution would have done the job, but I thought this should be "flexibilized" (that's a word I recently invented), so, in the spirit of how do your servers talk to you? I wanted this to be easy. It is.
That tweet contains the keytag and the DNSKEY flags for each of the KSK in the zone
d1.aa. OK, it may be a little crazy, but it works really well, and it's not half as bonkers as tweeting via RFC 2136 dynamic updates, is it?