*** ON YOUR AUTHORITATIVE SERVER AUTH1 *** 1. 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/master # cp MYTLD MYTLD.backup Also create a directory for the keys to live in, and let's create them # mkdir /etc/bind/keys # chown bind /etc/bind/keys # cd /etc/bind/keys 2. Generate first key pair (Zone Signing Key - ZSK) # dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -n ZONE MYTLD You should see an output like: Kmytld.+008+51333 Write this down as the ZSK. 4. Generate second key pair (Key Signing Key - KSK) # dnssec-keygen -r /dev/urandom -f KSK -a RSASHA256 -b 2048 -n ZONE MYTLD You should see an output like: Kmytld.+008+52159 Write this down KSK. 4. Let's look at the keys: # ls -l -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 4. Add the public keys to the end of the zone file: Edit the zone file for MYTLD and add the keys at the end: # cd /etc/bind/master (edit the file MYTLD or whatever name you picked, and add the lines corresponding to your keys) ; Keys to be published in DNSKEY RRset $include "/etc/bind/keys/KMYTLD.+008+51333.key" ; ZSK $include "/etc/bind/keys/KMYTLD.+008+52159.key" ; KSK (Yes. the "$" must be in column 1) **** Increment the serial number. *** Save and exit. 5. Sign the zone with the keys # cd /etc/bind/keys # dnssec-signzone -x -o MYTLD -k KMYTLD.+008+52159 ../master/MYTLD KMYTLD.+008+51333 The first key is the KSK and the second the ZSK. 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 ../master/MYTLD.signed The signed zone has been written out in the master/ directory, so let's check it out: # cd /etc/bind/master/ # 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 6. Notice that a set of DS records has been generated, and is ready to be communicated to your parent zone: # cd /etc/bind/keys/ # 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. 7. Change the /etc/bind/named.conf definition that loads the zone, to point to the signed zone: zone "MYTLD" { type master; file "/etc/bind/master/MYTLD.signed"; // load the signed zone ... }; 8. Also in the named.conf, enable dnssec (for the authoritative part): ... in the options { .. }; section, add the following dnssec-enable yes; 9. Reconfigure/restart your nameserver If you have done the NSD or KNOT exercizes, we need to disable them and enable BIND by doing the following. # update-rc.d nsd disable # service nsd stop # update-rc.d knot disable # service knot stop # update-rc.d bind9 enable # service bind9 start Then ensure the new BIND configuration and zone are being used # rndc reconfig # rndc reload 10. Test that the nameserver is answering with DNSSEC records: # dig @127.0.0.1 MYTLD SOA +dnssec 11. Now you need to make sure that your slave has ALSO configured their nameserver to enable dnssec in their configuration (step 8). They should have done it since they are working on the same lab, but check anyway! To test: # dig @10.192.Y.1 MYTLD SOA +dnssec ... where Y is the IP of the partner you picked to be slave for your domain. # dig @10.192.Y.1 MYTLD DNSKEY +dnssec shows the public half of the keys you generated. DNS resolvers will use these keys to validate the data you publish in your zone. 12. You now need to communicate the DS to your parent We could 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. Besides, you already have a trusted relationship with your parent with the online web site used to deliver your NS records. So... Go to https://rzm.dnssek.org/ Login (you should have signed up earlier) Under "Trust Anchor Details" you should see that the DS has been automatically calculated from the DNSKEY records extracted from on 10.192.X.1. It is NOT automatically activated - the only thing RZM has done is "see" the DNSKEY you have published and is waiting for your confirmation to include the calculated DS in the parent zone. Match these with your actual DS record found here: # cat /etc/bind/keys/dsset-MYTLD. Then click on either or both "eye" icons (only one trust anchor is needed) till you get a "check" and then click "Update" to commit and then "logout". It may take a minute for the DS records to propagate through the class root system (update the unsigned root zone file, sign it, publish on root servers, loaded into caching resolver...etc) Once you are certain that the DS is included in the parent zone, using dig: dig @a.root-servers.net DS MYTLD. ... then you can begin to test validation! 13. Test that the AD bit is set: # dig @10.192.0.230 +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 @a.root-servers.net 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.