Bv9ARM.ch04.html 47.9 KB
Newer Older
Rob Austein's avatar
regen  
Rob Austein committed
1
<!--
Mark Andrews's avatar
regen  
Mark Andrews committed
2
 - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
Mark Andrews's avatar
regen  
Mark Andrews committed
3
 - Copyright (C) 2000-2003 Internet Software Consortium.
Rob Austein's avatar
regen  
Rob Austein committed
4 5 6 7 8 9 10 11 12 13 14 15 16
 - 
 - 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.
-->
Mark Andrews's avatar
regen  
Mark Andrews committed
17
<!-- $Id: Bv9ARM.ch04.html,v 1.76 2007/05/16 06:12:01 marka Exp $ -->
Rob Austein's avatar
regen  
Rob Austein committed
18 19 20 21
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 4. Advanced DNS Features</title>
Mark Andrews's avatar
regen  
Mark Andrews committed
22
<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
Rob Austein's avatar
regen  
Rob Austein committed
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
<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>
Mark Andrews's avatar
regen  
Mark Andrews committed
52 53
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570658">Split DNS</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570676">Example split DNS setup</a></span></dt></dl></dd>
Rob Austein's avatar
regen  
Rob Austein committed
54 55
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
<dd><dl>
Mark Andrews's avatar
regen  
Mark Andrews committed
56 57 58 59 60 61
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571111">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571185">Copying the Shared Secret to Both Machines</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571264">Informing the Servers of the Key's Existence</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571303">Instructing the Server to Use the Key</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571429">TSIG Key Based Access Control</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571474">Errors</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
62
</dl></dd>
Mark Andrews's avatar
regen  
Mark Andrews committed
63 64
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571488">TKEY</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571673">SIG(0)</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
65 66
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
<dd><dl>
Mark Andrews's avatar
regen  
Mark Andrews committed
67 68 69
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571741">Generating Keys</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571811">Signing the Zone</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571890">Configuring Servers</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
70
</dl></dd>
Mark Andrews's avatar
regen  
Mark Andrews committed
71
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572033">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
72
<dd><dl>
Mark Andrews's avatar
regen  
Mark Andrews committed
73 74
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572163">Address Lookups Using AAAA Records</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572184">Address to Name Lookups Using Nibble Format</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
75 76 77 78 79 80 81
</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>
Mark Andrews's avatar
regen  
Mark Andrews committed
82
        <acronym class="acronym">DNS</acronym> NOTIFY is a mechanism that allows master
Rob Austein's avatar
regen  
Rob Austein committed
83
        servers to notify their slave servers of changes to a zone's data. In
Mark Andrews's avatar
gregen  
Mark Andrews committed
84
        response to a <span><strong class="command">NOTIFY</strong></span> from a master server, the
Rob Austein's avatar
regen  
Rob Austein committed
85 86 87 88
        slave will check to see that its version of the zone is the
        current version and, if not, initiate a zone transfer.
      </p>
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
89
        For more information about <acronym class="acronym">DNS</acronym>
Rob Austein's avatar
regen  
Rob Austein committed
90 91 92 93 94 95
        <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 &#8220;Boolean Options&#8221;</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 &#8220;Zone Transfers&#8221;</a>.  The <span><strong class="command">NOTIFY</strong></span>
        protocol is specified in RFC 1996.
      </p>
Mark Andrews's avatar
gregen  
Mark Andrews committed
96 97
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Mark Andrews's avatar
regen  
Mark Andrews committed
98
        As a slave zone can also be a master to other slaves, named,
Mark Andrews's avatar
gregen  
Mark Andrews committed
99 100 101 102 103
        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>
Rob Austein's avatar
regen  
Rob Austein committed
104 105 106 107 108 109 110 111 112 113 114
</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>
Mark Andrews's avatar
regen  
Mark Andrews committed
115 116 117 118 119 120 121 122 123
        Dynamic update is enabled by including an
        <span><strong class="command">allow-update</strong></span> or <span><strong class="command">update-policy</strong></span>
        clause in the <span><strong class="command">zone</strong></span> statement.  The
        <span><strong class="command">tkey-gssapi-credential</strong></span> and
        <span><strong class="command">tkey-domain</strong></span> clauses in the
        <span><strong class="command">options</strong></span>        statement enable the
        server to negotiate keys that can be matched against those
        in <span><strong class="command">update-policy</strong></span> or
        <span><strong class="command">allow-update</strong></span>.
Rob Austein's avatar
regen  
Rob Austein committed
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166
      </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
Mark Andrews's avatar
regen  
Mark Andrews committed
167
          dynamic changes &#8212; those are only in the journal file.
Rob Austein's avatar
regen  
Rob Austein committed
168 169 170 171 172 173 174 175 176 177
          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
Mark Andrews's avatar
gregen  
Mark Andrews committed
178
          <span><strong class="command">rndc thaw <em class="replaceable"><code>zone</code></em></strong></span>
Rob Austein's avatar
regen  
Rob Austein committed
179 180 181 182 183 184 185 186 187 188 189 190 191 192
          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>
Mark Andrews's avatar
regen  
Mark Andrews committed
193
        When acting as a master, <acronym class="acronym">BIND</acronym> 9
Rob Austein's avatar
regen  
Rob Austein committed
194 195 196 197 198 199 200 201 202 203
        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>
Mark Andrews's avatar
regen  
Mark Andrews committed
204
        When acting as a slave, <acronym class="acronym">BIND</acronym> 9 will
Rob Austein's avatar
regen  
Rob Austein committed
205 206 207 208 209 210 211 212
        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">
Mark Andrews's avatar
regen  
Mark Andrews committed
213
<a name="id2570658"></a>Split DNS</h2></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
214 215
<p>
        Setting up different views, or visibility, of the DNS space to
Mark Andrews's avatar
gregen  
Mark Andrews committed
216 217 218
        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.
Rob Austein's avatar
regen  
Rob Austein committed
219 220 221 222 223 224 225 226 227
      </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.
Mark Andrews's avatar
gregen  
Mark Andrews committed
228 229 230
        However, since listing addresses of internal servers that
        external clients cannot possibly reach can result in
        connection delays and other annoyances, an organization may
Mark Andrews's avatar
regen  
Mark Andrews committed
231
        choose to use a Split DNS to present a consistent view of itself
Mark Andrews's avatar
gregen  
Mark Andrews committed
232
        to the outside world.
Rob Austein's avatar
regen  
Rob Austein committed
233 234 235 236 237 238 239 240
      </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>
Mark Andrews's avatar
regen  
Mark Andrews committed
241 242
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
Mark Andrews's avatar
regen  
Mark Andrews committed
243
<a name="id2570676"></a>Example split DNS setup</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336
<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>
Mark Andrews's avatar
regen  
Mark Andrews committed
337
<li>Exchange mail with both internal and external people.</li>
Rob Austein's avatar
regen  
Rob Austein committed
338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355
</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;
Mark Andrews's avatar
regen  
Mark Andrews committed
356
        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>.
Rob Austein's avatar
regen  
Rob Austein committed
357 358 359 360 361 362
      </p>
<p>
        Internal DNS server config:
      </p>
<pre class="programlisting">

363 364
acl internals { 172.16.72.0/24; 192.168.1.0/24; };

Rob Austein's avatar
regen  
Rob Austein committed
365
acl externals { <code class="varname">bastion-ips-go-here</code>; };
366

367 368 369 370
options {
    ...
    ...
    forward only;
Andreas Gustafsson's avatar
Andreas Gustafsson committed
371
    forwarders {                                // forward to external servers
Mark Andrews's avatar
gregen  
Mark Andrews committed
372
        <code class="varname">bastion-ips-go-here</code>;
373
    };
Andreas Gustafsson's avatar
Andreas Gustafsson committed
374 375 376
    allow-transfer { none; };                   // sample allow-transfer (no one)
    allow-query { internals; externals; };      // restrict query access
    allow-recursion { internals; };             // restrict recursion
377 378 379
    ...
    ...
};
380

Andreas Gustafsson's avatar
Andreas Gustafsson committed
381
zone "site1.example.com" {                      // sample master zone
382 383
  type master;
  file "m/site1.example.com";
Andreas Gustafsson's avatar
Andreas Gustafsson committed
384 385
  forwarders { };                               // do normal iterative
                                                // resolution (do not forward)
386 387 388
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
389

Andreas Gustafsson's avatar
Andreas Gustafsson committed
390
zone "site2.example.com" {                      // sample slave zone
391 392 393 394 395 396 397
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
398

399 400 401 402 403 404 405
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};
406

407 408 409 410 411 412 413 414
zone "site2.internal" {
  type slave;
  file "s/site2.internal";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals };
  allow-transfer { internals; }
};
Rob Austein's avatar
regen  
Rob Austein committed
415 416 417 418 419 420
</pre>
<p>
        External (bastion host) DNS server config:
      </p>
<pre class="programlisting">
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
421

422
acl externals { bastion-ips-go-here; };
423

424 425 426
options {
  ...
  ...
Andreas Gustafsson's avatar
Andreas Gustafsson committed
427
  allow-transfer { none; };                     // sample allow-transfer (no one)
Mark Andrews's avatar
gregen  
Mark Andrews committed
428
  allow-query { any; };                         // default query access
Mark Andrews's avatar
regen  
Mark Andrews committed
429
  allow-query-cache { internals; externals; };  // restrict cache access
Andreas Gustafsson's avatar
Andreas Gustafsson committed
430
  allow-recursion { internals; externals; };    // restrict recursion
431 432 433
  ...
  ...
};
434

Andreas Gustafsson's avatar
Andreas Gustafsson committed
435
zone "site1.example.com" {                      // sample slave zone
436 437 438 439
  type master;
  file "m/site1.foo.com";
  allow-transfer { internals; externals; };
};
440

441 442 443 444 445 446
zone "site2.example.com" {
  type slave;
  file "s/site2.foo.com";
  masters { another_bastion_host_maybe; };
  allow-transfer { internals; externals; }
};
Rob Austein's avatar
regen  
Rob Austein committed
447 448 449 450 451 452 453
</pre>
<p>
        In the <code class="filename">resolv.conf</code> (or equivalent) on
        the bastion host(s):
      </p>
<pre class="programlisting">
search ...
454 455 456
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4
Rob Austein's avatar
regen  
Rob Austein committed
457 458
</pre>
</div>
Mark Andrews's avatar
regen  
Mark Andrews committed
459
</div>
Rob Austein's avatar
regen  
Rob Austein committed
460 461 462 463 464
<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
Mark Andrews's avatar
regen  
Mark Andrews committed
465
        (TSIG) based transaction security in <acronym class="acronym">BIND</acronym>. It describes changes
Rob Austein's avatar
regen  
Rob Austein committed
466 467
        to the configuration file as well as what changes are required for
        different features, including the process of creating transaction
Mark Andrews's avatar
regen  
Mark Andrews committed
468
        keys and using transaction signatures with <acronym class="acronym">BIND</acronym>.
Rob Austein's avatar
regen  
Rob Austein committed
469 470
      </p>
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
471
        <acronym class="acronym">BIND</acronym> primarily supports TSIG for server
Rob Austein's avatar
regen  
Rob Austein committed
472 473
        to server communication.
        This includes zone transfer, notify, and recursive query messages.
Mark Andrews's avatar
regen  
Mark Andrews committed
474
        Resolvers based on newer versions of <acronym class="acronym">BIND</acronym> 8 have limited support
Rob Austein's avatar
regen  
Rob Austein committed
475 476 477
        for TSIG.
      </p>
<p>
Mark Andrews's avatar
gregen  
Mark Andrews committed
478 479 480
        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.
Rob Austein's avatar
regen  
Rob Austein committed
481 482 483
        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
Mark Andrews's avatar
gregen  
Mark Andrews committed
484 485
        <code class="option">-y</code> command line options or inline by use
        of the <span><strong class="command">key</strong></span>.
Rob Austein's avatar
regen  
Rob Austein committed
486 487 488
      </p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
Mark Andrews's avatar
regen  
Mark Andrews committed
489
<a name="id2571111"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
490 491 492 493 494 495 496
<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">
Mark Andrews's avatar
regen  
Mark Andrews committed
497
<a name="id2571128"></a>Automatic Generation</h4></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
498
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
499
            The following command will generate a 128-bit (16 byte) HMAC-MD5
Rob Austein's avatar
regen  
Rob Austein committed
500 501
            key as described above. Longer keys are better, but shorter keys
            are easier to read. Note that the maximum key length is 512 bits;
Mark Andrews's avatar
regen  
Mark Andrews committed
502 503
            keys longer than that will be digested with MD5 to produce a
            128-bit key.
Rob Austein's avatar
regen  
Rob Austein committed
504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521
          </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">
Mark Andrews's avatar
regen  
Mark Andrews committed
522
<a name="id2571166"></a>Manual Generation</h4></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
523 524 525 526 527 528 529 530 531 532 533 534 535 536
<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">
Mark Andrews's avatar
regen  
Mark Andrews committed
537
<a name="id2571185"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
538 539 540 541 542 543 544
<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">
Mark Andrews's avatar
regen  
Mark Andrews committed
545
<a name="id2571264"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
546 547 548 549 550 551 552
<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. {
553 554 555
  algorithm hmac-md5;
  secret "La/E5CjG9O+os1jq0a2jdA==";
};
Rob Austein's avatar
regen  
Rob Austein committed
556 557
</pre>
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
558
          The algorithm, hmac-md5, is the only one supported by <acronym class="acronym">BIND</acronym>.
Rob Austein's avatar
regen  
Rob Austein committed
559 560 561 562 563 564 565 566 567 568 569 570 571 572 573
          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">
Mark Andrews's avatar
regen  
Mark Andrews committed
574
<a name="id2571303"></a>Instructing the Server to Use the Key</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
575 576 577 578 579 580 581 582
<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 {
583 584
  keys { host1-host2. ;};
};
Rob Austein's avatar
regen  
Rob Austein committed
585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605
</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">
Mark Andrews's avatar
regen  
Mark Andrews committed
606
<a name="id2571429"></a>TSIG Key Based Access Control</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
607
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
608
          <acronym class="acronym">BIND</acronym> allows IP addresses and ranges
Rob Austein's avatar
regen  
Rob Austein committed
609 610 611 612 613 614 615 616 617 618 619 620 621 622 623
          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
Mark Andrews's avatar
regen  
Mark Andrews committed
624
          was signed by a key named "<span><strong class="command">host1-host2.</strong></span>".
Rob Austein's avatar
regen  
Rob Austein committed
625 626
        </p>
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
627 628 629
          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 &#8220;Dynamic Update Policies&#8221;</a>.
Rob Austein's avatar
regen  
Rob Austein committed
630 631 632 633
        </p>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
Mark Andrews's avatar
regen  
Mark Andrews committed
634
<a name="id2571474"></a>Errors</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
635 636 637
<p>
          The processing of TSIG signed messages can result in
          several errors. If a signed message is sent to a non-TSIG aware
Mark Andrews's avatar
regen  
Mark Andrews committed
638
          server, a FORMERR (format error) will be returned, since the server will not
Rob Austein's avatar
regen  
Rob Austein committed
639 640 641 642 643 644 645 646 647 648 649 650 651 652
          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
Mark Andrews's avatar
regen  
Mark Andrews committed
653
          verified. In any of these cases, the message's rcode (response code) is set to
Mark Andrews's avatar
regen  
Mark Andrews committed
654
          NOTAUTH (not authenticated).
Rob Austein's avatar
regen  
Rob Austein committed
655 656 657 658 659
        </p>
</div>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
Mark Andrews's avatar
regen  
Mark Andrews committed
660
<a name="id2571488"></a>TKEY</h2></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
661 662 663 664
<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
Mark Andrews's avatar
regen  
Mark Andrews committed
665
        or assigned.  <acronym class="acronym">BIND</acronym> 9 implements only one of
Rob Austein's avatar
regen  
Rob Austein committed
666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695
        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">
Mark Andrews's avatar
regen  
Mark Andrews committed
696
<a name="id2571673"></a>SIG(0)</h2></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
697
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
698
        <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
Rob Austein's avatar
regen  
Rob Austein committed
699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714
            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>
Mark Andrews's avatar
regen  
Mark Andrews committed
715
        The only tool shipped with <acronym class="acronym">BIND</acronym> 9 that
Rob Austein's avatar
regen  
Rob Austein committed
716 717 718 719 720 721 722 723 724
        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,
Mark Andrews's avatar
regen  
Mark Andrews committed
725
        defined in RFC 4033, RFC 4034, and RFC 4035.
Mark Andrews's avatar
gregen  
Mark Andrews committed
726
        This section describes the creation and use of DNSSEC signed zones.
Rob Austein's avatar
regen  
Rob Austein committed
727 728 729
      </p>
<p>
        In order to set up a DNSSEC secure zone, there are a series
Mark Andrews's avatar
regen  
Mark Andrews committed
730
        of steps which must be followed.  <acronym class="acronym">BIND</acronym>
Rob Austein's avatar
regen  
Rob Austein committed
731 732 733 734 735 736
        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
Mark Andrews's avatar
gregen  
Mark Andrews committed
737
        directory specified by the <code class="option">-d</code> option, and
Rob Austein's avatar
regen  
Rob Austein committed
738 739 740 741 742 743 744
        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
Mark Andrews's avatar
regen  
Mark Andrews committed
745
        resolver to trust its data.  This is done through the presence
Rob Austein's avatar
regen  
Rob Austein committed
746 747 748 749 750 751 752 753 754 755 756
        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">
Mark Andrews's avatar
regen  
Mark Andrews committed
757
<a name="id2571741"></a>Generating Keys</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773
<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>
Mark Andrews's avatar
regen  
Mark Andrews committed
774
          The following command will generate a 768-bit RSASHA1 key for
Rob Austein's avatar
regen  
Rob Austein committed
775 776 777 778 779 780 781 782 783 784
          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
Mark Andrews's avatar
regen  
Mark Andrews committed
785
          12345 is an example of a key tag).  The key filenames contain
Rob Austein's avatar
regen  
Rob Austein committed
786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807
          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">
Mark Andrews's avatar
regen  
Mark Andrews committed
808
<a name="id2571811"></a>Signing the Zone</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
809 810 811 812 813 814 815 816 817 818 819 820
<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.
Mark Andrews's avatar
regen  
Mark Andrews committed
821
                If <code class="literal">'-d'</code> is not specified, then
Rob Austein's avatar
regen  
Rob Austein committed
822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842
          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>
Mark Andrews's avatar
gregen  
Mark Andrews committed
843
          will also produce a keyset and dsset files and optionally a
Rob Austein's avatar
regen  
Rob Austein committed
844
          dlvset file.  These are used to provide the parent zone
Mark Andrews's avatar
regen  
Mark Andrews committed
845
          administrators with the <code class="literal">DNSKEYs</code> (or their
Rob Austein's avatar
regen  
Rob Austein committed
846 847 848 849 850 851
          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">
Mark Andrews's avatar
regen  
Mark Andrews committed
852
<a name="id2571890"></a>Configuring Servers</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
853
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
854
          To enable <span><strong class="command">named</strong></span> to respond appropriately
Mark Andrews's avatar
regen  
Mark Andrews committed
855
          to DNS requests from DNSSEC aware clients,
Mark Andrews's avatar
regen  
Mark Andrews committed
856
          <span><strong class="command">dnssec-enable</strong></span> must be set to yes.
Rob Austein's avatar
regen  
Rob Austein committed
857 858
        </p>
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
859 860 861
          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-validate</strong></span> must be set and some
Mark Andrews's avatar
regen  
Mark Andrews committed
862
          <span><strong class="command">trusted-keys</strong></span> must be configured
Mark Andrews's avatar
regen  
Mark Andrews committed
863
          into <code class="filename">named.conf</code>.
Rob Austein's avatar
regen  
Rob Austein committed
864
        </p>
Mark Andrews's avatar
regen  
Mark Andrews committed
865 866
<p>
          <span><strong class="command">trusted-keys</strong></span> are copies of DNSKEY RRs
Mark Andrews's avatar
regen  
Mark Andrews committed
867
          for zones that are used to form the first link in the
Mark Andrews's avatar
regen  
Mark Andrews committed
868 869 870 871 872 873 874 875 876 877
          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>
Mark Andrews's avatar
regen  
Mark Andrews committed
878
          Unlike <acronym class="acronym">BIND</acronym> 8, <acronym class="acronym">BIND</acronym>
Mark Andrews's avatar
regen  
Mark Andrews committed
879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904
          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";

Mark Andrews's avatar
regen  
Mark Andrews committed
905
/* Key for our organization's forward zone */
Mark Andrews's avatar
regen  
Mark Andrews committed
906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932
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>
Mark Andrews's avatar
regen  
Mark Andrews committed
933
          None of the keys listed in this example are valid.  In particular,
Mark Andrews's avatar
regen  
Mark Andrews committed
934 935
          the root key is not valid.
        </div>
Rob Austein's avatar
regen  
Rob Austein committed
936 937 938 939
</div>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
Mark Andrews's avatar
regen  
Mark Andrews committed
940
<a name="id2572033"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
941
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
942
        <acronym class="acronym">BIND</acronym> 9 fully supports all currently
Rob Austein's avatar
regen  
Rob Austein committed
943 944 945 946 947 948
        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>
Mark Andrews's avatar
regen  
Mark Andrews committed
949
        For forward lookups, <acronym class="acronym">BIND</acronym> 9 supports
Mark Andrews's avatar
gregen  
Mark Andrews committed
950 951
        only AAAA records.  RFC 3363 deprecated the use of A6 records,
        and client-side support for A6 records was accordingly removed
Mark Andrews's avatar
regen  
Mark Andrews committed
952 953
        from <acronym class="acronym">BIND</acronym> 9.
        However, authoritative <acronym class="acronym">BIND</acronym> 9 name servers still
Rob Austein's avatar
regen  
Rob Austein committed
954 955 956 957 958
        load zone files containing A6 records correctly, answer queries
        for A6 records, and accept zone transfer for a zone containing A6
        records.
      </p>
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
959
        For IPv6 reverse lookups, <acronym class="acronym">BIND</acronym> 9 supports
Rob Austein's avatar
regen  
Rob Austein committed
960 961
        the traditional "nibble" format used in the
        <span class="emphasis"><em>ip6.arpa</em></span> domain, as well as the older, deprecated
Mark Andrews's avatar
gregen  
Mark Andrews committed
962
        <span class="emphasis"><em>ip6.int</em></span> domain.
Mark Andrews's avatar
regen  
Mark Andrews committed
963
        Older versions of <acronym class="acronym">BIND</acronym> 9 
Mark Andrews's avatar
gregen  
Mark Andrews committed
964 965 966
        supported the "binary label" (also known as "bitstring") format,
        but support of binary labels has been completely removed per
        RFC 3363.
Mark Andrews's avatar
regen  
Mark Andrews committed
967
        Many applications in <acronym class="acronym">BIND</acronym> 9 do not understand
Mark Andrews's avatar
gregen  
Mark Andrews committed
968 969
        the binary label format at all any more, and will return an
        error if given.
Mark Andrews's avatar
regen  
Mark Andrews committed
970
        In particular, an authoritative <acronym class="acronym">BIND</acronym> 9
Mark Andrews's avatar
gregen  
Mark Andrews committed
971
        name server will not load a zone file containing binary labels.
Rob Austein's avatar
regen  
Rob Austein committed
972 973 974 975 976 977 978
      </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 &#8220;IPv6 addresses (AAAA)&#8221;</a>.
      </p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
Mark Andrews's avatar
regen  
Mark Andrews committed
979
<a name="id2572163"></a>Address Lookups Using AAAA Records</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
980
<p>
Mark Andrews's avatar
gregen  
Mark Andrews committed
981 982 983
          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,
Rob Austein's avatar
regen  
Rob Austein committed
984 985 986
        </p>
<pre class="programlisting">
$ORIGIN example.com.
Mark Andrews's avatar
regen  
Mark Andrews committed
987
host            3600    IN      AAAA    2001:db8::1
Rob Austein's avatar
regen  
Rob Austein committed
988 989
</pre>
<p>
Mark Andrews's avatar
gregen  
Mark Andrews committed
990 991
          Use of IPv4-in-IPv6 mapped addresses is not recommended.
          If a host has an IPv4 address, use an A record, not
Rob Austein's avatar
regen  
Rob Austein committed
992
          a AAAA, with <code class="literal">::ffff:192.168.42.1</code> as
Mark Andrews's avatar
gregen  
Mark Andrews committed
993
          the address.
Rob Austein's avatar
regen  
Rob Austein committed
994 995 996 997
        </p>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
Mark Andrews's avatar
regen  
Mark Andrews committed
998
<a name="id2572184"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009
<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.
Mark Andrews's avatar
regen  
Mark Andrews committed
1010
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
Rob Austein's avatar
regen  
Rob Austein committed
1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027
</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>
Mark Andrews's avatar
regen  
Mark Andrews committed
1028
<td width="40%" align="right" valign="top"> Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</td>
Rob Austein's avatar
regen  
Rob Austein committed
1029 1030 1031 1032 1033
</tr>
</table>
</div>
</body>
</html>