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 DelegationSignerSubmitCommand.

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

What the 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?

The tweet is here for illustrative purposes only. What the user really wants is a smartphone notification, but that’s what mqttwarn is all about; it even has a dnsupdate plugin :-)

See also:

• Alert, backup, whatever on DNS NOTIFY with nsnotifyd