717 lines
39 KiB
HTML
717 lines
39 KiB
HTML
<!--
|
||
- Copyright (C) 2004, 2005 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.30.2.6.2.14 2005/10/13 02:33:59 marka 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.69.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#id2549203">Split DNS</a></span></dt>
|
||
<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#id2549627">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549830">Copying the Shared Secret to Both Machines</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549838">Informing the Servers of the Key's Existence</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549878">Instructing the Server to Use the Key</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549998">TSIG Key Based Access Control</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550042">Errors</a></span></dt>
|
||
</dl></dd>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550056">TKEY</a></span></dt>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550173">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#id2550308">Generating Keys</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550375">Signing the Zone</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550450">Configuring Servers</a></span></dt>
|
||
</dl></dd>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550473">IPv6 Support in <span class="acronym">BIND</span> 9</a></span></dt>
|
||
<dd><dl>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550600">Address Lookups Using AAAA Records</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550620">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><span class="acronym">DNS</span> 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><span class="acronym">DNS</span>
|
||
For more information about
|
||
<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>
|
||
<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 on a zone-by-zone basis, 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.</p>
|
||
<p>Updating of secure zones (zones using DNSSEC) follows
|
||
RFC 3007: RRSIG and NSEC 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. 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 unfreeze <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, <span class="acronym">BIND</span> 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, <span class="acronym">BIND</span> 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="id2549203"></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.</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>
|
||
<p>Here is an example of a split DNS setup:</p>
|
||
<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 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 { internals; externals; }; // restrict query access
|
||
allow-recursion { internals; externals; }; // restrict recursion
|
||
...
|
||
...
|
||
};
|
||
|
||
zone "site1.example.com" { // sample slave zone
|
||
type master;
|
||
file "m/site1.foo.com";
|
||
allow-query { any; };
|
||
allow-transfer { internals; externals; };
|
||
};
|
||
|
||
zone "site2.example.com" {
|
||
type slave;
|
||
file "s/site2.foo.com";
|
||
masters { another_bastion_host_maybe; };
|
||
allow-query { any; };
|
||
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 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 <span class="acronym">BIND</span>. 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 <span class="acronym">BIND</span>.</p>
|
||
<p><span class="acronym">BIND</span> primarily supports TSIG for server to server communication.
|
||
This includes zone transfer, notify, and recursive query messages.
|
||
Resolvers based on newer versions of <span class="acronym">BIND</span> 8 have limited support
|
||
for TSIG.</p>
|
||
<p>TSIG might be most useful for dynamic update. A primary
|
||
server for a dynamic zone should use access control to control
|
||
updates, 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.</p>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2549627"></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="id2549643"></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="id2549677"></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="id2549830"></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="id2549838"></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 <span class="acronym">BIND</span>.
|
||
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="id2549878"></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="id2549998"></a>TSIG Key Based Access Control</h3></div></div></div>
|
||
<p><span class="acronym">BIND</span> 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="id2550042"></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 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 is set to
|
||
NOTAUTH.</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect1" lang="en">
|
||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||
<a name="id2550056"></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. <span class="acronym">BIND</span> 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="id2550173"></a>SIG(0)</h2></div></div></div>
|
||
<p><span class="acronym">BIND</span> 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 <span class="acronym">BIND</span> 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 <TBA>. 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. <span class="acronym">BIND</span> 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">-h</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 presense
|
||
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="id2550308"></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 file names 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 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="id2550375"></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> 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">'-d'</code> is specified.
|
||
If <code class="literal">'-d'</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 administators 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="id2550450"></a>Configuring Servers</h3></div></div></div>
|
||
<p>Unlike <span class="acronym">BIND</span> 8,
|
||
<span class="acronym">BIND</span> 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>The public key for any security root must be present in
|
||
the configuration file's <span><strong class="command">trusted-keys</strong></span>
|
||
statement, as described later in this document. </p>
|
||
</div>
|
||
</div>
|
||
<div class="sect1" lang="en">
|
||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||
<a name="id2550473"></a>IPv6 Support in <span class="acronym">BIND</span> 9</h2></div></div></div>
|
||
<p><span class="acronym">BIND</span> 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, <span class="acronym">BIND</span> 9 supports only AAAA
|
||
records. The use of A6 records is deprecated by RFC 3363, and the
|
||
support for forward lookups in <span class="acronym">BIND</span> 9 is
|
||
removed accordingly.
|
||
However, authoritative <span class="acronym">BIND</span> 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, <span class="acronym">BIND</span> 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.
|
||
<span class="acronym">BIND</span> 9 formerly
|
||
supported the "binary label" (also known as "bitstring") format.
|
||
The support of binary labels, however, is now completely removed
|
||
according to the changes in RFC 3363.
|
||
Any applications in <span class="acronym">BIND</span> 9 do not understand
|
||
the format any more, and will return an error if given.
|
||
In particular, an authoritative <span class="acronym">BIND</span> 9 name
|
||
server rejects to 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="id2550600"></a>Address Lookups Using AAAA Records</h3></div></div></div>
|
||
<p>The AAAA record is a parallel to the IPv4 A record. It
|
||
specifies the entire address in a single record. For
|
||
example,</p>
|
||
<pre class="programlisting">
|
||
$ORIGIN example.com.
|
||
host 3600 IN AAAA 2001:db8::1
|
||
</pre>
|
||
<p>It is recommended that IPv4-in-IPv6 mapped addresses not
|
||
be used. 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="id2550620"></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 <span class="acronym">BIND</span> 9 Lightweight Resolver</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|