• Share
  • Dark
    Light

In-line Signing With NSEC3 in BIND 9.9+ -- A Walk-through

  • Updated on 05 Feb 2014
  • 15 minutes to read
  • Contributors 

Introduction

As of version 9.9, the BIND package supports three different methods of signing zones. 

1.Manual signing, initiated by the name server administrator from the command line, has been supported since BIND first added support for DNSSEC.

2.BIND 9.7 added support for auto-dnssec.  After initial configuration, servers using auto-dnssec will automatically sign and re-sign zones at the appopriate time as determined by key metadata, relieving the DNS operator from much of the tedium of manually rotating keys and resigning zone data for large numbers of zones.

3.BIND 9.9 introduces another method of zone signing, "inline signing" (enabled by the "inline-signing yes;" statement in named.conf)

Using in-line signing is straightforward and easy, but using the default options results in a zone signed with options that create NSEC records.

Many zones (e.g. .gov zones trying to meet federal specifications for zone security) may need to meet mandates that require NSEC3 usage.  The intent of this document is to give a simple walk-through showing an easy method to sign a zone using NSEC3 records in BIND 9.9+

Setup

Prior to the start of this walk-through, I configured a test environment on a fresh Linux VM.  I downloaded the BIND source from ISC, compiled, and installed it.  You can provide arguments to the "configure" script to control the location of configuration files (--sysconfdir) and other locations.  "./configure --help" gives a full list of options.

Substantial Randomness is Needed for Key Generation

If you are following this procedure on a virtual machine, please be aware that the key generation stage (dnssec-keygen) requires a pool of entropy to get random numbers and may block reading from /dev/random if it overruns the entropy available on your system.  If you are running on a VM you may need an additional source of entropy (e.g. an external entropy source, or haveged)

Though you can choose any directory you like as long as named can find the configuration files when it starts up (and knows where to look for other supporting files, e.g. key files, zone files, etc.) for purposes of this demonstration my configuration information for BIND is all stored within the /etc/namedb directory.

  • named.conf is in /etc/namedb/named.conf
  • key files are in /etc/namedb/keys
  • zone data files for master zones are in /etc/namedb/master

Let's have a look:

root:/# **cd /etc/namedb** root:/etc/namedb# ls ./ backup/bind.log@ keys/ named.confscripts/ ../ bind.keysds/ master/ rndc.key root:/etc/namedb# **ls keys** ./ ../ ddns-key root:/etc/namedb# **ls master** ./ ../ example.net

Our named.conf file is pretty simple.  Let's have a look at that as well:

`// // SIMPLE NAME SERVER CONFIGURATION // options { directory "/etc/namedb"; key-directory "/etc/namedb/keys"; allow-transfer{"none";}; dnssec-enable yes; allow-new-zones yes; };

key "ddns-key" { algorithm hmac-sha256; secret "5mJtXnJvb/1FDQQ/5jiB+WellbkBLazVEdIssxAsg1Q="; };

key "rndc-key" { algorithm hmac-md5; secret "MXV2PqDunuBWRHHqLUpjUw=="; };

controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; };

logging { channel named_log{ file "/var/log/named/bind.log" versions 3 size 2m; severity info; print-severity yes; print-time yes; print-category yes; }; category default { named_log; }; category lame-servers { null; }; };

zone "example.net" in{ type master; file "master/example.net"; key-directory "/etc/namedb/keys"; update-policy { grant ddns-key zonesub ANY; }; auto-dnssec maintain; inline-signing yes; };`

For our purposes, the significant bits of this are:* The "directory" and "key-directory" statements, so BIND knows where to find its configuration information.

  • The key declaration for the rdnc-key, and the controls statement telling the nameserver to allow remote control commands from localhost when they come in using the rdnc-key.  rdnc is going to be important to the process later, so if you don't already have it set up, take some time before proceeding to get it working correctly.  Review the rdnc-confgen command and its man page if necessary.
  • A basic logging block because you should always have one to help you figure out what happened if things should go wrong, and
  • A zone declaration for the zone example.net.  We are a master nameserver for this zone and its zone data lives in master/example.net while its signing keys (which do not yet exist) will be located in /etc/namedb/keys.  auto-dnssec is set to "maintain" and inline-signing is set to "yes" for this zone.

Because this is a very simple test configuration, we have only one zone declared, example.net.  Let's look at the zone data for that zone:

`root:/etc/namedb# cat master/example.net
$TTL 3600

example.net.86400INNSdns1.example.net.

example.net.14400IN SOA dns1.example.net. ( hostmaster.example.net. 2012061001 ; serial 86400 ; refresh 7200 ; retry 360000 ; expire 3600 ) ; negative ttl

mailINMX 10mail.example.net. fooINA192.168.10.10 barINA192.168.10.11 bazINA192.168.10.12 dns1INA127.0.0.1 `

This obviously isn't a zone you would generally use, but it covers enough of the basics for our example.

Signing the Zone

Up until this point, the named server daemon that I built for this VM hasn't been running.  I'm going to start it now, using the -g command line flag.  I'm using -g to override the usual logging destinations and dump log messages instead to the stderr stream in my shell.  You probably don't want to do this on your production server, but it's handy for this example because we will be able to see the log messages interleaved with the commands we execute.  Just keep in mind that your logging output is probably going to syslog or a log channel somwehere unless you have used -g as I did.

root:/etc/namedb# **named -g &** [1] 22438 11-Jun-2012 16:28:25.844 starting BIND 9.9.1-P1 -g 11-Jun-2012 16:28:25.844 built with '--prefix=/usr/local/bind-9.9.1-P1' 11-Jun-2012 16:28:25.844 ---------------------------------------------------- 11-Jun-2012 16:28:25.844 BIND 9 is maintained by Internet Systems Consortium, 11-Jun-2012 16:28:25.844 Inc. (ISC), a non-profit 501(c)(3) public-benefit 11-Jun-2012 16:28:25.844 corporation. Support and training for BIND 9 are 11-Jun-2012 16:28:25.845 available at https://www.isc.org/support 11-Jun-2012 16:28:25.845 ---------------------------------------------------- 11-Jun-2012 16:28:25.845 using 1 UDP listener per interface 11-Jun-2012 16:28:25.845 using up to 4096 sockets 11-Jun-2012 16:28:25.848 loading configuration from '/usr/local/bind-9.9.1-P1/etc/named.conf' 11-Jun-2012 16:28:25.848 reading built-in trusted keys from file '/usr/local/bind-9.9.1-P1/etc/bind.keys' 11-Jun-2012 16:28:25.848 using default UDP/IPv4 port range: [1024, 65535] 11-Jun-2012 16:28:25.848 using default UDP/IPv6 port range: [1024, 65535] 11-Jun-2012 16:28:25.863 listening on IPv4 interface lo, 127.0.0.1#53 11-Jun-2012 16:28:25.863 listening on IPv4 interface eth1, 192.168.56.101#53 11-Jun-2012 16:28:25.864 generating session key for dynamic DNS 11-Jun-2012 16:28:25.864 open: 3bf305731dd26307.nzf: file not found 11-Jun-2012 16:28:25.864 sizing zone task pool based on 1 zones 11-Jun-2012 16:28:25.872 set up managed keys zone for view _default, file 'managed-keys.bind' 11-Jun-2012 16:28:25.872 automatic empty zone: 10.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 16.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 17.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 18.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 19.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 20.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 21.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 22.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 23.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 24.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 25.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 26.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 27.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 28.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 29.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 30.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 31.172.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 168.192.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 0.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 127.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 254.169.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 2.0.192.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 100.51.198.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 113.0.203.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: D.F.IP6.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 8.E.F.IP6.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 9.E.F.IP6.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: A.E.F.IP6.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: B.E.F.IP6.ARPA 11-Jun-2012 16:28:25.872 automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA 11-Jun-2012 16:28:25.878 command channel listening on 127.0.0.1#953 11-Jun-2012 16:28:25.878 ignoring config file logging statement due to -g option 11-Jun-2012 16:28:25.879 managed-keys-zone: loaded serial 0 11-Jun-2012 16:28:25.880 zone example.net/IN (unsigned): mail.example.net/MX 'mail.example.net' has no address records (A or AAAA) 11-Jun-2012 16:28:25.880 zone example.net/IN (unsigned): loaded serial 2012061001 11-Jun-2012 16:28:25.894 all zones loaded 11-Jun-2012 16:28:25.894 running 11-Jun-2012 16:28:25.899 zone example.net/IN (signed): loaded serial 2012061001 11-Jun-2012 16:28:25.899 zone example.net/IN (signed): receive_secure_serial: unchanged 11-Jun-2012 16:28:25.899 zone example.net/IN (signed): reconfiguring zone keys 11-Jun-2012 16:28:25.899 zone example.net/IN (signed): next key event: 11-Jun-2012 17:28:25.899

Great!  named is started, the default empty zones are logging, and our single declared zone, example.net is logging as well.  That block of messages at the end about example.net being signed is a bit misleading -- it is not yet signed (in fact, we haven't even generated keys for it.)  But let's verify that.  We're going to check that rndc works, check the health of the server, and check the signing status of example.net:

` root:/etc/namedb# rndc status version: 9.9.1-P1 number of zones: 36 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/0/1000 tcp clients: 0/100 server is up and running

root:/etc/namedb# rndc signing -list example.net 11-Jun-2012 16:28:50.652 received control channel command 'signing -list example.net' No signing records found`

As we suspected it's not really signed yet.  To sign it, we will first need keys.  Let's create a zone-signing key (ZSK) and a key-signing key (KSK) in the key directory.  We want NSEC3-capable keys and for purposes of this demonstration we want to fulfill a mandate which specifies RSASHA256 as the required algorithm and requires at least a 2048 bit key length, so we choose arguments accordingly:

` root:/etc/namedb# cd keys

 root:/etc/namedb/keys# dnssec-keygen -a RSASHA256 -b 2048 -3 example.net Generating key pair.......+++ .......+++ Kexample.net.+008+57495

root:/etc/namedb/keys# dnssec-keygen -a RSASHA256 -b 2048 -3 -fk example.net Generating key pair...................+++ .......................................................................+++ Kexample.net.+008+50707`

That was easy!  Now we've got keys.  Before we actually sign, let's look at what the data in the zone looks like if we query using dig.

` root:/etc/namedb/keys# dig @127.0.0.1 foo.example.net any

; <<>> DiG 9.9.1-P1 <<>> @127.0.0.1 foo.example.net any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20991 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;foo.example.net.INANY

;; ANSWER SECTION: foo.example.net.3600INA192.168.10.10

;; AUTHORITY SECTION: example.net.86400INNSdns1.example.net.

;; ADDITIONAL SECTION: dns1.example.net.3600INA127.0.0.1

;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jun 11 16:34:26 2012 ;; MSG SIZE rcvd: 95 `

The server is answering queries for the zone, but at this point nothing is signed yet and there are no RRSIG records.

OK, let's sign the zone!

Load the keys you have created, using "rndc loadkeys", e.g.:

root:/etc/namedb/keys# **rndc loadkeys example.net** 11-Jun-2012 16:34:46.380 received control channel command 'loadkeys example.net' 11-Jun-2012 16:34:46.380 zone example.net/IN (signed): reconfiguring zone keys 11-Jun-2012 16:34:46.713 zone example.net/IN (signed): next key event: 11-Jun-2012 17:34:46.380

The log messages that followed our "rndc loadkeys" command indicate success.  Our keys are now loaded and we are now ready to tell the server to sign the zone using NSEC3.

"rndc signing -nsec3param" will insert an NSEC3PARAM record into the zone and immediately sign it (if active keys are available and loaded) and generate NSEC3 records for the zone.  The command takes several arguments.  The only one you are likely to want to vary in this case is the salt argument.  I have chosen 03F92714 randomly.  You should choose a different value.  You may choose any value between 0 and 2^32 -1, and you must specify it in nibble notation (i.e. 8 consecutive hexadecimal digits.)

root:/etc/namedb/keys# **rndc signing -nsec3param 1 0 10 03F92714 example.net.** 11-Jun-2012 16:35:59.644 received control channel command 'signing -nsec3param 1 0 10 03F92714 example.net.' request queued 11-Jun-2012 16:35:59.899 zone example.net/IN (signed): zone_addnsec3chain(1,CREATE,10,03F92714)

Congratulations, you just signed a zone!  Let's step back and take a look at a few things that happened when we did that.  If we repeat our dig command:

` root:/etc/namedb/keys# dig @127.0.0.1 foo.example.net any

; <<>> DiG 9.9.1-P1 <<>> @127.0.0.1 foo.example.net any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18838 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;foo.example.net.INANY

;; ANSWER SECTION: foo.example.net.3600INRRSIGA 8 3 3600 20120711235420 20120611233447 57495 example.net. N/7w9Um5hwzKQHginpXDrgtXmzWRqnQ3+y6brGsK8oUvrYnazltEAG46 8zOBFA/l0G4rYJjdrbphmbAHzl6hmh+X0PSt0HOwVSLXVzOX3ijPknu/ r1nMOWdKBpEtRN6vn4fPRYy3TzSAQk9xiSJUQ+DjCPmlB85/DnnB6cS7 4QgQSKxW9EmFWVF7vFQDazjsd0eeXKOlEm05OY9q1lbMaizX+DA8cros QsdR7V2y9VkYyiU+k1Y+mP5F751Fo6913Pzxa0K1s0vS6Te8C3AntLiH XuYMC/Ekrg8JDqBV4rN9P4QG/r0v88S/UIYmR3XECtNk0BFSTgONSzFq H9T+BQ== foo.example.net.3600INA192.168.10.10

;; AUTHORITY SECTION: example.net.86400INNSdns1.example.net.

;; ADDITIONAL SECTION: dns1.example.net.3600INA127.0.0.1

;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jun 11 16:36:34 2012 ;; MSG SIZE rcvd: 394 `

We can now see signatures returned in the zone data.  And if we look at the directory where the zone data is stored, we will find a few new files:

` root:/etc/namedb/keys# cd ../master

 root:/etc/namedb/master# ls ./ example.net example.net.signed ../ example.net.jbk example.net.signed.jnl `

Our original "example.net" file remains untouched.  named has generated example.net.signed, example.net.signed.jnl, and example.net.jbk.  The signed version and its journal contain the information that named is using to answer queries with.  They are stored in raw format to speed loading and saving.  If you wish to see a human-readable version of their contents you must use the named-compilezone utility provided with BIND to de-compile them from raw to "cooked".

root:/etc/namedb/master# **named-compilezone -D -f raw -o - example.net example.net.signed** zone example.net/IN: mail.example.net/MX 'mail.example.net' has no address records (A or AAAA) zone example.net/IN: loaded serial 2012061008 (DNSSEC signed) example.net. 14400 IN SOAdns1.example.net. hostmaster.example.net. 2012061008 86400 7200 360000 3600 example.net. 14400 IN RRSIGSOA 8 2 14400 20120712003600 20120611233600 57495 example.net. nA3SPp3GD1Sp8Em2HHcMQIPuyEz8bGJWpfOUv3bExJPEO1khJ3rRfggd c8PNrzqH4+4WRkV1Djr5yPmRI4gwSjUeJyrXNUap57BxgienuVZXOkqM s9qYfRVogmgxD679nsG3ZiHrlRG38+RtjJ5l0B6L2NlCZQrYmQ3iI0VP e5U/16caZXOkiXsTTW2HU6ccckeAcU1FHpefDTN6B14+fuiUfMYupLUJ kdouwijGCmEQ3JdHUzOUF+YXRqkmg3ckMOKAVqB/rVo0DuNOSyc+BXIZ vraxQCFzxwT75Vh1vUox1jdDMN5IjXl2rDEwm3Cso/NWjsvSK/BBvVgE 27tLaw== example.net. 86400 IN NSdns1.example.net. example.net. 86400 IN RRSIGNS 8 2 86400 20120712003204 20120611233446 57495 example.net. GCdZf2gRBIREm9MMbw4qhuA6J1he90bJRpRFK7Fl/7N0wLwj5DZ6D8Sd UjmY/SqyWYsd/7HoYYHHtijU0bR9gjGWKQCXih98nvOY1TzQNM9xTMg8 EsOmS5KcGcfVI/XV5x9GRqvlQ/0SFrYyNt1vSeBZjnPWmWrz1AP4BOC4 rKxkTa3Ap3Qs64orkpqae7VAkdvw4gKA4BLQA33pBC7N7ycZgEidvsXI 2E2WzljhooCdhzmgDLvqJX5r9BJruDdyaZAadAXEOIXVQzBkOqjpyGrH KwsXfQSAMBfZbLjKogDbWVyI3aRE9VB/iF1I2yqqqIoyiZlhtcN/gG/N nLF2iQ== example.net. 14400 IN DNSKEY256 3 8 AwEAAbDyIKGuw+FrbtPhbWbKmtm7YKXRhHpaS6AWod90nUcC+5UQaFFW n65fmSBH0r5TaA5XYmon0gPtNKuqVnfibIwE4USt1gG3JZb8q1C4m0yV tl2qDpMuvcP3zRDswDow+GbrA8oM9DXU9tdPBV5QgaCSdxK8Ta/QbS62 1XeZgKltfkCvQzP/9Bg7UuJ6Kf4kdCHmH6u6KwsaWo+QVRXbS9tO+1sI HXvsSOVi6d+fUCpWr+HpAueo/mVmBIvYCUrZVCmv5DR2d08X0GHKisw6 nf/s1KfCElvAezQvuntS2Z4zCFAFezGf/IQARNDyQfSAL8ASrAq71lr2 Dy1QBuTz0pc= example.net. 14400 IN DNSKEY257 3 8 AwEAAcrCrjiDCDI1o4My70YSXx5S4/7o2BiEzbNf3uwCLXu/1C7eztxG mst2kjaJxbPWhwM/Iq5z8gOhyUOsiF156NcQ8+rd6A+NbJnkYO2mxGYf eSD4a1V4Ph9FopHfBrySOa/lPBLJOCXw/yzL2yDoRRxn9TTF79aApxIZ 0z8UMPAaUloZ3J+ojiTRQhIPQZx1uNCN7FtBacaOfVEPwLmcZ90T2pYj 2aCJ887+0e3rzSsiuw6xKIJRTie8zp3qdp7KlTWmLXET/wjzhHDl0R0N t0nU1jKKqfiSZmGKqWqKRNZrs21eG/wUYhOcveYPbUfb+vSoartu44JN D/4TxM5jZOc= example.net. 14400 IN RRSIGDNSKEY 8 2 14400 20120712003446 20120611233446 50707 example.net. dvOv2cYomNKLTAvd8gZkeGVvobzkigRcy67ZT6ERdrP5LHpjsIXIpYwz Ok2UXABenhccrekKXr3MlCiamIg6wneZwi81vnDEyPqMKBStG2HuISH+ YZd4z+pURpI4Qde83oqtGM3TNkUqFGbANMRnu91dZMCsxpMpniLxrcKL a75718NT8Asc+kcJogQcjZ/iB+HKENarkQp5H2nXqlg/EhlzYRw2fgBo ezM9Nu+7IQMAgxdxOxDw1B6wZhvHQr7P7FW4geasyywgOdWoanaCLvkf Ok1BT8/kjVvWA/bRblHB0Txvp84HzJIeoNT/eGtuXeHWuwWJMOJaLNlk HGoh4g== example.net. 14400 IN RRSIGDNSKEY 8 2 14400 20120712003446 20120611233446 57495 example.net. mhjf97PZlDuOu73EFQwHYmKBqn9uvGtgtPl8+VMCFXZ4ZZ920hS2LQyb f+n8vExl38xPIgU1BjqzMlMFsxEV9Z0a/whO7nNp94N3Urmyutoqh89J dikmZi02yT3CE+djIAVTQoaBlBmBL2LnX+r5EDQkhD5rTVXSNS7NV3D6 MM9KLaK9IwnFP1dAtGRIW0kdcCLry+PbFWbRC1VSQub4Q0wVARYvLx18 a7Km/ufA18LcIdOA7pR/zv+YVihOYlsVZQFxvwBlO/Al5j7YKlep21IR 86tj60+yKbuyDfjvaTeTK0+47i7XjJ/wu3K2ofj4M1QLyxP1DPf5qSaO 9jQQ7g== example.net. 0IN NSEC3PARAM1 0 10 03F92714 example.net. 0IN RRSIGNSEC3PARAM 8 2 0 20120712001242 20120611233600 57495 example.net. FFBdgYl9sTAhIGNYidhKcnA5JOgAJiTtAZ+WNZZsu2gHOvfAbgwoYFk1 s4dDW9mLpIiCSLDmBLAy1PVNukexD9Fp3sGNiXxo045c8TNtlMbkmvoP MxZF2/mHOtFHpVHGq5U/ecITpI5W58guzIxkeNoZRcXnOL0RY8+yToJU s+NspYjy/ZevfyAOxLRrSIXD06EDxBeXi5GXKZ/CKNq/SvVSQdDtA2Yv 17wrdLcjgbsHf0SNRrdFZTWgrzID4RVLxoj6XOJnIxTKbK2qlu31VU4N u1Xlmai0gVSlZKOmk22AlCCBUxnMKm+P8QCEenNt008avV/c/+lotyqq 27Xkcw== example.net. 0IN TYPE65534\# 5 08C6130001 example.net. 0IN TYPE65534\# 5 08E0970001 example.net. 0IN RRSIGTYPE65534 8 2 0 20120712002607 20120611233600 57495 example.net. K8Wxby6qJkJtp0xkVu30IkHFH8P75b9BX5AuJaHXk3bdoNlS0DK699Ee A3p9OItTNmzQch350EYqqhfRDNLnzkcXA0eGJwuAbgsgyMgc7rXX8NG5 y7IU0HjquBKJMkWvawFTdbL2h3A7a0LGMqQFr/dyMjrAj5EGkNfx6ozx nB7u8P7qJhh2KaukEGknpHgzi/zq0iz98XKzijzP514QpWGg/ESG2Cup ubS+0uxLJ0Ww3Owl88bIZBPpanFDStrIxC2ifCef9pOi3Z5YZEAk/46+ EV7aa/e3PhqYk7IYQnjoyA9AcoOgEGZvejjLBeUEbqQ5H/sf5EKMo2bH F6f3KQ== bar.example.net. 3600 IN A192.168.10.11 bar.example.net. 3600 IN RRSIGA 8 3 3600 20120712003204 20120611233446 57495 example.net. J+4at2dQrNMNVg91Gjv9lHs3y7aIF+04UH6MkhgDkIaB9qc8awakAUUN nsbmSCk1uhrJk/mpjkdTVlZZ5SYOgw8Qv9mNzC8X3rAni1+LtjpovvVW X4y6jtutEgVzsKFbZ9gtbSIoiAZLmIx9RG5MeTun6/Getg/iLtRRgiSZ QPH3O/6kycry3wlfykEbCN+ZlmSXlSRH6ZO7Qq1AvgEUOI0mHUaJrPz8 KzY6ozb6vB9fszmb0FE1FseELClI0uSOQbP3fCoOzmAQydXBLOjoj5Zy xFj2noLoB4yRI97MZeD3QcZnrFLdFs7sakz06KtaaVFluAhSxd4AIMr3 yv6oaw== baz.example.net. 3600 IN A192.168.10.12 baz.example.net. 3600 IN RRSIGA 8 3 3600 20120712003204 20120611233446 57495 example.net. Ie69FGh/kG2Dly9lxUWp0vSbt+uOL581S6kHhHKE+4pAs01wU10SWXte VEed6CREyJ0y15quwSnE69RDNUgj1JUTuMXiMfQSnw+zkcH1ue7bNlrC R43XxtFX84IseDcBccSodzFU6Fg6WshF7DFDPGCxPe+RmshsR0AIiaOF 4PnSw4GqMI8HKZeL8+0d4FQOHWDLl2aEQDx1h7zzh2wyv49C8+pXXC9v AHnBUTRjhlAK8HHsx6MIbUKvce+pTRHBEEMuQ5zkgHRpFg+8xU7B1TXP KOPZpcH5fQUZx335VRnATVxHW37lEKZa6gYFX6nCItAGVdQWO72/p1Kb S4bO9Q== dns1.example.net. 3600 IN A127.0.0.1 dns1.example.net. 3600 IN RRSIGA 8 3 3600 20120712003204 20120611233446 57495 example.net. YhFSYwYQV9+9K+JJ+gMZmGCkZ1L9F0qb3vQa9hihNX+tzJlpUdcQESYc IRcOEXQ9FP8DJPp20uZiqDlBLN7MEAXsRL62sDn6TuCoQccW9Ce8ru/q 4dSvlBBZslThUEzpaourjvrwYrqNP37gjLRfJlsfU1h5tPB4pg5Pjiar cZH38U1y4MBQTfMNeY+vRSd7ddiDgms2VgjqB88wAFri2qBdfgHGZW3F ZU7X7fbtVZFE+5WdYiYPjxv9sWt+UKXIAI80KJEEfHxjxl2acjLuffyg 2vKdkKfnoDYADb7PjBRL9/CJfh9SHbluAEW8ymxHvx/n3UCoJdwACXBK D5EC0g== foo.example.net. 3600 IN A192.168.10.10 foo.example.net. 3600 IN RRSIGA 8 3 3600 20120711235420 20120611233447 57495 example.net. N/7w9Um5hwzKQHginpXDrgtXmzWRqnQ3+y6brGsK8oUvrYnazltEAG46 8zOBFA/l0G4rYJjdrbphmbAHzl6hmh+X0PSt0HOwVSLXVzOX3ijPknu/ r1nMOWdKBpEtRN6vn4fPRYy3TzSAQk9xiSJUQ+DjCPmlB85/DnnB6cS7 4QgQSKxW9EmFWVF7vFQDazjsd0eeXKOlEm05OY9q1lbMaizX+DA8cros QsdR7V2y9VkYyiU+k1Y+mP5F751Fo6913Pzxa0K1s0vS6Te8C3AntLiH XuYMC/Ekrg8JDqBV4rN9P4QG/r0v88S/UIYmR3XECtNk0BFSTgONSzFq H9T+BQ== mail.example.net. 3600 IN MX10 mail.example.net. mail.example.net. 3600 IN RRSIGMX 8 3 3600 20120711235420 20120611233447 57495 example.net. nznhlw/GTzRmUrDE7XvjEtvPVihmNsCUFszOPzmGaGiUliSqS1jAiHPB RZLISrz1Ue8XG8NZugrfHe6UrTCWBbhJA300UdrCnz0j5Zkon+MBL9sp avc3GcHgxlhplePYwRs4oJAnULV0391o61wAgboYiSkuNyXOZ0RmUYfB WqIpgnAkV2Q0qOoWT7bc59kin/fVxMMzHN9CGz/0739bn4ieoubo9Mqb z9O4fR3rwdNTAXFLKnfkjpNLK+Jy8rBnwxbnCBeZE0fIiTC9z7IeA5Ib cnBps4H6/ALQA666gvOwnMRxFgPRAtwTMBZuo6hzeJot7u7YJIGjCJE4 Ezjwlg== 4QVNI87081QKDQ7FPH6QTBCQNN93I539.example.net. 3600 IN NSEC31 0 10 03F92714 6OCOALHCR98EGNO7U502623ASTVQC3HN A RRSIG 4QVNI87081QKDQ7FPH6QTBCQNN93I539.example.net. 3600 IN RRSIGNSEC3 8 3 3600 20120712001242 20120611233600 57495 example.net. FNKt9kY8g1NY2kGsyy2wiAs/v9g6kZvHqiCn0GKnmL2w6ZUE5q03Rp2Q MqnHwXmLzyfyLlMx4JCPjKx1RIt1ccnJ4SKRo65qvnE7rAoeWarSKYr2 97ZjFoDQyqIKUOEPlVGweVhzH0lHoyO6Ob+oY5IChqCWOqLwIaGgmb3A q+xiKsu2jKAc7mGLWFGrZNrJivXlTf5TADnrJgTkZRlRHLntGT/OssH7 5wisA7UTTVwe71pjswxtI+W0mO2YackVyqeyLSVBUo4pJQXm2YpdZgIj V4W8qUH5IFM7lLG9TX3BIvazHZ3Y3TmjX98IeHf5Qvhfn5VR7+nz0Fxt /KRFsw== 6OCOALHCR98EGNO7U502623ASTVQC3HN.example.net. 3600 IN NSEC31 0 10 03F92714 DCV65TSHCH0UQAQGQSSIOHDPD97QJ2D3 A RRSIG 6OCOALHCR98EGNO7U502623ASTVQC3HN.example.net. 3600 IN RRSIGNSEC3 8 3 3600 20120712001242 20120611233600 57495 example.net. BnI92Onl6J+3VzQv+MqR9B1xfa4dcZ0At21pjLwAB1AaSkXOn/tXqTrD LAr+nQudJ3AxtiNOekKfBeab3NDe5ayCRkCKSjUAJD/Fw6xg9x5TXWmc YlCGCXdNYKE7eMpFKE7qNfGXrYiwT/z+5r7covovMXtf9H2GJCqgn91D dEkjeP93LdrepchD/6ZoefQbWyoh867oCg+5ASJ03oT4jx/t3UIrASqP 29JIE9zYupMQXR+VWvnPJIGREz/wzcBIpN4RH7qsdTG/O+JKfJIo9xdO AO3Np8XFl+T4mQXT6zRsBneX/OoypCY/0VTsOmSV9gUzYHTSwr2mdFRL B5E2fw== DCV65TSHCH0UQAQGQSSIOHDPD97QJ2D3.example.net. 3600 IN NSEC31 0 10 03F92714 DRVR6JA3E4VO5UIPOFAO5OEEVV2U4T1K A RRSIG DCV65TSHCH0UQAQGQSSIOHDPD97QJ2D3.example.net. 3600 IN RRSIGNSEC3 8 3 3600 20120712001242 20120611233600 57495 example.net. fal+YAdxNCOqAz0U6CHLfiKYQw0Ykp2YrxnGKYHwmIGvy7qulCTPyUih U9BBbPpnkScwUQZoucD7SVWLPbSKojuQ9B0ld0EV16zRPdZP1oPxBiRE jdoIMDyKs7eOvB1hFZdX9tkIM6Fk/ec7JPUTfxgrP8Awq+OwDFHWyE4W c/MKqb4SXcIOOhehCIUlu9kV8BbpktIc81XqxBkSypBg4o9TI2GmkBa2 gAKhZ7jZBgUuru617cF+79WboUiiYZ6GCTzv5J5pXFighNZKUJdxJV9w wWRJ3IclVNEQBM5PyzY9Ugs+EYKLFwItlTuNLJiVaO84U0keuJi85au2 e0AKeQ== DRVR6JA3E4VO5UIPOFAO5OEEVV2U4T1K.example.net. 3600 IN NSEC31 0 10 03F92714 GJPS66MS4J1N6TIIJ4CL58TS9GQ2KRJ0 A RRSIG DRVR6JA3E4VO5UIPOFAO5OEEVV2U4T1K.example.net. 3600 IN RRSIGNSEC3 8 3 3600 20120712001242 20120611233600 57495 example.net. n1ginWdfvOFxEjGqQQix63nMdZcTcyTdjp3RdNpnSh6s8FqI8H3y4UOF FOdGfu5mr8clSXJ4oBZUVbIzYGYY8i3m4+E5KZTxVQSv+//3sZ7QqETD U+MwYCbBw5pQhA9czJ5WmAjnoS/xuqdFBQ5OgyBFXKQJZ9TClULAiVUS Tj7/ZnWbXsV3+6TFNbpdjSo0eB9Zs46VL9u4S6Yd+VeIRc/qHYOAmPQb +9d0sgjZm5yQ0rNXJyNMdYiJSEMuFGaEuFmDBileDL4/cyow4ILrfYvI JVWiCZtOOX3TOGPE/MVte2o+RYXtu6xULIKCEpWltAdbL+KOVxwgJpJS hXdzhA== GJPS66MS4J1N6TIIJ4CL58TS9GQ2KRJ0.example.net. 3600 IN NSEC31 0 10 03F92714 U5741PRSLF5GSGV1539FIM09DPIU9FTU NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534 GJPS66MS4J1N6TIIJ4CL58TS9GQ2KRJ0.example.net. 3600 IN RRSIGNSEC3 8 3 3600 20120712001242 20120611233600 57495 example.net. T9oOWh14/q4lLGnDQPwZU0SkHoMOF7T93jc+o19xiNJiExaFZl8zDUP0 jMYLIgBf9jXgznUoM3E+uCL7GS/LqXmx4Io14DpSo2KfMFwAav2UCImm ArO7CGHvqcbT+tL6jq4lcZiDdAz+AT2do1cwyvLT96trElcUnt6ih2ow 0Yuw45Odah+xohnzV1F2y+XsHaAUwyDL9mQVV3qlVhqAytt55wwgqKpw ch9XHe6NOgA/NbmUuThxj19Pub5fvQ0z9ccgf0cVGTu+SlUX22SJe5Mp Gilhd/HLu6seMucb/F4zbSdUvce3SL3DH/GlCLBVzxCJITCJcYQFPeR9 B5zBzQ== U5741PRSLF5GSGV1539FIM09DPIU9FTU.example.net. 3600 IN NSEC31 0 10 03F92714 4QVNI87081QKDQ7FPH6QTBCQNN93I539 MX RRSIG U5741PRSLF5GSGV1539FIM09DPIU9FTU.example.net. 3600 IN RRSIGNSEC3 8 3 3600 20120712001242 20120611233600 57495 example.net. UcaulW/1EgLLUp3beOswwYdd9dsjkVGsDHNnjk6pD8ehQeapQHarVHfO R/JbmubzxTzmYyki7h0nyS2t1/bQWit17hIiqdcW22HLOFqXZA3d1tGK jBruLiHpUVeYd+RVwmVxx5RvLSRavMLj2rgqleXk2k18Av81Wotel+mH uJbPmt8UyjA0yygko2om5orlYmWETvxqJ8+a18fITFmxDKJrg0/cqppg KmgarhCDHkENhvXZlv+FmURsQNIMip4KIMHOreXgcGIYmEUBxSaMGyO5 3c2r/FSaGKgrLJttKzxgpVBD0a9XL101pnnv8Qb/GdSs+ehIzJeBwGtn creVhA== OK

..and there are our NSEC3 records. Our zone data looks good.

We are still missing something, however.  In order to verify your zone, DNSSEC requires a chain of trust from the root ('.') level of the DNS namespace.  The links in this chain of trust are delegation signing records (DS RRTYPE.)  A validating resolver attempting to verify your zone must be able to follow a chain of trust from either the root or a trust anchor that it has accepted and the common way of doing that is have the party responsible for your containing (or parent) zone insert your DS records in their zone along with the NS records they use to delegate the zone to your servers.

If you had used BIND's original manual signing method, the dnssec-signzone command would have produced for you a dsset file containing the DS resource records that need to go in your containing zone.  But using in-line signing we didn't ever need to call dnssec-signzone manually, we just created keys for the zone, loaded them, and then told it to begin signing the zone using NSEC3.  We still need DS records and we can create them using the dnssec-dsfromkey utility included in BIND.

The easiest method is to get the data needed to generate the DS records straight from the live zone:

root:/etc/namedb/master# **dig @127.0.0.1 dnskey example.net | dnssec-dsfromkey -f - example.net** example.net. IN DS 50707 8 1 42727823EB40A1D93F0A1CF22E4AE8768BC40FBA example.net. IN DS 50707 8 2 BC34B1EA3196C01EEFCC4C571B61753423D264A712E0A4F35847BBDC A5954A5F

But if necessary you can generate them from the key files:

` root:/etc/namedb/keys# dnssec-dsfromkey -a SHA-1 Kexample.net.+008+50707.key example.net. IN DS 50707 8 1 42727823EB40A1D93F0A1CF22E4AE8768BC40FBA

  root:/etc/namedb/keys# dnssec-dsfromkey -a SHA-256 Kexample.net.+008+50707.key example.net. IN DS 50707 8 2 BC34B1EA3196C01EEFCC4C571B61753423D264A712E0A4F35847BBDC A5954A5F `

The managers of your parent zone SHOULD provide you with some mechanism to insert the DS records in their zone but the method will vary depending on the operators of the zone.  Consult the administrators of your parent zone or your zone registrar to find the details that apply in your case.

That's all there is to signing a zone usingBIND 9.9+ and in-line signing.  Hopefully you've found this walk-through useful.  Thank you for choosingBIND.

© 2001-2018 Internet Systems Consortium For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership. ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Problems with this site? Email us at marketing@isc.org