>>**Project pages**: 
~[[ksknzsk | Root Zone Keys]]
~[[dnssecds | TLD DS Distribution]]
~[[dnssecplan | The Plan]]

**Links**:
~ 

>>

======Purpose======
Sign the OpenNIC root zone

======Tasks======
	- Modify the makeroot.sh script to output DNSSEC into the root zone - Jeff
	- Modify the makeroot.sh script to suck in DS records for OpenNIC TLDs - Jeff
	- Modify the makeroot.sh script to sign the root zone - Jeff
	- Create the ZSK and KSK OpenNIC keys
	- Create a maintenance policy for key refreshing(key-rolling policy)
	- Create a method to sync DS keys in a secure way

======Root Zone Script Changes======

The makeroot.sh script will need to be modified a little bit to support signing a root zone. Currently the script will output a DNSSEC zone but not output this into the actual zone created. This will first need to be enabled. Next the script will need to know how to inject DS records for signing. Then finally the script will need to sign the end zone. The first and last changes are straight forward as the script was built with forethought.

Injecting the DS records into the zone is also easy, but it is complicated by the fact we need to plan where they will live on ns0. Basically a TLD will send their dsset-* file to ns0 for verification and pending injection into the root zone. The script will in theory just have to look in a directory for all dsset-* files to inject, it does not actually need knowledge of what zones it's injection information for.

Once the DS records for all OpenNIC zones are injected, the root zone can be signed. Each time the root zone is re-generated it will be DNSSEC signed again.

An issue that can occur with DNSSEC is if there is an error or a misconfigured DS record makes it into the root zone it will break DNSSEC and possible the zone. In DNSSEC land, when an issue arise's from the DS key a SERVFAIL code is returned.  We have to devise a method to check all DNSSEC signed TLDs that they work with the new zone. We come to an issue here. Do we generate the zone then test it once it's in prod? I haven't tested yet, but maybe named-checkzone will pick this up?

Changes to the script:
	- Change to a config file(for the key location), this way the keys can be listed in there as the names changes every 3 or 6 Months
	- Add in function to sign the root zone

======Root Zone Keys======

The ZSK and KSK keys for the root zone will be created in a dir called dnssec in /etc/bind/ on ns0. It will be root RW only, no other permission bits will be set. This will ensure that only root can read these keys. As makeroot.sh is run by the root user, this will not call any issues.

====Key Rolling====
//Read: Key Maintenance//
The ZSK and KSK need to be regenerated every 3 or 6 months. This process is formally known as key-rolling. With TLDs this process will be integrated into the process of passing the dsset-* files to ns0. On ns0 there will be a certain key-rolling process. When the keys are first created, a file will also be created called CREATED. In this file will be the date the keys were created on. There will be a cron run once a week that checks this created date. When it comes down to the last week, it will email out everyday to remind the admin to re-generate the keys.

**Please see [[ksknzsk | Root Zone Keys]] for more information on this subject. I think it will turn into a complex document that warranted it's own page.**

======Distributing the root DS keys======

The DS keys for the root zone need to be distributed to all T1 servers and any T2's who wish to use it to enable dnssec for opennic root. There has been quite a few discussions about how this will be done. Some ideas are;

	- GPG armour encrypt the DS keys file
	- Make them available online via HTTPS
	- Get users to grab it from dnskey RR then verify with a TXT record of a GPG signature

**Please see [[dnssecds | TLD DS Distribution]] for more information on this subject. I think it will turn into a complex document that warranted it's own page.**

======Trusting the Root Zone======

Until the anchor keys have been published, you may use the following method in BIND9 to enable DNSSEC validation.

Begin by collecting the current DNSKEY for the root zone:
%%# dig +tcp +multi +noall +answer DNSKEY . @45.56.115.189%%
You are specifically looking for the block containing "IN DNSKEY 257 3 8".  If there is more than one such entry, you only need to use the first one.

In /etc/bind/bind.keys, copy the actual key into an entry like this:
%%managed-keys {
	"." initial-key 257 3 8 "
		AwEAAe2SqWzJDU5l8IiTdWIEi4gG0fNGXzX3ISbU1a6J
		AsUPFl7rCWDe9f5J67xGSAkbwS2doYzvPL72AmI077wF
		apBtNFCgUT4KruO+f0j0pO74QFM6dFlIRbVJBUuTReRc
		ikiqP8e1wWvLXd4PknSkAi6k+TQpl48YOEYCrf1jqWqP
		TJVZuJlMMdYyHSXndRhN5QF7+kP7FmulpDhLCNLFVHWC
		XXxHtd6AgF6OyuTMr1iQd44tBz2e8sNK9qJ9fsCvF2iR
		RUlePh1q2WKzC6DGJ5PJgeHKefSE515+hdyBWhGId2u7
		yOTNMxcbAOq17KOmf/fct1nvlqOMcLZ55oKPy0t9nU/n
		iQaYhU0P+F8rmdyCkK29ri4hbBHgOO7INw2ElYxAB/ui
		hgC+7ErTkQg5iZiIrGvAMXIeV0tXsB+QNgAFqAHpuNji
		yaXBnNkNYUKKcnHr54lJ2grXXSIgK/et2vPgeQK9TWNX
		7yiLwRcE6Nw8jK0ZdpfOujGgVnvVfOtJaTVkT2qyXp0M
		3FSQG8Se0C0x17Pvu9Jrs44P6cDwcA5nQPMjEZOyHdk+
		LeYrk41qhWubVF3D1MeJdxwgL8ZtW8Rk5J55SlQZU8cm
		bd8cklpiRYA/60G++wvatfKQs24zB/rlC0yXKWZ/IuRG
		N/p96Fes8O+sYAWFOHq/kA43fpgJ";
};%%

Now edit /etc/bind/named.conf.options and add the following lines as needed:
%%	dnssec-enable yes;
	dnssec-validation auto;
	dnssec-lookaside auto;%%

Restart BIND and check the log file.  You should see an entry similar to this:
%%managed-keys-zone ./IN: Initializing automatic trust anchor management for zone '.'; DNSKEY ID 39775 is now trusted, waiving the normal 30-day waiting period.%%

At this point you should be able to securely query DNS using DNSSEC validation.

======Misc======

Anyone is welcome to contribute their ideas within these project pages. If your unsure how to do so, just leave a comment. To see the plan as it is developed please see "[[dnssecplan | The Plan]]".