bind970-The last article discussed the basics of the BIND 9.7.0 "Smart Sign" feature. In this article, we expose additional functionality that has been incorporated into the software to make it much simpler to sign, operate, and maintain DNSSEC signed zones.  This article will help tie in some of the information provided in the previous article, Bind 9.7.0 - Part 2, New DNSSEC key metadata.  Bind 9.7.0 takes an interesting approach to automating DNSSEC key lifecycle maintenance, leveraging local Dynamic DNS enabled zones in conjunction with the embedded timing metadata in DNSSEC keys.  Other DNSSEC frameworks use a dedicated service or script to perform DNSSEC key rollovers.

In this article we'll focus on the following directives to achieve automated "Smart Signing" operations:

DirectiveGrammar ContextDescription
auto-dnssec zone statement

Configuring zones with this directive enables varying levels of automatic DNSSEC key management. There are currently four (4) possible settings:

allow - permits keys to be updated and the zone to be re-signed whenever the user issues the rndc sign zonename command.

maintain - includes the functionality above, but will also automatically adjust the zone's DNSSEC keys according to DNSSEC key timing metadata that is supplied. 

create - includes the above, but signals named to create new DNSSEC keys when needed. (NOTE: this option is not yet implemented; the syntax has been reserved for future use.)

off - which disables automatic DNSSEC functionality

Usage:

[ auto-dnssec off | allow | maintain | create; ]

dnssec-secure-to-insecure zone statement

This directive provides the ability to "convert" a DNSSEC signed (secure) zone to an unsigned (insecure) zone.  This directive takes a boolean yes | no value.

Usage: 

[ dnssec-secure-to-insecure yes | no; ]

update-policy zone statement

Sets the policy for enabling or disabling DDNS updates.  When set to local, updates to the zone will be permitted for a special key "local-ddns" which gets generated by named automatically at startup.

Usage:

[ update-policy local | { update_policy_rule [...] }; ]

key-directory zone statement

This directive sets the path to the zone's DNSSEC keys.  Bind 9.7.0 auto-dnssec relies on this directive to "find" the associated keys for a given zone. 

Usage:

[ key-directory "/path/to/dnssec/zone/keys"; ]

Example 1 - Semi-automatic "Smart Signing"

In this first example, we demonstrate semi-automatic "Smart Signing". To implement this, we'll need to "inform" the name server the following bits of information:

  • enable automatic "Smart Signing" feature on our zone(s)
  • the location of where to locate the zone's ZSK and KSK files
  • enable local Dynamic DNS on our zone(s)
  • optionally, enable the ability to "migrate" our zone(s) from being DNSSEC signed secured zone(s) to unsigned unsecured zone(s)

In this example, we'll configure example.com for semi-automatic signing using zone statements. The named.conf zone block for this zone should look like the following:

zone "example.com" {
        auto-dnssec allow;
        type master;
        update-policy local;
        file "dynamic/example.com/example.com";
        key-directory "dynamic/example.com";
};

Create the Zone Signing Key(s) or ZSK.  In this example, two ZSKs are built so that a pre-published ZSK rollover scheme can be implemented.  In this scheme, one key is marked "active" and immediately used in zone signing operations, while the other is marked "published", and simply embedded in the zone for future use. Eventually, the "published" key becomes the active key, and the former "active" key is retired. This scheme is widely used for ZSK maintenance to ensure that the chain of trust is properly maintained.  According to the NIST Secure Domain Name System (DNS) Deployment Guide, the ZSK is recommended to be 1024 Bits in length and rolled every month. Build the ZSKs as shown below:

-bash-4.0$ dnssec-keygen -r /dev/urandom example.com
Generating key pair............++++++ .................................++++++
Kexample.com.+005+16296
-bash-4.0$ dnssec-keygen -r /dev/urandom -P now -A +3024000 example.com
Generating key pair...................................++++++ ................
........................++++++ Kexample.com.+005+65475

The first command generates the current and active ZSK, and the second command generates the second ZSK that will be published now, but become active in 3,024,000 (seconds) or 5 weeks.  This example shows how the new timing metadata is set using dnssec-keygen. 

Kexample.com.+005+16296.key

; This is a zone-signing key, keyid 16296, for example.com.
; Created: Tue Feb 23 22:42:03 2010
; Publish: Tue Feb 23 22:42:03 2010
; Activate: Tue Feb 23 22:42:03 2010
example.com. IN DNSKEY 256 3 5 AwEAAc/zR+EVRV9HHwPCVIA4JPg+WinKZAAYDL5z/sFFL8OgN
6UR6anB 349k8SR++17Okl8GLG6EeMqBUaY+M6MIp/yZeU+h0w9t5hLqbsZ/Iuga xQhu0JMG3R+4DwM
3jPuHAnpJSJY6BJf00/tPXDYLkgA//kcvQBlHxvRZ f2Ipquz9

Kexample.com.+005+16296.private

Private-key-format: v1.3
Algorithm: 5 (RSASHA1)
Modulus: z/NH4RVFX0cfA8JUgDgk+D5aKcpkABgMvnP+wUUvw6A3pRHpqcHfj2TxJH77Xs6SXwYsboR
4yoFRpj4zowin/Jl5T6HTD23mEupuxn8i6BrFCG7QkwbdH7gPAzeM+4cCeklIljoEl/TT+09cNguSAD/
+Ry9AGUfG9Fl/Yimq7P0=
PublicExponent: AQAB
PrivateExponent: j4wouj+su7CkwDuNiVU4cATayK5liYsQgQghe9j+t9QJlXFgE0c5xAqyS7c8Xp3
KfL4OPdxEZcYPTurxSkHXc1AYbKl+/E1XyKy3a9EqUhrsrPOsYRVzgDdwa35xZt2rgtIwzdAI5CuDmNf
7P+Nvfz4FCLosA+dBdx5tIw/magE=
Prime1: +YVwNunBVvqaBtajhYn2Zipr1II3vBJZ0Z6cAnvcTTAXRpLQUc114J0F7BG5hBDjBflxcAXY
DofJTcMyLGnrkQ==
Prime2: 1VmFgE2ilWFSBa6KxmhxHCSA/H0MSUWxgx0iuICXVOEv6gR/PIPL0LgLAaqYPeY7QSW1M9xU
wvjUCcOxnPT8rQ==
Exponent1: PG0bOsErKCQyLtvF5+38NMurJ2CNnMcY51Gw2E0kkbDGwjmFp3nJRSbhq0Szl477W5QH6
6gOpZ4umt1dhjH0cQ==
Exponent2: lsO0O36hLb6gH7PADYUwqRqCq+oSDJVbY7PrHUaBqlGXcl/LKhBYrx3faUYMX3Ga3eavr
f49R6pe7KeFk8zr4Q==
Coefficient: XpT5SguN1q6cDds4RIiGmLAWu/l/nX6W/UMFoHuhlhIkSJalOdHR6AhYEt3U35wKDI6
EZ5Vc0V1NMlpwMIBdaA==
Created: 20100224054203
Publish: 20100224054203
Activate: 20100224054203

Kexample.com.+005+65475.key

; This is a zone-signing key, keyid 65475, for example.com.
; Created: Tue Feb 23 22:42:21 2010
; Publish: Tue Feb 23 22:42:21 2010
; Activate: Tue Mar 30 23:42:21 2010
example.com. IN DNSKEY 256 3 5 AwEAAZmwk+tNBPHOtnGOEstAIec212BB8ocsaDu2ZCQy8VOTK
6L/mWJE oAriM6qEbLlyYBJJwX23kW2sbSvQ4l0GgglLjn2E5v/AnuL8usrfav+6 LFUb+gaIbwx1ilu
rDL2khTjp7uNWtY7UPZcnxymunyO/S8B34aHNstAV NYdZ09at

Kexample.com.+005+65475.private

Private-key-format: v1.3
Algorithm: 5 (RSASHA1)
Modulus: mbCT600E8c62cY4Sy0Ah5zbXYEHyhyxoO7ZkJDLxU5Mrov+ZYkSgCuIzqoRsuXJgEknBfbe
RbaxtK9DiXQaCCUuOfYTm/8Ce4vy6yt9q/7osVRv6BohvDHWKW6sMvaSFOOnu41a1jtQ9lyfHKa6fI79
LwHfhoc2y0BU1h1nT1q0=
PublicExponent: AQAB
PrivateExponent: SyhX3dzHSzzsaXGx7SVKrxhZkOAPK11jB7h1FmK3M0ioMUjPiIfIwCnIXF3wEWx
GYQsijUkk3D5TEPdQi29wTTtd1bWv+xKl2KjWbxPsiiq/mocBGrMbvLE73agKymeAax/TuQycp6nElLw
VeL4h//2pNaUD3OVjeDt9Lz3XqV0=
Prime1: xx7dT7Al1arx+dqGIJy/q7EU4/kdYqNNofcjivKfbVhZMMZw4t2cSvhtTayTlUXxqhELTq3o
fqCTCZTZy2YuQw==
Prime2: xZd78nymeLZkqy12h7208oCLZxxBVsHl6S1yrS2tL68mQNjyIFd+cEhQjCIzNq565ObXdWjH
glV1ZDd3GHUwTw==
Exponent1: W2OIEa33/3Qg8RrhmpA2zFdPDj7kxMPMurySHJC0qVv2O5OodgdeV25jxFWjusxKWVLPT
MI2xf9u3OPrfhYcvw==
Exponent2: EDxPQfB+GUMbaHlW2PZ8jMSFL9bBg6hxBMToPFSZe2aP5RouYvvtdrpqa+lPffm+PVq+b
3ZJlmsBN1fbYFYYvw==
Coefficient: lFwSpG3CPyywZBbqloaamoYsD2Tn6/WaG72zneUzWtMNEeUT6KQnwCnt+PJfg9wUx5+
iIJYpk2P6u8l4euGzFw==
Created: 20100224054221
Publish: 20100224054221
Activate: 20100331054221

Next, a KSK needs to be generated so the zone and it's ZSKs can be signed.  This is done similar to our ZSK generation but it's suggested that a stronger key be generated.  NIST recommends KSKs be generated 2048 bits in length:

-bash-4.0$ dnssec-keygen -r /dev/urandom -f KSK -b 2048 example.com
Generating key pair..........+++ .............+++
Kexample.com.+005+16528

NOTE: that the -b 2048 is not required, this is now the default used when the -f flag is set to KSK. The above command will generate our KSK key pair with the following content:

Kexample.com.+005+16528.key

; This is a key-signing key, keyid 16528, for example.com.
; Created: Thu Feb 25 11:07:54 2010
; Publish: Thu Feb 25 11:07:54 2010
; Activate: Thu Feb 25 11:07:54 2010
example.com. IN DNSKEY 257 3 5 AwEAAaRnD68SVROkvuQ5Qez1LMGqciUJ5aVnzmrVLjtYUXg1X
VT7HQKw KR77YDE+TxaKDJH32kn8cfwPSb6k/iPynKnmcH02ynBUqMxYj+x0RyaP lKrC7GBjC2x56bp
leJFEqcq5YVUBaVPsPk8Gge9wf5vdLhmBzOH6DuDd LGB6VrcdTQdBHInVlAuXjQ31OObAkEbuMyfpGU
oU0TGoD/nhYoALLMzj WkBAkFCXnKsgT51hPBSG4SzmHSOSqkp4JvpawYRWL7BIVTZQ84Tb8m0F umFr
bzzJXR8IT6O0sHS3d5nw75m5OQaZ22WtHV0qfuLtKCAQP4P992jA b6YdVbwFg8U=

Kexample.com.+005+16528.private

Private-key-format: v1.3
Algorithm: 5 (RSASHA1)
Modulus: pGcPrxJVE6S+5DlB7PUswapyJQnlpWfOatUuO1hReDVdVPsdArApHvtgMT5PFooMkffaSfx
x/A9JvqT+I/KcqeZwfTbKcFSozFiP7HRHJo+UqsLsYGMLbHnpumV4kUSpyrlhVQFpU+w+TwaB73B/m90
uGYHM4foO4N0sYHpWtx1NB0EcidWUC5eNDfU45sCQRu4zJ+kZShTRMagP+eFigAsszONaQECQUJecqyB
PnWE8FIbhLOYdI5KqSngm+lrBhFYvsEhVNlDzhNvybQW6YWtvPMldHwhPo7SwdLd3mfDvmbk5BpnbZa0
dXSp+4u0oIBA/g/33aMBvph1VvAWDxQ==
PublicExponent: AQAB
PrivateExponent: UIlwZHpdlR7qqNDn29YLk+AUxNJBXrMoqqs+V7IfTv0NeLj/cDauHlBUwirdAZS
lLci2dfImQK2Ymb0oBqIuXwjVaHGz4C2I93oXH2WjCV/jG3gb5ef/S6e5eSeGVdvGNdp0tPjZCVS8/We
ZtZtt2AQVNkeg/77JFR0kRSsJWfBGichskG69Rb/2XMtgtJgzEnQs3d63jYu78P3FEiCn3OGWh9GMqQh
8w9LjQUHOf/r3DbG6R5TKZ5QIM0NGEPGd8YEHVMl0T8KSacW8qOeirVy86d5Q7RidQIS+5zAEBH8tLFV
xF8WvuCo3n9jd0qE6TG4AsiC0oDvGCfI2X5F0LQ==
Prime1: 1UqgdBMXvb0cP3ee8vk/xHLTJFgdvYPPlPPAJcO2torkEPUB5wHVciSzeJIlHMeKQTBVaqZd
OgCqiJFC21VNMnY77eKaJPsmT//HXDVSVI1Vi7nsoCudr1ydka1XEQTI3MdDUM4Y7GotLwqxXPN7VbMt
lqpGIivT8enqXsVM1Es=
Prime2: xVJgYtyCWsvBuBiBBFPEsCd0SFOc+KhZry/Vm0FnbKgzn9jOE/GhFBL3vXUL8hDHVcmwnzi1
ovO20LkPlaf5UnYAepxKzT4BlICbHCQZRlsSPhK7exmA0o06asMUTgTme77pa7ENyZQOP+jxikTeL92P
rs5N6RXZS8Pug8aFXi8=
Exponent1: HSGXLqNY78I/dG+rFvZx/ivMqL8cOMEi/e4YxU+oyd/IbIR6IQoAFBntJT+YsAiU2nh2g
h18yCpFIGfuoLRS2dyKLOBxOzHONsjxeqeRuhifoXjgV7P9UnEs2DO7m4hywqy4hfXQM6IAz9b/CHn80
2SoilZxQ8OGrBjNuOnrp2c=
Exponent2: JZNKR4k2SZQDj8saxngtPF5HBn7lpXRpn7K8OpR53XcqXYYruCCLTAdQpgNkAvSvAOcne
yqRbDZ82cJj9VvHXqyZ6r9Yfz0Pj/ftka5OIde14Zwvl4GDxpSeSzZa54CHY4k3agqNVZWcIQ9675mtt
e+7LM6ch4Zhmsv036MuQoE=
Coefficient: M9xTJuWxyanPu5rq5YOnT3XqlgJHLxLuBUCgYEuH9yJq9c/1nc3d+rGZol+4Bbf4QIJ
3mU+QIgScXBEea3GnTajToWqDJtAslW+8/3B4pDR3SWuNChFThUXpEc4QzENJk1RnigpHJ6KGkNYeJaC
qg4Sz63OjBtECTGrknzKL0oI=
Created: 20100225180754
Publish: 20100225180754
Activate: 20100225180754

Assume that our zone file for example.com is aptly named "example.com" and is located in the /var/named/dynamic/example.com directory path on our server. It's very important to ensure that file permissions are properly set and maintained on zone file(s) and/or key file(s). For example, if you run your name server as the user "named", then you must ensure that the file ownership and permissions are set appropriately to that user or else signing operations will fail. Here is the copy of the unsigned zone file example.com used in this example.

Provided the name server is running with the unsigned zone, you can now sign this zone using the rndc command as follows:

rndc sign example.com

Upon running this command, the name service will attempt to read in our newly created keys and use them to sign the zone. Since our zone is configured for local Dynamic DNS updates (update-policy local), any updates can be done dynamically to the zone.  A DDNS journal or .jnl file will be created, and it will contain all the RRs that were dynamically added during the signing process. This file is not human readable, but can be parsed with the bind-provided utility, named-journalprint.  The syntax for this is:

named-journalprint <jnlfile>

If you run that command on the example.com.jnl file, you should see all the dynamic updates that were injected to example.com during the signing. Our zone example.com has been fully signed automatically through local dynamic DNS updates.  Here is a copy of the signed zone file example.com.signed used in this example.

To this point, we've shown how to perform "semi-automatic" DNSSEC Smart Signing operations on a zone. Next, we'll demonstrate how to perform "fully-automatic" DNSSEC Smart Signing on the same zone. First, let's unsign the zone.  If we add the dnssec-secure-to-insecure directive to the zone block for example.com and set that value to "yes", we can unsign the zone easily with local DDNS updates by removing the DNSKEY records. NOTE: if you are using NSEC3, you will need to also remove the NSEC3PARAM record as well. This is done as follows:

nsupdate -l
> update delete example.com. DNSKEY
> send
> quit

Assuming no errors and $? evaluates to 0 after that command, the example.com zone should now be unsigned and returned to its original state. A dig lookup with the +dnssec flag set should not have any DNSSEC related records in the response from our server. To demonstrate "fully-automatic" Smart Signing, first stop the name server.  Then edit the named.conf so that the auto-dnssec is set to maintain.  The zone block of the named.conf should look like this:

zone "example.com" {
        auto-dnssec maintain;
        type master;
        update-policy local;
dnssec-secure-to-insecure yes; file "dynamic/example.com/example.com"; key-directory "dynamic/example.com"; };

When the name server is started, named will automatically search the key-directory path for valid DNSSEC ZSK and KSKs to sign the zone example.com. If the keys are valid, it will sign the zone at startup. This can be confirmed using the +dnssec flag using dig to query for the SOA of example.com. as an example.  If the server has responded with DNSSEC RRSIG records, our zone was DNSSEC signed. When operating the name service with auto-dnssec set to maintain, the name server will periodically check or set internal timers according to the metadata that is set in the keys that were generated.

At this point, it SHOULD be noted that in BIND 9.7.0, the name server will NOT automatically generate new keys. That code to do this has apparently been stubbed out for a future release. So, at this point, named will ONLY age out DNSSEC keys according to the -R (revoke), -I (inactive), and -D (delete) metadata embedded in the keys.

In conclusion, while BIND 9.7.0 doesn't fully support ZSK and KSK rollovers, there has been a tremendous amount of work and enhancements that have been made to BIND to ease the burden of configuring and maintaining DNSSEC to a DNS operator. It will be exciting to see key rollover support and additional functionality make its way into future releases of BIND.

Resources

NIST Secure Domain Name System (DNS) Deployment Guide Special Publication 800-81r1

Bind 9.7.0 Administrator Reference Manual - Internet Software Consortium (contained in BIND 9.7.0 package)

Add comment


Security code
Refresh