wiki:DnssecAuthoritativeServers

DNSSEC-Enabled Authoritative Servers

Introduction and Scenario Description

While the BIND 10 system does not yet support DNSSEC signing of zone files nor DNSSEC key management, the recent release of BIND 9.9 makes this scenario possible. Inline signing is a new feature in BIND 9.9 wherein a BIND 9.9 server can receive unsigned zone data via zone transfers, sign it automatically, and make the signed zone data available for queries or outgoing zone transfers. BIND 9.9 takes care of DNSSEC key maintenance as well, including automatic key rollover. Incoming updates to the unsigned zone data are processed automatically and reflected in the outgoing signed zone data.

In this scenario a BIND 10 server is used as a hidden master for one or more zones in unsigned form. It is configured to direct outgoing zone transfers to a BIND 9.9 hidden slave server, which is used for DNSSEC inline signing. The BIND 9.9 server in turn directs outgoing zone transfers to one or more additional BIND 10 servers. The latter are used as the publicly accessible authoritative servers for the zones in question. All of the zone transfers can be secured with TSIG if desired.

This is an ad-hoc design that is more complex than will ultimately be necessary with BIND 10, but it does provide the opportunity now to test the ability of BIND 10 to serve DNSSEC signed data in a production environment. This includes NSEC3 closest-encloser proofs. This test scenario provides for one small zone, but by scaling it up, one could evaluate BIND 10's performance in this arena.

Configuration Details

A minimum of three servers are required for this scenario, one running BIND 9.9 and at least two running BIND 10. Installation notes are available to help intall the appropriate versions of BIND on these systems with the Ubuntu 12.04 LTS operating system:

Name Role BIND Version Installation Notes
ns0 Stealth Master bind10-devel-20120517 Ubuntu 12.04 LTS (Precise Pangolin) BIND 10
ns0s Inline Signing 9.9.1 Ubuntu 12.04 LTS (Precise Pangolin) BIND 9
ns1 Public Slave bind10-devel-20120517 Ubuntu 12.04 LTS (Precise Pangolin) BIND 10

Please refer to the BIND 10 Guide and BIND 9 Administrator Reference Manual to understand the details of the various configuration commands.

Preparation of Cryptographic Keys

A number of cryptographic keys are required for DNSSEC and for TSIG-secured communications among the DNS servers. The ns0s system running BIND 9.9 will have the appropriate utilities available to produce the keys, but note that if ns0s is a VMware ESXi virtual machine, as is the case in my environment, it will not have sufficient entropy available to produce the necessary random numbers in a timely manner. There are a number of workarounds for this problem, including producing the keys on a physical machine, use of an Entropy Gathering Daemon, and use of an Entropy Key on a virtual machine running under VMware Workstation. See also this blog post by a frequent contributor to the BIND forums.

With an adequate source of entropy in place on a system running BIND 9.9, use the following procedure to generate the required DNSSEC keys using the dnssec-keyset script attached to this article. dnssec-keyset implements a pre-publication key rollover strategy, and the commands below generate the sets of zone signing keys (ZSK) and key signing keys (KSK) needed for two years of DNSSEC operations.

$ wget http://bind10.isc.org/attachment/wiki/DnssecAuthoritativeServers/dnssec-keyset
$ chmod 750 dnssec-keyset
$ ./dnssec-keyset -3 90 4 35 1 example.com 9
dnssec-keygen -q -3 -P 20120223 -A 20120527 -I 20120826 -D 20120930 -K example.com example.com
Kexample.com.+007+03602 is published and active.
dnssec-keygen -q -3 -P 20120523 -A 20120825 -I 20121124 -D 20121229 -K example.com example.com
Kexample.com.+007+58508 is published prior to activation date.
dnssec-keygen -q -3 -P 20120821 -A 20121123 -I 20130222 -D 20130329 -K example.com example.com
Kexample.com.+007+26834 is pending publication.
dnssec-keygen -q -3 -P 20121119 -A 20130221 -I 20130523 -D 20130627 -K example.com example.com
Kexample.com.+007+39887 is pending publication.
dnssec-keygen -q -3 -P 20130217 -A 20130522 -I 20130821 -D 20130925 -K example.com example.com
Kexample.com.+007+62342 is pending publication.
dnssec-keygen -q -3 -P 20130518 -A 20130820 -I 20131119 -D 20131224 -K example.com example.com
Kexample.com.+007+62030 is pending publication.
dnssec-keygen -q -3 -P 20130816 -A 20131118 -I 20140217 -D 20140324 -K example.com example.com
Kexample.com.+007+06524 is pending publication.
dnssec-keygen -q -3 -P 20131114 -A 20140216 -I 20140518 -D 20140622 -K example.com example.com
Kexample.com.+007+28613 is pending publication.
dnssec-keygen -q -3 -P 20140212 -A 20140517 -I 20140816 -D 20140920 -K example.com example.com
Kexample.com.+007+29798 is pending publication.
$ ./dnssec-keyset -k -3 720 7 35 1 example.com 2
dnssec-keygen -q -3 -f KSK -P 20100531 -A 20120527 -I 20140518 -D 20140622 -K example.com example.com
Kexample.com.+007+18060 is published and active.
KSK Kexample.com.+007+18060 requires the publication of DS records in the parent zone.
See example.com/DS-Kexample.com.+007+18060.
dnssec-keygen -q -3 -f KSK -P 20120520 -A 20140517 -I 20160507 -D 20160611 -K example.com example.com
Kexample.com.+007+46596 is published prior to activation date.
KSK Kexample.com.+007+46596 requires the publication of DS records in the parent zone.
See example.com/DS-Kexample.com.+007+46596.
$ ls -l example.com
total 96
-rw-rw-r-- 1 spainj spainj  165 May 28 15:56 DS-Kexample.com.+007+18060
-rw-rw-r-- 1 spainj spainj  165 May 28 15:56 DS-Kexample.com.+007+46596
-rw-rw-r-- 1 spainj spainj  536 May 28 15:55 Kexample.com.+007+03602.key
-rw------- 1 spainj spainj 1063 May 28 15:55 Kexample.com.+007+03602.private
-rw-rw-r-- 1 spainj spainj  536 May 28 15:55 Kexample.com.+007+06524.key
-rw------- 1 spainj spainj 1063 May 28 15:55 Kexample.com.+007+06524.private
-rw-rw-r-- 1 spainj spainj  711 May 28 15:56 Kexample.com.+007+18060.key
-rw------- 1 spainj spainj 1827 May 28 15:56 Kexample.com.+007+18060.private
-rw-rw-r-- 1 spainj spainj  537 May 28 15:55 Kexample.com.+007+26834.key
-rw------- 1 spainj spainj 1063 May 28 15:55 Kexample.com.+007+26834.private
-rw-rw-r-- 1 spainj spainj  537 May 28 15:55 Kexample.com.+007+28613.key
-rw------- 1 spainj spainj 1063 May 28 15:55 Kexample.com.+007+28613.private
-rw-rw-r-- 1 spainj spainj  537 May 28 15:55 Kexample.com.+007+29798.key
-rw------- 1 spainj spainj 1063 May 28 15:55 Kexample.com.+007+29798.private
-rw-rw-r-- 1 spainj spainj  537 May 28 15:55 Kexample.com.+007+39887.key
-rw------- 1 spainj spainj 1063 May 28 15:55 Kexample.com.+007+39887.private
-rw-rw-r-- 1 spainj spainj  711 May 28 15:56 Kexample.com.+007+46596.key
-rw------- 1 spainj spainj 1827 May 28 15:56 Kexample.com.+007+46596.private
-rw-rw-r-- 1 spainj spainj  537 May 28 15:55 Kexample.com.+007+58508.key
-rw------- 1 spainj spainj 1063 May 28 15:55 Kexample.com.+007+58508.private
-rw-rw-r-- 1 spainj spainj  537 May 28 15:55 Kexample.com.+007+62030.key
-rw------- 1 spainj spainj 1063 May 28 15:55 Kexample.com.+007+62030.private
-rw-rw-r-- 1 spainj spainj  537 May 28 15:55 Kexample.com.+007+62342.key
-rw------- 1 spainj spainj 1059 May 28 15:55 Kexample.com.+007+62342.private

It may be helpful to retain the output of the dnssec-keyset script in order to have a ready reference for the five-digit key identifiers (last five digits of the key name) and the associated timing metadata. Note also the two files with names beginning with DS-Kexample.com. These are the delegation signer (DS) records relating to the two KSKs generated. Each file contains two DS records, one for each of two digest algorithms: SHA-1 and SHA-256.

$ cat example.com/DS-Kexample.com.+007+18060 
example.com. IN DS 18060 7 1 E9CDE8AAB8F073AF0CB0E472D75D4907118B6648
example.com. IN DS 18060 7 2 9558AD376102C170EC04AEB50C9C0C5525128BA8F0376BC8A739BD01 24E1CCE4
$ cat example.com/DS-Kexample.com.+007+46596 
example.com. IN DS 46596 7 1 5B80C8D9DD325FCE46EF8BD5F7A85BF060C34BFB
example.com. IN DS 46596 7 2 FA73D94F3D44D13383F28D6CE8720B4F9A003447BED5B60A7BEE0AC6 DEEBF0BC

These DS records need to be added to the DNS parent zone, in this case com. Domain registrars have differing procedures for doing this, but typically it is a manual process via the registrar's website. The DS files themselves are not used by BIND and so can be discarded, but the digest strings will be needed to create the DS records. The other DNSSEC key files, each beginning with Kexample.com must be retained for use on the ns0s server.

TSIG keys are required to secure communications between the pairs of servers ns0-ns0s and ns0s-ns1. BIND 9.9's dnssec-keygen utility can be used to create these as follows:

$ dnssec-keygen -a hmac-sha256 -b 256 -n HOST ns0-ns0s
Kns0-ns0s.+163+02913
$ cat Kns0-ns0s.+163+02913.key 
ns0-ns0s. IN KEY 512 3 163 Ax2yqxgXnrL3kX6qZGyfaxSzCAolq9xnONNPOEelMJY=
$ dnssec-keygen -a hmac-sha256 -b 256 -n HOST ns0s-ns1
Kns0s-ns1.+163+40164
$ cat Kns0s-ns1.+163+40164.key 
ns0s-ns1. IN KEY 512 3 163 oBwT6UEKvMy8E0it1wVjTvvpzP22CBgPth53lgfk2bY=

The TSIG key files (*.key and *.private) that are generated by the above are not used by BIND and can be discarded, but the Base64 strings themselves will be used as TSIG shared secrets in the server configurations detailed below.

Network Addresses

Each of the DNS servers should be configured with static IPv4 and/or IPv6 addresses. Please make note of these addresses for subsequent use in the configuration files.

Configuration of Stealth Master Server NS0

When BIND 10 is initially installed on ns0 and the service is started, it is not configured to act as an authoritative DNS server. This functionality can be enabled using the bindctl configuration utility and a built-in configuration macro called init_authoritative_server. Note that the first time you execute bindctl it will require you to enter the user name root and the password bind10. These are the rudiments of an authentication system for bindctl that is still under development.

$ sudo bindctl
["login success "] login as root
> execute init_authoritative_server
adding Authoritative server component
adding Xfrin component
adding Xfrout component
adding Zone Manager component
Components added. Please enter "config commit" to
finalize initial setup and run the components.
> config commit

Since this is a stealth master server that will not be receiving incoming zone transfers, its inbound zone transfer functionality can be disabled. This is a good idea for both security and performance reasons.

> config remove Boss/components b10-xfrin
> config remove Boss/components b10-zonemgr
> config commit

The outbound zone transfers from ns0 to ns0s need to be configured using the ns0-ns0s TSIG key and the address of the ns0s server. Substitute the actual TSIG shared secret that you generate and the IPv4 or IPv6 network address of ns0s below.

> config set tsig_keys/keys ["ns0-ns0s:Ax2yqxgXnrL3kX6qZGyfaxSzCAolq9xnONNPOEelMJY=:hmac-sha256"]
> config set Xfrout/transfer_acl[0] {"action": "REJECT"}
> config add Xfrout/zone_config
> config set Xfrout/zone_config[0]/origin "example.com"
> config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "<network address of ns0s>", "key": "ns0-ns0s"}]
> config commit
> quit

Finally the zone data for example.com needs to be loaded. This is done using the b10-loadzone utility. For the source data for the zone, it is best to use the canonical zone file format. If you currently have the zone loaded on another BIND 9 server, use the named-checkzone utility to export it with the -D option to produce the output file in canonical format. The current version of b10-loadzone is easily confused by zone files in relative format. This utility is due to undergo further development this year.

$ sudo named-checkzone -D -f raw -F text -j -o example.com.db example.com /var/cache/bind/example.com.db
zone example.com/IN: loaded serial 2012052001
OK

Note in the above that depending on the configuration of the server, you may need to omit -f raw for the export to work correctly. Transfer the exported zone file example.com.db to the ns0 server and load the zone.

$ sudo b10-loadzone example.com.db
Using SQLite3 database file /var/bind10-devel/zone.sqlite3
Zone name is example.com.
Loading file "example.com.db"
8 RR(s) loaded in 0.10 second(s) (100.00% of example.com.db)
Done.

Note that if the file example.com.db contains extraneous trailing whitespace, the b10-loadzone utility will indicate that less than 100.00% of the file has been loaded. Also the count of resource records is always one greater than the actual number. The BIND 10 developers have this issue on their list. Finally note that b10-loadzone configures the example.com zone to use the SQLite3 data source. BIND 10 also supports an in-memory data source. See the BIND 10 Guide for details on how to configure the latter.

Configuration of Inline Signing Server NS0S

When BIND 9.9 is initially installed on ns0s and the service is started, BIND 9.9 is configured by default as a recursive resolver accessible only to the local host. To configure DNSSEC inline signing, the files /etc/bind/named.conf.options and /etc/bind/named.conf.local need to be modified.

Edit /etc/bind/named.conf.options to read as follows, substituting the TSIG shared secrets that you generate and actual network adrresses where indicated:

acl queriers {
	<network address of ns1>;
	<network address of your workstation>; // for troubleshooting purposes
};

acl transferees {
	<network address of ns1>;
	<network address of your workstation>; // for troubleshooting purposes
};

masters stealthMasters {
	<network address of ns0>;
};

masters publicSlaves {
	<network address of ns1>;
};

options {
	directory "/var/cache/bind";
	listen-on-v6 { any; };
	version none;
	allow-query { localhost; queriers; };
	recursion no;
};

key ns0-ns0s {
	algorithm hmac-sha256;
	secret "Ax2yqxgXnrL3kX6qZGyfaxSzCAolq9xnONNPOEelMJY=";
};

key ns0s-ns1 {
	algorithm hmac-sha256;
	secret "oBwT6UEKvMy8E0it1wVjTvvpzP22CBgPth53lgfk2bY=";
};

server <network address of ns0> {
	keys { ns0-ns0s; };
};

server <network address of ns1> {
	keys { ns0s-ns1; };
};

Edit /etc/bind/named.conf.local to read as follows:

zone "example.com" {
	type slave;
	file "/var/cache/bind/example.com.db";
	key-directory "/var/lib/bind/example.com";
	auto-dnssec maintain;
	inline-signing yes;
	masters { stealthMasters; };
	notify explicit;
	also-notify { publicSlaves; };
	allow-transfer { localhost; transferees; };
};

In accordance with the key-directory command above, you must copy the DNSSEC keys you created earlier to the ns0s server. Copy the entire example.com key directory and its contents to /var/lib/bind on the ns0s server. The ownership on this directory and its files must be set appropriately for DNSSEC to function. Once all this is set up, restart the bind9 service.

$ sudo chown -R bind:bind /var/lib/bind/example.com
$ sudo service bind9 restart

Once bind9 is restarted, the ns0s server will immediately transfer the example.com zone from ns0 and perform DNSSEC cryptogrpahic signing. You can verify this with the dig utility: dig @localhost example.com soa +dnssec

Configuration of Public Slave Server NS1

Like ns0, the BIND 10 server ns1 must be configured to be an authoritative DNS server.

$ sudo bindctl
["login success "] login as root
> execute init_authoritative_server
adding Authoritative server component
adding Xfrin component
adding Xfrout component
adding Zone Manager component
Components added. Please enter "config commit" to
finalize initial setup and run the components.
> config commit

Since this is a public slave server that will not be generating outgoing zone transfers, its outbound zone transfer functionality can be disabled. This is a good idea for both security and performance reasons.

> config remove Boss/components b10-xfrout
> config commit

The inbound zone transfers from ns0s to ns1 need to be configured using the ns0s-ns1 TSIG key and the address of the ns0s server. Substitute the TSIG shared secrets that you generate and the actual IPv4 or IPv6 network address of ns0s below.

> config set tsig_keys/keys ["ns0s-ns1:oBwT6UEKvMy8E0it1wVjTvvpzP22CBgPth53lgfk2bY=:hmac-sha256"]
> config add Xfrin/zones
> config set Xfrin/zones[0]/name "example.com"
> config set Xfrin/zones[0]/master_addr "<network address of ns0s>"
> config set Xfrin/zones[0]/tsig_key "ns0s-ns1:oBwT6UEKvMy8E0it1wVjTvvpzP22CBgPth53lgfk2bY=:hmac-sha256"
> config commit

In addition BIND 10 needs to be configured to process example.com is a secondary zone.

> config add Zonemgr/secondary_zones
> config set Zonemgr/secondary_zones[0]/name "example.com"
> config set Zonemgr/secondary_zones[0]/class "IN"
> config commit
> quit

BIND 10 should immediately load the DNSSEC-signed zone data from ns0s. You can verify this with the dig utility: dig @localhost example.com soa +dnssec

System Administration

Zone Data Updates

BIND 10 does not yet support dynamic updates to zone data, although this feature is due to be added soon. For the time being, in order to make changes, edit the example.com.db zone data file manually, remembering to increment the SOA serial number appropriately. Then execute sudo b10-loadzone example.com.db to load the new zone data.

DNS Notify

BIND 10 currently has a basic implementation of DNS Notify, which is equivalent to notify yes; in BIND 9. In other words when BIND 10 detects a change in zone data, it notifies the DNS servers listed in the NS records of the zone, if those servers are in the same DNS zone as specified to b10-loadzone, and if A or AAAA records for those DNS servers are also present. In this scenario, functionality equivalent to BIND 9's notify explicit; and also-notify { ... }; is required, and this is currently under development. The upshot of this is that a zone data change on ns0 will not be immediately reflected in ns0s and ns1. If the servers are left alone, the update should occur within the TTL interval of the SOA record. Using the rndc utility on the ns0s server, the update can be forced: rndc retransfer example.com followed by rndc notify example.com. Restarting the bind9 service on ns0s and the bind10 service on ns1 should also work.

Last modified 5 years ago Last modified on May 29, 2012, 1:39:24 AM

Attachments (1)

Download all attachments as: .zip