Chapter 4. Signing
Prev	DNSSEC Guide	Next

DNSSEC Guide : Chapter 4. Signing

Easy Start Guide for Signing Authoritative Zones

This section provides the minimum amount of information to setup a working DNSSEC-enabled authoritative name server. A DNSSEC-enabled zone (or "signed" zone) contains additional resource records that are used to verify the authenticity of its zone information.

To convert a traditional (insecure) DNS zone to a secure one, we need to create various additional records (DNSKEY, RRSIG, NSEC or NSEC3), and upload verifiable information (such as DS record) to the parent zone to complete the chain of trust. For more information about DNSSEC resource records, please see the section called “What does DNSSEC Add to DNS?”.

Note

In this chapter we assume all configuration files, key files, and zone files are stored in /etc/bind. And most of the times we show examples of running various commands as the root user. This is arguably not the best setup, but we don't want to distract you from what's important here: learning how to sign a zone. There are many best practices for deploying a more secure BIND installation, with techniques such as jailed process and restricted user privileges, but we are not going to cover any of those in this document. We are trusting you, a responsible DNS administrator, to take the necessary precautions to secure your system.

For our examples below, we will be working with the assumption that there is an existing insecure zone example.com that we will be converting to a secure version.

Generate Keys

Everything in DNSSEC centers around keys, and we will begin by generating our own keys. In our example, we are keeping all the keys for example.com in its own directory, /etc/bind/keys/example.com.

# mkdir -p /etc/bind/keys/example.com
# cd /etc/bind/keys/example.com
# dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...++++++ .............++++++ 
Kexample.com.+008+17694
# dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++ 
Kexample.com.+008+06817

This generated four key files in /etc/bind/keys/example.com, and the only one we care about for now is the KSK key, Kexample.com.+008+06817.key. Remember this file name: we will need it again shortly. Make sure these files are readable by named.

Refer to the section called “System Entropy” for information on how you might speed up the key generation process if your random number generator has insufficient entropy.

Reconfigure BIND

Below is a very simple named.conf, in our example environment, this file is /etc/bind/named.conf. The lines you most likely need to add are in bold.

options {
    directory "/etc/bind";
    recursion no;
    minimal-responses yes;
};

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
};

When you are done updating the configuration file, tell named to reload:

# rndc reload
server reload successful

Verification

Your zone is now signed. Before moving on to the next step of coordinating with your parent zone, let's make sure everything looks good using delv. What we want to do is to simulate what a validating resolver would check, by telling delv to use a specific trust anchor.

First of all, we need to make a copy of the key Kexample.com.+008+06817.key for editing:

# cp /etc/bind/keys/example.com/Kexample.com.+008+06817.key /tmp/example.key

The original key file looks like this (actual key shortened for display, and comments omitted):

# cat /etc/bind/keys/example.com/Kexample.com.+008+06817.key
...
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

We want to edit the copy to the be the trusted-keys format, so that it looks like this:

# cat /tmp/example.key
trusted-keys {
    example.com. 257 3 8 "AwEAAcWDps...lM3NRn/G/R";
};

Now we can run the delv command and point it to using this trusted-key file to validate the answer it receives from the authoritative name server 192.168.1.13:

$ delv @192.168.1.13 -a /tmp/example.key +root=example.com example.com. SOA +multiline
; fully validated
example.com.		600 IN SOA ns1.example.com. admin.example.com. (
				2014112007 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				2419200    ; expire (4 weeks)
				300        ; minimum (5 minutes)
				)
example.com.		600 IN RRSIG SOA 8 2 600 (
				20150107091559 20141208081559 17694 example.com.
				LwG0rLOm9Q1Lu9bgIz1O+PTCwcCSs1Ev8Eqkqqd3gUJK
				qo0FSVv//axNVJFH2Lz8VLgFypD8xARWj1XQBD/9DIf6
				A3ncnrFymKdKze+2ghvTUxpwqctK4RF66mhu93e33+Ir
				QJVJgdHJVHudQWICA1AbIBYYzLGkKlp7JAJcgBM= )

Upload to Parent Zone

Everything is done on our name server, now we need to generate some information to be uploaded to the parent zone to complete the chain of trust. The formats and the upload methods are actually dictated by your parent zone's administrator, so contact your registrar or parent zone administrator to find out what the actual format should be, and how to deliver or upload the information to your parent zone.

What about your zone between the time you signed it and the time your parent zone accepts the upload? Well, to the rest of the world, your zone still appears to be insecure. That is because when a validating resolver attempts to validate your domain name, it will eventually come across your parent zone, and your parent zone will indicate that you are not yet signed (as far as it knows). The validating resolver will then give up attempting to validate your domain name, and fall back to the insecure DNS. Basically, before you complete this final step with your parent zone, your zone is still insecure.

Note

Before uploading to your parent zone, verify that your newly signed zone has propagated to all of your name servers (usually zone transfers). If some of your name servers still have unsigned zone data while the parent tells the world it should be signed, validating resolvers around the world will not resolve your domain name.

Here are some examples of what you may upload to your parent zone, actual keys shortened for display. Note that no matter what formats may be required, the end result will be the parent zone publishing DS record(s) based on the information you upload. Again, contact your parent zone administrator(s) to find out what is the correct format for you.

DS Record Format: example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
DNSKEY Format: example.com. 172800 IN DNSKEY 257 3 8 (AwEAAcjGaU...zuu55If5) ; key id = 06817
Trusted Key Format: "example.com." 257 3 8 "AwEAAcjGaU...zuu55If5";

The DS record format may be generated using the dnssec-dsfromkey tool which is covered in the section called “DS Record Format”. For more details and examples on how to work with your parent zone, please see the section called “Working with Parent Zone”

So... What Now?

Congratulations, your zone is signed, your slave servers have received the new zone data, and the parent zone has accepted your upload and published your DS record. Your zone is now officially DNSSEC-enabled. What happens next? Well, there are a few maintenance tasks you need to do on a regular basis, which you can find in the section called “Maintenance Tasks”. As for updating your zone file, you can continue to update them the same way you have been prior to signing your zone, the normal work flow of editing zone file and using the rndc command to reload the zone still works the same, and although you are editing the unsigned version of the zone, BIND will generate the signed version automatically.

Curious as to what all these commands did to your zone file? Read on to the section called “Your Zone, Before and After DNSSEC” and find out. If you are interested in how you can roll this out to your existing master and slave name servers, check out the section called “Inline Signing Recipes” in Chapter 7, Recipes.

Your Zone, Before and After DNSSEC

In the previous section the section called “Easy Start Guide for Signing Authoritative Zones”, we provided the minimal amount of information to essentially convert a traditional DNS zone into a DNSSEC-enabled zone. This is what the zone looked like before we started:

$ dig @192.168.1.13 example.com. AXFR +multiline +onesoa

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
; (1 server found)
;; global options: +cmd
example.com.		600 IN SOA ns1.example.com. admin.example.com. (
				2014102100 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				2419200    ; expire (4 weeks)
				300        ; minimum (5 minutes)
				)
example.com.		600 IN NS ns1.example.com.
ftp.example.com.	600 IN A 192.168.1.200
ns1.example.com.	600 IN A 192.168.1.1
web.example.com.	600 IN CNAME www.example.com.
www.example.com.	600 IN A 192.168.1.100

Below shows the test zone example.com after we have reloaded the server configuration. As you can see, the zone grew in size, and the number of records multiplied:

# dig @192.168.1.13 example.com. AXFR +multiline +onesoa

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
; (1 server found)
;; global options: +cmd
example.com.		600 IN SOA ns1.example.com. admin.example.com. (
				2014102104 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				2419200    ; expire (4 weeks)
				300        ; minimum (5 minutes)
				)
example.com.		300 IN RRSIG NSEC 8 2 300 (
				20141126120153 20141027112239 60798 example.com.
				U1je2BEXY7S/u4An8sKEp2Cb8b90+9mNBoFb9nXgkTvC
				cJkT/4OIUIaO7EbsIASmlzjDwJEKSO/nPDFg3y6tsR0m
				GT7H7AYAouwBhUlIrDrGQpxqRLJXA1kPkxboX4M2JGx4
				rBcBsN/7lG5CGbjtLW3PMnJRELE5fBJBLZM1KLo= )
example.com.		300 IN NSEC ftp.example.com. NS SOA RRSIG NSEC DNSKEY TYPE65534
example.com.		600 IN RRSIG NS 8 2 600 (
				20141126115318 20141027112239 60798 example.com.
				TGC1gAksxHHDoltjJ8ETJ9qdr5MzFjA05vEllSNWBFe7
				O71Payf8o4MISHNeUoZpu7Ys4zBiTRLqUaLeI0oSEnzM
				r2QJkrfUHl1k8D/wCWApEUhMa1GxLIKMsEfgd3D5nK52
				6LAVNihx5BKC1YxuYZXhhBMYQm7bIlUXFvxl3uE= )
example.com.		600 IN RRSIG SOA 8 2 600 (
				20141126122239 20141027112239 60798 example.com.
				0ntLprFpg9bKWs5ArGvpZq8uFa9QPEfl6bOmfIwbNnEp
				9PgBS97icRs27JDgIXGM4dWxXiPVX6sZ8jFulSp2mi2v
				4dhtqMfb4S/rfxSmCphIz5PA+bngKSr5fhRI6tTM8fW1
				l5V3zfKCPFracE0CgdcWIt0xViEs56Axj942f5w= )
example.com.		0 IN RRSIG TYPE65534 8 2 0 (
				20141126120153 20141027112239 60798 example.com.
				Sv+7vfHXz4zlLSEuWs5Bt5boqSDVCK2GcOgAzVXnW9/0
				zgk3v8VwSXRTRnwdsvl3SK6YsM9S/HNXk32AQs2PjXf4
				2/cmv6VCOGSVGin/L5k4KWjpy0ESV2iY0hIIyeXWqUdB
				ZUCu1+2GhHiA5+gKODn/8sg6x04g+lZe6wuhU44= )
example.com.		600 IN RRSIG DNSKEY 8 2 600 (
				20141126122239 20141027112239 45319 example.com.
				F2vrBJqvloP5yNE6X1+b1XJ4gY6DlH1oyJz6pSULmGgQ
				FFztyrCJoV4MI6TeFRXJKLTePewjcTzKlaRKJHZRElcM
				QaClWr6RdZ2Uc1fFOBgYocrDZtGWdTVg7XCiLJ/ubrDH
				7et9rSexmKEwI44T4Vf7w3e+kUQSzMBGfA9Z5Q8WnnBW
				IDn4QFqRx0B02bVLV4giJbVp649ukIApVoHSpJvhrWq8
				eSSdP2ojymzr4gAuQZzmZUJnxp7Q3ktuQgIokhLG4FDH
				/O9qnhnOkUZFsxbBaDYVn5TIl1Kkmn3LH98JQE0z8a7D
				WfqAPAFy0rKHkvyOA8FlimDW09OYeJS00A== )
example.com.		600 IN RRSIG DNSKEY 8 2 600 (
				20141126122239 20141027112239 60798 example.com.
				PoUdallJO0ZF3iFmRoGoKh/iLAJVn52ABVEVku9LK34C
				oh4Y29rgK4jd3DwxU7zDLadVs0Fo3JFHp2jdYCEm03BS
				XE6d0cijZP5aFt8rO/grO/qbkdv+ScEi1kOhCKcvt3Kg
				1mXhiZt4Jx3LeisUpD9mGa+m9ehcPYlAHPKoZMg= )
example.com.		0 IN TYPE65534 \# 5 ( 08B1070001 )
example.com.		0 IN TYPE65534 \# 5 ( 08ED7E0001 )
example.com.		600 IN DNSKEY 256 3 8 (
				AwEAAfbc/0ESumm1mPVkm025PfHKHNYW62yx0wyLN5LE
				4DifN6FzIVSKSGdMOdq+z6vFGxzzjPDz7QZdeC6ttIUA
				Bo4tG7dDrsWK+tG5cm4vuylsEVbnnW5i+gFG/02+RYmZ
				ZT9AobXB5bVjfXl9SDBgpBluB35WUCAnK9WkRRUS08lf
				) ; ZSK; alg = RSASHA256; key id = 60798
example.com.		600 IN DNSKEY 257 3 8 (
				AwEAAb4N53kPbdRTAwvJT8OYVeVhQIldwppMy7KBJ+8k
				Uggx2PU3yP/qlq4Zjl0MMmqRiJhD/S+z9cJLNTZ9tHz1
				7aZQjFyGAyuU3DGW16xfMolcIn+c8TpPCzBOFhxk6jvO
				VLlz+Wgyi1ES+t29FjYYv5cVNRPmxXLRjlHFdO1DzX3N
				dmcUoZ+VVJCvaML9+6UpL/6jitNsoU8JHnxT9B2CGKcw
				N7VaK4l9Ida2BqY3/4UVqWzhj03/M5LK6cn1pEQbQMtY
				R0TNJURBKdK8bH663h98i23tVX0/85IsCVBL4Dd2boa3
				/7HPp7uZN1AjDvcRsOh1mqixwUGmVm1EskDIMy8=
				) ; KSK; alg = RSASHA256; key id = 45319
example.com.		600 IN NS ns1.example.com.
ftp.example.com.	600 IN RRSIG A 8 3 600 (
				20141126115318 20141027112239 60798 example.com.
				PNATas8HPjc6tm7Ldfk7P61IlRVSQW085P9lDw8qwITc
				TghDdAXHJBkCTXaDRWPyQZbGI5fNcxWLkf/HRbKREzQs
				eyztZj2OBnBnnK0t8SWLyM4+OMsGH17z4ZvBmPO/Wgju
				iSm98reH7J87yRlUMQHdPSwAP6q5tZeJbwpSkao= )
ftp.example.com.	300 IN RRSIG NSEC 8 3 300 (
				20141126115318 20141027112239 60798 example.com.
				ohuvpkqlNR+TYOG79JizEV+SFjVbUKSB3hEfHOJszCIr
				bcdPKTS0GgQS62N4ISwfvb735oQzc8pI5R+f+8MMn5c9
				/yRnArTpPJOKDnyIiMaMLBU5sEp5wI+OLsLFMkLef4iK
				gn+j608Qnoo7dXtWWQPv85FyaT9j3C+EV6rglCk= )
ftp.example.com.	300 IN NSEC ns1.example.com. A RRSIG NSEC
ftp.example.com.	600 IN A 192.168.1.200
ns1.example.com.	600 IN RRSIG A 8 3 600 (
				20141126115318 20141027112239 60798 example.com.
				z1rnlU9oVnIhwxQey3Zo6ENYmWXtf97RiZng3u6VkE0n
				yUC5S3sseZgD8Vc+uJsKVAvafM/k7NgS+P3pe5gN01Ln
				+geKEMZ3pCHpzHG4UgJj4Xw/iuWOVAFURD26GNnPppDK
				RNYPWIhA/9FF18vI3V9evNcHGxN+7rOOXF8Qbss= )
ns1.example.com.	300 IN RRSIG NSEC 8 3 300 (
				20141126115318 20141027112239 60798 example.com.
				chH7c6aW6Qk14d4LB866jva9OcH52pJkeHpdslVmUbJ2
				OkJQNhbpOekSjsroxDU4av3/Y49Dtg0lqoISvMMqwE5X
				5sKmn+CMKFfMmi22ui+RsPXyDqjkx+JOsi/7kCx7DFJz
				jF0a6KcsTWNV2QfZjQ50RyrSBBOkw6aqdUC3oF8= )
ns1.example.com.	300 IN NSEC web.example.com. A RRSIG NSEC
ns1.example.com.	600 IN A 192.168.1.1
web.example.com.	600 IN RRSIG CNAME 8 3 600 (
				20141126115318 20141027112239 60798 example.com.
				VgHPC0WllAlHY56xMF3j8FI7MsxDhLJJBDBMSVSQpQkA
				z81kfInYQL4YpAt25WrH7xt4pCmjVl3kUcDGAWWuSiQy
				nh2O4CoY/tSqQ7Sr9UnE5SIvpW5yws8iROOHvJYuKAmu
				8B3gYw1gp9xCMS4iBOIXTTq1KV2OHwo0cPXVyfI= )
web.example.com.	300 IN RRSIG NSEC 8 3 300 (
				20141126115318 20141027112239 60798 example.com.
				zh+9fnIQlfpvc0oFRnNIPJoL/S5RQF4HuGwmLxoCxRVp
				FCQoZbzNB0IVvaA+0XEslcHq3v4+0j9EeKKQw7xORaGu
				TrzcoRGbjuKZlpvnVlxYkjCiEKVbkXd5yEMnbgolFkhH
				NjFlozSyzypY0TY0UVRPXWhZ2shASae/ImqFiug= )
web.example.com.	300 IN NSEC www.example.com. CNAME RRSIG NSEC
web.example.com.	600 IN CNAME www.example.com.
www.example.com.	600 IN RRSIG A 8 3 600 (
				20141126120153 20141027112239 60798 example.com.
				TLkMRs7I3QW8HRS3trNG307Y0/drO4k8uG8Bv8856qPo
				33rbEajV49XBBQ+w8jynfKwxMNDfJhpSG0gxo7+0m75Y
				HRBZ9Xe3EAMNt2/iu0CL6NHyN99qF9TPNbYnD2Zw077L
				GSDOua1KFMxDqFU7rU0+YlKRGbSk1rqAJBqKEH4= )
www.example.com.	300 IN RRSIG NSEC 8 3 300 (
				20141126120153 20141027112239 60798 example.com.
				GSyFVBgMROqDuoSJoDegX3EkdqA90skBTvi9tkPxoQPo
				i8LlaD+wRmcXpYKE3vf/y0WpOOVQXbasyfFk8wGzFsde
				fqpFsscbz3OYgnkwYcTvGXZF9802ytiC5txli9uxUqjc
				lGL+SDl0woYhecwJD63fTDIMszlVR/eptIL9dLc= )
www.example.com.	300 IN NSEC example.com. A RRSIG NSEC
www.example.com.	600 IN A 192.168.1.100

But this is a really messy way to tell if your zone is properly setup with DNSSEC. Fortunately, there are tools to help us with that. Read on to the section called “How To Test Authoritative Zones (So You Think You Are Signed)” to learn more.

Prev		Next
What's EDNS All About (And Why Should I Care)?	DNSSEC Guide Table of Contents (License)	How To Test Authoritative Zones (So You Think You Are Signed)