Manual Signing

Introduction

Manual DNSSEC signing of your zone.

Notes

Commands preceded with “$” imply that you should execute the command as a general user - not as root.
Commands preceded with “#” imply that you should be working as root.
Commands with more specific command lines (e.g. “rtrX>” or “mysql>”) imply that you are executing commands on remote equipment, or within another program.

On your AUTHORITATIVE server (SOA)

Backup your zone!

Change to the directory where the zone resides, and make a backup of the zone (assuming it’s called mytld), just in case

$ cd /etc/bind/zones/mytld
$ sudo cp mytld mytld.backup

Generate the first key pair (Zone Signing Key - ZSK)

$ sudo dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -n ZONE mytld

You should see an output like:

Kmytld.+008+51333

Make a note of this on a piece of paper - label it “ZSK”.

Generate second key pair (Key Signing Key - KSK)

$ sudo dnssec-keygen -r /dev/urandom -f KSK -a RSASHA256 -b 2048 -n ZONE mytld

You should see an output like:

Kmytld.+008+52159

Make a note of this on a piece of paper - label it “KSK”.

Inspect the keys

$ ls -l K*

-rw-r--r--  1 root  wheel   417 Nov 29 00:07 Kmytld.+008+51333.key
-rw-------  1 root  wheel  1012 Nov 29 00:07 Kmytld.+008+51333.private
-rw-r--r--  1 root  wheel   590 Nov 29 00:07 Kmytld.+008+52159.key
-rw-------  1 root  wheel  1776 Nov 29 00:07 Kmytld.+008+52159.private

Add the public keys to the end of the zone file:

Edit the zone file for mytld

$ cd /etc/bind/zones/mytld
$ sudo editor mytld

At the end of the zone file, add the following lines:

; Keys to be published in DNSKEY RRset

$INCLUDE "/etc/bind/zones/mytld/Kmytld.+008+51333.key"     ; ZSK
$INCLUDE "/etc/bind/zones/mytld/Kmytld.+008+52159.key"     ; KSK

(Yes. the “$” must be in column 1)

This will tell BIND to include (load) the key files into the zone, when reading the zone file.

Remember to increment the serial number before saving!

Save and exit.

Sign the zone with the keys

$ sudo dnssec-signzone -x -o mytld mytld

You should see as output:

Verifying the zone using the following algorithms: RSASHA256.
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
mytld.signed

The signed zone has been written to a new file. Let’s check it out:

$ cd /etc/bind/zones/mytld
$ ls -l mytld*

-rw-r--r--  1 root  wheel   292 Nov 29 00:08 mytld
-rw-r--r--  1 root  wheel  4294 Nov 29 00:20 mytld.signed

Take a look at the zone contents, and observe the new records and signatures. You could use:

$ less mytld.signed

The DS record set

Notice that a set of DS records has been generated, and is ready to be communicated to your parent zone:

$ cd /etc/bind/zones/mytld/
$ sudo ls -l dsset-*

-rw-r--r--  1 root  wheel  155 Nov 29 00:22 dsset-mytld.

Look at the contents of the dsset:

$ cat dsset-mytld.

Update BIND configuration

Change the /etc/bind/named.conf.local definition that loads the zone, to point to the signed zone:

zone "mytld" {
   type master;
   file "/etc/bind/zones/mytld/mytld.signed"; // load the signed zone
   ...
};

Reconfigure BIND

$ sudo rndc reconfig

Test the zone

Verify that the nameserver is serving the zone with DNSSEC records:

$ dig @127.0.0.1 mytld SOA +dnssec

Communicate DS to your parent

We can manually deliver the DS record to our parent and they could type this in (after you both had a secret handshake) but this is prone to error.

Refer to your network diagram. What server is 10.0.0.237?

$ scp /etc/bind/zones/mytld/dsset-mytld. sysadm@10.0.0.237:

Let the instructor know when you’ve done this!

Once you are certain that the DS is included in the parent zone, using dig:

dig @10.0.0.237 DS mytld.

… then you can begin to test validation!

Test that the AD bit is set:

dig @10.0.0.252 +dnssec www.mytld.

Is it ?

If not, note that the root manager may not have necessarily signed the root zone with your DS included yet, OR due to the negative TTL, the DS record may not be in the cache of the resolver. You may have to wait, but check with your root manager, and you can always check at the root:

dig @10.0.0.237 DS mytld.

… to verify that the DS is published. Then it’s a matter of waiting for the cache to expire on the resolver, before you can verify your signatures.