726 lines
39 KiB
HTML
726 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.18 2005/10/13 02:23:42 marka Exp $ -->
|
||
<html>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||
<title>Chapter 4. Advanced Concepts</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. Nameserver 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 Concepts</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 Concepts</h2></div></div></div>
|
||
<div class="toc">
|
||
<p><b>Table of Contents</b></p>
|
||
<dl>
|
||
<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#id2550976">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#id2551469">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2551604">Copying the Shared Secret to Both Machines</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2551612">Informing the Servers of the Key's Existence</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2551652">Instructing the Server to Use the Key</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2551704">TSIG Key Based Access Control</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2551748">Errors</a></span></dt>
|
||
</dl></dd>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2551762">TKEY</a></span></dt>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2551879">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#id2551932">Generating Keys</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2552069">Creating a Keyset</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2552107">Signing the Child's Keyset</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2552217">Signing the Zone</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2552272">Configuring Servers</a></span></dt>
|
||
</dl></dd>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2552364">IPv6 Support in <span class="acronym">BIND</span> 9</a></span></dt>
|
||
<dd><dl>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2552420">Address Lookups Using AAAA Records</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2552434">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="dynamic_update"></a>Dynamic Update</h2></div></div></div>
|
||
<p>Dynamic update is the term used for the ability under
|
||
certain specified conditions to add, modify or delete records or
|
||
RRsets in the master zone files. Dynamic update is fully described
|
||
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: SIG and NXT 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 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: Shut down
|
||
the server using <span><strong class="command">rndc stop</strong></span> (sending a signal
|
||
or using <span><strong class="command">rndc halt</strong></span> is <span class="emphasis"><em>not</em></span>
|
||
sufficient). Wait for the server to exit,
|
||
then <span class="emphasis"><em>remove</em></span> the zone's
|
||
<code class="filename">.jnl</code> file, edit the zone file,
|
||
and restart the server. Removing the <code class="filename">.jnl</code>
|
||
file is necessary because the manual edits will not be
|
||
present in the journal, rendering it inconsistent with the
|
||
contents of the zone file.</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 documented 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, but not manually maintained master
|
||
zones nor slave zones obtained by performing a full zone transfer
|
||
(AXFR).</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="id2550976"></a>Split DNS</h2></div></div></div>
|
||
<p>Setting up different views, or visibility, of 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> (example.com)
|
||
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 nameservers. 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 nameservers 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
|
||
nameservers 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
|
||
nameservers 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" {
|
||
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. Key-based
|
||
access control is far superior, see <a href="Bv9ARM.ch09.html#proposed_standards">Proposed Standards</a>. 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="id2551469"></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="id2551485"></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="id2551520"></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="id2551604"></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="id2551612"></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 succeeds, 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="id2551652"></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="id2551704"></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="id2551748"></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="id2551762"></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> 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="id2551879"></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. 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><span class="acronym">BIND</span> 9 does not ship with any tools that generate SIG(0)
|
||
signed messages.</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</em></span>) extensions,
|
||
defined in RFC 2535. 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 and signedkey files to be in the working directory, and
|
||
that the tools shipped with BIND 9.0.x are not fully 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 and signatures. A
|
||
zone's security status must be indicated by the parent zone for a
|
||
DNSSEC capable resolver to trust its data.</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="id2551932"></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
|
||
these are RSASHA1 (which is not yet supported in BIND 9.2)
|
||
and DSA.</p>
|
||
<p>The following command will generate a 768 bit DSA key for
|
||
the <code class="filename">child.example</code> zone:</p>
|
||
<p><strong class="userinput"><code>dnssec-keygen -a DSA -b 768 -n ZONE child.example.</code></strong></p>
|
||
<p>Two output files will be produced:
|
||
<code class="filename">Kchild.example.+003+12345.key</code> and
|
||
<code class="filename">Kchild.example.+003+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 RSA, 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 with
|
||
<span><strong class="command">$INCLUDE</strong></span> statements, including the
|
||
<code class="filename">.key</code> files.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2552069"></a>Creating a Keyset</h3></div></div></div>
|
||
<p>The <span><strong class="command">dnssec-makekeyset</strong></span> program is used
|
||
to create a key set from one or more keys.</p>
|
||
<p>Once the zone keys have been generated, a key set must be
|
||
built for transmission to the administrator of the parent zone,
|
||
so that the parent zone can sign the keys with its own zone key
|
||
and correctly indicate the security status of this zone. When
|
||
building a key set, the list of keys to be included and the TTL
|
||
of the set must be specified, and the desired signature validity
|
||
period of the parent's signature may also be specified.</p>
|
||
<p>The list of keys to be inserted into the key set may also
|
||
included non-zone keys present at the top of the zone.
|
||
<span><strong class="command">dnssec-makekeyset</strong></span> may also be used at other
|
||
names in the zone.</p>
|
||
<p>The following command generates a key set containing the
|
||
above key and another key similarly generated, with a TTL of
|
||
3600 and a signature validity period of 10 days starting from
|
||
now.</p>
|
||
<p><strong class="userinput"><code>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</code></strong></p>
|
||
<p>One output file is produced:
|
||
<code class="filename">keyset-child.example.</code>. This file should be
|
||
transmitted to the parent to be signed. It includes the keys,
|
||
as well as signatures over the key set generated by the zone
|
||
keys themselves, which are used to prove ownership of the
|
||
private keys and encode the desired validity period.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2552107"></a>Signing the Child's Keyset</h3></div></div></div>
|
||
<p>The <span><strong class="command">dnssec-signkey</strong></span> program is used to
|
||
sign one child's keyset.</p>
|
||
<p>If the <code class="filename">child.example</code> zone has any
|
||
delegations which are secure, for example,
|
||
<code class="filename">grand.child.example</code>, the
|
||
<code class="filename">child.example</code> administrator should receive
|
||
keyset files for each secure subzone. These keys must be signed
|
||
by this zone's zone keys.</p>
|
||
<p>The following command signs the child's key set with the
|
||
zone keys:</p>
|
||
<p><strong class="userinput"><code>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</code></strong></p>
|
||
<p>One output file is produced:
|
||
<code class="filename">signedkey-grand.child.example.</code>. This file
|
||
should be both transmitted back to the child and retained. It
|
||
includes all keys (the child's keys) from the keyset file and
|
||
signatures generated by this zone's zone keys.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2552217"></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">signedkey</code> files corresponding to
|
||
secure subzones should be present, as well as a
|
||
<code class="filename">signedkey</code> file for this zone generated by
|
||
the parent (if there is one). The zone signer will generate
|
||
<code class="literal">NXT</code> and <code class="literal">SIG</code> records for
|
||
the zone, as well as incorporate the zone key signature from the
|
||
parent and indicate the security status at all delegation
|
||
points.</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>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2552272"></a>Configuring Servers</h3></div></div></div>
|
||
<p>Unlike in <span class="acronym">BIND</span> 8,
|
||
data is not verified on load in <span class="acronym">BIND</span> 9,
|
||
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="id2552364"></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
|
||
both A6 and AAAA records. The use of A6 records has been moved
|
||
to experimental (RFC 3363) and should be treated as deprecated.</p>
|
||
<p>The use of "bitstring" labels for IPv6 has been moved to
|
||
experimental (RFC 3363) reverting to a nibble format. The
|
||
suffix for the IPv6 reverse lookups has also changed from
|
||
<code class="literal">IP6.INT</code> to <code class="literal">IP6.ARPA</code> (RFC
|
||
3152).</p>
|
||
<p><span class="acronym">BIND</span> 9 now defaults to nibble
|
||
<code class="literal">IP6.ARPA</code> format lookups.</p>
|
||
<p><span class="acronym">BIND</span> 9 includes a new lightweight resolver library and
|
||
resolver daemon which new applications may choose to use to avoid
|
||
the complexities of A6 chain following and bitstring labels, see <a href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">Chapter 5, <i>The <span class="acronym">BIND</span> 9 Lightweight Resolver</i></a>.</p>
|
||
<p>For an overview of the format and structure of IPv6 addresses,
|
||
see <a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (A6)">the section called “IPv6 addresses (A6)”</a>.</p>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2552420"></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>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2552434"></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. Nameserver 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>
|