% DNSSEC - signing

# Introduction

Communicate KSK DS to parent 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)

We have signed our zone, and we have checked that:

1. The zone is signed and dig shows the new DNSSEC records (DNSKEY,
   RRSIG, ...). Hint: use `dig @10.0.x.1 SOA mytld +dnssec`
2. Those changes are visible on the class resolver
   `dig @10.0.0.252 SOA mytld +dnssec`

Now, it's time to upload the DS record...

## The DS record set

You first need to create the DS record from the DNSKEY.

To do this:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ cd /etc/bind/keys
$ sudo -s
# dnssec-dsfromkey Kmytld.+123+12345.key > mytld.ds
# exit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Notiice that here we first run 'sudo -s' to become superuser *then*
executee the dnssec-dsfromkey command. If we don't do it as above,
the creation of the output file ('>') will be executed as the `sysadm`
user, and fail to write in `/etc/bind/keys`.

... be sure to replace mytld.+123+12345 with the *KSK* for your domain.

Check the `mytld.ds` file, it should look like this:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mytld. IN DS 63595 8 2 F0C439C872715BD2DA315EDC48029818BC7E6D04E987C09B577BEF9AEA3CB16C
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you don't see something similar to the above, run the command
again, but don't send the output to a file (... > mytld.ds) - and check
the output.

This file should now be communicated to your parent zone:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ cd /etc/bind/keys/
$ scp mytld.ds sysadm@10.0.0.237:ds/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The above command will Secure Copy to copy the DS file onto the ROOT
primary, in the ds/ subdirectory. You know the password :)

Let the instructors 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.
$ dig @10.0.0.252 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.

<!-- Markdeep: -->
<style class="fallback">body{visibility:hidden;white-space:pre;font-family:monospace}</style>
<script src="../../../../software/markdeep.min.js"></script>
<script>window.alreadyProcessedMarkdeep||(document.body.style.visibility="visible")</script>
<!-- End footer region -->