As mentioned the other day, I’ve been tinkering with OpenDNSSEC, and I’m quite pleased with results so far. The background: for a client I need a system that will take care of as much as possible of the management tasks needed for managing keys, signing zones, etc., and OpenDNS appears to fit the bill to perfection. At least so far. I mentioned already that OpenDNSSEC can read plain zone files (i.e. unsigned zone files) from either the file system or via AXFR (zone transfer), using the zone_fetcher. It does real zone transfers, so even getting and signing a zone stored in PowerDNS isn’t a problem. I’ve set up a test environment like this: The stuff on the left is an authoritative hidden name server (Bind in this case) which reads zones off the file system, just like it always did. (Nothing special here, move on!) The chkr program is lots of magic: it compiles a zone to ensure it is valid, retrieves the zone’s serial number and verifies I’ve incremented it, check the zone into a Git repository (for backup, retrieval, and shit-happens situations), and when all is well, informs the Bind server (top left) that it should reload the zone. Bind notifies the zone_fetcher running in the blue box. The blue box contains all of OpenDNSSEC’s things. It runs on the same machine but need not to. It pulls in the zone it was NOTIFY’ied (I know that is incorrectly spelled) to, stores it and kicks off OpenDNSSEC’s signer to do the hard work. When the signing stuff is done (including creation of required keys, NSEC3’ing and all of that), OpenDNSSEC drops the signed zone into a directory and launches my reloader, giving it the name of the zone it has just finished signing (in %zone). My reloader now goes off and notifies the front-end name server (Bind or NSD), which reloads the signed zone from the file system. This notification is easily done wither either rndc or a DNS NOTIFY such as with

Speed and memory

I’ve been testing a bit with a number of zones, one of which has 85,000+ resource records in it. In a default KASP configuration, the zone is signed and it is then passed to the auditor, which rigorously checks the zone for errors. On the system I’m testing on, processing of this zone takes about 12 minutes from start to finish (signing and auditing). Changing the KASP configuration to do a partial audit only reduces that time by about 9 minutes. If however, I disable zone auditing entirely in the profile, a full signing (with no auditing) is reduced to between 1 and 3 minutes depending on whether keys need to be generated, etc. (This is measured from AXFR begin by the zone_fetcher until notification that the zone has been signed.) This is quite a substantial difference. I’m not yet sure of what exactly the auditor does; the documentation says:

If you are signing a large number of zones and have a high work load on your server, the memory resources might get exhausted because each instance of the auditor has its own Ruby VM.

I’ll have to see whether running the auditor on the target hardware is viable; if not, I think we’ll just switch it off. (May be dangerous.)

Apropos speed: I digress: When working with large zone files it can really be worth your while to search for the proper tools to use. As an example, I had a program based on Net::DNS::ZoneFile::Fast I used to extract the serial number from the SOA of a zone. Running that on the above largish zone took 27 seconds of wall-clock time; the Perl module parses the whole file. I found an ldns-based program in the OpenDNSSEC distribution called get_serial, which does the same and completes in under 1 second!

DNS, CLI, and dnssec :: 17 Sep 2010 :: e-mail