Contact ISC for professional support

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

03 Sep 2019
15 Minutes to read
Contributors

Print
Share
Dark

Light
PDF

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

Updated on 03 Sep 2019
15 Minutes to read
Contributors

Print
Share
Dark

Light
PDF

Article Summary

Share feedback

Thanks for sharing your feedback!

Introduction

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

Manual signing, initiated by the name server administrator from the command line, has been supported since BIND first added support for DNSSEC.
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.
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, we configured a test environment on a fresh Linux VM. We 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 our 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.    86400   IN  NS      dns1.example.net.

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


mail    IN  MX  10  mail.example.net.
foo     IN  A   192.168.10.10
bar     IN  A   192.168.10.11
baz     IN  A   192.168.10.12
dns1    IN  A   127.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 we built for this VM hasn't been running. We're going to start it now, using the -g command line flag. We're using -g to override the usual logging destinations and dump log messages instead to the stderr stream in our 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 somewhere unless you have used -g as we 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. IN  ANY

  ;; ANSWER SECTION:
  foo.example.net.  3600    IN  A   192.168.10.10

  ;; AUTHORITY SECTION:
  example.net.  86400   IN  NS  dns1.example.net.

  ;; ADDITIONAL SECTION:
  dns1.example.net. 3600    IN  A   127.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. We 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. IN  ANY

  ;; ANSWER SECTION:
  foo.example.net.  3600    IN  RRSIG   A 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.  3600    IN  A   192.168.10.10

  ;; AUTHORITY SECTION:
  example.net.  86400   IN  NS  dns1.example.net.

  ;; ADDITIONAL SECTION:
  dns1.example.net. 3600    IN  A   127.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 SOA    dns1.example.net. hostmaster.example.net. 2012061008 86400 7200 360000 3600
  example.net.      14400 IN RRSIG  SOA 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 NS dns1.example.net.
  example.net.      86400 IN RRSIG  NS 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 DNSKEY 256 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 DNSKEY 257 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 RRSIG  DNSKEY 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 RRSIG  DNSKEY 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 NSEC3PARAM  1 0 10 03F92714
  example.net.      0IN RRSIG   NSEC3PARAM 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 RRSIG   TYPE65534 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 A   192.168.10.11
  bar.example.net.      3600 IN RRSIG   A 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 A   192.168.10.12
  baz.example.net.      3600 IN RRSIG   A 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 A  127.0.0.1
  dns1.example.net.      3600 IN RRSIG  A 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 A   192.168.10.10
  foo.example.net.      3600 IN RRSIG   A 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 MX 10 mail.example.net.
  mail.example.net.      3600 IN RRSIG  MX 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 NSEC3   1 0 10 03F92714 6OCOALHCR98EGNO7U502623ASTVQC3HN A RRSIG
  4QVNI87081QKDQ7FPH6QTBCQNN93I539.example.net. 3600 IN RRSIG   NSEC3 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 NSEC3   1 0 10 03F92714 DCV65TSHCH0UQAQGQSSIOHDPD97QJ2D3 A RRSIG
  6OCOALHCR98EGNO7U502623ASTVQC3HN.example.net. 3600 IN RRSIG   NSEC3 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 NSEC3   1 0 10 03F92714 DRVR6JA3E4VO5UIPOFAO5OEEVV2U4T1K A RRSIG
  DCV65TSHCH0UQAQGQSSIOHDPD97QJ2D3.example.net. 3600 IN RRSIG   NSEC3 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 NSEC3   1 0 10 03F92714 GJPS66MS4J1N6TIIJ4CL58TS9GQ2KRJ0 A RRSIG
  DRVR6JA3E4VO5UIPOFAO5OEEVV2U4T1K.example.net. 3600 IN RRSIG   NSEC3 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 NSEC3   1 0 10 03F92714 U5741PRSLF5GSGV1539FIM09DPIU9FTU NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534
  GJPS66MS4J1N6TIIJ4CL58TS9GQ2KRJ0.example.net. 3600 IN RRSIG   NSEC3 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 NSEC3   1 0 10 03F92714 4QVNI87081QKDQ7FPH6QTBCQNN93I539 MX RRSIG
  U5741PRSLF5GSGV1539FIM09DPIU9FTU.example.net. 3600 IN RRSIG   NSEC3 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 using BIND 9.9+ and in-line signing. Hopefully you've found this walk-through useful. Thank you for choosing BIND.

What's Next

I don't get RRSIG's returned when I use "dig +dnssec" - why is this?

Table of contents