0N/A - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC") 0N/A - Copyright (C) 2000-2003 Internet Software Consortium. 0N/A - Permission to use, copy, modify, and/or distribute this software for any 0N/A - purpose with or without fee is hereby granted, provided that the above 0N/A - copyright notice and this permission notice appear in all copies. 0N/A - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH 0N/A - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 0N/A - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, 0N/A - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM 0N/A - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE 0N/A - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 0N/A - PERFORMANCE OF THIS SOFTWARE. 0N/A<
meta http-
equiv="Content-Type" content="text/html; charset=ISO-8859-1">
0N/A<
title>Chapter�4.�Advanced DNS Features</
title>
0N/A<
meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
0N/A<
link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
0N/A<
link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
0N/A<
body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
0N/A<
div class="navheader">
0N/A<
table width="100%" summary="Navigation header">
0N/A<
tr><
th colspan="3" align="center">Chapter�4.�Advanced DNS Features</
th></
tr>
0N/A<
td width="20%" align="left">
0N/A<
th width="60%" align="center">�</
th>
0N/A<
div class="chapter" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title">
0N/A<
a name="Bv9ARM.ch04"></
a>Chapter�4.�Advanced DNS Features</
h2></
div></
div></
div>
0N/A<
p><
b>Table of Contents</
b></
p>
0N/A<
dt><
span class="sect1"><
a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</
a></
span></
dt>
0N/A<
dd><
dl><
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#journal">The journal file</
a></
span></
dt></
dl></
dd>
0N/A<
dt><
span class="sect1"><
a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</
a></
span></
dt>
0N/A<
dd><
dl><
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2570843">Example split DNS setup</
a></
span></
dt></
dl></
dd>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571345">Generate Shared Keys for Each Pair of Hosts</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571555">Copying the Shared Secret to Both Machines</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571565">Informing the Servers of the Key's Existence</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571602">Instructing the Server to Use the Key</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571659">TSIG Key Based Access Control</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2572273">Configuring Servers</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2606210">Converting from insecure to secure</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2563512">Dynamic DNS update method</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2563548">Fully automatic zone signing</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2563835">Private-type records</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2563885">Dynamic DNS update method</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571837">Automatic key rollovers</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571864">NSEC3PARAM rollovers via UPDATE</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571874">Converting from NSEC to NSEC3</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571952">Converting from NSEC3 to NSEC</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2571964">Converting from secure to insecure</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2572002">Periodic re-signing</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2572065">Validating Resolver</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2605947">Authoritative Server</
a></
span></
dt>
0N/A<
dt><
span class="sect1"><
a href="Bv9ARM.ch04.html#pkcs11">PKCS #11 (Cryptoki) support</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2606674">Building BIND 9 with PKCS#11</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2608978">Specifying the engine on the command line</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2609024">Running named with automatic zone re-signing</
a></
span></
dt>
0N/A<
dt><
span class="sect1"><
a href="Bv9ARM.ch04.html#id2572468">IPv6 Support in <
acronym class="acronym">BIND</
acronym> 9</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2572734">Address Lookups Using AAAA Records</
a></
span></
dt>
0N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch04.html#id2572756">Address to Name Lookups Using Nibble Format</
a></
span></
dt>
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="notify"></
a>Notify</
h2></
div></
div></
div>
0N/A <
acronym class="acronym">DNS</
acronym> NOTIFY is a mechanism that allows master
0N/A servers to notify their slave servers of changes to a zone's data. In
0N/A response to a <
span><
strong class="command">NOTIFY</
strong></
span> from a master server, the
0N/A slave will check to see that its version of the zone is the
0N/A current version and, if not, initiate a zone transfer.
0N/A For more information about <
acronym class="acronym">DNS</
acronym>
0N/A <
span><
strong class="command">NOTIFY</
strong></
span>, see the description of the
0N/A <
span><
strong class="command">notify</
strong></
span> option in <
a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</
a> and
0N/A the description of the zone option <
span><
strong class="command">also-notify</
strong></
span> in
0N/A <
a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</
a>. The <
span><
strong class="command">NOTIFY</
strong></
span>
0N/A protocol is specified in RFC 1996.
0N/A<
div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
0N/A<
h3 class="title">Note</
h3>
0N/A As a slave zone can also be a master to other slaves, <
span><
strong class="command">named</
strong></
span>,
0N/A by default, sends <
span><
strong class="command">NOTIFY</
strong></
span> messages for every zone
0N/A it loads. Specifying <
span><
strong class="command">notify master-only;</
strong></
span> will
0N/A cause <
span><
strong class="command">named</
strong></
span> to only send <
span><
strong class="command">NOTIFY</
strong></
span> for master
0N/A zones that it loads.
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="dynamic_update"></
a>Dynamic Update</
h2></
div></
div></
div>
0N/A Dynamic Update is a method for adding, replacing or deleting
0N/A records in a master server by sending it a special form of DNS
0N/A messages. The format and meaning of these messages is specified
0N/A Dynamic update is enabled by including an
0N/A <
span><
strong class="command">allow-update</
strong></
span> or an <
span><
strong class="command">update-policy</
strong></
span>
0N/A clause in the <
span><
strong class="command">zone</
strong></
span> statement.
0N/A If the zone's <
span><
strong class="command">update-policy</
strong></
span> is set to
0N/A <
strong class="userinput"><
code>local</
code></
strong>, updates to the zone
0N/A will be permitted for the key <
code class="varname">local-ddns</
code>,
0N/A which will be generated by <
span><
strong class="command">named</
strong></
span> at startup.
0N/A See <
a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called “Dynamic Update Policies”</
a> for more details.
0N/A The <
span><
strong class="command">tkey-gssapi-credential</
strong></
span> and
0N/A <
span><
strong class="command">tkey-domain</
strong></
span> clauses in the
0N/A <
span><
strong class="command">options</
strong></
span> statement enable the
0N/A server to negotiate keys that can be matched against those
0N/A in <
span><
strong class="command">update-policy</
strong></
span> or
0N/A <
span><
strong class="command">allow-update</
strong></
span>.
0N/A Updating of secure zones (zones using DNSSEC) follows RFC
0N/A 3007: RRSIG, NSEC and NSEC3 records affected by updates are
0N/A automatically regenerated by the server using an online
0N/A zone key. Update authorization is based on transaction
0N/A signatures and an explicit server policy.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="journal"></
a>The journal file</
h3></
div></
div></
div>
0N/A All changes made to a zone using dynamic update are stored
0N/A in the zone's journal file. This file is automatically created
0N/A by the server when the first dynamic update takes place.
0N/A The name of the journal file is formed by appending the extension
0N/A <
code class="filename">.jnl</
code> to the name of the
0N/A file unless specifically overridden. The journal file is in a
0N/A binary format and should not be edited manually.
0N/A The server will also occasionally write ("dump")
0N/A the complete contents of the updated zone to its zone file.
0N/A This is not done immediately after
0N/A each dynamic update, because that would be too slow when a large
0N/A zone is updated frequently. Instead, the dump is delayed by
0N/A up to 15 minutes, allowing additional updates to take place.
0N/A During the dump process, transient files will be created
0N/A with the extensions <
code class="filename">.jnw</
code> and
0N/A <
code class="filename">.jbk</
code>; under ordinary circumstances, these
0N/A will be removed when the dump is complete, and can be safely
0N/A When a server is restarted after a shutdown or crash, it will replay
0N/A the journal file to incorporate into the zone any updates that
0N/A place after the last zone dump.
0N/A Changes that result from incoming incremental zone transfers are
0N/A journalled in a similar way.
0N/A The zone files of dynamic zones cannot normally be edited by
0N/A hand because they are not guaranteed to contain the most recent
0N/A dynamic changes — those are only in the journal file.
0N/A The only way to ensure that the zone file of a dynamic zone
0N/A is up to date is to run <
span><
strong class="command">rndc stop</
strong></
span>.
0N/A If you have to make changes to a dynamic zone
0N/A manually, the following procedure will work: Disable dynamic updates
0N/A <
span><
strong class="command">rndc freeze <
em class="replaceable"><
code>zone</
code></
em></
strong></
span>.
0N/A This will also remove the zone's <
code class="filename">.jnl</
code> file
0N/A and update the master file. Edit the zone file. Run
0N/A <
span><
strong class="command">rndc thaw <
em class="replaceable"><
code>zone</
code></
em></
strong></
span>
0N/A to reload the changed zone and re-enable dynamic updates.
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="incremental_zone_transfers"></
a>Incremental Zone Transfers (IXFR)</
h2></
div></
div></
div>
0N/A The incremental zone transfer (IXFR) protocol is a way for
0N/A slave servers to transfer only changed data, instead of having to
0N/A transfer the entire zone. The IXFR protocol is specified in RFC
0N/A When acting as a master, <
acronym class="acronym">BIND</
acronym> 9
0N/A supports IXFR for those zones
0N/A where the necessary change history information is available. These
0N/A include master zones maintained by dynamic update and slave zones
0N/A whose data was obtained by IXFR. For manually maintained master
0N/A zones, and for slave zones obtained by performing a full zone
0N/A transfer (AXFR), IXFR is supported only if the option
0N/A <
span><
strong class="command">ixfr-from-differences</
strong></
span> is set
0N/A to <
strong class="userinput"><
code>yes</
code></
strong>.
0N/A When acting as a slave, <
acronym class="acronym">BIND</
acronym> 9 will
0N/A attempt to use IXFR unless
0N/A it is explicitly disabled. For more information about disabling
0N/A IXFR, see the description of the <
span><
strong class="command">request-ixfr</
strong></
span> clause
0N/A of the <
span><
strong class="command">server</
strong></
span> statement.
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="id2570825"></
a>Split DNS</
h2></
div></
div></
div>
0N/A Setting up different views, or visibility, of the DNS space to
0N/A internal and external resolvers is usually referred to as a
0N/A <
span class="emphasis"><
em>Split DNS</
em></
span> setup. There are several
0N/A reasons an organization would want to set up its DNS this way.
0N/A One common reason for setting up a DNS system this way is
0N/A to hide "internal" DNS information from "external" clients on the
0N/A Internet. There is some debate as to whether or not this is actually
0N/A Internal DNS information leaks out in many ways (via email headers,
0N/A for example) and most savvy "attackers" can find the information
0N/A they need using other means.
0N/A However, since listing addresses of internal servers that
0N/A external clients cannot possibly reach can result in
0N/A connection delays and other annoyances, an organization may
0N/A choose to use a Split DNS to present a consistent view of itself
0N/A to the outside world.
0N/A Another common reason for setting up a Split DNS system is
0N/A to allow internal networks that are behind filters or in RFC 1918
0N/A space (reserved IP space, as documented in RFC 1918) to resolve DNS
0N/A on the Internet. Split DNS can also be used to allow mail from outside
0N/A back in to the internal network.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2570843"></
a>Example split DNS setup</
h3></
div></
div></
div>
0N/A Let's say a company named <
span class="emphasis"><
em>Example, Inc.</
em></
span>
0N/A has several corporate sites that have an internal network with
0N/A Internet Protocol (IP) space and an external demilitarized zone (DMZ),
0N/A or "outside" section of a network, that is available to the public.
0N/A <
span class="emphasis"><
em>Example, Inc.</
em></
span> wants its internal clients
0N/A to be able to resolve external hostnames and to exchange mail with
0N/A people on the outside. The company also wants its internal resolvers
0N/A to have access to certain internal-only zones that are not available
0N/A at all outside of the internal network.
0N/A In order to accomplish this, the company will set up two sets
0N/A of name servers. One set will be on the inside network (in the
0N/A IP space) and the other set will be on bastion hosts, which are
0N/A hosts that can talk to both sides of its network, in the DMZ.
0N/A The internal servers will be configured to forward all queries,
0N/A DMZ. These internal servers will have complete sets of information
0N/A the internal name servers must be configured to disallow all queries
0N/A to these domains from any external hosts, including the bastion
0N/A The external servers, which are on the bastion hosts, will
0N/A be configured to serve the "public" version of the <
code class="filename">site1</
code> and <
code class="filename">
site2.example.com</
code> zones.
0N/A This could include things such as the host records for public servers
0N/A In addition, the public <
code class="filename">site1</
code> and <
code class="filename">
site2.example.com</
code> zones
0N/A should have special MX records that contain wildcard (`*') records
0N/A pointing to the bastion hosts. This is needed because external mail
0N/A servers do not have any other way of looking up how to deliver mail
0N/A to those internal hosts. With the wildcard records, the mail will
0N/A be delivered to the bastion host, which can then forward it on to
0N/A Here's an example of a wildcard MX record:
0N/A Now that they accept mail on behalf of anything in the internal
0N/A network, the bastion hosts will need to know how to deliver mail
0N/A to internal hosts. In order for this to work properly, the resolvers
0N/A the bastion hosts will need to be configured to point to the internal
0N/A name servers for DNS resolution.
0N/A Queries for internal hostnames will be answered by the internal
0N/A servers, and queries for external hostnames will be forwarded back
0N/A out to the DNS servers on the bastion hosts.
0N/A In order for all this to work properly, internal clients will
0N/A need to be configured to query <
span class="emphasis"><
em>only</
em></
span> the internal
0N/A name servers for DNS queries. This could also be enforced via
0N/A filtering on the network.
0N/A If everything has been set properly, <
span class="emphasis"><
em>Example, Inc.</
em></
span>'s
0N/A internal clients will now be able to:
0N/A<
div class="itemizedlist"><
ul type="disc">
0N/A Look up any hostnames in the <
code class="literal">site1</
code>
0N/A<
li>Look up any hostnames on the Internet.</
li>
0N/A<
li>Exchange mail with both internal and external people.</
li>
0N/A Hosts on the Internet will be able to:
0N/A<
div class="itemizedlist"><
ul type="disc">
0N/A Look up any hostnames in the <
code class="literal">site1</
code>
0N/A Exchange mail with anyone in the <
code class="literal">site1</
code> and
0N/A Here is an example configuration for the setup we just
0N/A described above. Note that this is only configuration information;
0N/A for information on how to configure your zone files, see <
a href="Bv9ARM.ch03.html#sample_configuration" title="Sample Configurations">the section called “Sample Configurations”</
a>.
0N/A Internal DNS server config:
0N/A<
pre class="programlisting">
0N/Aacl externals { <
code class="varname">bastion-ips-go-here</
code>; };
0N/A // forward to external servers
0N/A <
code class="varname">bastion-ips-go-here</
code>;
0N/A // sample allow-transfer (no one)
0N/A allow-transfer { none; };
0N/A // restrict query access
0N/A allow-query { internals; externals; };
0N/A // restrict recursion
0N/A allow-recursion { internals; };
0N/A// sample master zone
0N/A // do normal iterative resolution (do not forward)
0N/A allow-query { internals; externals; };
0N/A allow-transfer { internals; };
0N/A masters { 172.16.72.3; };
0N/A allow-query { internals; externals; };
0N/A allow-transfer { internals; };
0N/A allow-query { internals; };
0N/A allow-transfer { internals; }
0N/A masters { 172.16.72.3; };
0N/A allow-query { internals };
0N/A allow-transfer { internals; }
0N/A External (bastion host) DNS server config:
0N/A<
pre class="programlisting">
0N/Aacl externals { bastion-ips-go-here; };
0N/A // sample allow-transfer (no one)
0N/A allow-transfer { none; };
0N/A // default query access
0N/A allow-query { any; };
0N/A // restrict cache access
0N/A allow-query-cache { internals; externals; };
0N/A // restrict recursion
0N/A allow-recursion { internals; externals; };
0N/A allow-transfer { internals; externals; };
0N/A masters { another_bastion_host_maybe; };
0N/A allow-transfer { internals; externals; }
0N/A the bastion host(s):
0N/A<
pre class="programlisting">
0N/Anameserver 172.16.72.2
0N/Anameserver 172.16.72.3
0N/Anameserver 172.16.72.4
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="tsig"></
a>TSIG</
h2></
div></
div></
div>
0N/A This is a short guide to setting up Transaction SIGnatures
0N/A (TSIG) based transaction security in <
acronym class="acronym">BIND</
acronym>. It describes changes
0N/A to the configuration file as well as what changes are required for
0N/A different features, including the process of creating transaction
0N/A keys and using transaction signatures with <
acronym class="acronym">BIND</
acronym>.
0N/A <
acronym class="acronym">BIND</
acronym> primarily supports TSIG for server
0N/A to server communication.
0N/A This includes zone transfer, notify, and recursive query messages.
0N/A Resolvers based on newer versions of <
acronym class="acronym">BIND</
acronym> 8 have limited support
0N/A TSIG can also be useful for dynamic update. A primary
0N/A server for a dynamic zone should control access to the dynamic
0N/A update service, but IP-based access control is insufficient.
0N/A The cryptographic access control provided by TSIG
0N/A is far superior. The <
span><
strong class="command">nsupdate</
strong></
span>
0N/A program supports TSIG via the <
code class="option">-k</
code> and
0N/A <
code class="option">-y</
code> command line options or inline by use
0N/A of the <
span><
strong class="command">key</
strong></
span>.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571345"></
a>Generate Shared Keys for Each Pair of Hosts</
h3></
div></
div></
div>
0N/A A shared secret is generated to be shared between <
span class="emphasis"><
em>host1</
em></
span> and <
span class="emphasis"><
em>host2</
em></
span>.
0N/A An arbitrary key name is chosen: "host1-host2.". The key name must
0N/A be the same on both hosts.
0N/A<
div class="sect3" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h4 class="title">
0N/A<
a name="id2571362"></
a>Automatic Generation</
h4></
div></
div></
div>
0N/A The following command will generate a 128-bit (16 byte) HMAC-SHA256
0N/A key as described above. Longer keys are better, but shorter keys
0N/A are easier to read. Note that the maximum key length is the digest
0N/A length, here 256 bits.
0N/A <
strong class="userinput"><
code>dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2.</
code></
strong>
0N/A The key is in the file <
code class="filename">Khost1-host2.+163+
00000.private</
code>.
0N/A Nothing directly uses this file, but the base-64 encoded string
0N/A following "<
code class="literal">Key:</
code>"
0N/A can be extracted from the file and used as a shared secret:
0N/A<
pre class="programlisting">Key:
La/
E5CjG9O+os1jq0a2jdA==</
pre>
0N/A The string "<
code class="literal">
La/
E5CjG9O+os1jq0a2jdA==</
code>" can
0N/A be used as the shared secret.
0N/A<
div class="sect3" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h4 class="title">
0N/A<
a name="id2571537"></
a>Manual Generation</
h4></
div></
div></
div>
0N/A The shared secret is simply a random sequence of bits, encoded
0N/A in base-64. Most ASCII strings are valid base-64 strings (assuming
0N/A the length is a multiple of 4 and only valid characters are used),
0N/A so the shared secret can be manually generated.
0N/A Also, a known string can be run through <
span><
strong class="command">mmencode</
strong></
span> or
0N/A a similar program to generate base-64 encoded data.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571555"></
a>Copying the Shared Secret to Both Machines</
h3></
div></
div></
div>
0N/A This is beyond the scope of DNS. A secure transport mechanism
0N/A should be used. This could be secure FTP, ssh, telephone, etc.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571565"></
a>Informing the Servers of the Key's Existence</
h3></
div></
div></
div>
0N/A Imagine <
span class="emphasis"><
em>host1</
em></
span> and <
span class="emphasis"><
em>host 2</
em></
span>
0N/A both servers. The following is added to each server's <
code class="filename">
named.conf</
code> file:
0N/A<
pre class="programlisting">
0N/A algorithm hmac-sha256;
0N/A The secret is the one generated above. Since this is a secret, it
0N/A is recommended that either <
code class="filename">
named.conf</
code> be
0N/A non-world readable, or the key directive be added to a non-world
0N/A readable file that is included by <
code class="filename">
named.conf</
code>.
0N/A At this point, the key is recognized. This means that if the
0N/A server receives a message signed by this key, it can verify the
0N/A signature. If the signature is successfully verified, the
0N/A response is signed by the same key.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571602"></
a>Instructing the Server to Use the Key</
h3></
div></
div></
div>
0N/A Since keys are shared between two hosts only, the server must
0N/A be told when keys are to be used. The following is added to the <
code class="filename">
named.conf</
code> file
0N/A for <
span class="emphasis"><
em>host1</
em></
span>, if the IP address of <
span class="emphasis"><
em>host2</
em></
span> is
0N/A<
pre class="programlisting">
0N/A keys { host1-host2. ;};
0N/A Multiple keys may be present, but only the first is used.
0N/A This directive does not contain any secrets, so it may be in a
0N/A If <
span class="emphasis"><
em>host1</
em></
span> sends a message that is a request
0N/A to that address, the message will be signed with the specified key. <
span class="emphasis"><
em>host1</
em></
span> will
0N/A expect any responses to signed messages to be signed with the same
0N/A A similar statement must be present in <
span class="emphasis"><
em>host2</
em></
span>'s
0N/A configuration file (with <
span class="emphasis"><
em>host1</
em></
span>'s address) for <
span class="emphasis"><
em>host2</
em></
span> to
0N/A sign request messages to <
span class="emphasis"><
em>host1</
em></
span>.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571659"></
a>TSIG Key Based Access Control</
h3></
div></
div></
div>
0N/A <
acronym class="acronym">BIND</
acronym> allows IP addresses and ranges
0N/A to be specified in ACL
0N/A <
span><
strong class="command">allow-{ query | transfer | update }</
strong></
span>
0N/A This has been extended to allow TSIG keys also. The above key would
0N/A be denoted <
span><
strong class="command">key host1-host2.</
strong></
span>
0N/A An example of an <
span><
strong class="command">allow-update</
strong></
span> directive would be:
0N/A<
pre class="programlisting">
0N/Aallow-update { key host1-host2. ;};
0N/A This allows dynamic updates to succeed only if the request
2047N/A was signed by a key named "<
span><
strong class="command">host1-host2.</
strong></
span>".
0N/A See <
a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called “Dynamic Update Policies”</
a> for a discussion of
0N/A the more flexible <
span><
strong class="command">update-policy</
strong></
span> statement.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571708"></
a>Errors</
h3></
div></
div></
div>
0N/A The processing of TSIG signed messages can result in
0N/A several errors. If a signed message is sent to a non-TSIG aware
0N/A server, a FORMERR (format error) will be returned, since the server will not
0N/A understand the record. This is a result of misconfiguration,
0N/A since the server must be explicitly configured to send a TSIG
0N/A signed message to a specific server.
0N/A If a TSIG aware server receives a message signed by an
0N/A unknown key, the response will be unsigned with the TSIG
0N/A extended error code set to BADKEY. If a TSIG aware server
0N/A receives a message with a signature that does not validate, the
0N/A response will be unsigned with the TSIG extended error code set
0N/A to BADSIG. If a TSIG aware server receives a message with a time
0N/A outside of the allowed range, the response will be signed with
0N/A the TSIG extended error code set to BADTIME, and the time values
0N/A will be adjusted so that the response can be successfully
0N/A verified. In any of these cases, the message's rcode (response code) is set to
0N/A NOTAUTH (not authenticated).
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="id2571722"></
a>TKEY</
h2></
div></
div></
div>
0N/A<
p><
span><
strong class="command">TKEY</
strong></
span>
0N/A is a mechanism for automatically generating a shared secret
0N/A between two hosts. There are several "modes" of
0N/A <
span><
strong class="command">TKEY</
strong></
span> that specify how the key is generated
0N/A or assigned. <
acronym class="acronym">BIND</
acronym> 9 implements only one of
0N/A these modes, the Diffie-Hellman key exchange. Both hosts are
0N/A required to have a Diffie-Hellman KEY record (although this
0N/A record is not required to be present in a zone). The
0N/A <
span><
strong class="command">TKEY</
strong></
span> process must use signed messages,
0N/A signed either by TSIG or SIG(0). The result of
0N/A <
span><
strong class="command">TKEY</
strong></
span> is a shared secret that can be used to
0N/A sign messages with TSIG. <
span><
strong class="command">TKEY</
strong></
span> can also be
0N/A used to delete shared secrets that it had previously
0N/A The <
span><
strong class="command">TKEY</
strong></
span> process is initiated by a
0N/A or server by sending a signed <
span><
strong class="command">TKEY</
strong></
span>
0N/A (including any appropriate KEYs) to a TKEY-aware server. The
0N/A server response, if it indicates success, will contain a
0N/A <
span><
strong class="command">TKEY</
strong></
span> record and any appropriate keys.
0N/A this exchange, both participants have enough information to
0N/A determine the shared secret; the exact process depends on the
0N/A <
span><
strong class="command">TKEY</
strong></
span> mode. When using the
0N/A <
span><
strong class="command">TKEY</
strong></
span> mode, Diffie-Hellman keys are
0N/A and the shared secret is derived by both participants.
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="id2563989"></
a>SIG(0)</
h2></
div></
div></
div>
0N/A <
acronym class="acronym">BIND</
acronym> 9 partially supports DNSSEC SIG(0)
0N/A transaction signatures as specified in RFC 2535 and RFC 2931.
0N/A is performed in the same manner as TSIG keys; privileges can be
0N/A granted or denied based on the key name.
0N/A When a SIG(0) signed message is received, it will only be
0N/A verified if the key is known and trusted by the server; the server
0N/A will not attempt to locate
and/
or validate the key.
0N/A SIG(0) signing of multiple-message TCP streams is not
0N/A The only tool shipped with <
acronym class="acronym">BIND</
acronym> 9 that
0N/A generates SIG(0) signed messages is <
span><
strong class="command">nsupdate</
strong></
span>.
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="DNSSEC"></
a>DNSSEC</
h2></
div></
div></
div>
0N/A Cryptographic authentication of DNS information is possible
0N/A through the DNS Security (<
span class="emphasis"><
em>DNSSEC-bis</
em></
span>) extensions,
0N/A defined in RFC 4033, RFC 4034, and RFC 4035.
0N/A This section describes the creation and use of DNSSEC signed zones.
0N/A In order to set up a DNSSEC secure zone, there are a series
0N/A of steps which must be followed. <
acronym class="acronym">BIND</
acronym>
0N/A that are used in this process, which are explained in more detail
0N/A below. In all cases, the <
code class="option">-h</
code> option prints a
0N/A full list of parameters. Note that the DNSSEC tools require the
0N/A keyset files to be in the working directory or the
0N/A directory specified by the <
code class="option">-d</
code> option, and
0N/A that the tools shipped with BIND
9.2.x and earlier are not compatible
0N/A with the current ones.
0N/A There must also be communication with the administrators of
0N/A the parent
and/
or child zone to transmit keys. A zone's security
0N/A status must be indicated by the parent zone for a DNSSEC capable
0N/A resolver to trust its data. This is done through the presence
0N/A or absence of a <
code class="literal">DS</
code> record at the
0N/A For other servers to trust data in this zone, they must
0N/A either be statically configured with this zone's zone key or the
0N/A zone key of another zone above this one in the DNS tree.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2564057"></
a>Generating Keys</
h3></
div></
div></
div>
0N/A The <
span><
strong class="command">dnssec-keygen</
strong></
span> program is used to
0N/A A secure zone must contain one or more zone keys. The
0N/A zone keys will sign all other records in the zone, as well as
0N/A the zone keys of any secure delegated zones. Zone keys must
0N/A have the same name as the zone, a name type of
0N/A <
span><
strong class="command">ZONE</
strong></
span>, and must be usable for
0N/A It is recommended that zone keys use a cryptographic algorithm
0N/A designated as "mandatory to implement" by the IETF; currently
0N/A the only one is RSASHA1.
0N/A The following command will generate a 768-bit RSASHA1 key for
0N/A <
strong class="userinput"><
code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE
child.example.</
code></
strong>
0N/A Two output files will be produced:
0N/A 12345 is an example of a key tag). The key filenames contain
0N/A is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
0N/A The private key (in the <
code class="filename">.private</
code>
0N/A used to generate signatures, and the public key (in the
0N/A <
code class="filename">.key</
code> file) is used for signature
0N/A To generate another key with the same properties (but with
0N/A a different key tag), repeat the above command.
0N/A The <
span><
strong class="command">dnssec-keyfromlabel</
strong></
span> program is used
0N/A to get a key pair from a crypto hardware and build the key
0N/A files. Its usage is similar to <
span><
strong class="command">dnssec-keygen</
strong></
span>.
0N/A The public keys should be inserted into the zone file by
0N/A including the <
code class="filename">.key</
code> files using
0N/A <
span><
strong class="command">$INCLUDE</
strong></
span> statements.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2572192"></
a>Signing the Zone</
h3></
div></
div></
div>
0N/A The <
span><
strong class="command">dnssec-signzone</
strong></
span> program is used
0N/A Any <
code class="filename">keyset</
code> files corresponding to
0N/A secure subzones should be present. The zone signer will
0N/A generate <
code class="literal">NSEC</
code>, <
code class="literal">NSEC3</
code>
0N/A and <
code class="literal">RRSIG</
code> records for the zone, as
0N/A well as <
code class="literal">DS</
code> for the child zones if
0N/A <
code class="literal">'-g'</
code> is specified. If <
code class="literal">'-g'</
code>
0N/A is not specified, then DS RRsets for the secure child
0N/A zones need to be added manually.
0N/A The following command signs the zone, assuming it is in a
0N/A default, all zone keys which have an available private key are
0N/A used to generate signatures.
0N/A One output file is produced:
0N/A input file for the zone.
0N/A<
p><
span><
strong class="command">dnssec-signzone</
strong></
span>
0N/A will also produce a keyset and dsset files and optionally a
0N/A dlvset file. These are used to provide the parent zone
0N/A administrators with the <
code class="literal">DNSKEYs</
code> (or their
0N/A corresponding <
code class="literal">DS</
code> records) that are the
0N/A secure entry point to the zone.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2572273"></
a>Configuring Servers</
h3></
div></
div></
div>
0N/A To enable <
span><
strong class="command">named</
strong></
span> to respond appropriately
0N/A to DNS requests from DNSSEC aware clients,
0N/A <
span><
strong class="command">dnssec-enable</
strong></
span> must be set to yes.
0N/A (This is the default setting.)
0N/A To enable <
span><
strong class="command">named</
strong></
span> to validate answers from
0N/A other servers, the <
span><
strong class="command">dnssec-enable</
strong></
span> and
0N/A <
span><
strong class="command">dnssec-validation</
strong></
span> options must both be
0N/A set to yes (the default setting in <
acronym class="acronym">BIND</
acronym> 9.5
0N/A and later), and at least one trust anchor must be configured
0N/A with a <
span><
strong class="command">trusted-keys</
strong></
span> or
0N/A <
span><
strong class="command">managed-keys</
strong></
span> statement in
0N/A <
span><
strong class="command">trusted-keys</
strong></
span> are copies of DNSKEY RRs
0N/A for zones that are used to form the first link in the
0N/A cryptographic chain of trust. All keys listed in
0N/A <
span><
strong class="command">trusted-keys</
strong></
span> (and corresponding zones)
0N/A are deemed to exist and only the listed keys will be used
0N/A to validated the DNSKEY RRset that they are from.
0N/A <
span><
strong class="command">managed-keys</
strong></
span> are trusted keys which are
0N/A automatically kept up to date via RFC 5011 trust anchor
0N/A <
span><
strong class="command">trusted-keys</
strong></
span> and
0N/A <
span><
strong class="command">managed-keys</
strong></
span> are described in more detail
0N/A later in this document.
0N/A Unlike <
acronym class="acronym">BIND</
acronym> 8, <
acronym class="acronym">BIND</
acronym>
0N/A 9 does not verify signatures on load, so zone keys for
0N/A authoritative zones do not need to be specified in the
0N/A After DNSSEC gets established, a typical DNSSEC configuration
0N/A will look something like the following. It has one or
0N/A more public keys for the root. This allows answers from
0N/A outside the organization to be validated. It will also
0N/A have several keys for parts of the namespace the organization
0N/A controls. These are here to ensure that <
span><
strong class="command">named</
strong></
span>
0N/A is immune to compromises in the DNSSEC components of the security
0N/A<
pre class="programlisting">
0N/A "." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
0N/A 66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
0N/A dgxbcDTClU0CRBdiieyLMNzXG3";
0N/A /* Key for our organization's forward zone */
0N/A 5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
0N/A GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
0N/A 4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
0N/A g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
0N/A TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
0N/A F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
0N/A /* Key for our reverse zone. */
0N/A xOdNax071L18QqZnQQQAVVr+i
0N/A LhGTnNGp3HoWQLUIzKrJVZ3zg
0N/A gy3WwNT6kZo6c0tszYqbtvchm
0N/A siaOdS0yOI6BgPsw+YZdzlYMa
0N/A IJGf4M4dyoKIhzdZyQ2bYQrjy
0N/A Q4LB0lC7aOnsMyYKHHYeRvPxj
0N/A IQXmdqgOJGq+vsevG06zW+1xg
0N/A 59VvjSPsZJHeDCUyWYrvPZesZ
0N/A DIRvhDD52SKvbheeTJUm6Ehkz
0N/A dnssec-validation yes;
0N/A<
div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
0N/A<
h3 class="title">Note</
h3>
0N/A None of the keys listed in this example are valid. In particular,
0N/A the root key is not valid.
0N/A When DNSSEC validation is enabled and properly configured,
0N/A the resolver will reject any answers from signed, secure zones
0N/A which fail to validate, and will return SERVFAIL to the client.
0N/A Responses may fail to validate for any of several reasons,
0N/A including missing, expired, or invalid signatures, a key which
0N/A does not match the DS RRset in the parent zone, or an insecure
0N/A response from a zone which, according to its parent, should have
0N/A<
div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
0N/A<
h3 class="title">Note</
h3>
0N/A When the validator receives a response from an unsigned zone
0N/A that has a signed parent, it must confirm with the parent
0N/A that the zone was intentionally left unsigned. It does
0N/A this by verifying, via signed and validated
NSEC/
NSEC3 records,
0N/A that the parent zone contains no DS records for the child.
0N/A If the validator <
span class="emphasis"><
em>can</
em></
span> prove that the zone
0N/A is insecure, then the response is accepted. However, if it
0N/A cannot, then it must assume an insecure response to be a
0N/A forgery; it rejects the response and logs an error.
0N/A The logged error reads "insecurity proof failed" and
0N/A "got insecure response; parent indicates it should be secure".
0N/A (Prior to BIND 9.7, the logged error was "not insecure".
0N/A This referred to the zone, not the response.)
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
p>As of BIND 9.7.0 it is possible to change a dynamic zone
0N/A from insecure to signed and back again. A secure zone can use
0N/A either NSEC or NSEC3 chains.</
p>
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2606210"></
a>Converting from insecure to secure</
h3></
div></
div></
div></
div>
0N/A<
p>Changing a zone from insecure to secure can be done in two
0N/A ways: using a dynamic DNS update, or the
0N/A <
span><
strong class="command">auto-dnssec</
strong></
span> zone option.</
p>
0N/A<
p>For either method, you need to configure
0N/A <
span><
strong class="command">named</
strong></
span> so that it can see the
0N/A <
code class="filename">K*</
code> files which contain the public and private
0N/A parts of the keys that will be used to sign the zone. These files
0N/A will have been generated by
0N/A <
span><
strong class="command">dnssec-keygen</
strong></
span>. You can do this by placing them
0N/A in the key-directory, as specified in
0N/A<
pre class="programlisting">
0N/A update-policy local;
0N/A<
p>If one KSK and one ZSK DNSKEY key have been generated, this
0N/A configuration will cause all records in the zone to be signed
0N/A with the ZSK, and the DNSKEY RRset to be signed with the KSK as
0N/A well. An NSEC chain will be generated as part of the initial
0N/A signing process.</
p>
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2563512"></
a>Dynamic DNS update method</
h3></
div></
div></
div></
div>
0N/A<
p>To insert the keys via dynamic update:</
p>
0N/A<
p>While the update request will complete almost immediately,
0N/A the zone will not be completely signed until
0N/A <
span><
strong class="command">named</
strong></
span> has had time to walk the zone and
0N/A generate the NSEC and RRSIG records. The NSEC record at the apex
0N/A will be added last, to signal that there is a complete NSEC
0N/A<
p>If you wish to sign using NSEC3 instead of NSEC, you should
0N/A add an NSEC3PARAM record to the initial update request. If you
0N/A wish the NSEC3 chain to have the OPTOUT bit set, set it in the
0N/A flags field of the NSEC3PARAM record.</
p>
0N/A<
p>Again, this update request will complete almost
0N/A immediately; however, the record won't show up until
0N/A <
span><
strong class="command">named</
strong></
span> has had a chance to
build/
remove the
0N/A relevant chain. A private type record will be created to record
0N/A the state of the operation (see below for more details), and will
0N/A be removed once the operation completes.</
p>
0N/A is happening, other updates are possible as well.</
p>
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2563548"></
a>Fully automatic zone signing</
h3></
div></
div></
div></
div>
0N/A<
p>To enable automatic signing, add the
0N/A <
span><
strong class="command">auto-dnssec</
strong></
span> option to the zone statement in
0N/A <
span><
strong class="command">auto-dnssec</
strong></
span> has two possible arguments:
0N/A <
code class="constant">allow</
code> or
0N/A <
code class="constant">maintain</
code>.</
p>
0N/A <
span><
strong class="command">auto-dnssec allow</
strong></
span>,
0N/A <
span><
strong class="command">named</
strong></
span> can search the key directory for keys
0N/A matching the zone, insert them into the zone, and use them to
0N/A sign the zone. It will do so only when it receives an
0N/A <
span><
strong class="command">rndc sign <zonename></
strong></
span> or
0N/A <
span><
strong class="command">rndc loadkeys <zonename></
strong></
span> command.</
p>
0N/A <
span><
strong class="command">auto-dnssec maintain</
strong></
span> includes the above
0N/A functionality, but will also automatically adjust the zone's
0N/A DNSKEY records on schedule according to the keys' timing metadata.
0N/A (See <
a href="man.dnssec-keygen.html" title="dnssec-keygen"><
span class="refentrytitle"><
span class="application">dnssec-keygen</
span></
span>(8)</
a> and
0N/A <
a href="man.dnssec-settime.html" title="dnssec-settime"><
span class="refentrytitle"><
span class="application">dnssec-settime</
span></
span>(8)</
a> for more information.)
0N/A If keys are present in the key directory the first time the zone
0N/A is loaded, it will be signed immediately, without waiting for an
0N/A <
span><
strong class="command">rndc sign</
strong></
span> or <
span><
strong class="command">rndc loadkeys</
strong></
span>
0N/A command. (Those commands can still be used when there are unscheduled
0N/A key changes, however.)
0N/A <
span><
strong class="command">auto-dnssec</
strong></
span> option requires the zone to be
0N/A configured to allow dynamic updates, by adding an
0N/A <
span><
strong class="command">allow-update</
strong></
span> or
0N/A <
span><
strong class="command">update-policy</
strong></
span> statement to the zone
0N/A configuration. If this has not been done, the configuration will
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2563835"></
a>Private-type records</
h3></
div></
div></
div></
div>
0N/A<
p>The state of the signing process is signaled by
0N/A private-type records (with a default type value of 65534). When
0N/A signing is complete, these records will have a nonzero value for
0N/A the final octet (for those records which have a nonzero initial
0N/A<
p>The private type record format: If the first octet is
0N/A non-zero then the record indicates that the zone needs to be
0N/A signed with the key matching the record, or that all signatures
0N/A that match the record should be removed.</
p>
0N/A<
div class="literallayout"><
p><
br>
0N/A��algorithm�(octet�1)<
br>
0N/A��key�id�in�network�order�(octet�2�and�3)<
br>
0N/A��removal�flag�(octet�4)<
br>
0N/A��complete�flag�(octet�5)<
br>
0N/A<
p>Only records flagged as "complete" can be removed via
0N/A dynamic update. Attempts to remove other private type records
0N/A will be silently ignored.</
p>
0N/A<
p>If the first octet is zero (this is a reserved algorithm
0N/A number that should never appear in a DNSKEY record) then the
0N/A record indicates changes to the NSEC3 chains are in progress. The
0N/A rest of the record contains an NSEC3PARAM record. The flag field
0N/A tells what operation to perform based on the flag bits.</
p>
0N/A<
div class="literallayout"><
p><
br>
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2563873"></
a>DNSKEY rollovers</
h3></
div></
div></
div></
div>
0N/A<
p>As with insecure-to-secure conversions, rolling DNSSEC
0N/A keys can be done in two ways: using a dynamic DNS update, or the
0N/A <
span><
strong class="command">auto-dnssec</
strong></
span> zone option.</
p>
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2563885"></
a>Dynamic DNS update method</
h3></
div></
div></
div></
div>
0N/A<
p> To perform key rollovers via dynamic update, you need to add
0N/A the <
code class="filename">K*</
code> files for the new keys so that
0N/A <
span><
strong class="command">named</
strong></
span> can find them. You can then add the new
0N/A DNSKEY RRs via dynamic update.
0N/A <
span><
strong class="command">named</
strong></
span> will then cause the zone to be signed
0N/A with the new keys. When the signing is complete the private type
0N/A records will be updated so that the last octet is non
0N/A<
p>If this is for a KSK you need to inform the parent and any
0N/A trust anchor repositories of the new KSK.</
p>
0N/A<
p>You should then wait for the maximum TTL in the zone before
0N/A removing the old DNSKEY. If it is a KSK that is being updated,
0N/A you also need to wait for the DS RRset in the parent to be
0N/A updated and its TTL to expire. This ensures that all clients will
0N/A be able to verify at least one signature when you remove the old
0N/A<
p>The old DNSKEY can be removed via UPDATE. Take care to
0N/A specify the correct key.
0N/A <
span><
strong class="command">named</
strong></
span> will clean out any signatures generated
0N/A by the old key after the update completes.</
p>
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571837"></
a>Automatic key rollovers</
h3></
div></
div></
div></
div>
0N/A<
p>When a new key reaches its activation date (as set by
0N/A <
span><
strong class="command">dnssec-keygen</
strong></
span> or <
span><
strong class="command">dnssec-settime</
strong></
span>),
0N/A if the <
span><
strong class="command">auto-dnssec</
strong></
span> zone option is set to
0N/A <
code class="constant">maintain</
code>, <
span><
strong class="command">named</
strong></
span> will
0N/A automatically carry out the key rollover. If the key's algorithm
0N/A has not previously been used to sign the zone, then the zone will
0N/A be fully signed as quickly as possible. However, if the new key
0N/A is replacing an existing key of the same algorithm, then the
0N/A zone will be re-signed incrementally, with signatures from the
0N/A old key being replaced with signatures from the new key as their
0N/A signature validity periods expire. By default, this rollover
0N/A completes in 30 days, after which it will be safe to remove the
0N/A old key from the DNSKEY RRset.</
p>
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571864"></
a>NSEC3PARAM rollovers via UPDATE</
h3></
div></
div></
div></
div>
0N/A<
p>Add the new NSEC3PARAM record via dynamic update. When the
0N/A new NSEC3 chain has been generated, the NSEC3PARAM flag field
0N/A will be zero. At this point you can remove the old NSEC3PARAM
0N/A record. The old chain will be removed after the update request
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571874"></
a>Converting from NSEC to NSEC3</
h3></
div></
div></
div></
div>
0N/A<
p>To do this, you just need to add an NSEC3PARAM record. When
0N/A the conversion is complete, the NSEC chain will have been removed
0N/A and the NSEC3PARAM record will have a zero flag field. The NSEC3
0N/A chain will be generated before the NSEC chain is
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571952"></
a>Converting from NSEC3 to NSEC</
h3></
div></
div></
div></
div>
0N/A<
p>To do this, use <
span><
strong class="command">nsupdate</
strong></
span> to
0N/A remove all NSEC3PARAM records with a zero flag
0N/A field. The NSEC chain will be generated before the NSEC3 chain is
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2571964"></
a>Converting from secure to insecure</
h3></
div></
div></
div></
div>
0N/A<
p>To convert a signed zone to unsigned using dynamic DNS,
0N/A delete all the DNSKEY records from the zone apex using
0N/A <
span><
strong class="command">nsupdate</
strong></
span>. All signatures, NSEC or NSEC3 chains,
0N/A and associated NSEC3PARAM records will be removed automatically.
0N/A This will take place after the update request completes.</
p>
0N/A<
p> This requires the
0N/A <
span><
strong class="command">dnssec-secure-to-insecure</
strong></
span> option to be set to
0N/A <
strong class="userinput"><
code>yes</
code></
strong> in
0N/A<
p>In addition, if the <
span><
strong class="command">auto-dnssec maintain</
strong></
span>
0N/A zone statement is used, it should be removed or changed to
0N/A <
span><
strong class="command">allow</
strong></
span> instead (or it will re-sign).
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2572002"></
a>Periodic re-signing</
h3></
div></
div></
div></
div>
0N/A<
p>In any secure zone which supports dynamic updates, named
0N/A will periodically re-sign RRsets which have not been re-signed as
0N/A a result of some update action. The signature lifetimes will be
0N/A adjusted so as to spread the re-sign load over time rather than
0N/A<
div class="sect2" lang="en"><
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2572011"></
a>NSEC3 and OPTOUT</
h3></
div></
div></
div></
div>
0N/A <
span><
strong class="command">named</
strong></
span> only supports creating new NSEC3 chains
0N/A where all the NSEC3 records in the zone have the same OPTOUT
0N/A <
span><
strong class="command">named</
strong></
span> supports UPDATES to zones where the NSEC3
0N/A records in the chain have mixed OPTOUT state.
0N/A <
span><
strong class="command">named</
strong></
span> does not support changing the OPTOUT
0N/A state of an individual NSEC3 record, the entire chain needs to be
0N/A changed if the OPTOUT state of an individual NSEC3 needs to be
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
p>BIND 9.7.0 introduces support for RFC 5011, dynamic trust
0N/A anchor management. Using this feature allows
0N/A <
span><
strong class="command">named</
strong></
span> to keep track of changes to critical
0N/A DNSSEC keys without any need for the operator to make changes to
0N/A configuration files.</
p>
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2572065"></
a>Validating Resolver</
h3></
div></
div></
div>
0N/A<
p>To configure a validating resolver to use RFC 5011 to
0N/A maintain a trust anchor, configure the trust anchor using a
0N/A <
span><
strong class="command">managed-keys</
strong></
span> statement. Information about
0N/A this can be found in
0N/A and Usage">the section called “<
span><
strong class="command">managed-keys</
strong></
span> Statement Definition
0N/A and Usage”</
a>.</
p>
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2605947"></
a>Authoritative Server</
h3></
div></
div></
div>
0N/A<
p>To set up an authoritative zone for RFC 5011 trust anchor
0N/A maintenance, generate two (or more) key signing keys (KSKs) for
0N/A the zone. Sign the zone with one of them; this is the "active"
0N/A KSK. All KSK's which do not sign the zone are "stand-by"
0N/A<
p>Any validating resolver which is configured to use the
0N/A active KSK as an RFC 5011-managed trust anchor will take note
0N/A of the stand-by KSKs in the zone's DNSKEY RRset, and store them
0N/A for future reference. The resolver will recheck the zone
0N/A periodically, and after 30 days, if the new key is still there,
0N/A then the key will be accepted by the resolver as a valid trust
0N/A anchor for the zone. Any time after this 30-day acceptance
0N/A timer has completed, the active KSK can be revoked, and the
0N/A zone can be "rolled over" to the newly accepted key.</
p>
0N/A<
p>The easiest way to place a stand-by key in a zone is to
0N/A use the "smart signing" features of
0N/A <
span><
strong class="command">dnssec-keygen</
strong></
span> and
0N/A <
span><
strong class="command">dnssec-signzone</
strong></
span>. If a key with a publication
0N/A date in the past, but an activation date which is unset or in
0N/A <
span><
strong class="command">dnssec-signzone -S</
strong></
span>" will include the DNSKEY
0N/A record in the zone, but will not sign with it:</
p>
0N/A$ <
strong class="userinput"><
code>dnssec-keygen -K keys -f KSK -P now -A now+2y
example.net</
code></
strong>
0N/A$ <
strong class="userinput"><
code>dnssec-signzone -S -K keys
example.net</
code></
strong>
0N/A<
p>To revoke a key, the new command
0N/A <
span><
strong class="command">dnssec-revoke</
strong></
span> has been added. This adds the
0N/A REVOKED bit to the key flags and re-generates the
0N/A <
code class="filename">K*.key</
code> and
0N/A <
code class="filename">K*.private</
code> files.</
p>
0N/A<
p>After revoking the active key, the zone must be signed
0N/A with both the revoked KSK and the new active KSK. (Smart
0N/A signing takes care of this automatically.)</
p>
0N/A<
p>Once a key has been revoked and used to sign the DNSKEY
0N/A RRset in which it appears, that key will never again be
0N/A accepted as a valid trust anchor by the resolver. However,
0N/A validation can proceed using the new active key (which had been
0N/A accepted by the resolver when it was a stand-by key).</
p>
0N/A<
p>See RFC 5011 for more details on key rollover
0N/A<
p>When a key has been revoked, its key ID changes,
0N/A increasing by 128, and wrapping around at 65535. So, for
0N/A example, the key "<
code class="filename">
Kexample.com.+005+10000</
code>" becomes
0N/A<
p>If two keys have ID's exactly 128 apart, and one is
0N/A revoked, then the two key ID's will collide, causing several
0N/A problems. To prevent this,
0N/A <
span><
strong class="command">dnssec-keygen</
strong></
span> will not generate a new key if
0N/A another key is present which may collide. This checking will
0N/A only occur if the new keys are written to the same directory
0N/A which holds all other keys in use for that zone.</
p>
0N/A<
p>Older versions of BIND 9 did not have this precaution.
0N/A Exercise caution if using key revocation on keys that were
0N/A generated by previous releases, or if using keys stored in
0N/A multiple directories or on multiple machines.</
p>
0N/A<
p>It is expected that a future release of BIND 9 will
0N/A address this problem in a different way, by storing revoked
0N/A keys with their original unrevoked key ID's.</
p>
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="pkcs11"></
a>PKCS #11 (Cryptoki) support</
h2></
div></
div></
div>
0N/A<
p>PKCS #11 (Public Key Cryptography Standard #11) defines a
0N/A platform- independent API for the control of hardware security
0N/A modules (HSMs) and other cryptographic support devices.</
p>
0N/A<
p>BIND 9 is known to work with two HSMs: The Sun SCA 6000
0N/A cryptographic acceleration board, tested under Solaris x86, and
0N/A the AEP Keyper network-attached key storage device, tested with
0N/A Debian Linux, Solaris x86 and Windows Server 2003.</
p>
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2608314"></
a>Prerequisites</
h3></
div></
div></
div>
0N/A<
p>See the HSM vendor documentation for information about
0N/A installing, initializing, testing and troubleshooting the
0N/A<
p>BIND 9 uses OpenSSL for cryptography, but stock OpenSSL
0N/A does not yet fully support PKCS #11. However, a PKCS #11 engine
0N/A for OpenSSL is available from the OpenSolaris project. It has
0N/A been modified by ISC to work with with BIND 9, and to provide
0N/A new features such as PIN management and key by
0N/A<
p>The patched OpenSSL depends on a "PKCS #11 provider".
0N/A This is a shared library object, providing a low-level PKCS #11
0N/A interface to the HSM hardware. It is dynamically loaded by
0N/A OpenSSL at runtime. The PKCS #11 provider comes from the HSM
0N/A vendor, and and is specific to the HSM to be controlled.</
p>
0N/A<
p>There are two "flavors" of PKCS #11 support provided by
0N/A the patched OpenSSL, one of which must be chosen at
0N/A configuration time. The correct choice depends on the HSM
0N/A<
div class="itemizedlist"><
ul type="disc">
0N/A<
li><
p>Use 'crypto-accelerator' with HSMs that have hardware
0N/A cryptographic acceleration features, such as the SCA 6000
0N/A board. This causes OpenSSL to run all supported
0N/A cryptographic operations in the HSM.</
p></
li>
0N/A<
li><
p>Use 'sign-only' with HSMs that are designed to
0N/A function primarily as secure key storage devices, but lack
0N/A hardware acceleration. These devices are highly secure, but
0N/A are not necessarily any faster at cryptography than the
0N/A system CPU — often, they are slower. It is therefore
0N/A most efficient to use them only for those cryptographic
0N/A functions that require access to the secured private key,
0N/A such as zone signing, and to use the system CPU for all
0N/A other computationally-intensive operations. The AEP Keyper
0N/A is an example of such a device.</
p></
li>
0N/A<
p>The modified OpenSSL code is included in the BIND 9.7.0
0N/A release, in the form of a context diff against the latest OpenSSL.
0N/A<
div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
0N/A<
h3 class="title">Note</
h3>
0N/A The latest OpenSSL version at the time of the BIND release
0N/A ISC will provide an updated patch as new versions of OpenSSL
0N/A are released. The version number in the following examples
0N/A is expected to change.</
div>
0N/A Before building BIND 9 with PKCS #11 support, it will be
0N/A necessary to build OpenSSL with this patch in place and inform
0N/A it of the path to the HSM-specific PKCS #11 provider
0N/A<
p>Obtain OpenSSL 0.9.8l:</
p>
0N/A<
p>Extract the tarball:</
p>
0N/A<
p>Apply the patch from the BIND 9 release:</
p>
0N/A$ <
strong class="userinput"><
code>patch -p1 -d openssl-0.9.8l \
0N/A<
div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
0N/A<
h3 class="title">Note</
h3>(Note that the patch file may not be compatible with the
0N/A "patch" utility on all operating systems. You may need to
0N/A install GNU patch.)</
div>
0N/A<
p>When building OpenSSL, place it in a non-standard
0N/A location so that it does not interfere with OpenSSL libraries
0N/A elsewhere on the system. In the following examples, we choose
0N/A when we configure BIND 9.</
p>
0N/A<
div class="sect3" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h4 class="title">
0N/A<
a name="id2606430"></
a>Building OpenSSL for the AEP Keyper on Linux</
h4></
div></
div></
div>
0N/A<
p>The AEP Keyper is a highly secure key storage device,
0N/A but does not provide hardware cryptographic acceleration. It
0N/A can carry out cryptographic operations, but it is probably
0N/A slower than your system's CPU. Therefore, we choose the
0N/A 'sign-only' flavor when building OpenSSL.</
p>
0N/A<
p>The Keyper-specific PKCS #11 provider library is
0N/A delivered with the Keyper software. In this example, we place
0N/A<
p>This library is only available for Linux as a 32-bit
0N/A binary. If we are compiling on a 64-bit Linux system, it is
0N/A necessary to force a 32-bit build, by specifying -m32 in the
0N/A<
p>Finally, the Keyper library requires threads, so we
0N/A must specify -pthread.</
p>
0N/A$ <
strong class="userinput"><
code>cd openssl-0.9.8l</
code></
strong>
0N/A$ <
strong class="userinput"><
code>/
Configure linux-generic32 -m32 -pthread \
0N/A --pk11-flavor=sign-only \
0N/A<
p>After configuring, run "<
span><
strong class="command">make</
strong></
span>"
0N/A and "<
span><
strong class="command">make test</
strong></
span>". If "<
span><
strong class="command">make
0N/A test</
strong></
span>" fails with "pthread_atfork() not found", you forgot to
0N/A add the -pthread above.</
p>
0N/A<
div class="sect3" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h4 class="title">
0N/A<
a name="id2606568"></
a>Building OpenSSL for the SCA 6000 on Solaris</
h4></
div></
div></
div>
0N/A<
p>The SCA-6000 PKCS #11 provider is installed as a system
0N/A library, libpkcs11. It is a true crypto accelerator, up to 4
0N/A times faster than any CPU, so the flavor shall be
0N/A 'crypto-accelerator'.</
p>
0N/A<
p>In this example, we are building on Solaris x86 on an
0N/A$ <
strong class="userinput"><
code>cd openssl-0.9.8l</
code></
strong>
0N/A$ <
strong class="userinput"><
code>/
Configure solaris64-x86_64-cc \
0N/A --pk11-flavor=crypto-accelerator \
0N/A<
p>(For a 32-bit build, use "solaris-x86-cc" and
0N/A<
p>After configuring, run
0N/A <
span><
strong class="command">make</
strong></
span> and
0N/A <
span><
strong class="command">make test</
strong></
span>.</
p>
0N/A<
p>Once you have built OpenSSL, run
0N/A "<
span><
strong class="command">
apps/
openssl engine pkcs11</
strong></
span>" to confirm
0N/A that PKCS #11 support was compiled in correctly. The output
0N/A should be one of the following lines, depending on the flavor
0N/A (pkcs11) PKCS #11 engine support (sign only)
0N/A (pkcs11) PKCS #11 engine support (crypto accelerator)
0N/A "<
span><
strong class="command">
apps/
openssl engine pkcs11 -t</
strong></
span>". This will
0N/A attempt to initialize the PKCS #11 engine. If it is able to
0N/A do so successfully, it will report
0N/A “<
span class="quote"><
code class="literal">[ available ]</
code></
span>”.</
p>
0N/A<
p>If the output is correct, run
0N/A "<
span><
strong class="command">make install</
strong></
span>" which will install the
0N/A modified OpenSSL suite to
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2606674"></
a>Building BIND 9 with PKCS#11</
h3></
div></
div></
div>
0N/A<
p>When building BIND 9, the location of the custom-built
0N/A OpenSSL library must be specified via configure.</
p>
0N/A<
div class="sect3" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h4 class="title">
0N/A<
a name="id2606682"></
a>Configuring BIND 9 for Linux</
h4></
div></
div></
div>
0N/A<
p>To link with the PKCS #11 provider, threads must be
0N/A enabled in the BIND 9 build.</
p>
0N/A<
p>The PKCS #11 library for the AEP Keyper is currently
0N/A only available as a 32-bit binary. If we are building on a
0N/A 64-bit host, we must force a 32-bit build by adding "-m32" to
0N/A the CC options on the "configure" command line.</
p>
0N/A$ <
strong class="userinput"><
code>/
configure CC="gcc -m32" --enable-threads \
0N/A<
div class="sect3" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h4 class="title">
0N/A<
a name="id2606850"></
a>Configuring BIND 9 for Solaris</
h4></
div></
div></
div>
0N/A<
p>To link with the PKCS #11 provider, threads must be
0N/A enabled in the BIND 9 build.</
p>
0N/A$ <
strong class="userinput"><
code>/
configure CC="cc -xarch=amd64" --enable-threads \
0N/A<
p>(For a 32-bit build, omit CC="cc -xarch=amd64".)</
p>
0N/A<
p>If configure complains about OpenSSL not working, you
0N/A may have a
32/
64-bit architecture mismatch. Or, you may have
0N/A incorrectly specified the path to OpenSSL (it should be the
0N/A same as the --prefix argument to the OpenSSL
0N/A<
p>After configuring, run
0N/A "<
span><
strong class="command">make</
strong></
span>",
0N/A "<
span><
strong class="command">make test</
strong></
span>" and
0N/A "<
span><
strong class="command">make install</
strong></
span>".</
p>
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2608475"></
a>PKCS #11 Tools</
h3></
div></
div></
div>
0N/A<
p>BIND 9 includes a minimal set of tools to operate the
0N/A <
span><
strong class="command">pkcs11-keygen</
strong></
span> to generate a new key pair
0N/A <
span><
strong class="command">pkcs11-list</
strong></
span> to list objects currently
0N/A <
span><
strong class="command">pkcs11-destroy</
strong></
span> to remove objects.</
p>
0N/A 9 is configured with the --with-pkcs11 option. (NOTE: If
0N/A --with-pkcs11 is set to "yes", rather than to the path of the
0N/A PKCS #11 provider, then the tools will be built but the
0N/A provider will be left undefined. Use the -m option or the
0N/A PKCS11_PROVIDER environment variable to specify the path to the
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2608506"></
a>Using the HSM</
h3></
div></
div></
div>
0N/A<
p>First, we must set up the runtime environment so the
0N/A OpenSSL and PKCS #11 libraries can be loaded:</
p>
0N/A$ <
strong class="userinput"><
code>export LD_LIBRARY_PATH=/
opt/
pkcs11/
usr/
lib:${LD_LIBRARY_PATH}</
code></
strong>
0N/A<
p>When operating an AEP Keyper, it is also necessary to
0N/A specify the location of the "machine" file, which stores
0N/A information about the Keyper for use by PKCS #11 provider
0N/A library. If the machine file is in
0N/A<
p>These environment variables must be set whenever running
0N/A any tool that uses the HSM, including
0N/A <
span><
strong class="command">pkcs11-keygen</
strong></
span>,
0N/A <
span><
strong class="command">pkcs11-list</
strong></
span>,
0N/A <
span><
strong class="command">pkcs11-destroy</
strong></
span>,
0N/A <
span><
strong class="command">dnssec-keyfromlabel</
strong></
span>,
0N/A <
span><
strong class="command">dnssec-signzone</
strong></
span>,
0N/A <
span><
strong class="command">dnssec-keygen</
strong></
span>(which will use the HSM for
0N/A random number generation), and
0N/A <
span><
strong class="command">named</
strong></
span>.</
p>
0N/A<
p>We can now create and use keys in the HSM. In this case,
0N/A we will create a 2048 bit key and give it the label
0N/A$ <
strong class="userinput"><
code>pkcs11-keygen -b 2048 -l sample-ksk</
code></
strong>
0N/A<
p>To confirm that the key exists:</
p>
0N/A$ <
strong class="userinput"><
code>pkcs11-list</
code></
strong>
0N/Aobject[0]: handle 2147483658 class 3 label[8] 'sample-ksk' id[0]
0N/Aobject[1]: handle 2147483657 class 2 label[8] 'sample-ksk' id[0]
0N/A<
p>Before using this key to sign a zone, we must create a
0N/A pair of BIND 9 key files. The "dnssec-keyfromlabel" utility
0N/A does this. In this case, we will be using the HSM key
0N/A$ <
strong class="userinput"><
code>dnssec-keyfromlabel -l sample-ksk -f KSK
example.net</
code></
strong>
0N/A<
p>The resulting K*.key and K*.private files can now be used
0N/A to sign the zone. Unlike normal K* files, which contain both
0N/A public and private key data, these files will contain only the
0N/A public key data, plus an identifier for the private key which
0N/A remains stored within the HSM. The HSM handles signing with the
0N/A<
p>If you wish to generate a second key in the HSM for use
0N/A as a zone-signing key, follow the same procedure above, using a
0N/A different keylabel, a smaller key size, and omitting "-f KSK"
0N/A from the dnssec-keyfromlabel arguments:</
p>
0N/A$ <
strong class="userinput"><
code>pkcs11-keygen -b 1024 -l sample-zsk</
code></
strong>
0N/A$ <
strong class="userinput"><
code>dnssec-keyfromlabel -l sample-zsk
example.net</
code></
strong>
0N/A<
p>Alternatively, you may prefer to generate a conventional
0N/A on-disk key, using dnssec-keygen:</
p>
0N/A$ <
strong class="userinput"><
code>dnssec-keygen
example.net</
code></
strong>
0N/A<
p>This provides less security than an HSM key, but since
0N/A HSMs can be slow or cumbersome to use for security reasons, it
0N/A may be more efficient to reserve HSM keys for use in the less
0N/A frequent key-signing operation. The zone-signing key can be
0N/A rolled more frequently, if you wish, to compensate for a
0N/A reduction in key security.</
p>
0N/A<
p>Now you can sign the zone. (Note: If not using the -S
0N/A <
span><
strong class="command">dnssec-signzone</
strong></
span>, it will be necessary to add
0N/A the contents of both
0N/A <
code class="filename">K*.key</
code> files to the zone master file before
0N/A$ <
strong class="userinput"><
code>dnssec-signzone -S
example.net</
code></
strong>
0N/AVerifying the zone using the following algorithms:
0N/AZone signing complete:
0N/AAlgorithm: NSEC3RSASHA1: ZSKs: 1, KSKs: 1 active, 0 revoked, 0 stand-by
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2608978"></
a>Specifying the engine on the command line</
h3></
div></
div></
div>
0N/A<
p>The OpenSSL engine can be specified in
0N/A <
span><
strong class="command">named</
strong></
span> and all of the BIND
0N/A <
span><
strong class="command">dnssec-*</
strong></
span> tools by using the "-E
0N/A <engine>" command line option. If BIND 9 is built with
0N/A the --with-pkcs11 option, this option defaults to "pkcs11".
0N/A Specifying the engine will generally not be necessary unless
0N/A for some reason you wish to use a different OpenSSL
0N/A<
p>If you wish to disable use of the "pkcs11" engine —
0N/A for troubleshooting purposes, or because the HSM is unavailable
0N/A — set the engine to the empty string. For example:</
p>
0N/A$ <
strong class="userinput"><
code>dnssec-signzone -E '' -S
example.net</
code></
strong>
0N/A <
span><
strong class="command">dnssec-signzone</
strong></
span> to run as if it were compiled
0N/A without the --with-pkcs11 option.</
p>
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2609024"></
a>Running named with automatic zone re-signing</
h3></
div></
div></
div>
0N/A <
span><
strong class="command">named</
strong></
span> to dynamically re-sign zones using HSM
0N/A keys,
and/
or to to sign new records inserted via nsupdate, then
0N/A named must have access to the HSM PIN. This can be accomplished
0N/A setting the OPENSSL_CONF environment variable before running
0N/A<
pre class="programlisting">
0N/A openssl_conf = openssl_def
0N/A engines = engine_section
0N/A pkcs11 = pkcs11_section
0N/A PIN = <
em class="replaceable"><
code><PLACE PIN HERE></
code></
em>
0N/A<
p>This will also allow the dnssec-* tools to access the HSM
0N/A without PIN entry. (The pkcs11-* tools access the HSM directly,
0N/A not via OpenSSL, so a PIN will still be required to use
0N/A<
div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
0N/A<
h3 class="title">Warning</
h3>
0N/A<
p>Placing the HSM's PIN in a text file in
0N/A this manner may reduce the security advantage of using an
0N/A HSM. Be sure this is what you want to do before configuring
0N/A OpenSSL in this way.</
p>
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="id2572468"></
a>IPv6 Support in <
acronym class="acronym">BIND</
acronym> 9</
h2></
div></
div></
div>
0N/A <
acronym class="acronym">BIND</
acronym> 9 fully supports all currently
0N/A defined forms of IPv6 name to address and address to name
0N/A lookups. It will also use IPv6 addresses to make queries when
0N/A running on an IPv6 capable system.
0N/A For forward lookups, <
acronym class="acronym">BIND</
acronym> 9 supports
0N/A only AAAA records. RFC 3363 deprecated the use of A6 records,
0N/A and client-side support for A6 records was accordingly removed
0N/A from <
acronym class="acronym">BIND</
acronym> 9.
0N/A However, authoritative <
acronym class="acronym">BIND</
acronym> 9 name servers still
0N/A load zone files containing A6 records correctly, answer queries
0N/A for A6 records, and accept zone transfer for a zone containing A6
0N/A For IPv6 reverse lookups, <
acronym class="acronym">BIND</
acronym> 9 supports
0N/A the traditional "nibble" format used in the
0N/A <
span class="emphasis"><
em>
ip6.arpa</
em></
span> domain, as well as the older, deprecated
0N/A <
span class="emphasis"><
em>
ip6.int</
em></
span> domain.
0N/A Older versions of <
acronym class="acronym">BIND</
acronym> 9
0N/A supported the "binary label" (also known as "bitstring") format,
0N/A but support of binary labels has been completely removed per
0N/A Many applications in <
acronym class="acronym">BIND</
acronym> 9 do not understand
0N/A the binary label format at all any more, and will return an
0N/A In particular, an authoritative <
acronym class="acronym">BIND</
acronym> 9
0N/A name server will not load a zone file containing binary labels.
0N/A For an overview of the format and structure of IPv6 addresses,
0N/A see <
a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (AAAA)">the section called “IPv6 addresses (AAAA)”</
a>.
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2572734"></
a>Address Lookups Using AAAA Records</
h3></
div></
div></
div>
0N/A The IPv6 AAAA record is a parallel to the IPv4 A record,
0N/A and, unlike the deprecated A6 record, specifies the entire
0N/A IPv6 address in a single record. For example,
0N/A<
pre class="programlisting">
0N/Ahost 3600 IN AAAA 2001:db8::1
0N/A Use of IPv4-in-IPv6 mapped addresses is not recommended.
0N/A If a host has an IPv4 address, use an A record, not
0N/A a AAAA, with <
code class="literal">::ffff:192.168.42.1</
code> as
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2572756"></
a>Address to Name Lookups Using Nibble Format</
h3></
div></
div></
div>
0N/A When looking up an address in nibble format, the address
0N/A components are simply reversed, just as in IPv4, and
0N/A For example, the following would provide reverse name lookup for
0N/A <
code class="literal">2001:db8::1</
code>.
0N/A<
pre class="programlisting">
0N/A1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR (
0N/A<
div class="navfooter">
0N/A<
table width="100%" summary="Navigation footer">
0N/A<
td width="40%" align="left">
0N/A<
td width="20%" align="center">�</
td>
0N/A<
td width="40%" align="left" valign="top">Chapter�3.�Name Server Configuration�</
td>
0N/A<
td width="20%" align="center"><
a accesskey="h" href="Bv9ARM.html">Home</
a></
td>
0N/A<
td width="40%" align="right" valign="top">�Chapter�5.�The <
acronym class="acronym">BIND</
acronym> 9 Lightweight Resolver</
td>