Bv9ARM.ch04.html 130 KB
Newer Older
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Rob Austein's avatar
regen  
Rob Austein committed
2
<!--
Tinderbox User's avatar
Tinderbox User committed
3
 - Copyright (C) 2000-2020 Internet Systems Consortium, Inc. ("ISC")
Rob Austein's avatar
regen  
Rob Austein committed
4
 - 
Tinderbox User's avatar
Tinderbox User committed
5 6 7
 - This Source Code Form is subject to the terms of the Mozilla Public
 - License, v. 2.0. If a copy of the MPL was not distributed with this
 - file, You can obtain one at http://mozilla.org/MPL/2.0/.
Rob Austein's avatar
regen  
Rob Austein committed
8
-->
9
<html lang="en">
Rob Austein's avatar
regen  
Rob Austein committed
10 11 12
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter4.Advanced DNS Features</title>
Tinderbox User's avatar
Tinderbox User committed
13
<meta name="generator" content="DocBook XSL Stylesheets V1.78.1">
Evan Hunt's avatar
Evan Hunt committed
14
<link rel="home" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
Rob Austein's avatar
regen  
Rob Austein committed
15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="prev" href="Bv9ARM.ch03.html" title="Chapter3.Name Server Configuration">
<link rel="next" href="Bv9ARM.ch05.html" title="Chapter5.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">Chapter4.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>
Tinderbox User's avatar
Tinderbox User committed
33 34 35
<div class="chapter">
<div class="titlepage"><div><div><h1 class="title">
<a name="Bv9ARM.ch04"></a>Chapter4.Advanced DNS Features</h1></div></div></div>
Rob Austein's avatar
regen  
Rob Austein committed
36 37
<div class="toc">
<p><b>Table of Contents</b></p>
Tinderbox User's avatar
Tinderbox User committed
38
<dl class="toc">
Evan Hunt's avatar
Evan Hunt committed
39 40 41 42
<dt><span class="section"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
<dd><dl><dt><span class="section"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
<dt><span class="section"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
Tinderbox User's avatar
Tinderbox User committed
43 44
<dt><span class="section"><a href="Bv9ARM.ch04.html#split_dns">Split DNS</a></span></dt>
<dd><dl><dt><span class="section"><a href="Bv9ARM.ch04.html#split_dns_sample">Example split DNS setup</a></span></dt></dl></dd>
Evan Hunt's avatar
Evan Hunt committed
45
<dt><span class="section"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
46
<dd><dl>
Tinderbox User's avatar
Tinderbox User committed
47 48 49 50 51
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.6.5">Generating a Shared Key</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.6.6">Loading A New Key</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.6.7">Instructing the Server to Use a Key</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.6.8">TSIG-Based Access Control</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.6.9">Errors</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
52
</dl></dd>
Tinderbox User's avatar
Tinderbox User committed
53 54
<dt><span class="section"><a href="Bv9ARM.ch04.html#tkey">TKEY</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#sig0">SIG(0)</a></span></dt>
Evan Hunt's avatar
Evan Hunt committed
55
<dt><span class="section"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
56
<dd><dl>
Tinderbox User's avatar
Tinderbox User committed
57 58 59
<dt><span class="section"><a href="Bv9ARM.ch04.html#dnssec_keys">Generating Keys</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#dnssec_signing">Signing the Zone</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#dnssec_config">Configuring Servers</a></span></dt>
Automatic Updater's avatar
regen  
Automatic Updater committed
60
</dl></dd>
Evan Hunt's avatar
Evan Hunt committed
61
<dt><span class="section"><a href="Bv9ARM.ch04.html#dnssec.dynamic.zones">DNSSEC, Dynamic Zones, and Automatic Signing</a></span></dt>
Automatic Updater's avatar
Automatic Updater committed
62
<dd><dl>
Tinderbox User's avatar
Tinderbox User committed
63 64 65 66 67 68 69 70 71 72 73 74 75
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.2">Converting from insecure to secure</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.7">Dynamic DNS update method</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.15">Fully automatic zone signing</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.24">Private-type records</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.31">DNSKEY rollovers</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.33">Dynamic DNS update method</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.38">Automatic key rollovers</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.40">NSEC3PARAM rollovers via UPDATE</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.42">Converting from NSEC to NSEC3</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.44">Converting from NSEC3 to NSEC</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.46">Converting from secure to insecure</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.50">Periodic re-signing</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.52">NSEC3 and OPTOUT</a></span></dt>
Automatic Updater's avatar
Automatic Updater committed
76
</dl></dd>
Evan Hunt's avatar
Evan Hunt committed
77
<dt><span class="section"><a href="Bv9ARM.ch04.html#rfc5011.support">Dynamic Trust Anchor Management</a></span></dt>
Automatic Updater's avatar
regen  
Automatic Updater committed
78
<dd><dl>
Tinderbox User's avatar
Tinderbox User committed
79 80
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.11.3">Validating Resolver</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.11.4">Authoritative Server</a></span></dt>
Tinderbox User's avatar
Tinderbox User committed
81
</dl></dd>
Evan Hunt's avatar
Evan Hunt committed
82
<dt><span class="section"><a href="Bv9ARM.ch04.html#pkcs11">PKCS#11 (Cryptoki) support</a></span></dt>
Tinderbox User's avatar
Tinderbox User committed
83
<dd><dl>
Tinderbox User's avatar
Tinderbox User committed
84 85 86 87 88 89 90
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.12.6">Prerequisites</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.12.7">Native PKCS#11</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.12.8">OpenSSL-based PKCS#11</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.12.9">PKCS#11 Tools</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.12.10">Using the HSM</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.12.11">Specifying the engine on the command line</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.12.12">Running named with automatic zone re-signing</a></span></dt>
Automatic Updater's avatar
regen  
Automatic Updater committed
91
</dl></dd>
Evan Hunt's avatar
Evan Hunt committed
92
<dt><span class="section"><a href="Bv9ARM.ch04.html#dlz-info">DLZ (Dynamically Loadable Zones)</a></span></dt>
Automatic Updater's avatar
regen  
Automatic Updater committed
93
<dd><dl>
Tinderbox User's avatar
Tinderbox User committed
94 95
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.13.6">Configuring DLZ</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.13.7">Sample DLZ Driver</a></span></dt>
Tinderbox User's avatar
Tinderbox User committed
96
</dl></dd>
Evan Hunt's avatar
Evan Hunt committed
97
<dt><span class="section"><a href="Bv9ARM.ch04.html#dyndb-info">DynDB (Dynamic Database)</a></span></dt>
Tinderbox User's avatar
Tinderbox User committed
98
<dd><dl>
Tinderbox User's avatar
Tinderbox User committed
99 100
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.14.5">Configuring DynDB</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.14.6">Sample DynDB Module</a></span></dt>
Tinderbox User's avatar
Tinderbox User committed
101
</dl></dd>
Tinderbox User's avatar
Tinderbox User committed
102 103 104 105 106 107
<dt><span class="section"><a href="Bv9ARM.ch04.html#catz-info">Catalog Zones</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.15.4">Principle of Operation</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.15.5">Configuring Catalog Zones</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.15.6">Catalog Zone format</a></span></dt>
</dl></dd>
Tinderbox User's avatar
Tinderbox User committed
108
<dt><span class="section"><a href="Bv9ARM.ch04.html#ipv6">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
Tinderbox User's avatar
Tinderbox User committed
109
<dd><dl>
Tinderbox User's avatar
Tinderbox User committed
110 111
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.16.6">Address Lookups Using AAAA Records</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.16.7">Address to Name Lookups Using Nibble Format</a></span></dt>
Rob Austein's avatar
regen  
Rob Austein committed
112 113 114
</dl></dd>
</dl>
</div>
Tinderbox User's avatar
Tinderbox User committed
115 116

    <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
117 118
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="notify"></a>Notify</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
119
      <p>
Mark Andrews's avatar
regen  
Mark Andrews committed
120
        <acronym class="acronym">DNS</acronym> NOTIFY is a mechanism that allows master
Rob Austein's avatar
regen  
Rob Austein committed
121
        servers to notify their slave servers of changes to a zone's data. In
Evan Hunt's avatar
Evan Hunt committed
122
        response to a <span class="command"><strong>NOTIFY</strong></span> from a master server, the
Rob Austein's avatar
regen  
Rob Austein committed
123 124 125
        slave will check to see that its version of the zone is the
        current version and, if not, initiate a zone transfer.
      </p>
Tinderbox User's avatar
Tinderbox User committed
126 127

      <p>
Mark Andrews's avatar
regen  
Mark Andrews committed
128
        For more information about <acronym class="acronym">DNS</acronym>
Evan Hunt's avatar
Evan Hunt committed
129 130 131 132
        <span class="command"><strong>NOTIFY</strong></span>, see the description of the
        <span class="command"><strong>notify</strong></span> option in <a class="xref" 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 class="command"><strong>also-notify</strong></span> in
        <a class="xref" href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.  The <span class="command"><strong>NOTIFY</strong></span>
Rob Austein's avatar
regen  
Rob Austein committed
133 134
        protocol is specified in RFC 1996.
      </p>
Tinderbox User's avatar
Tinderbox User committed
135 136

      <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
Mark Andrews's avatar
gregen  
Mark Andrews committed
137
<h3 class="title">Note</h3>
Tinderbox User's avatar
Tinderbox User committed
138
<p>
Evan Hunt's avatar
Evan Hunt committed
139 140 141 142
        As a slave zone can also be a master to other slaves, <span class="command"><strong>named</strong></span>,
        by default, sends <span class="command"><strong>NOTIFY</strong></span> messages for every zone
        it loads.  Specifying <span class="command"><strong>notify master-only;</strong></span> will
        cause <span class="command"><strong>named</strong></span> to only send <span class="command"><strong>NOTIFY</strong></span> for master
Mark Andrews's avatar
gregen  
Mark Andrews committed
143
        zones that it loads.
Tinderbox User's avatar
Tinderbox User committed
144 145
      </p>
</div>
Tinderbox User's avatar
Tinderbox User committed
146 147 148 149

    </div>

    <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
150 151
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="dynamic_update"></a>Dynamic Update</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
152 153

      <p>
Rob Austein's avatar
regen  
Rob Austein committed
154 155 156 157 158
        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>
Tinderbox User's avatar
Tinderbox User committed
159 160

      <p>
Mark Andrews's avatar
regen  
Mark Andrews committed
161
        Dynamic update is enabled by including an
Evan Hunt's avatar
Evan Hunt committed
162 163
        <span class="command"><strong>allow-update</strong></span> or an <span class="command"><strong>update-policy</strong></span>
        clause in the <span class="command"><strong>zone</strong></span> statement.
Automatic Updater's avatar
regen  
Automatic Updater committed
164
      </p>
Tinderbox User's avatar
Tinderbox User committed
165 166

      <p>
Evan Hunt's avatar
Evan Hunt committed
167
        If the zone's <span class="command"><strong>update-policy</strong></span> is set to
Automatic Updater's avatar
regen  
Automatic Updater committed
168 169
        <strong class="userinput"><code>local</code></strong>, updates to the zone
        will be permitted for the key <code class="varname">local-ddns</code>,
Evan Hunt's avatar
Evan Hunt committed
170 171
        which will be generated by <span class="command"><strong>named</strong></span> at startup.
        See <a class="xref" href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a> for more details.
Automatic Updater's avatar
regen  
Automatic Updater committed
172
      </p>
Tinderbox User's avatar
Tinderbox User committed
173 174

      <p>
Automatic Updater's avatar
Automatic Updater committed
175 176
        Dynamic updates using Kerberos signed requests can be made
        using the TKEY/GSS protocol by setting either the
Evan Hunt's avatar
Evan Hunt committed
177 178 179
        <span class="command"><strong>tkey-gssapi-keytab</strong></span> option, or alternatively
        by setting both the <span class="command"><strong>tkey-gssapi-credential</strong></span>
        and <span class="command"><strong>tkey-domain</strong></span> options. Once enabled,
Automatic Updater's avatar
Automatic Updater committed
180 181 182
        Kerberos signed requests will be matched against the update
        policies for the zone, using the Kerberos principal as the
        signer for the request.
Rob Austein's avatar
regen  
Rob Austein committed
183
      </p>
Tinderbox User's avatar
Tinderbox User committed
184 185

      <p>
Automatic Updater's avatar
regen  
Automatic Updater committed
186 187 188 189 190
        Updating of secure zones (zones using DNSSEC) follows RFC
        3007: RRSIG, NSEC and NSEC3 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.
Rob Austein's avatar
regen  
Rob Austein committed
191
      </p>
Tinderbox User's avatar
Tinderbox User committed
192 193

      <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
194 195
<div class="titlepage"><div><div><h3 class="title">
<a name="journal"></a>The journal file</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
196 197

        <p>
Rob Austein's avatar
regen  
Rob Austein committed
198 199 200 201 202 203 204 205 206
          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>
Tinderbox User's avatar
Tinderbox User committed
207 208

        <p>
Rob Austein's avatar
regen  
Rob Austein committed
209 210 211 212 213 214
          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.
Automatic Updater's avatar
regen  
Automatic Updater committed
215 216 217 218 219
          During the dump process, transient files will be created
          with the extensions <code class="filename">.jnw</code> and
          <code class="filename">.jbk</code>; under ordinary circumstances, these
          will be removed when the dump is complete, and can be safely
          ignored.
Rob Austein's avatar
regen  
Rob Austein committed
220
        </p>
Tinderbox User's avatar
Tinderbox User committed
221 222

        <p>
Rob Austein's avatar
regen  
Rob Austein committed
223 224 225 226 227
          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>
Tinderbox User's avatar
Tinderbox User committed
228 229

        <p>
Rob Austein's avatar
regen  
Rob Austein committed
230 231 232 233
          Changes that result from incoming incremental zone transfers are
          also
          journalled in a similar way.
        </p>
Tinderbox User's avatar
Tinderbox User committed
234 235

        <p>
Rob Austein's avatar
regen  
Rob Austein committed
236 237
          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
238
          dynamic changes &#8212; those are only in the journal file.
Rob Austein's avatar
regen  
Rob Austein committed
239
          The only way to ensure that the zone file of a dynamic zone
Evan Hunt's avatar
Evan Hunt committed
240
          is up to date is to run <span class="command"><strong>rndc stop</strong></span>.
Rob Austein's avatar
regen  
Rob Austein committed
241
        </p>
Tinderbox User's avatar
Tinderbox User committed
242 243

        <p>
Rob Austein's avatar
regen  
Rob Austein committed
244
          If you have to make changes to a dynamic zone
Tinderbox User's avatar
Tinderbox User committed
245 246
          manually, the following procedure will work:
          Disable dynamic updates to the zone using
Evan Hunt's avatar
Evan Hunt committed
247
          <span class="command"><strong>rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>.
Tinderbox User's avatar
Tinderbox User committed
248 249 250
          This will update the zone's master file with the changes
          stored in its <code class="filename">.jnl</code> file.
          Edit the zone file.  Run
Evan Hunt's avatar
Evan Hunt committed
251
          <span class="command"><strong>rndc thaw <em class="replaceable"><code>zone</code></em></strong></span>
Rob Austein's avatar
regen  
Rob Austein committed
252 253
          to reload the changed zone and re-enable dynamic updates.
        </p>
Tinderbox User's avatar
Tinderbox User committed
254 255

        <p>
Evan Hunt's avatar
Evan Hunt committed
256
          <span class="command"><strong>rndc sync <em class="replaceable"><code>zone</code></em></strong></span>
Tinderbox User's avatar
Tinderbox User committed
257 258 259 260
          will update the zone file with changes from the journal file
          without stopping dynamic updates; this may be useful for viewing
          the current zone state.  To remove the <code class="filename">.jnl</code>
          file after updating the zone file, use
Evan Hunt's avatar
Evan Hunt committed
261
          <span class="command"><strong>rndc sync -clean</strong></span>.
Tinderbox User's avatar
Tinderbox User committed
262
        </p>
Tinderbox User's avatar
Tinderbox User committed
263 264 265 266 267 268

      </div>

    </div>

    <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
269 270
<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>
Tinderbox User's avatar
Tinderbox User committed
271 272

      <p>
Rob Austein's avatar
regen  
Rob Austein committed
273 274 275
        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
Evan Hunt's avatar
Evan Hunt committed
276
        1995. See <a class="xref" href="Bv9ARM.ch11.html#proposed_standards" title="Proposed Standards">Proposed Standards</a>.
Rob Austein's avatar
regen  
Rob Austein committed
277
      </p>
Tinderbox User's avatar
Tinderbox User committed
278 279

      <p>
Mark Andrews's avatar
regen  
Mark Andrews committed
280
        When acting as a master, <acronym class="acronym">BIND</acronym> 9
Rob Austein's avatar
regen  
Rob Austein committed
281 282 283 284 285 286
        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
Evan Hunt's avatar
Evan Hunt committed
287
        <span class="command"><strong>ixfr-from-differences</strong></span> is set
Rob Austein's avatar
regen  
Rob Austein committed
288 289
        to <strong class="userinput"><code>yes</code></strong>.
      </p>
Tinderbox User's avatar
Tinderbox User committed
290 291

      <p>
Mark Andrews's avatar
regen  
Mark Andrews committed
292
        When acting as a slave, <acronym class="acronym">BIND</acronym> 9 will
Rob Austein's avatar
regen  
Rob Austein committed
293 294
        attempt to use IXFR unless
        it is explicitly disabled. For more information about disabling
Evan Hunt's avatar
Evan Hunt committed
295 296
        IXFR, see the description of the <span class="command"><strong>request-ixfr</strong></span> clause
        of the <span class="command"><strong>server</strong></span> statement.
Rob Austein's avatar
regen  
Rob Austein committed
297
      </p>
Tinderbox User's avatar
Tinderbox User committed
298 299 300
    </div>

    <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
301
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
Tinderbox User's avatar
Tinderbox User committed
302
<a name="split_dns"></a>Split DNS</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
303 304

      <p>
Rob Austein's avatar
regen  
Rob Austein committed
305
        Setting up different views, or visibility, of the DNS space to
Mark Andrews's avatar
gregen  
Mark Andrews committed
306 307 308
        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
309
      </p>
Tinderbox User's avatar
Tinderbox User committed
310
      <p>
Rob Austein's avatar
regen  
Rob Austein committed
311 312 313 314 315 316 317
        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
318 319 320
        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
321
        choose to use a Split DNS to present a consistent view of itself
Mark Andrews's avatar
gregen  
Mark Andrews committed
322
        to the outside world.
Rob Austein's avatar
regen  
Rob Austein committed
323
      </p>
Tinderbox User's avatar
Tinderbox User committed
324
      <p>
Rob Austein's avatar
regen  
Rob Austein committed
325 326 327 328 329 330
        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>
Tinderbox User's avatar
Tinderbox User committed
331
      <div class="section">
Mark Andrews's avatar
regen  
Mark Andrews committed
332
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
333
<a name="split_dns_sample"></a>Example split DNS setup</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
334
        <p>
Tinderbox User's avatar
Tinderbox User committed
335 336 337 338 339 340 341
          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>
Tinderbox User's avatar
Tinderbox User committed
342
        <p>
Tinderbox User's avatar
Tinderbox User committed
343 344 345 346 347 348
          <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>
Tinderbox User's avatar
Tinderbox User committed
349
        <p>
Tinderbox User's avatar
Tinderbox User committed
350 351 352 353 354 355 356
          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>
Tinderbox User's avatar
Tinderbox User committed
357
        <p>
Tinderbox User's avatar
Tinderbox User committed
358 359 360 361 362 363 364 365
          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>, <code class="filename">site1.internal</code>,
          and <code class="filename">site2.internal</code>.
        </p>
Tinderbox User's avatar
Tinderbox User committed
366
        <p>
Tinderbox User's avatar
Tinderbox User committed
367 368 369 370 371
          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>
Tinderbox User's avatar
Tinderbox User committed
372
        <p>
Tinderbox User's avatar
Tinderbox User committed
373 374 375 376 377 378
          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>
Tinderbox User's avatar
Tinderbox User committed
379
        <p>
Tinderbox User's avatar
Tinderbox User committed
380 381 382 383 384 385 386 387
          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>
Tinderbox User's avatar
Tinderbox User committed
388
        <p>
Tinderbox User's avatar
Tinderbox User committed
389 390
          Here's an example of a wildcard MX record:
        </p>
Tinderbox User's avatar
Tinderbox User committed
391 392
        <pre class="programlisting">*   IN MX 10 external1.example.com.</pre>
        <p>
Tinderbox User's avatar
Tinderbox User committed
393 394 395 396 397 398 399
          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>
Tinderbox User's avatar
Tinderbox User committed
400
        <p>
Tinderbox User's avatar
Tinderbox User committed
401 402 403 404
          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>
Tinderbox User's avatar
Tinderbox User committed
405
        <p>
Tinderbox User's avatar
Tinderbox User committed
406 407 408 409 410 411
          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>
Tinderbox User's avatar
Tinderbox User committed
412
        <p>
Tinderbox User's avatar
Tinderbox User committed
413 414 415
          If everything has been set properly, <span class="emphasis"><em>Example, Inc.</em></span>'s
          internal clients will now be able to:
        </p>
Tinderbox User's avatar
Tinderbox User committed
416
        <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
Evan Hunt's avatar
Evan Hunt committed
417
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
418
            
Tinderbox User's avatar
Tinderbox User committed
419 420 421
              Look up any hostnames in the <code class="literal">site1</code>
              and
              <code class="literal">site2.example.com</code> zones.
Tinderbox User's avatar
Tinderbox User committed
422 423
            
          </li>
Evan Hunt's avatar
Evan Hunt committed
424
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
425
            
Tinderbox User's avatar
Tinderbox User committed
426 427
              Look up any hostnames in the <code class="literal">site1.internal</code> and
              <code class="literal">site2.internal</code> domains.
Tinderbox User's avatar
Tinderbox User committed
428 429 430 431 432 433 434 435
            
          </li>
<li class="listitem">
            Look up any hostnames on the Internet.
          </li>
<li class="listitem">
            Exchange mail with both internal and external people.
          </li>
Rob Austein's avatar
regen  
Rob Austein committed
436
</ul></div>
Tinderbox User's avatar
Tinderbox User committed
437
        <p>
Tinderbox User's avatar
Tinderbox User committed
438 439
          Hosts on the Internet will be able to:
        </p>
Tinderbox User's avatar
Tinderbox User committed
440
        <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
Evan Hunt's avatar
Evan Hunt committed
441
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
442
            
Tinderbox User's avatar
Tinderbox User committed
443 444 445
              Look up any hostnames in the <code class="literal">site1</code>
              and
              <code class="literal">site2.example.com</code> zones.
Tinderbox User's avatar
Tinderbox User committed
446 447
            
          </li>
Evan Hunt's avatar
Evan Hunt committed
448
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
449
            
Tinderbox User's avatar
Tinderbox User committed
450 451
              Exchange mail with anyone in the <code class="literal">site1</code> and
              <code class="literal">site2.example.com</code> zones.
Tinderbox User's avatar
Tinderbox User committed
452 453
            
          </li>
Rob Austein's avatar
regen  
Rob Austein committed
454
</ul></div>
Tinderbox User's avatar
Tinderbox User committed
455 456

        <p>
Tinderbox User's avatar
Tinderbox User committed
457 458 459 460
          Here is an example configuration for the setup we just
          described above. Note that this is only configuration information;
          for information on how to configure your zone files, see <a class="xref" href="Bv9ARM.ch03.html#sample_configuration" title="Sample Configurations">the section called &#8220;Sample Configurations&#8221;</a>.
        </p>
Tinderbox User's avatar
Tinderbox User committed
461 462

        <p>
Tinderbox User's avatar
Tinderbox User committed
463 464
          Internal DNS server config:
        </p>
Tinderbox User's avatar
Tinderbox User committed
465

Rob Austein's avatar
regen  
Rob Austein committed
466 467
<pre class="programlisting">

468 469
acl internals { 172.16.72.0/24; 192.168.1.0/24; };

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

472 473 474 475
options {
    ...
    ...
    forward only;
Automatic Updater's avatar
regen  
Automatic Updater committed
476 477
    // forward to external servers
    forwarders {
Mark Andrews's avatar
gregen  
Mark Andrews committed
478
        <code class="varname">bastion-ips-go-here</code>;
479
    };
Automatic Updater's avatar
regen  
Automatic Updater committed
480 481 482 483 484 485
    // sample allow-transfer (no one)
    allow-transfer { none; };
    // restrict query access
    allow-query { internals; externals; };
    // restrict recursion
    allow-recursion { internals; };
486 487 488
    ...
    ...
};
489

Automatic Updater's avatar
regen  
Automatic Updater committed
490 491
// sample master zone
zone "site1.example.com" {
492 493
  type master;
  file "m/site1.example.com";
Automatic Updater's avatar
regen  
Automatic Updater committed
494 495
  // do normal iterative resolution (do not forward)
  forwarders { };
496 497 498
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
499

Automatic Updater's avatar
regen  
Automatic Updater committed
500 501
// sample slave zone
zone "site2.example.com" {
502 503 504 505 506 507 508
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
509

510 511 512 513 514 515 516
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};
517

518 519 520 521 522 523 524 525
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
526
</pre>
Tinderbox User's avatar
Tinderbox User committed
527 528

        <p>
Tinderbox User's avatar
Tinderbox User committed
529 530
          External (bastion host) DNS server config:
        </p>
Tinderbox User's avatar
Tinderbox User committed
531

Rob Austein's avatar
regen  
Rob Austein committed
532 533
<pre class="programlisting">
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
534

535
acl externals { bastion-ips-go-here; };
536

537 538 539
options {
  ...
  ...
Automatic Updater's avatar
regen  
Automatic Updater committed
540 541 542 543 544 545 546 547
  // sample allow-transfer (no one)
  allow-transfer { none; };
  // default query access
  allow-query { any; };
  // restrict cache access
  allow-query-cache { internals; externals; };
  // restrict recursion
  allow-recursion { internals; externals; };
548 549 550
  ...
  ...
};
551

Automatic Updater's avatar
regen  
Automatic Updater committed
552 553
// sample slave zone
zone "site1.example.com" {
554 555 556 557
  type master;
  file "m/site1.foo.com";
  allow-transfer { internals; externals; };
};
558

559 560 561 562 563 564
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
565
</pre>
Tinderbox User's avatar
Tinderbox User committed
566 567

        <p>
Tinderbox User's avatar
Tinderbox User committed
568 569 570
          In the <code class="filename">resolv.conf</code> (or equivalent) on
          the bastion host(s):
        </p>
Tinderbox User's avatar
Tinderbox User committed
571

Rob Austein's avatar
regen  
Rob Austein committed
572 573
<pre class="programlisting">
search ...
574 575 576
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4
Rob Austein's avatar
regen  
Rob Austein committed
577
</pre>
Tinderbox User's avatar
Tinderbox User committed
578 579 580 581

      </div>
    </div>
    <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
582 583
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="tsig"></a>TSIG</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
584 585

      <p>
Tinderbox User's avatar
Tinderbox User committed
586 587 588 589 590 591 592 593 594
        TSIG (Transaction SIGnatures) is a mechanism for authenticating DNS
        messages, originally specified in RFC 2845. It allows DNS messages
        to be cryptographically signed using a shared secret.  TSIG can
        be used in any DNS transaction, as a way to restrict access to
        certain server functions (e.g., recursive queries) to authorized
        clients when IP-based access control is insufficient or needs to
        be overridden, or as a way to ensure message authenticity when it
        is critical to the integrity of the server, such as with dynamic
        UPDATE messages or zone transfers from a master to a slave server.
Rob Austein's avatar
regen  
Rob Austein committed
595
      </p>
Tinderbox User's avatar
Tinderbox User committed
596
      <p>
Tinderbox User's avatar
Tinderbox User committed
597 598 599
        This is a guide to setting up TSIG in <acronym class="acronym">BIND</acronym>.
        It describes the configuration syntax and the process of creating
        TSIG keys.
Rob Austein's avatar
regen  
Rob Austein committed
600
      </p>
Tinderbox User's avatar
Tinderbox User committed
601
      <p>
Tinderbox User's avatar
Tinderbox User committed
602 603 604 605 606 607 608
        <span class="command"><strong>named</strong></span> supports TSIG for server-to-server
        communication, and some of the tools included with
        <acronym class="acronym">BIND</acronym> support it for sending messages to
        <span class="command"><strong>named</strong></span>:
        </p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
609
            <a class="xref" href="man.nsupdate.html" title="nsupdate"><span class="refentrytitle"><span class="application">nsupdate</span></span>(1)</a> supports TSIG via the
Tinderbox User's avatar
Tinderbox User committed
610 611 612 613 614 615
            <code class="option">-k</code>, <code class="option">-l</code> and
            <code class="option">-y</code> command line options, or via
            the <span class="command"><strong>key</strong></span> command when running
            interactively.
          </li>
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
616
            <a class="xref" href="man.dig.html" title="dig"><span class="refentrytitle">dig</span>(1)</a> supports TSIG via the
Tinderbox User's avatar
Tinderbox User committed
617 618 619 620 621
            <code class="option">-k</code> and <code class="option">-y</code> command
            line options.
          </li>
</ul></div>
<p>
Rob Austein's avatar
regen  
Rob Austein committed
622
      </p>
Tinderbox User's avatar
Tinderbox User committed
623 624

      <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
625
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
626
<a name="id-1.5.6.5"></a>Generating a Shared Key</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
627
        <p>
Tinderbox User's avatar
Tinderbox User committed
628 629
          TSIG keys can be generated using the <span class="command"><strong>tsig-keygen</strong></span>
          command; the output of the command is a <span class="command"><strong>key</strong></span> directive
Tinderbox User's avatar
Tinderbox User committed
630
          suitable for inclusion in <code class="filename">named.conf</code>.  The
Tinderbox User's avatar
Tinderbox User committed
631 632
          key name, algorithm and size can be specified by command line parameters;
          the defaults are "tsig-key", HMAC-SHA256, and 256 bits, respectively.
Rob Austein's avatar
regen  
Rob Austein committed
633
        </p>
Tinderbox User's avatar
Tinderbox User committed
634
        <p>
Tinderbox User's avatar
Tinderbox User committed
635 636 637 638 639 640 641 642
          Any string which is a valid DNS name can be used as a key name.
          For example, a key to be shared between servers called
          <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span> could
          be called "host1-host2.", and this key could be generated using:
        </p>
<pre class="programlisting">
  $ tsig-keygen host1-host2. &gt; host1-host2.key
</pre>
Tinderbox User's avatar
Tinderbox User committed
643
        <p>
Tinderbox User's avatar
Tinderbox User committed
644 645 646 647 648 649
          This key may then be copied to both hosts.  The key name and secret
          must be identical on both hosts.
          (Note: copying a shared secret from one server to another is beyond
          the scope of the DNS. A secure transport mechanism should be used:
          secure FTP, SSL, ssh, telephone, encrypted email, etc.)
        </p>
Tinderbox User's avatar
Tinderbox User committed
650
        <p>
Tinderbox User's avatar
Tinderbox User committed
651 652 653 654 655
          <span class="command"><strong>tsig-keygen</strong></span> can also be run as
          <span class="command"><strong>ddns-confgen</strong></span>, in which case its output includes
          additional configuration text for setting up dynamic DNS in
          <span class="command"><strong>named</strong></span>.  See <a class="xref" href="man.ddns-confgen.html" title="ddns-confgen"><span class="refentrytitle"><span class="application">ddns-confgen</span></span>(8)</a>
          for details.
Rob Austein's avatar
regen  
Rob Austein committed
656
        </p>
Tinderbox User's avatar
Tinderbox User committed
657 658 659
      </div>

      <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
660
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
661
<a name="id-1.5.6.6"></a>Loading A New Key</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
662
        <p>
Tinderbox User's avatar
Tinderbox User committed
663 664 665 666
          For a key shared between servers called
          <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>,
          the following could be added to each server's
          <code class="filename">named.conf</code> file:
Rob Austein's avatar
regen  
Rob Austein committed
667 668
        </p>
<pre class="programlisting">
Tinderbox User's avatar
Tinderbox User committed
669 670 671
key "host1-host2." {
        algorithm hmac-sha256;
        secret "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=";
672
};
Rob Austein's avatar
regen  
Rob Austein committed
673
</pre>
Tinderbox User's avatar
Tinderbox User committed
674
        <p>
Tinderbox User's avatar
Tinderbox User committed
675 676
          (This is the same key generated above using
          <span class="command"><strong>tsig-keygen</strong></span>.)
Rob Austein's avatar
regen  
Rob Austein committed
677
        </p>
Tinderbox User's avatar
Tinderbox User committed
678
        <p>
Tinderbox User's avatar
Tinderbox User committed
679 680 681 682 683 684 685
          Since this text contains a secret, it
          is recommended that either <code class="filename">named.conf</code> not be
          world-readable, or that the <span class="command"><strong>key</strong></span> directive
          be stored in a file which is not world-readable, and which is
          included in <code class="filename">named.conf</code> via the
          <span class="command"><strong>include</strong></span> directive.
        </p>
Tinderbox User's avatar
Tinderbox User committed
686
        <p>
Tinderbox User's avatar
Tinderbox User committed
687 688 689 690 691 692
          Once a key has been added to <code class="filename">named.conf</code> and the
          server has been restarted or reconfigured, the server can recognize
          the key.  If the server receives a message signed by the
          key, it will be able to verify the signature.  If the signature
          is valid, the response will be signed using the same key.
        </p>
Tinderbox User's avatar
Tinderbox User committed
693
        <p>
Tinderbox User's avatar
Tinderbox User committed
694 695
          TSIG keys that are known to a server can be listed using the
          command <span class="command"><strong>rndc tsig-list</strong></span>.
Rob Austein's avatar
regen  
Rob Austein committed
696
        </p>
Tinderbox User's avatar
Tinderbox User committed
697 698 699
      </div>

      <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
700
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
701
<a name="id-1.5.6.7"></a>Instructing the Server to Use a Key</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
702
        <p>
Tinderbox User's avatar
Tinderbox User committed
703 704 705
          A server sending a request to another server must be told whether
          to use a key, and if so, which key to use.
        </p>
Tinderbox User's avatar
Tinderbox User committed
706
        <p>
Tinderbox User's avatar
Tinderbox User committed
707 708 709 710 711 712 713
          For example, a key may be specified for each server in the
          <span class="command"><strong>masters</strong></span> statement in the definition of a
          slave zone; in this case, all SOA QUERY messages, NOTIFY
          messages, and zone transfer requests (AXFR or IXFR) will be
          signed using the specified key.  Keys may also be specified
          in the <span class="command"><strong>also-notify</strong></span> statement of a master
          or slave zone, causing NOTIFY messages to be signed using
Tinderbox User's avatar
Tinderbox User committed
714
          the specified key.
Tinderbox User's avatar
Tinderbox User committed
715
        </p>
Tinderbox User's avatar
Tinderbox User committed
716
        <p>
Tinderbox User's avatar
Tinderbox User committed
717 718 719 720 721 722
          Keys can also be specified in a <span class="command"><strong>server</strong></span>
          directive. Adding the following on <span class="emphasis"><em>host1</em></span>,
          if the IP address of <span class="emphasis"><em>host2</em></span> is 10.1.2.3, would
          cause <span class="emphasis"><em>all</em></span> requests from <span class="emphasis"><em>host1</em></span>
          to <span class="emphasis"><em>host2</em></span>, including normal DNS queries, to be
          signed using the <span class="command"><strong>host1-host2.</strong></span> key:
Rob Austein's avatar
regen  
Rob Austein committed
723 724 725
        </p>
<pre class="programlisting">
server 10.1.2.3 {
Tinderbox User's avatar
Tinderbox User committed
726
        keys { host1-host2. ;};
727
};
Rob Austein's avatar
regen  
Rob Austein committed
728
</pre>
Tinderbox User's avatar
Tinderbox User committed
729
        <p>
Tinderbox User's avatar
Tinderbox User committed
730 731 732
          Multiple keys may be present in the <span class="command"><strong>keys</strong></span>
          statement, but only the first one is used.  As this directive does
          not contain secrets, it can be used in a world-readable file.
Rob Austein's avatar
regen  
Rob Austein committed
733
        </p>
Tinderbox User's avatar
Tinderbox User committed
734
        <p>
Tinderbox User's avatar
Tinderbox User committed
735 736 737 738
          Requests sent by <span class="emphasis"><em>host2</em></span> to <span class="emphasis"><em>host1</em></span>
          would <span class="emphasis"><em>not</em></span> be signed, unless a similar
          <span class="command"><strong>server</strong></span> directive were in <span class="emphasis"><em>host2</em></span>'s
          configuration file.
Rob Austein's avatar
regen  
Rob Austein committed
739
        </p>
Tinderbox User's avatar
Tinderbox User committed
740
        <p>
Tinderbox User's avatar
Tinderbox User committed
741 742 743 744
          Whenever any server sends a TSIG-signed DNS request, it will expect
          the response to be signed with the same key. If a response is not
          signed, or if the signature is not valid, the response will be
          rejected.
Rob Austein's avatar
regen  
Rob Austein committed
745
        </p>
Tinderbox User's avatar
Tinderbox User committed
746 747 748
      </div>

      <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
749
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
750
<a name="id-1.5.6.8"></a>TSIG-Based Access Control</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
751
        <p>
Tinderbox User's avatar
Tinderbox User committed
752 753 754 755 756
          TSIG keys may be specified in ACL definitions and ACL directives
          such as <span class="command"><strong>allow-query</strong></span>, <span class="command"><strong>allow-transfer</strong></span>
          and <span class="command"><strong>allow-update</strong></span>.
          The above key would be denoted in an ACL element as
          <span class="command"><strong>key host1-host2.</strong></span>
Rob Austein's avatar
regen  
Rob Austein committed
757
        </p>
Tinderbox User's avatar
Tinderbox User committed
758
        <p>
Tinderbox User's avatar
Tinderbox User committed
759 760
          An example of an <span class="command"><strong>allow-update</strong></span> directive using
          a TSIG key:
Rob Austein's avatar
regen  
Rob Austein committed
761 762
        </p>
<pre class="programlisting">
Tinderbox User's avatar
Tinderbox User committed
763
allow-update { !{ !localnets; any; }; key host1-host2. ;};
Rob Austein's avatar
regen  
Rob Austein committed
764
</pre>
Tinderbox User's avatar
Tinderbox User committed
765
        <p>
Tinderbox User's avatar
Tinderbox User committed
766 767 768 769
          This allows dynamic updates to succeed only if the UPDATE
          request comes from an address in <span class="command"><strong>localnets</strong></span>,
          <span class="emphasis"><em>and</em></span> if it is signed using the
          <span class="command"><strong>host1-host2.</strong></span> key.
Rob Austein's avatar
regen  
Rob Austein committed
770
        </p>
Tinderbox User's avatar
Tinderbox User committed
771
        <p>
Evan Hunt's avatar
Evan Hunt committed
772 773
          See <a class="xref" href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a> for a discussion of
          the more flexible <span class="command"><strong>update-policy</strong></span> statement.
Rob Austein's avatar
regen  
Rob Austein committed
774
        </p>
Tinderbox User's avatar
Tinderbox User committed
775 776 777
      </div>

      <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
778
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
779
<a name="id-1.5.6.9"></a>Errors</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
780
        <p>
Tinderbox User's avatar
Tinderbox User committed
781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804
          Processing of TSIG-signed messages can result in several errors:
          </p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">
              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.
            </li>
<li class="listitem">
              If a TSIG-aware server receives a message from a known key
              but with an invalid signature, the response will be unsigned,
              with the TSIG extended error code set to BADSIG.
            </li>
<li class="listitem">
              If a TSIG-aware server receives a message with a time
              outside of the allowed range, the response will be signed, with
              the TSIG extended error code set to BADTIME, and the time values
              will be adjusted so that the response can be successfully
              verified.
            </li>
</ul></div>
<p>
          In all of the above cases, the server will return a response code
          of NOTAUTH (not authenticated).
Rob Austein's avatar
regen  
Rob Austein committed
805
        </p>
Tinderbox User's avatar
Tinderbox User committed
806 807 808 809
      </div>
    </div>

    <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
810
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
Tinderbox User's avatar
Tinderbox User committed
811
<a name="tkey"></a>TKEY</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
812 813

      <p>
Tinderbox User's avatar
Tinderbox User committed
814 815 816
        TKEY (Transaction KEY) is a mechanism for automatically negotiating
        a shared secret between two hosts, originally specified in RFC 2930.
      </p>
Tinderbox User's avatar
Tinderbox User committed
817
      <p>
Tinderbox User's avatar
Tinderbox User committed
818 819 820 821 822 823
        There are several TKEY "modes" that specify how a key is to be
        generated or assigned.  <acronym class="acronym">BIND</acronym> 9 implements only
        one of these modes: Diffie-Hellman key exchange.  Both hosts are
        required to have a KEY record with algorithm DH (though this
        record is not required to be present in a zone).
      </p>
Tinderbox User's avatar
Tinderbox User committed
824
      <p>
Tinderbox User's avatar
Tinderbox User committed
825 826
        The TKEY process is initiated by a client or server by sending
        a query of type TKEY to a TKEY-aware server.  The query must include
Tinderbox User's avatar
Tinderbox User committed
827
        an appropriate KEY record in the additional section, and
Tinderbox User's avatar
Tinderbox User committed
828 829 830 831 832 833 834 835
        must be signed using either TSIG or SIG(0) with a previously
        established key.  The server's response, if successful, will
        contain a TKEY record in its answer section.  After this transaction,
        both participants will have enough information to calculate a
        shared secret using Diffie-Hellman key exchange.  The shared secret
        can then be used by to sign subsequent transactions between the
        two servers.
      </p>
Tinderbox User's avatar
Tinderbox User committed
836
      <p>
Tinderbox User's avatar
Tinderbox User committed
837 838
        TSIG keys known by the server, including TKEY-negotiated keys, can
        be listed using <span class="command"><strong>rndc tsig-list</strong></span>.
Rob Austein's avatar
regen  
Rob Austein committed
839
      </p>
Tinderbox User's avatar
Tinderbox User committed
840
      <p>
Tinderbox User's avatar
Tinderbox User committed
841 842 843 844
        TKEY-negotiated keys can be deleted from a server using
        <span class="command"><strong>rndc tsig-delete</strong></span>.  This can also be done via
        the TKEY protocol itself, by sending an authenticated TKEY query
        specifying the "key deletion" mode.
Rob Austein's avatar
regen  
Rob Austein committed
845
      </p>
Tinderbox User's avatar
Tinderbox User committed
846 847 848

    </div>
    <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
849
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
Tinderbox User's avatar
Tinderbox User committed
850
<a name="sig0"></a>SIG(0)</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
851 852

      <p>
Tinderbox User's avatar
Tinderbox User committed
853 854 855
        <acronym class="acronym">BIND</acronym> partially supports DNSSEC SIG(0)
        transaction signatures as specified in RFC 2535 and RFC 2931.
        SIG(0) uses public/private keys to authenticate messages.  Access control
Rob Austein's avatar
regen  
Rob Austein committed
856
        is performed in the same manner as TSIG keys; privileges can be
Tinderbox User's avatar
Tinderbox User committed
857
        granted or denied in ACL directives based on the key name.
Rob Austein's avatar
regen  
Rob Austein committed
858
      </p>
Tinderbox User's avatar
Tinderbox User committed
859
      <p>
Rob Austein's avatar
regen  
Rob Austein committed
860
        When a SIG(0) signed message is received, it will only be
Tinderbox User's avatar
Tinderbox User committed
861 862 863
        verified if the key is known and trusted by the server. The
        server will not attempt to recursively fetch or validate the
        key.
Rob Austein's avatar
regen  
Rob Austein committed
864
      </p>
Tinderbox User's avatar
Tinderbox User committed
865
      <p>
Tinderbox User's avatar
Tinderbox User committed
866
        SIG(0) signing of multiple-message TCP streams is not supported.
Rob Austein's avatar
regen  
Rob Austein committed
867
      </p>
Tinderbox User's avatar
Tinderbox User committed
868
      <p>
Mark Andrews's avatar
regen  
Mark Andrews committed
869
        The only tool shipped with <acronym class="acronym">BIND</acronym> 9 that
Evan Hunt's avatar
Evan Hunt committed
870
        generates SIG(0) signed messages is <span class="command"><strong>nsupdate</strong></span>.
Rob Austein's avatar
regen  
Rob Austein committed
871
      </p>
Tinderbox User's avatar
Tinderbox User committed
872 873 874
    </div>

    <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
875 876
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="DNSSEC"></a>DNSSEC</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
877
      <p>
Rob Austein's avatar
regen  
Rob Austein committed
878 879
        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
880
        defined in RFC 4033, RFC 4034, and RFC 4035.
Mark Andrews's avatar
gregen  
Mark Andrews committed
881
        This section describes the creation and use of DNSSEC signed zones.
Rob Austein's avatar
regen  
Rob Austein committed
882
      </p>
Tinderbox User's avatar
Tinderbox User committed
883 884

      <p>
Rob Austein's avatar
regen  
Rob Austein committed
885
        In order to set up a DNSSEC secure zone, there are a series
Mark Andrews's avatar
regen  
Mark Andrews committed
886
        of steps which must be followed.  <acronym class="acronym">BIND</acronym>
Rob Austein's avatar
regen  
Rob Austein committed
887 888 889 890 891 892
        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
893
        directory specified by the <code class="option">-d</code> option, and
Rob Austein's avatar
regen  
Rob Austein committed
894 895 896
        that the tools shipped with BIND 9.2.x and earlier are not compatible
        with the current ones.
      </p>
Tinderbox User's avatar
Tinderbox User committed
897 898

      <p>
Rob Austein's avatar
regen  
Rob Austein committed
899 900 901
        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
902
        resolver to trust its data.  This is done through the presence
Rob Austein's avatar
regen  
Rob Austein committed
903 904 905 906
        or absence of a <code class="literal">DS</code> record at the
        delegation
        point.
      </p>
Tinderbox User's avatar
Tinderbox User committed
907 908

      <p>
Rob Austein's avatar
regen  
Rob Austein committed
909 910 911 912
        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>
Tinderbox User's avatar
Tinderbox User committed
913 914

      <div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
915
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
916
<a name="dnssec_keys"></a>Generating Keys</h3></div></div></div>