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
dnsnotify.pl.
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!
