diff options
Diffstat (limited to 'contrib/bind9/doc/arm/Bv9ARM.ch04.html')
| -rw-r--r-- | contrib/bind9/doc/arm/Bv9ARM.ch04.html | 1028 |
1 files changed, 0 insertions, 1028 deletions
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch04.html b/contrib/bind9/doc/arm/Bv9ARM.ch04.html deleted file mode 100644 index 09507fe..0000000 --- a/contrib/bind9/doc/arm/Bv9ARM.ch04.html +++ /dev/null @@ -1,1028 +0,0 @@ -<!-- - - Copyright (C) 2004-2007 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.40.18.41 2007/10/31 01:35:57 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.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#id2570642">Split DNS</a></span></dt> -<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570660">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#id2571095">Generate Shared Keys for Each Pair of Hosts</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571169">Copying the Shared Secret to Both Machines</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571179">Informing the Servers of the Key's Existence</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571219">Instructing the Server to Use the Key</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571413">TSIG Key Based Access Control</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571458">Errors</a></span></dt> -</dl></dd> -<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571472">TKEY</a></span></dt> -<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571521">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#id2571725">Generating Keys</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571795">Signing the Zone</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571874">Configuring Servers</a></span></dt> -</dl></dd> -<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572153">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt> -<dd><dl> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572215">Address Lookups Using AAAA Records</a></span></dt> -<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572236">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. - </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 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="id2570642"></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="id2570660"></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="id2571095"></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="id2571112"></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="id2571150"></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="id2571169"></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="id2571179"></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="id2571219"></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="id2571413"></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="id2571458"></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="id2571472"></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="id2571521"></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="id2571725"></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 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="id2571795"></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 - 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="id2571874"></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="id2572153"></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="id2572215"></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="id2572236"></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> |
