generaterecords(1) generates a test dnssec zone that can be used to DNSSEC


generaterecords -v -d


The generaterecords script generates a zone file, given a domain name, which is then signed and modified to invalidate portions of the data in particular ways. Each generated record is named appropriately to how the security data is modified (the gooda record will contain a A record with valid DNSSEC data, but the badseca record will contain an A record where the signature has been modified to invalidate it).

The results of this process can then be served and test secure validators, applications, and other software can be thrown at it to see if they properly fail or succeed under the dns security policies being deployed.

After the files are generated, consider running donuts on them to see how the data in them has been tampered with to be invalid.


zonesigner from the dnssec-tools project bind software 9.3.1 or greater


To get started creating a new zone, you'll need to tell zonesigner to create new keys for all of the new zones that maketestzone creates. Thus, the first run of maketestzone should look like:
First Time:
maketestzone -k [OTHER DESIRED OPTIONS]

After that, the generated zone files can be loaded and served in a test server.

Once every 30 days (by default via zonesigner) the script will need to be rerun to recreate the records and resign the data so the signature date stamps remain valid (or in some cases invalid).

Every 30 days:


Below are thoe options that are accepted by the maketestzone tool.

Output File Naming:

Output prefix to use for zone files (default = db.)
Output suffix to be given to zonesigner (default = .zs)
Output suffix for the modified zone file (default = .modified)
Run donuts on the results
The file suffix to use for donuts output (default = .donuts)

Output Zone Information:

domain name to generate records for
Comma separated name=addr name-server records
A record (IPv4) address to use in data
AAAA record (IPv6) address to use in data

Output Data Type Selection:

Comma separated list of record prefixes to use
Comma separated list of NS record prefixes to use
Don't create CNAME records
Don't create sub-zone records

Task Selection:

Do not generate the zone; use the existing and sign/modify it
Do not run zonesigner to sign the records
Do not destroy the records and leave them properly signed
Generate a bind configuration file snippit to load the DB sets
Generate a HTML page containing a list of record names
Generate a Apache config snippit for configuring apache for each zone record
Generate a test script for running dig commands
Verbose output

Zonesigner Configuration:

Arguments to pass to zonesigner
Have zonesigner generate needed keys

Bind Configuration Options

The base directory where the bind DB files will be placed

HTML Output Configuration

Make each html record name a http link to that address
Add a link to each of the generated DB files.
Add a link to each of the generated donuts error list files.

SH Test Script Configuration Options

The resolver address to force

Help Options

Display a help summary (short flags preferred)
Display a help summary (long flags preferred)
Display all help options (both short and long)
Display the script version number.


The following section discusses how to extend the maketestzone tool with new output modifications.


For the legend HTML output, the %LegendInformation hash contains a keyname and description for each modification type.


The %zonesigner_domain_opts hash lists additional arguments between how zonesigner is called for various sub-domains. Thus you can create additional sub-zones with different zonesigner optionns to test other operational parameters between parent and child. For example:

   'rollzsk-ns.' . $opts{'d'} => '-rollzsk',

Forces the rollzsk-ns test sub-zone to roll it's zsk when the zone is signed.


Maketestzone is in early development stages but already has the beginnings of an extnesible system allowing you to modify records at will based on regexp => subroutine hooks.

To add a new modification, add a new keyword to the 'p' and optionally 'P' default flags (or add it at run time), and then add a new function to the list of callbacks defined in the %destroyFunctions hash that is based on your new keyword. When the file is getting parsed and hits a record matching your expression, your functional will be called. Arguments can be added to the function by passing an array reference where the first argument is the subroutine to be called, and the remainder are additional arguments. Output lines should be printed to the $fh file handle.

Here's an example function that deletes the RRSIG signature of the next record:

  sub delete_signature {
      # the first 2 arguments are always passed; the other was in the
      # array refeence the subroutine was registered with.
      my ($name, $type, $expr) = @_;
      Verbose("  deleting signatures of $_[0]");
      # print the current line
      print $fh $_;
      my $inrec = 0;
      while (<I>) {
        # new name record means we're done.
        last if /^\w/;
        # we're in a multi-line rrsig record
        $inrec = 1 if (/$expr\s+$type/);
        # print the line if we're not in the rrsig record
        print $fh $_ if (!$inrec);
        # when done with the last line of the rrsig record, mark this spot
        $inrec = 0 if (/\)/);

This is then registered within %destroyFunctions. Here's an example of registering the function to delete the signature on a DS record:

   '^(nosig[-\w]+).*IN\s+NS\s+' => [\&delete_signature, 'DS', 'RRSIG'],


Copyright 2004-2013 SPARTA, Inc. All rights reserved. See the COPYING file included with the DNSSEC-Tools package for details.


Wes Hardaker <[email protected]>