• Choose a category
• All
• Classic-Fiction

# dnssec-makekeyset -t 3600 -s +0 -e +864000 Kmydomain.com.+003+12345

bundles the public zone key that you just generated with a TTL of 3,600 seconds (one hour) and requests that the parent’s signature be valid for 10 days starting from now. dnssec-makekeyset creates a single output file, mydomain.com.keyset. You must then send the file to the parent zone for signing. It contains the public key and signatures generated by the zone keys themselves so that the parent can verify the child’s public key.

In BIND 9, the parent zone uses the dnssec-signkey program to sign the bundled set of keys:

# dnssec-signkey mydomain.com.keyset Kcom.+003+56789

This command produces a file called mydomain.com.signedkey, which the parent (com) sends back to the child (mydomain.com) to be included in the zone files for mydomain.com. In BIND 8, the parent uses the dnssigner command.

Once you have obtained the parent’s signature, you are ready to sign the zone’s actual data. The signing operation takes a normal zone data file as input and adds SIG and NXT records immediately after every set of resource records. The SIG records are the actual signatures, and the NXT records support signing of negative answers.

In BIND 8, you use the dnssigner program in the contrib directory of the distribution to sign a zone; in BIND9, you use the dnssec-signzone command. For example, the commands

# dnssigner -or mydomain.com -zi db.mydomain -zo

db.mydomain.signed -k1 mydomain.com dsa 12345 -st # BIND 8

# dnssec-signzone -o mydomain.com db.mydomain # BIND 9

read the zone file db.mydomain and produce a signed version of the zone file called db.mydomain.signed. The BIND 8 command shows several statistics about the signing operation (requested by the -st parameter). In particular, it shows how long it took to sign the zone and shows what records were added or deleted. It can take a long time to sign a zone.

A SIG record contains a wealth of information:

• The type of record set being signed

• The signature algorithm used (in our case, it’s 3, the DSA algorithm)

• The TTL of the record set that was signed

• The time the signature expires (as yyyymmddhhssss)

• The time the record set was signed (also yyyymmddhhssss)

• The key identifier (in our case 12345)

• The signer’s name (mydomain.com.)

• And finally, the digital signature itself

To use the signed zone, change the file parameter in the named.conf zone statement for mydomain.com to point at db.mydomain.signed instead of db.mydomain. In BIND 8, you must also include a pubkey statement in the zone statement; BIND 8 verifies the zone data as it loads and so must know the key beforehand. BIND 9 does not perform this verification. It gets the public key from the KEY record in the zone data and does not need any other configuration. Whew! That’s it.

Digital signatures are fine for positive answers like “Here is the IP address for the host anchor.cs.colorado.edu, along with a signature to prove that it really came from cs.colorado.edu and that the data is valid.” But what about negative answers like “No such host?” Such negative responses typically do not return any signable records.

In DNSSEC, this problem is handled by NXT records that list the next record in the zone in a canonical sorted order.14

If the next record after anchor in cs.colorado.edu was awesome.cs.colorado.edu and a query for anthill.cs.colorado.edu arrived, the response would be a signed NXT record such as

anchor.cs.colorado.edu. IN NXT awesome.cs.colorado.edu A MX NXT

This record says that the name immediately after anchor in the cs.colorado.edu zone is awesome, and that anchor has at least one A record, MX record, and NXT record. The last NXT record in a zone wraps around to the first host in the zone. For example, the NXT record for zamboni.cs.colorado.edu would point back to the first record, that of cs.colorado.edu itself:

zamboni.cs.colorado.edu. IN NXT cs.colorado.edu A MX NXT

NXT records are