diff options
Diffstat (limited to 'doc/arm/Bv9ARM.ch04.html')
| -rw-r--r-- | doc/arm/Bv9ARM.ch04.html | 1036 |
1 files changed, 1036 insertions, 0 deletions
diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html new file mode 100644 index 0000000..4aba208 --- /dev/null +++ b/doc/arm/Bv9ARM.ch04.html @@ -0,0 +1,1036 @@ +<!-- + - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + - Copyright (C) 2000-2003 Internet Software Consortium. + - + - Permission to use, copy, modify, and distribute this software for any + - purpose with or without fee is hereby granted, provided that the above + - copyright notice and this permission notice appear in all copies. + - + - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + - PERFORMANCE OF THIS SOFTWARE. +--> +<!-- $Id: Bv9ARM.ch04.html,v 1.87 2008/09/25 06:24:42 tbox Exp $ --> +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> +<title>Chapter 4. Advanced DNS Features</title> +<meta name="generator" content="DocBook XSL Stylesheets V1.71.1"> +<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> +<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual"> +<link rel="prev" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration"> +<link rel="next" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver"> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> +<div class="navheader"> +<table width="100%" summary="Navigation header"> +<tr><th colspan="3" align="center">Chapter 4. Advanced DNS Features</th></tr> +<tr> +<td width="20%" align="left"> +<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td> +<th width="60%" align="center"> </th> +<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a> +</td> +</tr> +</table> +<hr> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"><div><div><h2 class="title"> +<a name="Bv9ARM.ch04"></a>Chapter 4. Advanced DNS Features</h2></div></div></div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt> +<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570509">Split DNS</a></span></dt> +<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570528">Example split DNS setup</a></span></dt></dl></dd> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571168">Generate Shared Keys for Each Pair of Hosts</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571241">Copying the Shared Secret to Both Machines</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571252">Informing the Servers of the Key's Existence</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571291">Instructing the Server to Use the Key</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571485">TSIG Key Based Access Control</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571530">Errors</a></span></dt> +</dl></dd> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571612">TKEY</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571661">SIG(0)</a></span></dt> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571798">Generating Keys</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571877">Signing the Zone</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571958">Configuring Servers</a></span></dt> +</dl></dd> +<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572101">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572163">Address Lookups Using AAAA Records</a></span></dt> +<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572184">Address to Name Lookups Using Nibble Format</a></span></dt> +</dl></dd> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="notify"></a>Notify</h2></div></div></div> +<p> + <acronym class="acronym">DNS</acronym> NOTIFY is a mechanism that allows master + servers to notify their slave servers of changes to a zone's data. In + response to a <span><strong class="command">NOTIFY</strong></span> from a master server, the + slave will check to see that its version of the zone is the + current version and, if not, initiate a zone transfer. + </p> +<p> + For more information about <acronym class="acronym">DNS</acronym> + <span><strong class="command">NOTIFY</strong></span>, see the description of the + <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 + the description of the zone option <span><strong class="command">also-notify</strong></span> in + <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>. The <span><strong class="command">NOTIFY</strong></span> + protocol is specified in RFC 1996. + </p> +<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> +<h3 class="title">Note</h3> + As a slave zone can also be a master to other slaves, named, + by default, sends <span><strong class="command">NOTIFY</strong></span> messages for every zone + it loads. Specifying <span><strong class="command">notify master-only;</strong></span> will + cause named to only send <span><strong class="command">NOTIFY</strong></span> for master + zones that it loads. + </div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="dynamic_update"></a>Dynamic Update</h2></div></div></div> +<p> + Dynamic Update is a method for adding, replacing or deleting + records in a master server by sending it a special form of DNS + messages. The format and meaning of these messages is specified + in RFC 2136. + </p> +<p> + Dynamic update is enabled by including an + <span><strong class="command">allow-update</strong></span> or <span><strong class="command">update-policy</strong></span> + clause in the <span><strong class="command">zone</strong></span> statement. The + <span><strong class="command">tkey-gssapi-credential</strong></span> and + <span><strong class="command">tkey-domain</strong></span> clauses in the + <span><strong class="command">options</strong></span> statement enable the + server to negotiate keys that can be matched against those + in <span><strong class="command">update-policy</strong></span> or + <span><strong class="command">allow-update</strong></span>. + </p> +<p> + Updating of secure zones (zones using DNSSEC) follows RFC + 3007: RRSIG, NSEC and NSEC3 records affected by updates are + automatically regenerated by the server using an online + zone key. Update authorization is based on transaction + signatures and an explicit server policy. + </p> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="journal"></a>The journal file</h3></div></div></div> +<p> + All changes made to a zone using dynamic update are stored + in the zone's journal file. This file is automatically created + by the server when the first dynamic update takes place. + The name of the journal file is formed by appending the extension + <code class="filename">.jnl</code> to the name of the + corresponding zone + file unless specifically overridden. The journal file is in a + binary format and should not be edited manually. + </p> +<p> + The server will also occasionally write ("dump") + the complete contents of the updated zone to its zone file. + This is not done immediately after + each dynamic update, because that would be too slow when a large + zone is updated frequently. Instead, the dump is delayed by + up to 15 minutes, allowing additional updates to take place. + </p> +<p> + When a server is restarted after a shutdown or crash, it will replay + the journal file to incorporate into the zone any updates that + took + place after the last zone dump. + </p> +<p> + Changes that result from incoming incremental zone transfers are + also + journalled in a similar way. + </p> +<p> + The zone files of dynamic zones cannot normally be edited by + hand because they are not guaranteed to contain the most recent + dynamic changes — those are only in the journal file. + The only way to ensure that the zone file of a dynamic zone + is up to date is to run <span><strong class="command">rndc stop</strong></span>. + </p> +<p> + If you have to make changes to a dynamic zone + manually, the following procedure will work: Disable dynamic updates + to the zone using + <span><strong class="command">rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>. + This will also remove the zone's <code class="filename">.jnl</code> file + and update the master file. Edit the zone file. Run + <span><strong class="command">rndc thaw <em class="replaceable"><code>zone</code></em></strong></span> + to reload the changed zone and re-enable dynamic updates. + </p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="incremental_zone_transfers"></a>Incremental Zone Transfers (IXFR)</h2></div></div></div> +<p> + The incremental zone transfer (IXFR) protocol is a way for + slave servers to transfer only changed data, instead of having to + transfer the entire zone. The IXFR protocol is specified in RFC + 1995. See <a href="Bv9ARM.ch09.html#proposed_standards">Proposed Standards</a>. + </p> +<p> + When acting as a master, <acronym class="acronym">BIND</acronym> 9 + supports IXFR for those zones + where the necessary change history information is available. These + include master zones maintained by dynamic update and slave zones + whose data was obtained by IXFR. For manually maintained master + zones, and for slave zones obtained by performing a full zone + transfer (AXFR), IXFR is supported only if the option + <span><strong class="command">ixfr-from-differences</strong></span> is set + to <strong class="userinput"><code>yes</code></strong>. + </p> +<p> + When acting as a slave, <acronym class="acronym">BIND</acronym> 9 will + attempt to use IXFR unless + it is explicitly disabled. For more information about disabling + IXFR, see the description of the <span><strong class="command">request-ixfr</strong></span> clause + of the <span><strong class="command">server</strong></span> statement. + </p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="id2570509"></a>Split DNS</h2></div></div></div> +<p> + Setting up different views, or visibility, of the DNS space to + internal and external resolvers is usually referred to as a + <span class="emphasis"><em>Split DNS</em></span> setup. There are several + reasons an organization would want to set up its DNS this way. + </p> +<p> + One common reason for setting up a DNS system this way is + to hide "internal" DNS information from "external" clients on the + Internet. There is some debate as to whether or not this is actually + useful. + Internal DNS information leaks out in many ways (via email headers, + for example) and most savvy "attackers" can find the information + they need using other means. + However, since listing addresses of internal servers that + external clients cannot possibly reach can result in + connection delays and other annoyances, an organization may + choose to use a Split DNS to present a consistent view of itself + to the outside world. + </p> +<p> + Another common reason for setting up a Split DNS system is + to allow internal networks that are behind filters or in RFC 1918 + space (reserved IP space, as documented in RFC 1918) to resolve DNS + on the Internet. Split DNS can also be used to allow mail from outside + back in to the internal network. + </p> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2570528"></a>Example split DNS setup</h3></div></div></div> +<p> + Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span> + (<code class="literal">example.com</code>) + has several corporate sites that have an internal network with + reserved + Internet Protocol (IP) space and an external demilitarized zone (DMZ), + or "outside" section of a network, that is available to the public. + </p> +<p> + <span class="emphasis"><em>Example, Inc.</em></span> wants its internal clients + to be able to resolve external hostnames and to exchange mail with + people on the outside. The company also wants its internal resolvers + to have access to certain internal-only zones that are not available + at all outside of the internal network. + </p> +<p> + In order to accomplish this, the company will set up two sets + of name servers. One set will be on the inside network (in the + reserved + IP space) and the other set will be on bastion hosts, which are + "proxy" + hosts that can talk to both sides of its network, in the DMZ. + </p> +<p> + The internal servers will be configured to forward all queries, + except queries for <code class="filename">site1.internal</code>, <code class="filename">site2.internal</code>, <code class="filename">site1.example.com</code>, + and <code class="filename">site2.example.com</code>, to the servers + in the + DMZ. These internal servers will have complete sets of information + for <code class="filename">site1.example.com</code>, <code class="filename">site2.example.com</code>,<span class="emphasis"><em></em></span> <code class="filename">site1.internal</code>, + and <code class="filename">site2.internal</code>. + </p> +<p> + To protect the <code class="filename">site1.internal</code> and <code class="filename">site2.internal</code> domains, + the internal name servers must be configured to disallow all queries + to these domains from any external hosts, including the bastion + hosts. + </p> +<p> + The external servers, which are on the bastion hosts, will + be configured to serve the "public" version of the <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones. + This could include things such as the host records for public servers + (<code class="filename">www.example.com</code> and <code class="filename">ftp.example.com</code>), + and mail exchange (MX) records (<code class="filename">a.mx.example.com</code> and <code class="filename">b.mx.example.com</code>). + </p> +<p> + In addition, the public <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones + should have special MX records that contain wildcard (`*') records + pointing to the bastion hosts. This is needed because external mail + servers do not have any other way of looking up how to deliver mail + to those internal hosts. With the wildcard records, the mail will + be delivered to the bastion host, which can then forward it on to + internal hosts. + </p> +<p> + Here's an example of a wildcard MX record: + </p> +<pre class="programlisting">* IN MX 10 external1.example.com.</pre> +<p> + Now that they accept mail on behalf of anything in the internal + network, the bastion hosts will need to know how to deliver mail + to internal hosts. In order for this to work properly, the resolvers + on + the bastion hosts will need to be configured to point to the internal + name servers for DNS resolution. + </p> +<p> + Queries for internal hostnames will be answered by the internal + servers, and queries for external hostnames will be forwarded back + out to the DNS servers on the bastion hosts. + </p> +<p> + In order for all this to work properly, internal clients will + need to be configured to query <span class="emphasis"><em>only</em></span> the internal + name servers for DNS queries. This could also be enforced via + selective + filtering on the network. + </p> +<p> + If everything has been set properly, <span class="emphasis"><em>Example, Inc.</em></span>'s + internal clients will now be able to: + </p> +<div class="itemizedlist"><ul type="disc"> +<li> + Look up any hostnames in the <code class="literal">site1</code> + and + <code class="literal">site2.example.com</code> zones. + </li> +<li> + Look up any hostnames in the <code class="literal">site1.internal</code> and + <code class="literal">site2.internal</code> domains. + </li> +<li>Look up any hostnames on the Internet.</li> +<li>Exchange mail with both internal and external people.</li> +</ul></div> +<p> + Hosts on the Internet will be able to: + </p> +<div class="itemizedlist"><ul type="disc"> +<li> + Look up any hostnames in the <code class="literal">site1</code> + and + <code class="literal">site2.example.com</code> zones. + </li> +<li> + Exchange mail with anyone in the <code class="literal">site1</code> and + <code class="literal">site2.example.com</code> zones. + </li> +</ul></div> +<p> + Here is an example configuration for the setup we just + described above. Note that this is only configuration information; + 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>. + </p> +<p> + Internal DNS server config: + </p> +<pre class="programlisting"> + +acl internals { 172.16.72.0/24; 192.168.1.0/24; }; + +acl externals { <code class="varname">bastion-ips-go-here</code>; }; + +options { + ... + ... + forward only; + forwarders { // forward to external servers + <code class="varname">bastion-ips-go-here</code>; + }; + allow-transfer { none; }; // sample allow-transfer (no one) + allow-query { internals; externals; }; // restrict query access + allow-recursion { internals; }; // restrict recursion + ... + ... +}; + +zone "site1.example.com" { // sample master zone + type master; + file "m/site1.example.com"; + forwarders { }; // do normal iterative + // resolution (do not forward) + allow-query { internals; externals; }; + allow-transfer { internals; }; +}; + +zone "site2.example.com" { // sample slave zone + type slave; + file "s/site2.example.com"; + masters { 172.16.72.3; }; + forwarders { }; + allow-query { internals; externals; }; + allow-transfer { internals; }; +}; + +zone "site1.internal" { + type master; + file "m/site1.internal"; + forwarders { }; + allow-query { internals; }; + allow-transfer { internals; } +}; + +zone "site2.internal" { + type slave; + file "s/site2.internal"; + masters { 172.16.72.3; }; + forwarders { }; + allow-query { internals }; + allow-transfer { internals; } +}; +</pre> +<p> + External (bastion host) DNS server config: + </p> +<pre class="programlisting"> +acl internals { 172.16.72.0/24; 192.168.1.0/24; }; + +acl externals { bastion-ips-go-here; }; + +options { + ... + ... + allow-transfer { none; }; // sample allow-transfer (no one) + allow-query { any; }; // default query access + allow-query-cache { internals; externals; }; // restrict cache access + allow-recursion { internals; externals; }; // restrict recursion + ... + ... +}; + +zone "site1.example.com" { // sample slave zone + type master; + file "m/site1.foo.com"; + allow-transfer { internals; externals; }; +}; + +zone "site2.example.com" { + type slave; + file "s/site2.foo.com"; + masters { another_bastion_host_maybe; }; + allow-transfer { internals; externals; } +}; +</pre> +<p> + In the <code class="filename">resolv.conf</code> (or equivalent) on + the bastion host(s): + </p> +<pre class="programlisting"> +search ... +nameserver 172.16.72.2 +nameserver 172.16.72.3 +nameserver 172.16.72.4 +</pre> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="tsig"></a>TSIG</h2></div></div></div> +<p> + This is a short guide to setting up Transaction SIGnatures + (TSIG) based transaction security in <acronym class="acronym">BIND</acronym>. It describes changes + to the configuration file as well as what changes are required for + different features, including the process of creating transaction + keys and using transaction signatures with <acronym class="acronym">BIND</acronym>. + </p> +<p> + <acronym class="acronym">BIND</acronym> primarily supports TSIG for server + to server communication. + This includes zone transfer, notify, and recursive query messages. + Resolvers based on newer versions of <acronym class="acronym">BIND</acronym> 8 have limited support + for TSIG. + </p> +<p> + TSIG can also be useful for dynamic update. A primary + server for a dynamic zone should control access to the dynamic + update service, but IP-based access control is insufficient. + The cryptographic access control provided by TSIG + is far superior. The <span><strong class="command">nsupdate</strong></span> + program supports TSIG via the <code class="option">-k</code> and + <code class="option">-y</code> command line options or inline by use + of the <span><strong class="command">key</strong></span>. + </p> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571168"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div> +<p> + A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>. + An arbitrary key name is chosen: "host1-host2.". The key name must + be the same on both hosts. + </p> +<div class="sect3" lang="en"> +<div class="titlepage"><div><div><h4 class="title"> +<a name="id2571185"></a>Automatic Generation</h4></div></div></div> +<p> + The following command will generate a 128-bit (16 byte) HMAC-MD5 + key as described above. Longer keys are better, but shorter keys + are easier to read. Note that the maximum key length is 512 bits; + keys longer than that will be digested with MD5 to produce a + 128-bit key. + </p> +<p> + <strong class="userinput"><code>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</code></strong> + </p> +<p> + The key is in the file <code class="filename">Khost1-host2.+157+00000.private</code>. + Nothing directly uses this file, but the base-64 encoded string + following "<code class="literal">Key:</code>" + can be extracted from the file and used as a shared secret: + </p> +<pre class="programlisting">Key: La/E5CjG9O+os1jq0a2jdA==</pre> +<p> + The string "<code class="literal">La/E5CjG9O+os1jq0a2jdA==</code>" can + be used as the shared secret. + </p> +</div> +<div class="sect3" lang="en"> +<div class="titlepage"><div><div><h4 class="title"> +<a name="id2571223"></a>Manual Generation</h4></div></div></div> +<p> + The shared secret is simply a random sequence of bits, encoded + in base-64. Most ASCII strings are valid base-64 strings (assuming + the length is a multiple of 4 and only valid characters are used), + so the shared secret can be manually generated. + </p> +<p> + Also, a known string can be run through <span><strong class="command">mmencode</strong></span> or + a similar program to generate base-64 encoded data. + </p> +</div> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571241"></a>Copying the Shared Secret to Both Machines</h3></div></div></div> +<p> + This is beyond the scope of DNS. A secure transport mechanism + should be used. This could be secure FTP, ssh, telephone, etc. + </p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571252"></a>Informing the Servers of the Key's Existence</h3></div></div></div> +<p> + Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span> + are + both servers. The following is added to each server's <code class="filename">named.conf</code> file: + </p> +<pre class="programlisting"> +key host1-host2. { + algorithm hmac-md5; + secret "La/E5CjG9O+os1jq0a2jdA=="; +}; +</pre> +<p> + The algorithm, hmac-md5, is the only one supported by <acronym class="acronym">BIND</acronym>. + The secret is the one generated above. Since this is a secret, it + is recommended that either <code class="filename">named.conf</code> be non-world + readable, or the key directive be added to a non-world readable + file that is included by + <code class="filename">named.conf</code>. + </p> +<p> + At this point, the key is recognized. This means that if the + server receives a message signed by this key, it can verify the + signature. If the signature is successfully verified, the + response is signed by the same key. + </p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571291"></a>Instructing the Server to Use the Key</h3></div></div></div> +<p> + Since keys are shared between two hosts only, the server must + be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file + for <span class="emphasis"><em>host1</em></span>, if the IP address of <span class="emphasis"><em>host2</em></span> is + 10.1.2.3: + </p> +<pre class="programlisting"> +server 10.1.2.3 { + keys { host1-host2. ;}; +}; +</pre> +<p> + Multiple keys may be present, but only the first is used. + This directive does not contain any secrets, so it may be in a + world-readable + file. + </p> +<p> + If <span class="emphasis"><em>host1</em></span> sends a message that is a request + to that address, the message will be signed with the specified key. <span class="emphasis"><em>host1</em></span> will + expect any responses to signed messages to be signed with the same + key. + </p> +<p> + A similar statement must be present in <span class="emphasis"><em>host2</em></span>'s + configuration file (with <span class="emphasis"><em>host1</em></span>'s address) for <span class="emphasis"><em>host2</em></span> to + sign request messages to <span class="emphasis"><em>host1</em></span>. + </p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571485"></a>TSIG Key Based Access Control</h3></div></div></div> +<p> + <acronym class="acronym">BIND</acronym> allows IP addresses and ranges + to be specified in ACL + definitions and + <span><strong class="command">allow-{ query | transfer | update }</strong></span> + directives. + This has been extended to allow TSIG keys also. The above key would + be denoted <span><strong class="command">key host1-host2.</strong></span> + </p> +<p> + An example of an allow-update directive would be: + </p> +<pre class="programlisting"> +allow-update { key host1-host2. ;}; +</pre> +<p> + This allows dynamic updates to succeed only if the request + was signed by a key named "<span><strong class="command">host1-host2.</strong></span>". + </p> +<p> + You may want to read about the more powerful + <span><strong class="command">update-policy</strong></span> statement in + <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called “Dynamic Update Policies”</a>. + </p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571530"></a>Errors</h3></div></div></div> +<p> + The processing of TSIG signed messages can result in + several errors. If a signed message is sent to a non-TSIG aware + server, a FORMERR (format error) will be returned, since the server will not + understand the record. This is a result of misconfiguration, + since the server must be explicitly configured to send a TSIG + signed message to a specific server. + </p> +<p> + If a TSIG aware server receives a message signed by an + unknown key, the response will be unsigned with the TSIG + extended error code set to BADKEY. If a TSIG aware server + receives a message with a signature that does not validate, the + response will be unsigned with the TSIG extended error code set + to BADSIG. If a TSIG aware server receives a message with a time + outside of the allowed range, the response will be signed with + the TSIG extended error code set to BADTIME, and the time values + will be adjusted so that the response can be successfully + verified. In any of these cases, the message's rcode (response code) is set to + NOTAUTH (not authenticated). + </p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="id2571612"></a>TKEY</h2></div></div></div> +<p><span><strong class="command">TKEY</strong></span> + is a mechanism for automatically generating a shared secret + between two hosts. There are several "modes" of + <span><strong class="command">TKEY</strong></span> that specify how the key is generated + or assigned. <acronym class="acronym">BIND</acronym> 9 implements only one of + these modes, the Diffie-Hellman key exchange. Both hosts are + required to have a Diffie-Hellman KEY record (although this + record is not required to be present in a zone). The + <span><strong class="command">TKEY</strong></span> process must use signed messages, + signed either by TSIG or SIG(0). The result of + <span><strong class="command">TKEY</strong></span> is a shared secret that can be used to + sign messages with TSIG. <span><strong class="command">TKEY</strong></span> can also be + used to delete shared secrets that it had previously + generated. + </p> +<p> + The <span><strong class="command">TKEY</strong></span> process is initiated by a + client + or server by sending a signed <span><strong class="command">TKEY</strong></span> + query + (including any appropriate KEYs) to a TKEY-aware server. The + server response, if it indicates success, will contain a + <span><strong class="command">TKEY</strong></span> record and any appropriate keys. + After + this exchange, both participants have enough information to + determine the shared secret; the exact process depends on the + <span><strong class="command">TKEY</strong></span> mode. When using the + Diffie-Hellman + <span><strong class="command">TKEY</strong></span> mode, Diffie-Hellman keys are + exchanged, + and the shared secret is derived by both participants. + </p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="id2571661"></a>SIG(0)</h2></div></div></div> +<p> + <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0) + transaction signatures as specified in RFC 2535 and RFC2931. + SIG(0) + uses public/private keys to authenticate messages. Access control + is performed in the same manner as TSIG keys; privileges can be + granted or denied based on the key name. + </p> +<p> + When a SIG(0) signed message is received, it will only be + verified if the key is known and trusted by the server; the server + will not attempt to locate and/or validate the key. + </p> +<p> + SIG(0) signing of multiple-message TCP streams is not + supported. + </p> +<p> + The only tool shipped with <acronym class="acronym">BIND</acronym> 9 that + generates SIG(0) signed messages is <span><strong class="command">nsupdate</strong></span>. + </p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="DNSSEC"></a>DNSSEC</h2></div></div></div> +<p> + Cryptographic authentication of DNS information is possible + through the DNS Security (<span class="emphasis"><em>DNSSEC-bis</em></span>) extensions, + defined in RFC 4033, RFC 4034, and RFC 4035. + This section describes the creation and use of DNSSEC signed zones. + </p> +<p> + In order to set up a DNSSEC secure zone, there are a series + of steps which must be followed. <acronym class="acronym">BIND</acronym> + 9 ships + with several tools + that are used in this process, which are explained in more detail + below. In all cases, the <code class="option">-h</code> option prints a + full list of parameters. Note that the DNSSEC tools require the + keyset files to be in the working directory or the + directory specified by the <code class="option">-d</code> option, and + that the tools shipped with BIND 9.2.x and earlier are not compatible + with the current ones. + </p> +<p> + There must also be communication with the administrators of + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presence + or absence of a <code class="literal">DS</code> record at the + delegation + point. + </p> +<p> + For other servers to trust data in this zone, they must + either be statically configured with this zone's zone key or the + zone key of another zone above this one in the DNS tree. + </p> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571798"></a>Generating Keys</h3></div></div></div> +<p> + The <span><strong class="command">dnssec-keygen</strong></span> program is used to + generate keys. + </p> +<p> + A secure zone must contain one or more zone keys. The + zone keys will sign all other records in the zone, as well as + the zone keys of any secure delegated zones. Zone keys must + have the same name as the zone, a name type of + <span><strong class="command">ZONE</strong></span>, and must be usable for + authentication. + It is recommended that zone keys use a cryptographic algorithm + designated as "mandatory to implement" by the IETF; currently + the only one is RSASHA1. + </p> +<p> + The following command will generate a 768-bit RSASHA1 key for + the <code class="filename">child.example</code> zone: + </p> +<p> + <strong class="userinput"><code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</code></strong> + </p> +<p> + Two output files will be produced: + <code class="filename">Kchild.example.+005+12345.key</code> and + <code class="filename">Kchild.example.+005+12345.private</code> + (where + 12345 is an example of a key tag). The key filenames contain + the key name (<code class="filename">child.example.</code>), + algorithm (3 + is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in + this case). + The private key (in the <code class="filename">.private</code> + file) is + used to generate signatures, and the public key (in the + <code class="filename">.key</code> file) is used for signature + verification. + </p> +<p> + To generate another key with the same properties (but with + a different key tag), repeat the above command. + </p> +<p> + The <span><strong class="command">dnssec-keyfromlabel</strong></span> program is used + to get a key pair from a crypto hardware and build the key + files. Its usage is similar to <span><strong class="command">dnssec-keygen</strong></span>. + </p> +<p> + The public keys should be inserted into the zone file by + including the <code class="filename">.key</code> files using + <span><strong class="command">$INCLUDE</strong></span> statements. + </p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571877"></a>Signing the Zone</h3></div></div></div> +<p> + The <span><strong class="command">dnssec-signzone</strong></span> program is used + to sign a zone. + </p> +<p> + Any <code class="filename">keyset</code> files corresponding to + secure subzones should be present. The zone signer will + generate <code class="literal">NSEC</code>, <code class="literal">NSEC3</code> + and <code class="literal">RRSIG</code> records for the zone, as + well as <code class="literal">DS</code> for the child zones if + <code class="literal">'-g'</code> is specified. If <code class="literal">'-g'</code> + is not specified, then DS RRsets for the secure child + zones need to be added manually. + </p> +<p> + The following command signs the zone, assuming it is in a + file called <code class="filename">zone.child.example</code>. By + default, all zone keys which have an available private key are + used to generate signatures. + </p> +<p> + <strong class="userinput"><code>dnssec-signzone -o child.example zone.child.example</code></strong> + </p> +<p> + One output file is produced: + <code class="filename">zone.child.example.signed</code>. This + file + should be referenced by <code class="filename">named.conf</code> + as the + input file for the zone. + </p> +<p><span><strong class="command">dnssec-signzone</strong></span> + will also produce a keyset and dsset files and optionally a + dlvset file. These are used to provide the parent zone + administrators with the <code class="literal">DNSKEYs</code> (or their + corresponding <code class="literal">DS</code> records) that are the + secure entry point to the zone. + </p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2571958"></a>Configuring Servers</h3></div></div></div> +<p> + To enable <span><strong class="command">named</strong></span> to respond appropriately + to DNS requests from DNSSEC aware clients, + <span><strong class="command">dnssec-enable</strong></span> must be set to yes. + </p> +<p> + To enable <span><strong class="command">named</strong></span> to validate answers from + other servers both <span><strong class="command">dnssec-enable</strong></span> and + <span><strong class="command">dnssec-validation</strong></span> must be set and some + <span><strong class="command">trusted-keys</strong></span> must be configured + into <code class="filename">named.conf</code>. + </p> +<p> + <span><strong class="command">trusted-keys</strong></span> are copies of DNSKEY RRs + for zones that are used to form the first link in the + cryptographic chain of trust. All keys listed in + <span><strong class="command">trusted-keys</strong></span> (and corresponding zones) + are deemed to exist and only the listed keys will be used + to validated the DNSKEY RRset that they are from. + </p> +<p> + <span><strong class="command">trusted-keys</strong></span> are described in more detail + later in this document. + </p> +<p> + Unlike <acronym class="acronym">BIND</acronym> 8, <acronym class="acronym">BIND</acronym> + 9 does not verify signatures on load, so zone keys for + authoritative zones do not need to be specified in the + configuration file. + </p> +<p> + After DNSSEC gets established, a typical DNSSEC configuration + will look something like the following. It has a one or + more public keys for the root. This allows answers from + outside the organization to be validated. It will also + have several keys for parts of the namespace the organization + controls. These are here to ensure that named is immune + to compromises in the DNSSEC components of the security + of parent zones. + </p> +<pre class="programlisting"> +trusted-keys { + + /* Root Key */ +"." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwSJxrGkxJWoZu6I7PzJu/ + E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3 + zy2Xy4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYghf+6fElrmLkdaz + MQ2OCnACR817DF4BBa7UR/beDHyp5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M + /lUUVRbkeg1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq66gKodQj+M + iA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ97S+LKUTpQcq27R7AT3/V5hRQxScI + Nqwcz4jYqZD2fQdgxbcDTClU0CRBdiieyLMNzXG3"; + +/* Key for our organization's forward zone */ +example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe + 3Y9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbb + OTcM8pwXlj0EiX3oDFVmjHO444gLkBO UKUf/mC7HvfwYH/Be22GnC + lrinKJp1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt + 8lgnyTUHs1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/b + iuvF4qJCyduieHukuY3H4XMAcR+xia2 nIUPvm/oyWR8BW/hWdzOvn + SCThlHf3xiYleDbt/o1OTQ09A0="; + +/* Key for our reverse zone. */ +2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwcxOdNax071L18QqZnQQQA + VVr+iLhGTnNGp3HoWQLUIzKrJVZ3zggy3WwNT6kZo6c0 + tszYqbtvchmgQC8CzKojM/W16i6MG/ea fGU3siaOdS0 + yOI6BgPsw+YZdzlYMaIJGf4M4dyoKIhzdZyQ2bYQrjyQ + 4LB0lC7aOnsMyYKHHYeRv PxjIQXmdqgOJGq+vsevG06 + zW+1xgYJh9rCIfnm1GX/KMgxLPG2vXTD/RnLX+D3T3UL + 7HJYHJhAZD5L59VvjSPsZJHeDCUyWYrvPZesZDIRvhDD + 52SKvbheeTJUm6EhkzytNN2SN96QRk8j/iI8ib"; +}; + +options { + ... + dnssec-enable yes; + dnssec-validation yes; +}; +</pre> +<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> +<h3 class="title">Note</h3> + None of the keys listed in this example are valid. In particular, + the root key is not valid. + </div> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="id2572101"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div> +<p> + <acronym class="acronym">BIND</acronym> 9 fully supports all currently + defined forms of IPv6 + name to address and address to name lookups. It will also use + IPv6 addresses to make queries when running on an IPv6 capable + system. + </p> +<p> + For forward lookups, <acronym class="acronym">BIND</acronym> 9 supports + only AAAA records. RFC 3363 deprecated the use of A6 records, + and client-side support for A6 records was accordingly removed + from <acronym class="acronym">BIND</acronym> 9. + However, authoritative <acronym class="acronym">BIND</acronym> 9 name servers still + load zone files containing A6 records correctly, answer queries + for A6 records, and accept zone transfer for a zone containing A6 + records. + </p> +<p> + For IPv6 reverse lookups, <acronym class="acronym">BIND</acronym> 9 supports + the traditional "nibble" format used in the + <span class="emphasis"><em>ip6.arpa</em></span> domain, as well as the older, deprecated + <span class="emphasis"><em>ip6.int</em></span> domain. + Older versions of <acronym class="acronym">BIND</acronym> 9 + supported the "binary label" (also known as "bitstring") format, + but support of binary labels has been completely removed per + RFC 3363. + Many applications in <acronym class="acronym">BIND</acronym> 9 do not understand + the binary label format at all any more, and will return an + error if given. + In particular, an authoritative <acronym class="acronym">BIND</acronym> 9 + name server will not load a zone file containing binary labels. + </p> +<p> + For an overview of the format and structure of IPv6 addresses, + see <a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (AAAA)">the section called “IPv6 addresses (AAAA)”</a>. + </p> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2572163"></a>Address Lookups Using AAAA Records</h3></div></div></div> +<p> + The IPv6 AAAA record is a parallel to the IPv4 A record, + and, unlike the deprecated A6 record, specifies the entire + IPv6 address in a single record. For example, + </p> +<pre class="programlisting"> +$ORIGIN example.com. +host 3600 IN AAAA 2001:db8::1 +</pre> +<p> + Use of IPv4-in-IPv6 mapped addresses is not recommended. + If a host has an IPv4 address, use an A record, not + a AAAA, with <code class="literal">::ffff:192.168.42.1</code> as + the address. + </p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="id2572184"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div> +<p> + When looking up an address in nibble format, the address + components are simply reversed, just as in IPv4, and + <code class="literal">ip6.arpa.</code> is appended to the + resulting name. + For example, the following would provide reverse name lookup for + a host with address + <code class="literal">2001:db8::1</code>. + </p> +<pre class="programlisting"> +$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. +1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR host.example.com. +</pre> +</div> +</div> +</div> +<div class="navfooter"> +<hr> +<table width="100%" summary="Navigation footer"> +<tr> +<td width="40%" align="left"> +<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td> +<td width="20%" align="center"> </td> +<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a> +</td> +</tr> +<tr> +<td width="40%" align="left" valign="top">Chapter 3. Name Server Configuration </td> +<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> +<td width="40%" align="right" valign="top"> Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</td> +</tr> +</table> +</div> +</body> +</html> |