contrib/bind9/doc/arm/Bv9ARM.ch04.html

   1 <!--
   2  - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
   3  - Copyright (C) 2000-2003 Internet Software Consortium.
   4  -
   5  - Permission to use, copy, modify, and/or distribute this software for any
   6  - purpose with or without fee is hereby granted, provided that the above
   7  - copyright notice and this permission notice appear in all copies.
   8  -
   9  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  10  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
  11  - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  12  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  13  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  14  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  15  - PERFORMANCE OF THIS SOFTWARE.
  16 -->
  17 <!-- $Id: Bv9ARM.ch04.html,v 1.87.48.6 2010/01/24 01:55:26 tbox Exp $ -->
  18 <html>
  19 <head>
  20 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
  21 <title>Chapter 4. Advanced DNS Features</title>
  22 <meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
  23 <link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
  24 <link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
  25 <link rel="prev" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
  26 <link rel="next" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
  27 </head>
  28 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
  29 <div class="navheader">
  30 <table width="100%" summary="Navigation header">
  31 <tr><th colspan="3" align="center">Chapter 4. Advanced DNS Features</th></tr>
  32 <tr>
  33 <td width="20%" align="left">
  34 <a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
  35 <th width="60%" align="center"> </th>
  36 <td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
  37 </td>
  38 </tr>
  39 </table>
  40 <hr>
  41 </div>
  42 <div class="chapter" lang="en">
  43 <div class="titlepage"><div><div><h2 class="title">
  44 <a name="Bv9ARM.ch04"></a>Chapter 4. Advanced DNS Features</h2></div></div></div>
  45 <div class="toc">
  46 <p><b>Table of Contents</b></p>
  47 <dl>
  48 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
  49 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
  50 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
  51 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
  52 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570492">Split DNS</a></span></dt>
  53 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570510">Example split DNS setup</a></span></dt></dl></dd>
  54 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
  55 <dd><dl>
  56 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571082">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
  57 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571156">Copying the Shared Secret to Both Machines</a></span></dt>
  58 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571166">Informing the Servers of the Key's Existence</a></span></dt>
  59 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571203">Instructing the Server to Use the Key</a></span></dt>
  60 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571260">TSIG Key Based Access Control</a></span></dt>
  61 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571445">Errors</a></span></dt>
  62 </dl></dd>
  63 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571459">TKEY</a></span></dt>
  64 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571576">SIG(0)</a></span></dt>
  65 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
  66 <dd><dl>
  67 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571644">Generating Keys</a></span></dt>
  68 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571792">Signing the Zone</a></span></dt>
  69 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571873">Configuring Servers</a></span></dt>
  70 </dl></dd>
  71 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572110">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
  72 <dd><dl>
  73 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572172">Address Lookups Using AAAA Records</a></span></dt>
  74 <dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572194">Address to Name Lookups Using Nibble Format</a></span></dt>
  75 </dl></dd>
  76 </dl>
  77 </div>
  78 <div class="sect1" lang="en">
  79 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
  80 <a name="notify"></a>Notify</h2></div></div></div>
  81 <p>
  82         <acronym class="acronym">DNS</acronym> NOTIFY is a mechanism that allows master
  83         servers to notify their slave servers of changes to a zone's data. In
  84         response to a <span><strong class="command">NOTIFY</strong></span> from a master server, the
  85         slave will check to see that its version of the zone is the
  86         current version and, if not, initiate a zone transfer.
  87       </p>
  88 <p>
  89         For more information about <acronym class="acronym">DNS</acronym>
  90         <span><strong class="command">NOTIFY</strong></span>, see the description of the
  91         <span><strong class="command">notify</strong></span> option in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a> and
  92         the description of the zone option <span><strong class="command">also-notify</strong></span> in
  93         <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.  The <span><strong class="command">NOTIFY</strong></span>
  94         protocol is specified in RFC 1996.
  95       </p>
  96 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
  97 <h3 class="title">Note</h3>
  98         As a slave zone can also be a master to other slaves, <span><strong class="command">named</strong></span>,
  99         by default, sends <span><strong class="command">NOTIFY</strong></span> messages for every zone
 100         it loads.  Specifying <span><strong class="command">notify master-only;</strong></span> will
 101         cause <span><strong class="command">named</strong></span> to only send <span><strong class="command">NOTIFY</strong></span> for master
 102         zones that it loads.
 103       </div>
 104 </div>
 105 <div class="sect1" lang="en">
 106 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 107 <a name="dynamic_update"></a>Dynamic Update</h2></div></div></div>
 108 <p>
 109         Dynamic Update is a method for adding, replacing or deleting
 110         records in a master server by sending it a special form of DNS
 111         messages.  The format and meaning of these messages is specified
 112         in RFC 2136.
 113       </p>
 114 <p>
 115         Dynamic update is enabled by including an
 116         <span><strong class="command">allow-update</strong></span> or <span><strong class="command">update-policy</strong></span>
 117         clause in the <span><strong class="command">zone</strong></span> statement.  The
 118         <span><strong class="command">tkey-gssapi-credential</strong></span> and
 119         <span><strong class="command">tkey-domain</strong></span> clauses in the
 120         <span><strong class="command">options</strong></span>        statement enable the
 121         server to negotiate keys that can be matched against those
 122         in <span><strong class="command">update-policy</strong></span> or
 123         <span><strong class="command">allow-update</strong></span>.
 124       </p>
 125 <p>
 126         Updating of secure zones (zones using DNSSEC) follows RFC
 127         3007: RRSIG, NSEC and NSEC3 records affected by updates are
 128         automatically regenerated by the server using an online
 129         zone key.  Update authorization is based on transaction
 130         signatures and an explicit server policy.
 131       </p>
 132 <div class="sect2" lang="en">
 133 <div class="titlepage"><div><div><h3 class="title">
 134 <a name="journal"></a>The journal file</h3></div></div></div>
 135 <p>
 136           All changes made to a zone using dynamic update are stored
 137           in the zone's journal file.  This file is automatically created
 138           by the server when the first dynamic update takes place.
 139           The name of the journal file is formed by appending the extension
 140           <code class="filename">.jnl</code> to the name of the
 141           corresponding zone
 142           file unless specifically overridden.  The journal file is in a
 143           binary format and should not be edited manually.
 144         </p>
 145 <p>
 146           The server will also occasionally write ("dump")
 147           the complete contents of the updated zone to its zone file.
 148           This is not done immediately after
 149           each dynamic update, because that would be too slow when a large
 150           zone is updated frequently.  Instead, the dump is delayed by
 151           up to 15 minutes, allowing additional updates to take place.
 152           During the dump process, transient files will be created
 153           with the extensions <code class="filename">.jnw</code> and
 154           <code class="filename">.jbk</code>; under ordinary circumstances, these
 155           will be removed when the dump is complete, and can be safely
 156           ignored.
 157         </p>
 158 <p>
 159           When a server is restarted after a shutdown or crash, it will replay
 160               the journal file to incorporate into the zone any updates that
 161           took
 162           place after the last zone dump.
 163         </p>
 164 <p>
 165           Changes that result from incoming incremental zone transfers are
 166           also
 167           journalled in a similar way.
 168         </p>
 169 <p>
 170           The zone files of dynamic zones cannot normally be edited by
 171           hand because they are not guaranteed to contain the most recent
 172           dynamic changes &#8212; those are only in the journal file.
 173           The only way to ensure that the zone file of a dynamic zone
 174           is up to date is to run <span><strong class="command">rndc stop</strong></span>.
 175         </p>
 176 <p>
 177           If you have to make changes to a dynamic zone
 178           manually, the following procedure will work: Disable dynamic updates
 179               to the zone using
 180           <span><strong class="command">rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>.
 181           This will also remove the zone's <code class="filename">.jnl</code> file
 182           and update the master file.  Edit the zone file.  Run
 183           <span><strong class="command">rndc thaw <em class="replaceable"><code>zone</code></em></strong></span>
 184           to reload the changed zone and re-enable dynamic updates.
 185         </p>
 186 </div>
 187 </div>
 188 <div class="sect1" lang="en">
 189 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 190 <a name="incremental_zone_transfers"></a>Incremental Zone Transfers (IXFR)</h2></div></div></div>
 191 <p>
 192         The incremental zone transfer (IXFR) protocol is a way for
 193         slave servers to transfer only changed data, instead of having to
 194         transfer the entire zone. The IXFR protocol is specified in RFC
 195         1995. See <a href="Bv9ARM.ch09.html#proposed_standards">Proposed Standards</a>.
 196       </p>
 197 <p>
 198         When acting as a master, <acronym class="acronym">BIND</acronym> 9
 199         supports IXFR for those zones
 200         where the necessary change history information is available. These
 201         include master zones maintained by dynamic update and slave zones
 202         whose data was obtained by IXFR.  For manually maintained master
 203         zones, and for slave zones obtained by performing a full zone
 204         transfer (AXFR), IXFR is supported only if the option
 205         <span><strong class="command">ixfr-from-differences</strong></span> is set
 206         to <strong class="userinput"><code>yes</code></strong>.
 207       </p>
 208 <p>
 209         When acting as a slave, <acronym class="acronym">BIND</acronym> 9 will
 210         attempt to use IXFR unless
 211         it is explicitly disabled. For more information about disabling
 212         IXFR, see the description of the <span><strong class="command">request-ixfr</strong></span> clause
 213         of the <span><strong class="command">server</strong></span> statement.
 214       </p>
 215 </div>
 216 <div class="sect1" lang="en">
 217 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 218 <a name="id2570492"></a>Split DNS</h2></div></div></div>
 219 <p>
 220         Setting up different views, or visibility, of the DNS space to
 221         internal and external resolvers is usually referred to as a
 222         <span class="emphasis"><em>Split DNS</em></span> setup. There are several
 223         reasons an organization would want to set up its DNS this way.
 224       </p>
 225 <p>
 226         One common reason for setting up a DNS system this way is
 227         to hide "internal" DNS information from "external" clients on the
 228         Internet. There is some debate as to whether or not this is actually
 229         useful.
 230         Internal DNS information leaks out in many ways (via email headers,
 231         for example) and most savvy "attackers" can find the information
 232         they need using other means.
 233         However, since listing addresses of internal servers that
 234         external clients cannot possibly reach can result in
 235         connection delays and other annoyances, an organization may
 236         choose to use a Split DNS to present a consistent view of itself
 237         to the outside world.
 238       </p>
 239 <p>
 240         Another common reason for setting up a Split DNS system is
 241         to allow internal networks that are behind filters or in RFC 1918
 242         space (reserved IP space, as documented in RFC 1918) to resolve DNS
 243         on the Internet. Split DNS can also be used to allow mail from outside
 244         back in to the internal network.
 245       </p>
 246 <div class="sect2" lang="en">
 247 <div class="titlepage"><div><div><h3 class="title">
 248 <a name="id2570510"></a>Example split DNS setup</h3></div></div></div>
 249 <p>
 250         Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
 251         (<code class="literal">example.com</code>)
 252         has several corporate sites that have an internal network with
 253         reserved
 254         Internet Protocol (IP) space and an external demilitarized zone (DMZ),
 255         or "outside" section of a network, that is available to the public.
 256       </p>
 257 <p>
 258         <span class="emphasis"><em>Example, Inc.</em></span> wants its internal clients
 259         to be able to resolve external hostnames and to exchange mail with
 260         people on the outside. The company also wants its internal resolvers
 261         to have access to certain internal-only zones that are not available
 262         at all outside of the internal network.
 263       </p>
 264 <p>
 265         In order to accomplish this, the company will set up two sets
 266         of name servers. One set will be on the inside network (in the
 267         reserved
 268         IP space) and the other set will be on bastion hosts, which are
 269         "proxy"
 270         hosts that can talk to both sides of its network, in the DMZ.
 271       </p>
 272 <p>
 273         The internal servers will be configured to forward all queries,
 274         except queries for <code class="filename">site1.internal</code>, <code class="filename">site2.internal</code>, <code class="filename">site1.example.com</code>,
 275         and <code class="filename">site2.example.com</code>, to the servers
 276         in the
 277         DMZ. These internal servers will have complete sets of information
 278         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>,
 279         and <code class="filename">site2.internal</code>.
 280       </p>
 281 <p>
 282         To protect the <code class="filename">site1.internal</code> and <code class="filename">site2.internal</code> domains,
 283         the internal name servers must be configured to disallow all queries
 284         to these domains from any external hosts, including the bastion
 285         hosts.
 286       </p>
 287 <p>
 288         The external servers, which are on the bastion hosts, will
 289         be configured to serve the "public" version of the <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones.
 290         This could include things such as the host records for public servers
 291         (<code class="filename">www.example.com</code> and <code class="filename">ftp.example.com</code>),
 292         and mail exchange (MX)  records (<code class="filename">a.mx.example.com</code> and <code class="filename">b.mx.example.com</code>).
 293       </p>
 294 <p>
 295         In addition, the public <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones
 296         should have special MX records that contain wildcard (`*') records
 297         pointing to the bastion hosts. This is needed because external mail
 298         servers do not have any other way of looking up how to deliver mail
 299         to those internal hosts. With the wildcard records, the mail will
 300         be delivered to the bastion host, which can then forward it on to
 301         internal hosts.
 302       </p>
 303 <p>
 304         Here's an example of a wildcard MX record:
 305       </p>
 306 <pre class="programlisting">*   IN MX 10 external1.example.com.</pre>
 307 <p>
 308         Now that they accept mail on behalf of anything in the internal
 309         network, the bastion hosts will need to know how to deliver mail
 310         to internal hosts. In order for this to work properly, the resolvers
 311         on
 312         the bastion hosts will need to be configured to point to the internal
 313         name servers for DNS resolution.
 314       </p>
 315 <p>
 316         Queries for internal hostnames will be answered by the internal
 317         servers, and queries for external hostnames will be forwarded back
 318         out to the DNS servers on the bastion hosts.
 319       </p>
 320 <p>
 321         In order for all this to work properly, internal clients will
 322         need to be configured to query <span class="emphasis"><em>only</em></span> the internal
 323         name servers for DNS queries. This could also be enforced via
 324         selective
 325         filtering on the network.
 326       </p>
 327 <p>
 328         If everything has been set properly, <span class="emphasis"><em>Example, Inc.</em></span>'s
 329         internal clients will now be able to:
 330       </p>
 331 <div class="itemizedlist"><ul type="disc">
 332 <li>
 333             Look up any hostnames in the <code class="literal">site1</code>
 334             and
 335             <code class="literal">site2.example.com</code> zones.
 336           </li>
 337 <li>
 338             Look up any hostnames in the <code class="literal">site1.internal</code> and
 339             <code class="literal">site2.internal</code> domains.
 340           </li>
 341 <li>Look up any hostnames on the Internet.</li>
 342 <li>Exchange mail with both internal and external people.</li>
 343 </ul></div>
 344 <p>
 345         Hosts on the Internet will be able to:
 346       </p>
 347 <div class="itemizedlist"><ul type="disc">
 348 <li>
 349             Look up any hostnames in the <code class="literal">site1</code>
 350             and
 351             <code class="literal">site2.example.com</code> zones.
 352           </li>
 353 <li>
 354             Exchange mail with anyone in the <code class="literal">site1</code> and
 355             <code class="literal">site2.example.com</code> zones.
 356           </li>
 357 </ul></div>
 358 <p>
 359         Here is an example configuration for the setup we just
 360         described above. Note that this is only configuration information;
 361         for information on how to configure your zone files, see <a href="Bv9ARM.ch03.html#sample_configuration" title="Sample Configurations">the section called &#8220;Sample Configurations&#8221;</a>.
 362       </p>
 363 <p>
 364         Internal DNS server config:
 365       </p>
 366 <pre class="programlisting">
 367
 368 acl internals { 172.16.72.0/24; 192.168.1.0/24; };
 369
 370 acl externals { <code class="varname">bastion-ips-go-here</code>; };
 371
 372 options {
 373     ...
 374     ...
 375     forward only;
 376     forwarders {                                // forward to external servers
 377         <code class="varname">bastion-ips-go-here</code>;
 378     };
 379     allow-transfer { none; };                   // sample allow-transfer (no one)
 380     allow-query { internals; externals; };      // restrict query access
 381     allow-recursion { internals; };             // restrict recursion
 382     ...
 383     ...
 384 };
 385
 386 zone "site1.example.com" {                      // sample master zone
 387   type master;
 388   file "m/site1.example.com";
 389   forwarders { };                               // do normal iterative
 390                                                 // resolution (do not forward)
 391   allow-query { internals; externals; };
 392   allow-transfer { internals; };
 393 };
 394
 395 zone "site2.example.com" {                      // sample slave zone
 396   type slave;
 397   file "s/site2.example.com";
 398   masters { 172.16.72.3; };
 399   forwarders { };
 400   allow-query { internals; externals; };
 401   allow-transfer { internals; };
 402 };
 403
 404 zone "site1.internal" {
 405   type master;
 406   file "m/site1.internal";
 407   forwarders { };
 408   allow-query { internals; };
 409   allow-transfer { internals; }
 410 };
 411
 412 zone "site2.internal" {
 413   type slave;
 414   file "s/site2.internal";
 415   masters { 172.16.72.3; };
 416   forwarders { };
 417   allow-query { internals };
 418   allow-transfer { internals; }
 419 };
 420 </pre>
 421 <p>
 422         External (bastion host) DNS server config:
 423       </p>
 424 <pre class="programlisting">
 425 acl internals { 172.16.72.0/24; 192.168.1.0/24; };
 426
 427 acl externals { bastion-ips-go-here; };
 428
 429 options {
 430   ...
 431   ...
 432   allow-transfer { none; };                     // sample allow-transfer (no one)
 433   allow-query { any; };                         // default query access
 434   allow-query-cache { internals; externals; };  // restrict cache access
 435   allow-recursion { internals; externals; };    // restrict recursion
 436   ...
 437   ...
 438 };
 439
 440 zone "site1.example.com" {                      // sample slave zone
 441   type master;
 442   file "m/site1.foo.com";
 443   allow-transfer { internals; externals; };
 444 };
 445
 446 zone "site2.example.com" {
 447   type slave;
 448   file "s/site2.foo.com";
 449   masters { another_bastion_host_maybe; };
 450   allow-transfer { internals; externals; }
 451 };
 452 </pre>
 453 <p>
 454         In the <code class="filename">resolv.conf</code> (or equivalent) on
 455         the bastion host(s):
 456       </p>
 457 <pre class="programlisting">
 458 search ...
 459 nameserver 172.16.72.2
 460 nameserver 172.16.72.3
 461 nameserver 172.16.72.4
 462 </pre>
 463 </div>
 464 </div>
 465 <div class="sect1" lang="en">
 466 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 467 <a name="tsig"></a>TSIG</h2></div></div></div>
 468 <p>
 469         This is a short guide to setting up Transaction SIGnatures
 470         (TSIG) based transaction security in <acronym class="acronym">BIND</acronym>. It describes changes
 471         to the configuration file as well as what changes are required for
 472         different features, including the process of creating transaction
 473         keys and using transaction signatures with <acronym class="acronym">BIND</acronym>.
 474       </p>
 475 <p>
 476         <acronym class="acronym">BIND</acronym> primarily supports TSIG for server
 477         to server communication.
 478         This includes zone transfer, notify, and recursive query messages.
 479         Resolvers based on newer versions of <acronym class="acronym">BIND</acronym> 8 have limited support
 480         for TSIG.
 481       </p>
 482 <p>
 483         TSIG can also be useful for dynamic update. A primary
 484         server for a dynamic zone should control access to the dynamic
 485         update service, but IP-based access control is insufficient.
 486         The cryptographic access control provided by TSIG
 487         is far superior. The <span><strong class="command">nsupdate</strong></span>
 488         program supports TSIG via the <code class="option">-k</code> and
 489         <code class="option">-y</code> command line options or inline by use
 490         of the <span><strong class="command">key</strong></span>.
 491       </p>
 492 <div class="sect2" lang="en">
 493 <div class="titlepage"><div><div><h3 class="title">
 494 <a name="id2571082"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
 495 <p>
 496           A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
 497           An arbitrary key name is chosen: "host1-host2.". The key name must
 498           be the same on both hosts.
 499         </p>
 500 <div class="sect3" lang="en">
 501 <div class="titlepage"><div><div><h4 class="title">
 502 <a name="id2571099"></a>Automatic Generation</h4></div></div></div>
 503 <p>
 504             The following command will generate a 128-bit (16 byte) HMAC-SHA256
 505             key as described above. Longer keys are better, but shorter keys
 506             are easier to read. Note that the maximum key length is the digest
 507             length, here 256 bits.
 508           </p>
 509 <p>
 510             <strong class="userinput"><code>dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2.</code></strong>
 511           </p>
 512 <p>
 513             The key is in the file <code class="filename">Khost1-host2.+163+00000.private</code>.
 514             Nothing directly uses this file, but the base-64 encoded string
 515             following "<code class="literal">Key:</code>"
 516             can be extracted from the file and used as a shared secret:
 517           </p>
 518 <pre class="programlisting">Key: La/E5CjG9O+os1jq0a2jdA==</pre>
 519 <p>
 520             The string "<code class="literal">La/E5CjG9O+os1jq0a2jdA==</code>" can
 521             be used as the shared secret.
 522           </p>
 523 </div>
 524 <div class="sect3" lang="en">
 525 <div class="titlepage"><div><div><h4 class="title">
 526 <a name="id2571138"></a>Manual Generation</h4></div></div></div>
 527 <p>
 528             The shared secret is simply a random sequence of bits, encoded
 529             in base-64. Most ASCII strings are valid base-64 strings (assuming
 530             the length is a multiple of 4 and only valid characters are used),
 531             so the shared secret can be manually generated.
 532           </p>
 533 <p>
 534             Also, a known string can be run through <span><strong class="command">mmencode</strong></span> or
 535             a similar program to generate base-64 encoded data.
 536           </p>
 537 </div>
 538 </div>
 539 <div class="sect2" lang="en">
 540 <div class="titlepage"><div><div><h3 class="title">
 541 <a name="id2571156"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
 542 <p>
 543           This is beyond the scope of DNS. A secure transport mechanism
 544           should be used. This could be secure FTP, ssh, telephone, etc.
 545         </p>
 546 </div>
 547 <div class="sect2" lang="en">
 548 <div class="titlepage"><div><div><h3 class="title">
 549 <a name="id2571166"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
 550 <p>
 551           Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span>
 552           are
 553           both servers. The following is added to each server's <code class="filename">named.conf</code> file:
 554         </p>
 555 <pre class="programlisting">
 556 key host1-host2. {
 557   algorithm hmac-sha256;
 558   secret "La/E5CjG9O+os1jq0a2jdA==";
 559 };
 560 </pre>
 561 <p>
 562           The secret is the one generated above. Since this is a secret, it
 563           is recommended that either <code class="filename">named.conf</code> be
 564           non-world readable, or the key directive be added to a non-world
 565           readable file that is included by <code class="filename">named.conf</code>.
 566         </p>
 567 <p>
 568           At this point, the key is recognized. This means that if the
 569           server receives a message signed by this key, it can verify the
 570           signature. If the signature is successfully verified, the
 571           response is signed by the same key.
 572         </p>
 573 </div>
 574 <div class="sect2" lang="en">
 575 <div class="titlepage"><div><div><h3 class="title">
 576 <a name="id2571203"></a>Instructing the Server to Use the Key</h3></div></div></div>
 577 <p>
 578           Since keys are shared between two hosts only, the server must
 579           be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file
 580           for <span class="emphasis"><em>host1</em></span>, if the IP address of <span class="emphasis"><em>host2</em></span> is
 581           10.1.2.3:
 582         </p>
 583 <pre class="programlisting">
 584 server 10.1.2.3 {
 585   keys { host1-host2. ;};
 586 };
 587 </pre>
 588 <p>
 589           Multiple keys may be present, but only the first is used.
 590           This directive does not contain any secrets, so it may be in a
 591           world-readable
 592           file.
 593         </p>
 594 <p>
 595           If <span class="emphasis"><em>host1</em></span> sends a message that is a request
 596           to that address, the message will be signed with the specified key. <span class="emphasis"><em>host1</em></span> will
 597           expect any responses to signed messages to be signed with the same
 598           key.
 599         </p>
 600 <p>
 601           A similar statement must be present in <span class="emphasis"><em>host2</em></span>'s
 602           configuration file (with <span class="emphasis"><em>host1</em></span>'s address) for <span class="emphasis"><em>host2</em></span> to
 603           sign request messages to <span class="emphasis"><em>host1</em></span>.
 604         </p>
 605 </div>
 606 <div class="sect2" lang="en">
 607 <div class="titlepage"><div><div><h3 class="title">
 608 <a name="id2571260"></a>TSIG Key Based Access Control</h3></div></div></div>
 609 <p>
 610           <acronym class="acronym">BIND</acronym> allows IP addresses and ranges
 611           to be specified in ACL
 612           definitions and
 613           <span><strong class="command">allow-{ query | transfer | update }</strong></span>
 614           directives.
 615           This has been extended to allow TSIG keys also. The above key would
 616           be denoted <span><strong class="command">key host1-host2.</strong></span>
 617         </p>
 618 <p>
 619           An example of an <span><strong class="command">allow-update</strong></span> directive would be:
 620         </p>
 621 <pre class="programlisting">
 622 allow-update { key host1-host2. ;};
 623 </pre>
 624 <p>
 625           This allows dynamic updates to succeed only if the request
 626           was signed by a key named "<span><strong class="command">host1-host2.</strong></span>".
 627         </p>
 628 <p>
 629           You may want to read about the more powerful
 630           <span><strong class="command">update-policy</strong></span> statement in
 631           <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.
 632         </p>
 633 </div>
 634 <div class="sect2" lang="en">
 635 <div class="titlepage"><div><div><h3 class="title">
 636 <a name="id2571445"></a>Errors</h3></div></div></div>
 637 <p>
 638           The processing of TSIG signed messages can result in
 639           several errors. If a signed message is sent to a non-TSIG aware
 640           server, a FORMERR (format error) will be returned, since the server will not
 641           understand the record. This is a result of misconfiguration,
 642           since the server must be explicitly configured to send a TSIG
 643           signed message to a specific server.
 644         </p>
 645 <p>
 646           If a TSIG aware server receives a message signed by an
 647           unknown key, the response will be unsigned with the TSIG
 648           extended error code set to BADKEY. If a TSIG aware server
 649           receives a message with a signature that does not validate, the
 650           response will be unsigned with the TSIG extended error code set
 651           to BADSIG. If a TSIG aware server receives a message with a time
 652           outside of the allowed range, the response will be signed with
 653           the TSIG extended error code set to BADTIME, and the time values
 654           will be adjusted so that the response can be successfully
 655           verified. In any of these cases, the message's rcode (response code) is set to
 656           NOTAUTH (not authenticated).
 657         </p>
 658 </div>
 659 </div>
 660 <div class="sect1" lang="en">
 661 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 662 <a name="id2571459"></a>TKEY</h2></div></div></div>
 663 <p><span><strong class="command">TKEY</strong></span>
 664         is a mechanism for automatically generating a shared secret
 665         between two hosts.  There are several "modes" of
 666         <span><strong class="command">TKEY</strong></span> that specify how the key is generated
 667         or assigned.  <acronym class="acronym">BIND</acronym> 9 implements only one of
 668         these modes, the Diffie-Hellman key exchange.  Both hosts are
 669         required to have a Diffie-Hellman KEY record (although this
 670         record is not required to be present in a zone).  The
 671         <span><strong class="command">TKEY</strong></span> process must use signed messages,
 672         signed either by TSIG or SIG(0).  The result of
 673         <span><strong class="command">TKEY</strong></span> is a shared secret that can be used to
 674         sign messages with TSIG.  <span><strong class="command">TKEY</strong></span> can also be
 675         used to delete shared secrets that it had previously
 676         generated.
 677       </p>
 678 <p>
 679         The <span><strong class="command">TKEY</strong></span> process is initiated by a
 680         client
 681         or server by sending a signed <span><strong class="command">TKEY</strong></span>
 682         query
 683         (including any appropriate KEYs) to a TKEY-aware server.  The
 684         server response, if it indicates success, will contain a
 685         <span><strong class="command">TKEY</strong></span> record and any appropriate keys.
 686         After
 687         this exchange, both participants have enough information to
 688         determine the shared secret; the exact process depends on the
 689         <span><strong class="command">TKEY</strong></span> mode.  When using the
 690         Diffie-Hellman
 691         <span><strong class="command">TKEY</strong></span> mode, Diffie-Hellman keys are
 692         exchanged,
 693         and the shared secret is derived by both participants.
 694       </p>
 695 </div>
 696 <div class="sect1" lang="en">
 697 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 698 <a name="id2571576"></a>SIG(0)</h2></div></div></div>
 699 <p>
 700         <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
 701             transaction signatures as specified in RFC 2535 and RFC 2931.
 702         SIG(0)
 703         uses public/private keys to authenticate messages.  Access control
 704         is performed in the same manner as TSIG keys; privileges can be
 705         granted or denied based on the key name.
 706       </p>
 707 <p>
 708         When a SIG(0) signed message is received, it will only be
 709         verified if the key is known and trusted by the server; the server
 710         will not attempt to locate and/or validate the key.
 711       </p>
 712 <p>
 713         SIG(0) signing of multiple-message TCP streams is not
 714         supported.
 715       </p>
 716 <p>
 717         The only tool shipped with <acronym class="acronym">BIND</acronym> 9 that
 718         generates SIG(0) signed messages is <span><strong class="command">nsupdate</strong></span>.
 719       </p>
 720 </div>
 721 <div class="sect1" lang="en">
 722 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 723 <a name="DNSSEC"></a>DNSSEC</h2></div></div></div>
 724 <p>
 725         Cryptographic authentication of DNS information is possible
 726         through the DNS Security (<span class="emphasis"><em>DNSSEC-bis</em></span>) extensions,
 727         defined in RFC 4033, RFC 4034, and RFC 4035.
 728         This section describes the creation and use of DNSSEC signed zones.
 729       </p>
 730 <p>
 731         In order to set up a DNSSEC secure zone, there are a series
 732         of steps which must be followed.  <acronym class="acronym">BIND</acronym>
 733         9 ships
 734         with several tools
 735         that are used in this process, which are explained in more detail
 736         below.  In all cases, the <code class="option">-h</code> option prints a
 737         full list of parameters.  Note that the DNSSEC tools require the
 738         keyset files to be in the working directory or the
 739         directory specified by the <code class="option">-d</code> option, and
 740         that the tools shipped with BIND 9.2.x and earlier are not compatible
 741         with the current ones.
 742       </p>
 743 <p>
 744         There must also be communication with the administrators of
 745         the parent and/or child zone to transmit keys.  A zone's security
 746         status must be indicated by the parent zone for a DNSSEC capable
 747         resolver to trust its data.  This is done through the presence
 748         or absence of a <code class="literal">DS</code> record at the
 749         delegation
 750         point.
 751       </p>
 752 <p>
 753         For other servers to trust data in this zone, they must
 754         either be statically configured with this zone's zone key or the
 755         zone key of another zone above this one in the DNS tree.
 756       </p>
 757 <div class="sect2" lang="en">
 758 <div class="titlepage"><div><div><h3 class="title">
 759 <a name="id2571644"></a>Generating Keys</h3></div></div></div>
 760 <p>
 761           The <span><strong class="command">dnssec-keygen</strong></span> program is used to
 762           generate keys.
 763         </p>
 764 <p>
 765           A secure zone must contain one or more zone keys.  The
 766           zone keys will sign all other records in the zone, as well as
 767           the zone keys of any secure delegated zones.  Zone keys must
 768           have the same name as the zone, a name type of
 769           <span><strong class="command">ZONE</strong></span>, and must be usable for
 770           authentication.
 771           It is recommended that zone keys use a cryptographic algorithm
 772           designated as "mandatory to implement" by the IETF; currently
 773           the only one is RSASHA1.
 774         </p>
 775 <p>
 776           The following command will generate a 768-bit RSASHA1 key for
 777           the <code class="filename">child.example</code> zone:
 778         </p>
 779 <p>
 780           <strong class="userinput"><code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</code></strong>
 781         </p>
 782 <p>
 783           Two output files will be produced:
 784           <code class="filename">Kchild.example.+005+12345.key</code> and
 785           <code class="filename">Kchild.example.+005+12345.private</code>
 786           (where
 787           12345 is an example of a key tag).  The key filenames contain
 788           the key name (<code class="filename">child.example.</code>),
 789           algorithm (3
 790           is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
 791           this case).
 792           The private key (in the <code class="filename">.private</code>
 793           file) is
 794           used to generate signatures, and the public key (in the
 795           <code class="filename">.key</code> file) is used for signature
 796           verification.
 797         </p>
 798 <p>
 799           To generate another key with the same properties (but with
 800           a different key tag), repeat the above command.
 801         </p>
 802 <p>
 803           The <span><strong class="command">dnssec-keyfromlabel</strong></span> program is used
 804           to get a key pair from a crypto hardware and build the key
 805           files. Its usage is similar to <span><strong class="command">dnssec-keygen</strong></span>.
 806         </p>
 807 <p>
 808           The public keys should be inserted into the zone file by
 809           including the <code class="filename">.key</code> files using
 810           <span><strong class="command">$INCLUDE</strong></span> statements.
 811         </p>
 812 </div>
 813 <div class="sect2" lang="en">
 814 <div class="titlepage"><div><div><h3 class="title">
 815 <a name="id2571792"></a>Signing the Zone</h3></div></div></div>
 816 <p>
 817           The <span><strong class="command">dnssec-signzone</strong></span> program is used
 818           to sign a zone.
 819         </p>
 820 <p>
 821           Any <code class="filename">keyset</code> files corresponding to
 822           secure subzones should be present.  The zone signer will
 823           generate <code class="literal">NSEC</code>, <code class="literal">NSEC3</code>
 824           and <code class="literal">RRSIG</code> records for the zone, as
 825           well as <code class="literal">DS</code> for the child zones if
 826           <code class="literal">'-g'</code> is specified.  If <code class="literal">'-g'</code>
 827           is not specified, then DS RRsets for the secure child
 828           zones need to be added manually.
 829         </p>
 830 <p>
 831           The following command signs the zone, assuming it is in a
 832           file called <code class="filename">zone.child.example</code>.  By
 833                 default, all zone keys which have an available private key are
 834                 used to generate signatures.
 835         </p>
 836 <p>
 837           <strong class="userinput"><code>dnssec-signzone -o child.example zone.child.example</code></strong>
 838         </p>
 839 <p>
 840           One output file is produced:
 841           <code class="filename">zone.child.example.signed</code>.  This
 842           file
 843           should be referenced by <code class="filename">named.conf</code>
 844           as the
 845           input file for the zone.
 846         </p>
 847 <p><span><strong class="command">dnssec-signzone</strong></span>
 848           will also produce a keyset and dsset files and optionally a
 849           dlvset file.  These are used to provide the parent zone
 850           administrators with the <code class="literal">DNSKEYs</code> (or their
 851           corresponding <code class="literal">DS</code> records) that are the
 852           secure entry point to the zone.
 853         </p>
 854 </div>
 855 <div class="sect2" lang="en">
 856 <div class="titlepage"><div><div><h3 class="title">
 857 <a name="id2571873"></a>Configuring Servers</h3></div></div></div>
 858 <p>
 859           To enable <span><strong class="command">named</strong></span> to respond appropriately
 860           to DNS requests from DNSSEC aware clients,
 861           <span><strong class="command">dnssec-enable</strong></span> must be set to yes.
 862           (This is the default setting.)
 863         </p>
 864 <p>
 865           To enable <span><strong class="command">named</strong></span> to validate answers from
 866           other servers, the <span><strong class="command">dnssec-enable</strong></span> and
 867           <span><strong class="command">dnssec-validation</strong></span> options must both be
 868           set to yes (the default setting in <acronym class="acronym">BIND</acronym> 9.5
 869           and later), and at least one trust anchor must be configured
 870           with a <span><strong class="command">trusted-keys</strong></span> statement in
 871           <code class="filename">named.conf</code>.
 872         </p>
 873 <p>
 874           <span><strong class="command">trusted-keys</strong></span> are copies of DNSKEY RRs
 875           for zones that are used to form the first link in the
 876           cryptographic chain of trust.  All keys listed in
 877           <span><strong class="command">trusted-keys</strong></span> (and corresponding zones)
 878           are deemed to exist and only the listed keys will be used
 879           to validated the DNSKEY RRset that they are from.
 880         </p>
 881 <p>
 882           <span><strong class="command">trusted-keys</strong></span> are described in more detail
 883           later in this document.
 884         </p>
 885 <p>
 886           Unlike <acronym class="acronym">BIND</acronym> 8, <acronym class="acronym">BIND</acronym>
 887           9 does not verify signatures on load, so zone keys for
 888           authoritative zones do not need to be specified in the
 889           configuration file.
 890         </p>
 891 <p>
 892           After DNSSEC gets established, a typical DNSSEC configuration
 893           will look something like the following.  It has a one or
 894           more public keys for the root.  This allows answers from
 895           outside the organization to be validated.  It will also
 896           have several keys for parts of the namespace the organization
 897           controls.  These are here to ensure that <span><strong class="command">named</strong></span> is immune
 898           to compromises in the DNSSEC components of the security
 899           of parent zones.
 900         </p>
 901 <pre class="programlisting">
 902 trusted-keys {
 903
 904         /* Root Key */
 905 "." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwSJxrGkxJWoZu6I7PzJu/
 906              E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3
 907              zy2Xy4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYghf+6fElrmLkdaz
 908              MQ2OCnACR817DF4BBa7UR/beDHyp5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M
 909              /lUUVRbkeg1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq66gKodQj+M
 910              iA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ97S+LKUTpQcq27R7AT3/V5hRQxScI
 911              Nqwcz4jYqZD2fQdgxbcDTClU0CRBdiieyLMNzXG3";
 912
 913 /* Key for our organization's forward zone */
 914 example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe
 915                       3Y9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbb
 916                       OTcM8pwXlj0EiX3oDFVmjHO444gLkBO UKUf/mC7HvfwYH/Be22GnC
 917                       lrinKJp1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt
 918                       8lgnyTUHs1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/b
 919                       iuvF4qJCyduieHukuY3H4XMAcR+xia2 nIUPvm/oyWR8BW/hWdzOvn
 920                       SCThlHf3xiYleDbt/o1OTQ09A0=";
 921
 922 /* Key for our reverse zone. */
 923 2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwcxOdNax071L18QqZnQQQA
 924                                 VVr+iLhGTnNGp3HoWQLUIzKrJVZ3zggy3WwNT6kZo6c0
 925                                 tszYqbtvchmgQC8CzKojM/W16i6MG/ea fGU3siaOdS0
 926                                 yOI6BgPsw+YZdzlYMaIJGf4M4dyoKIhzdZyQ2bYQrjyQ
 927                                 4LB0lC7aOnsMyYKHHYeRv PxjIQXmdqgOJGq+vsevG06
 928                                 zW+1xgYJh9rCIfnm1GX/KMgxLPG2vXTD/RnLX+D3T3UL
 929                                 7HJYHJhAZD5L59VvjSPsZJHeDCUyWYrvPZesZDIRvhDD
 930                                 52SKvbheeTJUm6EhkzytNN2SN96QRk8j/iI8ib";
 931 };
 932
 933 options {
 934         ...
 935         dnssec-enable yes;
 936         dnssec-validation yes;
 937 };
 938 </pre>
 939 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 940 <h3 class="title">Note</h3>
 941           None of the keys listed in this example are valid.  In particular,
 942           the root key is not valid.
 943         </div>
 944 <p>
 945           When DNSSEC validation is enabled and properly configured,
 946           the resolver will reject any answers from signed, secure zones
 947           which fail to validate, and will return SERVFAIL to the client.
 948         </p>
 949 <p>
 950           Responses may fail to validate for any of several reasons,
 951           including missing, expired, or invalid signatures, a key which
 952           does not match the DS RRset in the parent zone, or an insecure
 953           response from a zone which, according to its parent, should have
 954           been secure.
 955         </p>
 956 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 957 <h3 class="title">Note</h3>
 958 <p>
 959             When the validator receives a response from an unsigned zone
 960             that has a signed parent, it must confirm with the parent
 961             that the zone was intentionally left unsigned.  It does
 962             this by verifying, via signed and validated NSEC/NSEC3 records,
 963             that the parent zone contains no DS records for the child.
 964           </p>
 965 <p>
 966             If the validator <span class="emphasis"><em>can</em></span> prove that the zone
 967             is insecure, then the response is accepted.  However, if it
 968             cannot, then it must assume an insecure response to be a
 969             forgery; it rejects the response and logs an error.
 970           </p>
 971 <p>
 972             The logged error reads "insecurity proof failed" and
 973             "got insecure response; parent indicates it should be secure".
 974             (Prior to BIND 9.7, the logged error was "not insecure".
 975             This referred to the zone, not the response.)
 976           </p>
 977 </div>
 978 </div>
 979 </div>
 980 <div class="sect1" lang="en">
 981 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 982 <a name="id2572110"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
 983 <p>
 984         <acronym class="acronym">BIND</acronym> 9 fully supports all currently
 985         defined forms of IPv6 name to address and address to name
 986         lookups.  It will also use IPv6 addresses to make queries when
 987         running on an IPv6 capable system.
 988       </p>
 989 <p>
 990         For forward lookups, <acronym class="acronym">BIND</acronym> 9 supports
 991         only AAAA records.  RFC 3363 deprecated the use of A6 records,
 992         and client-side support for A6 records was accordingly removed
 993         from <acronym class="acronym">BIND</acronym> 9.
 994         However, authoritative <acronym class="acronym">BIND</acronym> 9 name servers still
 995         load zone files containing A6 records correctly, answer queries
 996         for A6 records, and accept zone transfer for a zone containing A6
 997         records.
 998       </p>
 999 <p>
1000         For IPv6 reverse lookups, <acronym class="acronym">BIND</acronym> 9 supports
1001         the traditional "nibble" format used in the
1002         <span class="emphasis"><em>ip6.arpa</em></span> domain, as well as the older, deprecated
1003         <span class="emphasis"><em>ip6.int</em></span> domain.
1004         Older versions of <acronym class="acronym">BIND</acronym> 9
1005         supported the "binary label" (also known as "bitstring") format,
1006         but support of binary labels has been completely removed per
1007         RFC 3363.
1008         Many applications in <acronym class="acronym">BIND</acronym> 9 do not understand
1009         the binary label format at all any more, and will return an
1010         error if given.
1011         In particular, an authoritative <acronym class="acronym">BIND</acronym> 9
1012         name server will not load a zone file containing binary labels.
1013       </p>
1014 <p>
1015         For an overview of the format and structure of IPv6 addresses,
1016         see <a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (AAAA)">the section called &#8220;IPv6 addresses (AAAA)&#8221;</a>.
1017       </p>
1018 <div class="sect2" lang="en">
1019 <div class="titlepage"><div><div><h3 class="title">
1020 <a name="id2572172"></a>Address Lookups Using AAAA Records</h3></div></div></div>
1021 <p>
1022           The IPv6 AAAA record is a parallel to the IPv4 A record,
1023           and, unlike the deprecated A6 record, specifies the entire
1024           IPv6 address in a single record.  For example,
1025         </p>
1026 <pre class="programlisting">
1027 $ORIGIN example.com.
1028 host            3600    IN      AAAA    2001:db8::1
1029 </pre>
1030 <p>
1031           Use of IPv4-in-IPv6 mapped addresses is not recommended.
1032           If a host has an IPv4 address, use an A record, not
1033           a AAAA, with <code class="literal">::ffff:192.168.42.1</code> as
1034           the address.
1035         </p>
1036 </div>
1037 <div class="sect2" lang="en">
1038 <div class="titlepage"><div><div><h3 class="title">
1039 <a name="id2572194"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
1040 <p>
1041           When looking up an address in nibble format, the address
1042           components are simply reversed, just as in IPv4, and
1043           <code class="literal">ip6.arpa.</code> is appended to the
1044           resulting name.
1045           For example, the following would provide reverse name lookup for
1046           a host with address
1047           <code class="literal">2001:db8::1</code>.
1048         </p>
1049 <pre class="programlisting">
1050 $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1051 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
1052 </pre>
1053 </div>
1054 </div>
1055 </div>
1056 <div class="navfooter">
1057 <hr>
1058 <table width="100%" summary="Navigation footer">
1059 <tr>
1060 <td width="40%" align="left">
1061 <a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
1062 <td width="20%" align="center"> </td>
1063 <td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
1064 </td>
1065 </tr>
1066 <tr>
1067 <td width="40%" align="left" valign="top">Chapter 3. Name Server Configuration </td>
1068 <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
1069 <td width="40%" align="right" valign="top"> Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</td>
1070 </tr>
1071 </table>
1072 </div>
1073 </body>
1074 </html>