Bv9ARM.ch04.html 127 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-2015 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.3">Converting from insecure to secure</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.8">Dynamic DNS update method</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.16">Fully automatic zone signing</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.25">Private-type records</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.32">DNSKEY rollovers</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.34">Dynamic DNS update method</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.39">Automatic key rollovers</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.41">NSEC3PARAM rollovers via UPDATE</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.43">Converting from NSEC to NSEC3</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.45">Converting from NSEC3 to NSEC</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.47">Converting from secure to insecure</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.51">Periodic re-signing</a></span></dt>
<dt><span class="section"><a href="Bv9ARM.ch04.html#id-1.5.10.53">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
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
116 117
<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
118
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
119
        <acronym class="acronym">DNS</acronym> NOTIFY is a mechanism that allows master
Rob Austein's avatar
regen  
Rob Austein committed
120
        servers to notify their slave servers of changes to a zone's data. In
Evan Hunt's avatar
Evan Hunt committed
121
        response to a <span class="command"><strong>NOTIFY</strong></span> from a master server, the
Rob Austein's avatar
regen  
Rob Austein committed
122 123 124
        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
125
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
126
        For more information about <acronym class="acronym">DNS</acronym>
Evan Hunt's avatar
Evan Hunt committed
127 128 129 130
        <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
131 132
        protocol is specified in RFC 1996.
      </p>
Tinderbox User's avatar
Tinderbox User committed
133
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
Mark Andrews's avatar
gregen  
Mark Andrews committed
134
<h3 class="title">Note</h3>
Tinderbox User's avatar
Tinderbox User committed
135
<p>
Evan Hunt's avatar
Evan Hunt committed
136 137 138 139
        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
140
        zones that it loads.
Tinderbox User's avatar
Tinderbox User committed
141 142
      </p>
</div>
Tinderbox User's avatar
Tinderbox User committed
143 144
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
145 146
<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
147
<p>
Rob Austein's avatar
regen  
Rob Austein committed
148 149 150 151 152
        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
153
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
154
        Dynamic update is enabled by including an
Evan Hunt's avatar
Evan Hunt committed
155 156
        <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
157
      </p>
Tinderbox User's avatar
Tinderbox User committed
158
<p>
Evan Hunt's avatar
Evan Hunt committed
159
        If the zone's <span class="command"><strong>update-policy</strong></span> is set to
Automatic Updater's avatar
regen  
Automatic Updater committed
160 161
        <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
162 163
        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
164
      </p>
Tinderbox User's avatar
Tinderbox User committed
165
<p>
Automatic Updater's avatar
Automatic Updater committed
166 167
        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
168 169 170
        <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
171 172 173
        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
174
      </p>
Tinderbox User's avatar
Tinderbox User committed
175
<p>
Automatic Updater's avatar
regen  
Automatic Updater committed
176 177 178 179 180
        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
181
      </p>
Tinderbox User's avatar
Tinderbox User committed
182
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
183 184
<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
185
<p>
Rob Austein's avatar
regen  
Rob Austein committed
186 187 188 189 190 191 192 193 194
          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
195
<p>
Rob Austein's avatar
regen  
Rob Austein committed
196 197 198 199 200 201
          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
202 203 204 205 206
          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
207
        </p>
Tinderbox User's avatar
Tinderbox User committed
208
<p>
Rob Austein's avatar
regen  
Rob Austein committed
209 210 211 212 213
          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
214
<p>
Rob Austein's avatar
regen  
Rob Austein committed
215 216 217 218
          Changes that result from incoming incremental zone transfers are
          also
          journalled in a similar way.
        </p>
Tinderbox User's avatar
Tinderbox User committed
219
<p>
Rob Austein's avatar
regen  
Rob Austein committed
220 221
          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
222
          dynamic changes &#8212; those are only in the journal file.
Rob Austein's avatar
regen  
Rob Austein committed
223
          The only way to ensure that the zone file of a dynamic zone
Evan Hunt's avatar
Evan Hunt committed
224
          is up to date is to run <span class="command"><strong>rndc stop</strong></span>.
Rob Austein's avatar
regen  
Rob Austein committed
225
        </p>
Tinderbox User's avatar
Tinderbox User committed
226
<p>
Rob Austein's avatar
regen  
Rob Austein committed
227
          If you have to make changes to a dynamic zone
Tinderbox User's avatar
Tinderbox User committed
228 229
          manually, the following procedure will work:
          Disable dynamic updates to the zone using
Evan Hunt's avatar
Evan Hunt committed
230
          <span class="command"><strong>rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>.
Tinderbox User's avatar
Tinderbox User committed
231 232 233
          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
234
          <span class="command"><strong>rndc thaw <em class="replaceable"><code>zone</code></em></strong></span>
Rob Austein's avatar
regen  
Rob Austein committed
235 236
          to reload the changed zone and re-enable dynamic updates.
        </p>
Tinderbox User's avatar
Tinderbox User committed
237
<p>
Evan Hunt's avatar
Evan Hunt committed
238
          <span class="command"><strong>rndc sync <em class="replaceable"><code>zone</code></em></strong></span>
Tinderbox User's avatar
Tinderbox User committed
239 240 241 242
          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
243
          <span class="command"><strong>rndc sync -clean</strong></span>.
Tinderbox User's avatar
Tinderbox User committed
244
        </p>
Tinderbox User's avatar
Tinderbox User committed
245 246 247
</div>
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
248 249
<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
250
<p>
Rob Austein's avatar
regen  
Rob Austein committed
251 252 253
        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
254
        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
255
      </p>
Tinderbox User's avatar
Tinderbox User committed
256
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
257
        When acting as a master, <acronym class="acronym">BIND</acronym> 9
Rob Austein's avatar
regen  
Rob Austein committed
258 259 260 261 262 263
        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
264
        <span class="command"><strong>ixfr-from-differences</strong></span> is set
Rob Austein's avatar
regen  
Rob Austein committed
265 266
        to <strong class="userinput"><code>yes</code></strong>.
      </p>
Tinderbox User's avatar
Tinderbox User committed
267
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
268
        When acting as a slave, <acronym class="acronym">BIND</acronym> 9 will
Rob Austein's avatar
regen  
Rob Austein committed
269 270
        attempt to use IXFR unless
        it is explicitly disabled. For more information about disabling
Evan Hunt's avatar
Evan Hunt committed
271 272
        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
273
      </p>
Tinderbox User's avatar
Tinderbox User committed
274 275
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
276
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
Tinderbox User's avatar
Tinderbox User committed
277
<a name="split_dns"></a>Split DNS</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
278
<p>
Rob Austein's avatar
regen  
Rob Austein committed
279
        Setting up different views, or visibility, of the DNS space to
Mark Andrews's avatar
gregen  
Mark Andrews committed
280 281 282
        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
283
      </p>
Tinderbox User's avatar
Tinderbox User committed
284
<p>
Rob Austein's avatar
regen  
Rob Austein committed
285 286 287 288 289 290 291
        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
292 293 294
        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
295
        choose to use a Split DNS to present a consistent view of itself
Mark Andrews's avatar
gregen  
Mark Andrews committed
296
        to the outside world.
Rob Austein's avatar
regen  
Rob Austein committed
297
      </p>
Tinderbox User's avatar
Tinderbox User committed
298
<p>
Rob Austein's avatar
regen  
Rob Austein committed
299 300 301 302 303 304
        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
305
<div class="section">
Mark Andrews's avatar
regen  
Mark Andrews committed
306
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
307 308 309 310 311 312 313 314 315
<a name="split_dns_sample"></a>Example split DNS setup</h3></div></div></div>
<p>
          Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
          (<code class="literal">example.com</code>)
          has several corporate sites that have an internal network with
          reserved
          Internet Protocol (IP) space and an external demilitarized zone (DMZ),
          or "outside" section of a network, that is available to the public.
        </p>
Tinderbox User's avatar
Tinderbox User committed
316
<p>
Tinderbox User's avatar
Tinderbox User committed
317 318 319 320 321 322
          <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
323
<p>
Tinderbox User's avatar
Tinderbox User committed
324 325 326 327 328 329 330
          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
331
<p>
Tinderbox User's avatar
Tinderbox User committed
332 333 334 335 336 337 338 339
          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
340
<p>
Tinderbox User's avatar
Tinderbox User committed
341 342 343 344 345
          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
346
<p>
Tinderbox User's avatar
Tinderbox User committed
347 348 349 350 351 352
          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
353
<p>
Tinderbox User's avatar
Tinderbox User committed
354 355 356 357 358 359 360 361
          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
362
<p>
Tinderbox User's avatar
Tinderbox User committed
363 364
          Here's an example of a wildcard MX record:
        </p>
Tinderbox User's avatar
Tinderbox User committed
365 366
<pre class="programlisting">*   IN MX 10 external1.example.com.</pre>
<p>
Tinderbox User's avatar
Tinderbox User committed
367 368 369 370 371 372 373
          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
374
<p>
Tinderbox User's avatar
Tinderbox User committed
375 376 377 378
          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
379
<p>
Tinderbox User's avatar
Tinderbox User committed
380 381 382 383 384 385
          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
386
<p>
Tinderbox User's avatar
Tinderbox User committed
387 388 389
          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
390
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
Evan Hunt's avatar
Evan Hunt committed
391
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
392 393 394 395
              Look up any hostnames in the <code class="literal">site1</code>
              and
              <code class="literal">site2.example.com</code> zones.
            </li>
Evan Hunt's avatar
Evan Hunt committed
396
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
397 398 399
              Look up any hostnames in the <code class="literal">site1.internal</code> and
              <code class="literal">site2.internal</code> domains.
            </li>
Tinderbox User's avatar
Tinderbox User committed
400 401
<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
402
</ul></div>
Tinderbox User's avatar
Tinderbox User committed
403
<p>
Tinderbox User's avatar
Tinderbox User committed
404 405
          Hosts on the Internet will be able to:
        </p>
Tinderbox User's avatar
Tinderbox User committed
406
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
Evan Hunt's avatar
Evan Hunt committed
407
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
408 409 410 411
              Look up any hostnames in the <code class="literal">site1</code>
              and
              <code class="literal">site2.example.com</code> zones.
            </li>
Evan Hunt's avatar
Evan Hunt committed
412
<li class="listitem">
Tinderbox User's avatar
Tinderbox User committed
413 414 415
              Exchange mail with anyone in the <code class="literal">site1</code> and
              <code class="literal">site2.example.com</code> zones.
            </li>
Rob Austein's avatar
regen  
Rob Austein committed
416
</ul></div>
Tinderbox User's avatar
Tinderbox User committed
417
<p>
Tinderbox User's avatar
Tinderbox User committed
418 419 420 421
          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
422
<p>
Tinderbox User's avatar
Tinderbox User committed
423 424
          Internal DNS server config:
        </p>
Rob Austein's avatar
regen  
Rob Austein committed
425 426
<pre class="programlisting">

427 428
acl internals { 172.16.72.0/24; 192.168.1.0/24; };

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

431 432 433 434
options {
    ...
    ...
    forward only;
Automatic Updater's avatar
regen  
Automatic Updater committed
435 436
    // forward to external servers
    forwarders {
Mark Andrews's avatar
gregen  
Mark Andrews committed
437
        <code class="varname">bastion-ips-go-here</code>;
438
    };
Automatic Updater's avatar
regen  
Automatic Updater committed
439 440 441 442 443 444
    // sample allow-transfer (no one)
    allow-transfer { none; };
    // restrict query access
    allow-query { internals; externals; };
    // restrict recursion
    allow-recursion { internals; };
445 446 447
    ...
    ...
};
448

Automatic Updater's avatar
regen  
Automatic Updater committed
449 450
// sample master zone
zone "site1.example.com" {
451 452
  type master;
  file "m/site1.example.com";
Automatic Updater's avatar
regen  
Automatic Updater committed
453 454
  // do normal iterative resolution (do not forward)
  forwarders { };
455 456 457
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
458

Automatic Updater's avatar
regen  
Automatic Updater committed
459 460
// sample slave zone
zone "site2.example.com" {
461 462 463 464 465 466 467
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
468

469 470 471 472 473 474 475
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};
476

477 478 479 480 481 482 483 484
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
485
</pre>
Tinderbox User's avatar
Tinderbox User committed
486
<p>
Tinderbox User's avatar
Tinderbox User committed
487 488
          External (bastion host) DNS server config:
        </p>
Rob Austein's avatar
regen  
Rob Austein committed
489 490
<pre class="programlisting">
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
491

492
acl externals { bastion-ips-go-here; };
493

494 495 496
options {
  ...
  ...
Automatic Updater's avatar
regen  
Automatic Updater committed
497 498 499 500 501 502 503 504
  // 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; };
505 506 507
  ...
  ...
};
508

Automatic Updater's avatar
regen  
Automatic Updater committed
509 510
// sample slave zone
zone "site1.example.com" {
511 512 513 514
  type master;
  file "m/site1.foo.com";
  allow-transfer { internals; externals; };
};
515

516 517 518 519 520 521
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
522
</pre>
Tinderbox User's avatar
Tinderbox User committed
523
<p>
Tinderbox User's avatar
Tinderbox User committed
524 525 526
          In the <code class="filename">resolv.conf</code> (or equivalent) on
          the bastion host(s):
        </p>
Rob Austein's avatar
regen  
Rob Austein committed
527 528
<pre class="programlisting">
search ...
529 530 531
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4
Rob Austein's avatar
regen  
Rob Austein committed
532
</pre>
Tinderbox User's avatar
Tinderbox User committed
533 534 535
</div>
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
536 537
<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
538
<p>
Tinderbox User's avatar
Tinderbox User committed
539 540 541 542 543 544 545 546 547
        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
548
      </p>
Tinderbox User's avatar
Tinderbox User committed
549
<p>
Tinderbox User's avatar
Tinderbox User committed
550 551 552
        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
553
      </p>
Tinderbox User's avatar
Tinderbox User committed
554
<p>
Tinderbox User's avatar
Tinderbox User committed
555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574
        <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">
<a class="xref" href="man.nsupdate.html" title="nsupdate"><span class="refentrytitle"><span class="application">nsupdate</span></span>(1)</a> supports TSIG via the
            <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">
<a class="xref" href="man.dig.html" title="dig"><span class="refentrytitle">dig</span>(1)</a> supports TSIG via the
            <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
575
      </p>
Tinderbox User's avatar
Tinderbox User committed
576
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
577
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
578
<a name="id-1.5.6.5"></a>Generating a Shared Key</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
579
<p>
Tinderbox User's avatar
Tinderbox User committed
580 581
          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
582
          suitable for inclusion in <code class="filename">named.conf</code>.  The
Tinderbox User's avatar
Tinderbox User committed
583 584
          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
585
        </p>
Tinderbox User's avatar
Tinderbox User committed
586
<p>
Tinderbox User's avatar
Tinderbox User committed
587 588 589 590 591 592 593 594
          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
595
<p>
Tinderbox User's avatar
Tinderbox User committed
596 597 598 599 600 601
          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
602
<p>
Tinderbox User's avatar
Tinderbox User committed
603 604 605 606 607
          <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
608
        </p>
Tinderbox User's avatar
Tinderbox User committed
609 610
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
611
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
612
<a name="id-1.5.6.6"></a>Loading A New Key</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
613
<p>
Tinderbox User's avatar
Tinderbox User committed
614 615 616 617
          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
618 619
        </p>
<pre class="programlisting">
Tinderbox User's avatar
Tinderbox User committed
620 621 622
key "host1-host2." {
        algorithm hmac-sha256;
        secret "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=";
623
};
Rob Austein's avatar
regen  
Rob Austein committed
624
</pre>
Tinderbox User's avatar
Tinderbox User committed
625
<p>
Tinderbox User's avatar
Tinderbox User committed
626 627
          (This is the same key generated above using
          <span class="command"><strong>tsig-keygen</strong></span>.)
Rob Austein's avatar
regen  
Rob Austein committed
628
        </p>
Tinderbox User's avatar
Tinderbox User committed
629
<p>
Tinderbox User's avatar
Tinderbox User committed
630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646
          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>
<p>
          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>
<p>
          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
647
        </p>
Tinderbox User's avatar
Tinderbox User committed
648 649
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
650
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
651
<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
652
<p>
Tinderbox User's avatar
Tinderbox User committed
653 654 655 656 657 658 659 660 661 662 663
          A server sending a request to another server must be told whether
          to use a key, and if so, which key to use.
        </p>
<p>
          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
664
          the specified key.
Tinderbox User's avatar
Tinderbox User committed
665 666 667 668 669 670 671 672
        </p>
<p>
          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
673 674 675
        </p>
<pre class="programlisting">
server 10.1.2.3 {
Tinderbox User's avatar
Tinderbox User committed
676
        keys { host1-host2. ;};
677
};
Rob Austein's avatar
regen  
Rob Austein committed
678
</pre>
Tinderbox User's avatar
Tinderbox User committed
679
<p>
Tinderbox User's avatar
Tinderbox User committed
680 681 682
          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
683
        </p>
Tinderbox User's avatar
Tinderbox User committed
684
<p>
Tinderbox User's avatar
Tinderbox User committed
685 686 687 688
          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
689
        </p>
Tinderbox User's avatar
Tinderbox User committed
690
<p>
Tinderbox User's avatar
Tinderbox User committed
691 692 693 694
          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
695
        </p>
Tinderbox User's avatar
Tinderbox User committed
696 697
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
698
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
699
<a name="id-1.5.6.8"></a>TSIG-Based Access Control</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
700
<p>
Tinderbox User's avatar
Tinderbox User committed
701 702 703 704 705
          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
706
        </p>
Tinderbox User's avatar
Tinderbox User committed
707
<p>
Tinderbox User's avatar
Tinderbox User committed
708 709
          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
710 711
        </p>
<pre class="programlisting">
Tinderbox User's avatar
Tinderbox User committed
712
allow-update { !{ !localnets; any; }; key host1-host2. ;};
Rob Austein's avatar
regen  
Rob Austein committed
713
</pre>
Tinderbox User's avatar
Tinderbox User committed
714
<p>
Tinderbox User's avatar
Tinderbox User committed
715 716 717 718
          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
719
        </p>
Tinderbox User's avatar
Tinderbox User committed
720
<p>
Evan Hunt's avatar
Evan Hunt committed
721 722
          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
723
        </p>
Tinderbox User's avatar
Tinderbox User committed
724 725
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
726
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752
<a name="id-1.5.6.9"></a>Errors</h3></div></div></div>
<p>
          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
753
        </p>
Tinderbox User's avatar
Tinderbox User committed
754 755 756
</div>
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
757
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
Tinderbox User's avatar
Tinderbox User committed
758
<a name="tkey"></a>TKEY</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
759 760 761 762 763 764 765 766 767 768 769 770 771 772
<p>
        TKEY (Transaction KEY) is a mechanism for automatically negotiating
        a shared secret between two hosts, originally specified in RFC 2930.
      </p>
<p>
        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>
<p>
        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
773
        an appropriate KEY record in the additional section, and
Tinderbox User's avatar
Tinderbox User committed
774 775 776 777 778 779 780 781 782 783 784
        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>
<p>
        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
785
      </p>
Tinderbox User's avatar
Tinderbox User committed
786
<p>
Tinderbox User's avatar
Tinderbox User committed
787 788 789 790
        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
791
      </p>
Tinderbox User's avatar
Tinderbox User committed
792 793
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
794
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
Tinderbox User's avatar
Tinderbox User committed
795
<a name="sig0"></a>SIG(0)</h2></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
796
<p>
Tinderbox User's avatar
Tinderbox User committed
797 798 799
        <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
800
        is performed in the same manner as TSIG keys; privileges can be
Tinderbox User's avatar
Tinderbox User committed
801
        granted or denied in ACL directives based on the key name.
Rob Austein's avatar
regen  
Rob Austein committed
802
      </p>
Tinderbox User's avatar
Tinderbox User committed
803
<p>
Rob Austein's avatar
regen  
Rob Austein committed
804
        When a SIG(0) signed message is received, it will only be
Tinderbox User's avatar
Tinderbox User committed
805 806 807
        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
808
      </p>
Tinderbox User's avatar
Tinderbox User committed
809
<p>
Tinderbox User's avatar
Tinderbox User committed
810
        SIG(0) signing of multiple-message TCP streams is not supported.
Rob Austein's avatar
regen  
Rob Austein committed
811
      </p>
Tinderbox User's avatar
Tinderbox User committed
812
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
813
        The only tool shipped with <acronym class="acronym">BIND</acronym> 9 that
Evan Hunt's avatar
Evan Hunt committed
814
        generates SIG(0) signed messages is <span class="command"><strong>nsupdate</strong></span>.
Rob Austein's avatar
regen  
Rob Austein committed
815
      </p>
Tinderbox User's avatar
Tinderbox User committed
816 817
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
818 819
<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
820
<p>
Rob Austein's avatar
regen  
Rob Austein committed
821 822
        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
823
        defined in RFC 4033, RFC 4034, and RFC 4035.
Mark Andrews's avatar
gregen  
Mark Andrews committed
824
        This section describes the creation and use of DNSSEC signed zones.
Rob Austein's avatar
regen  
Rob Austein committed
825
      </p>
Tinderbox User's avatar
Tinderbox User committed
826
<p>
Rob Austein's avatar
regen  
Rob Austein committed
827
        In order to set up a DNSSEC secure zone, there are a series
Mark Andrews's avatar
regen  
Mark Andrews committed
828
        of steps which must be followed.  <acronym class="acronym">BIND</acronym>
Rob Austein's avatar
regen  
Rob Austein committed
829 830 831 832 833 834
        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
835
        directory specified by the <code class="option">-d</code> option, and
Rob Austein's avatar
regen  
Rob Austein committed
836 837 838
        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
839
<p>
Rob Austein's avatar
regen  
Rob Austein committed
840 841 842
        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
843
        resolver to trust its data.  This is done through the presence
Rob Austein's avatar
regen  
Rob Austein committed
844 845 846 847
        or absence of a <code class="literal">DS</code> record at the
        delegation
        point.
      </p>
Tinderbox User's avatar
Tinderbox User committed
848
<p>
Rob Austein's avatar
regen  
Rob Austein committed
849 850 851 852
        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
853
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
854
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
855
<a name="dnssec_keys"></a>Generating Keys</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
856
<p>
Evan Hunt's avatar
Evan Hunt committed
857
          The <span class="command"><strong>dnssec-keygen</strong></span> program is used to
Rob Austein's avatar
regen  
Rob Austein committed
858 859
          generate keys.
        </p>
Tinderbox User's avatar
Tinderbox User committed
860
<p>
Rob Austein's avatar
regen  
Rob Austein committed
861 862 863 864
          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
Evan Hunt's avatar
Evan Hunt committed
865
          <span class="command"><strong>ZONE</strong></span>, and must be usable for
Rob Austein's avatar
regen  
Rob Austein committed
866 867 868 869 870
          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>
Tinderbox User's avatar
Tinderbox User committed
871
<p>
Mark Andrews's avatar
regen  
Mark Andrews committed
872
          The following command will generate a 768-bit RSASHA1 key for
Rob Austein's avatar
regen  
Rob Austein committed
873 874
          the <code class="filename">child.example</code> zone:
        </p>
Tinderbox User's avatar
Tinderbox User committed
875
<p>
Rob Austein's avatar
regen  
Rob Austein committed
876 877
          <strong class="userinput"><code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</code></strong>
        </p>
Tinderbox User's avatar
Tinderbox User committed
878
<p>
Rob Austein's avatar
regen  
Rob Austein committed
879 880 881 882
          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
883
          12345 is an example of a key tag).  The key filenames contain
Rob Austein's avatar
regen  
Rob Austein committed
884 885 886 887 888 889 890 891 892 893
          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>
Tinderbox User's avatar
Tinderbox User committed
894
<p>
Rob Austein's avatar
regen  
Rob Austein committed
895 896 897
          To generate another key with the same properties (but with
          a different key tag), repeat the above command.
        </p>
Tinderbox User's avatar
Tinderbox User committed
898
<p>
Evan Hunt's avatar
Evan Hunt committed
899
          The <span class="command"><strong>dnssec-keyfromlabel</strong></span> program is used
Automatic Updater's avatar
regen  
Automatic Updater committed
900
          to get a key pair from a crypto hardware and build the key
Evan Hunt's avatar
Evan Hunt committed
901
          files. Its usage is similar to <span class="command"><strong>dnssec-keygen</strong></span>.
Automatic Updater's avatar
regen  
Automatic Updater committed
902
        </p>
Tinderbox User's avatar
Tinderbox User committed
903
<p>
Rob Austein's avatar
regen  
Rob Austein committed
904 905
          The public keys should be inserted into the zone file by
          including the <code class="filename">.key</code> files using
Evan Hunt's avatar
Evan Hunt committed
906
          <span class="command"><strong>$INCLUDE</strong></span> statements.
Rob Austein's avatar
regen  
Rob Austein committed
907
        </p>
Tinderbox User's avatar
Tinderbox User committed
908 909
</div>
<div class="section">
Rob Austein's avatar
regen  
Rob Austein committed
910
<div class="titlepage"><div><div><h3 class="title">
Tinderbox User's avatar
Tinderbox User committed
911
<a name="dnssec_signing"></a>Signing the Zone</h3></div></div></div>
Tinderbox User's avatar
Tinderbox User committed
912
<p>
Evan Hunt's avatar
Evan Hunt committed