Bv9ARM.ch04.html revision 162933bac8fec492e683b1c09224344e568191e5
c25203fdca093d4504c51b4cd974ff60d5aa4fb1wrowe - Copyright (C) 2004-2013 Internet Systems Consortium, Inc. ("ISC")
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj - Copyright (C) 2000-2003 Internet Software Consortium.
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj - Permission to use, copy, modify, and/or distribute this software for any
c25203fdca093d4504c51b4cd974ff60d5aa4fb1wrowe - purpose with or without fee is hereby granted, provided that the above
c25203fdca093d4504c51b4cd974ff60d5aa4fb1wrowe - copyright notice and this permission notice appear in all copies.
d89c116f82699294ca744125723651c554bc5925wrowe - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
4214e98fc9045e5010e66f9a967bd6d68f40d342aaron - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
8721697e2aece27b0e738519329f7976c72b27bfjerenkrantz - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
c25203fdca093d4504c51b4cd974ff60d5aa4fb1wrowe - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
91cacb801f6c0215b38322f6d2fc58cbfedfecfbjerenkrantz - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
91cacb801f6c0215b38322f6d2fc58cbfedfecfbjerenkrantz - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
df14f0d3a5191cdd7c4bb5b03acd135d43a6f51brbb - PERFORMANCE OF THIS SOFTWARE.
ab71b233b3a36489e44a7b061c48293be0b17788jwoolley<!-- $Id$ -->
9180a5933673ffb1af633c255ceee029340f3b1erbb<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
9bd71e35f5d26d26d23fe3a677401828e842ed72wrowe<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
2900ab946a2d76b73a14cebfe2985d253f01c967stoddard<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
a548c09e6a8ca1b059d0e93b5256c6ccb2b3c3cdrbb<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
a548c09e6a8ca1b059d0e93b5256c6ccb2b3c3cdrbb<link rel="prev" href="Bv9ARM.ch03.html" title="Chapter�3.�Name Server Configuration">
a548c09e6a8ca1b059d0e93b5256c6ccb2b3c3cdrbb<link rel="next" href="Bv9ARM.ch05.html" title="Chapter�5.�The BIND 9 Lightweight Resolver">
cf6bf6c34c936e6a6fe731dbce4a5c3c8bf8e9a3gstein<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
8dd4618c4709236b4ea297d7250d282e463ce2d8rbb<tr><th colspan="3" align="center">Chapter�4.�Advanced DNS Features</th></tr>
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj<td width="20%" align="right">�<a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
10270f6f94b2069d0d357805c140a9897449b9ccianh<a name="Bv9ARM.ch04"></a>Chapter�4.�Advanced DNS Features</h2></div></div></div>
0d2f57cf389a981efa5e98d9b451c6baf0af12bfjerenkrantz<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
5ca8e11fadb6f7a8d9d0367c1800205c99d4bcd6jerenkrantz<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
4b62424416882687387923b3130b96241503cbe0jerenkrantz<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
4b62424416882687387923b3130b96241503cbe0jerenkrantz<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
e96626975ebc300abc02202f98296f2774e04367brianp<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571285">Split DNS</a></span></dt>
e96626975ebc300abc02202f98296f2774e04367brianp<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571303">Example split DNS setup</a></span></dt></dl></dd>
e96626975ebc300abc02202f98296f2774e04367brianp<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
0d2f57cf389a981efa5e98d9b451c6baf0af12bfjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571873">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
0d2f57cf389a981efa5e98d9b451c6baf0af12bfjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563959">Copying the Shared Secret to Both Machines</a></span></dt>
0d2f57cf389a981efa5e98d9b451c6baf0af12bfjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563970">Informing the Servers of the Key's Existence</a></span></dt>
a12b7938cf47a0017a70ba195bbce035aa040e38aaron<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564006">Instructing the Server to Use the Key</a></span></dt>
a12b7938cf47a0017a70ba195bbce035aa040e38aaron<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564064">TSIG Key Based Access Control</a></span></dt>
a12b7938cf47a0017a70ba195bbce035aa040e38aaron<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564113">Errors</a></span></dt>
f49387f556886ad6a6b4efc724ed9aa1d3412228jerenkrantz<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2564126">TKEY</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572368">SIG(0)</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572504">Generating Keys</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572651">Signing the Zone</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572801">Configuring Servers</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dnssec.dynamic.zones">DNSSEC, Dynamic Zones, and Automatic Signing</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611074">Converting from insecure to secure</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611111">Dynamic DNS update method</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563497">Fully automatic zone signing</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563669">Private-type records</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563774">DNSKEY rollovers</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563787">Dynamic DNS update method</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563820">Automatic key rollovers</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563915">NSEC3PARAM rollovers via UPDATE</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563925">Converting from NSEC to NSEC3</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563934">Converting from NSEC3 to NSEC</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563947">Converting from secure to insecure</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571972">Periodic re-signing</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571981">NSEC3 and OPTOUT</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect1"><a href="Bv9ARM.ch04.html#rfc5011.support">Dynamic Trust Anchor Management</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572151">Validating Resolver</a></span></dt>
f4cb04eb78da02a38fcdd87489dc7b660107d55fjerenkrantz<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572173">Authoritative Server</a></span></dt>
a23b1c5a74208b03884c09a6f9dd5d6c97fa6415trawick<dt><span class="sect1"><a href="Bv9ARM.ch04.html#pkcs11">PKCS #11 (Cryptoki) support</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2655562">Prerequisites</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611760">Building BIND 9 with PKCS#11</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2638235">PKCS #11 Tools</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2638266">Using the HSM</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2638465">Specifying the engine on the command line</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2638647">Running named with automatic zone re-signing</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dlz-info">DLZ (Dynamically Loadable Zones)</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2655544">Configuring DLZ</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611048">Sample DLZ Driver</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572956">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573086">Address Lookups Using AAAA Records</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573176">Address to Name Lookups Using Nibble Format</a></span></dt>
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe<div class="titlepage"><div><div><h2 class="title" style="clear: both">
638a9edaf48cf003cd40ac25ee8c25f572107414stoddard <acronym class="acronym">DNS</acronym> NOTIFY is a mechanism that allows master
638a9edaf48cf003cd40ac25ee8c25f572107414stoddard servers to notify their slave servers of changes to a zone's data. In
83d91d60d00dc345bfbcbc48ff206db4a6b23b2eaaron response to a <span><strong class="command">NOTIFY</strong></span> from a master server, the
83d91d60d00dc345bfbcbc48ff206db4a6b23b2eaaron slave will check to see that its version of the zone is the
83d91d60d00dc345bfbcbc48ff206db4a6b23b2eaaron current version and, if not, initiate a zone transfer.
83d91d60d00dc345bfbcbc48ff206db4a6b23b2eaaron For more information about <acronym class="acronym">DNS</acronym>
83d91d60d00dc345bfbcbc48ff206db4a6b23b2eaaron <span><strong class="command">NOTIFY</strong></span>, see the description of the
83d91d60d00dc345bfbcbc48ff206db4a6b23b2eaaron <span><strong class="command">notify</strong></span> option in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</a> and
db2d668e6233d8949b35ee7f9f42f444758f9ce9rbb the description of the zone option <span><strong class="command">also-notify</strong></span> in
db2d668e6233d8949b35ee7f9f42f444758f9ce9rbb <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>. The <span><strong class="command">NOTIFY</strong></span>
db2d668e6233d8949b35ee7f9f42f444758f9ce9rbb protocol is specified in RFC 1996.
db2d668e6233d8949b35ee7f9f42f444758f9ce9rbb<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
db2d668e6233d8949b35ee7f9f42f444758f9ce9rbb As a slave zone can also be a master to other slaves, <span><strong class="command">named</strong></span>,
1ea5221b240a8b41a07c6fb04aab5a73adcddabfaaron by default, sends <span><strong class="command">NOTIFY</strong></span> messages for every zone
1ea5221b240a8b41a07c6fb04aab5a73adcddabfaaron it loads. Specifying <span><strong class="command">notify master-only;</strong></span> will
1ea5221b240a8b41a07c6fb04aab5a73adcddabfaaron cause <span><strong class="command">named</strong></span> to only send <span><strong class="command">NOTIFY</strong></span> for master
1ea5221b240a8b41a07c6fb04aab5a73adcddabfaaron zones that it loads.
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz<div class="titlepage"><div><div><h2 class="title" style="clear: both">
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz<a name="dynamic_update"></a>Dynamic Update</h2></div></div></div>
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz Dynamic Update is a method for adding, replacing or deleting
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz records in a master server by sending it a special form of DNS
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz messages. The format and meaning of these messages is specified
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz in RFC 2136.
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz Dynamic update is enabled by including an
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz <span><strong class="command">allow-update</strong></span> or an <span><strong class="command">update-policy</strong></span>
5d12baef135b5d3cb94745e007a1575398469724jerenkrantz clause in the <span><strong class="command">zone</strong></span> statement.
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz If the zone's <span><strong class="command">update-policy</strong></span> is set to
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz <strong class="userinput"><code>local</code></strong>, updates to the zone
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz will be permitted for the key <code class="varname">local-ddns</code>,
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz which will be generated by <span><strong class="command">named</strong></span> at startup.
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz See <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called “Dynamic Update Policies”</a> for more details.
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz Dynamic updates using Kerberos signed requests can be made
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz using the TKEY/GSS protocol by setting either the
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz <span><strong class="command">tkey-gssapi-keytab</strong></span> option, or alternatively
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz by setting both the <span><strong class="command">tkey-gssapi-credential</strong></span>
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz and <span><strong class="command">tkey-domain</strong></span> options. Once enabled,
b865daaa4ef731a7066ee6d97e2aae36c7743939jerenkrantz Kerberos signed requests will be matched against the update
dc098c7ce5d36179c504d09fc722d190683d0262aaron policies for the zone, using the Kerberos principal as the
dc098c7ce5d36179c504d09fc722d190683d0262aaron signer for the request.
dc098c7ce5d36179c504d09fc722d190683d0262aaron Updating of secure zones (zones using DNSSEC) follows RFC
dc098c7ce5d36179c504d09fc722d190683d0262aaron 3007: RRSIG, NSEC and NSEC3 records affected by updates are
dc098c7ce5d36179c504d09fc722d190683d0262aaron automatically regenerated by the server using an online
364dfd4527e6ce37b828a42e2c0bbdf9ba19a9b8gregames zone key. Update authorization is based on transaction
364dfd4527e6ce37b828a42e2c0bbdf9ba19a9b8gregames signatures and an explicit server policy.
0bcb1fe39dfaacf9745b6633f5cc9ebc8e2596caaaron<a name="journal"></a>The journal file</h3></div></div></div>
0bcb1fe39dfaacf9745b6633f5cc9ebc8e2596caaaron All changes made to a zone using dynamic update are stored
0bcb1fe39dfaacf9745b6633f5cc9ebc8e2596caaaron in the zone's journal file. This file is automatically created
262bfa74293f7bc2049b4cd525875c8775711ca2aaron by the server when the first dynamic update takes place.
262bfa74293f7bc2049b4cd525875c8775711ca2aaron The name of the journal file is formed by appending the extension
262bfa74293f7bc2049b4cd525875c8775711ca2aaron corresponding zone
262bfa74293f7bc2049b4cd525875c8775711ca2aaron file unless specifically overridden. The journal file is in a
262bfa74293f7bc2049b4cd525875c8775711ca2aaron binary format and should not be edited manually.
5842e6b336b1cc0252b6cc2944dd81c7d3a19a1bbrianp The server will also occasionally write ("dump")
262bfa74293f7bc2049b4cd525875c8775711ca2aaron the complete contents of the updated zone to its zone file.
33f5961d34a8b5390cebad0543b3ebe67830e5d7jerenkrantz This is not done immediately after
33f5961d34a8b5390cebad0543b3ebe67830e5d7jerenkrantz each dynamic update, because that would be too slow when a large
33f5961d34a8b5390cebad0543b3ebe67830e5d7jerenkrantz zone is updated frequently. Instead, the dump is delayed by
33f5961d34a8b5390cebad0543b3ebe67830e5d7jerenkrantz up to 15 minutes, allowing additional updates to take place.
33f5961d34a8b5390cebad0543b3ebe67830e5d7jerenkrantz During the dump process, transient files will be created
33f5961d34a8b5390cebad0543b3ebe67830e5d7jerenkrantz with the extensions <code class="filename">.jnw</code> and
ff42f83cbf31893bcde9712332a8e5ee970f6a74trawick <code class="filename">.jbk</code>; under ordinary circumstances, these
ff42f83cbf31893bcde9712332a8e5ee970f6a74trawick will be removed when the dump is complete, and can be safely
54e1babd5a5a56c576eeeace54110150769cc916coar When a server is restarted after a shutdown or crash, it will replay
54e1babd5a5a56c576eeeace54110150769cc916coar the journal file to incorporate into the zone any updates that
54e1babd5a5a56c576eeeace54110150769cc916coar place after the last zone dump.
54e1babd5a5a56c576eeeace54110150769cc916coar Changes that result from incoming incremental zone transfers are
54e1babd5a5a56c576eeeace54110150769cc916coar journalled in a similar way.
54e1babd5a5a56c576eeeace54110150769cc916coar The zone files of dynamic zones cannot normally be edited by
949aa7bba7f804faa8e6b08cad42a98fc0255d85jerenkrantz hand because they are not guaranteed to contain the most recent
949aa7bba7f804faa8e6b08cad42a98fc0255d85jerenkrantz dynamic changes — those are only in the journal file.
949aa7bba7f804faa8e6b08cad42a98fc0255d85jerenkrantz The only way to ensure that the zone file of a dynamic zone
949aa7bba7f804faa8e6b08cad42a98fc0255d85jerenkrantz is up to date is to run <span><strong class="command">rndc stop</strong></span>.
e0427bf8e52a8fb920cb8b6adb5cdb3b6535b7fecoar If you have to make changes to a dynamic zone
e0427bf8e52a8fb920cb8b6adb5cdb3b6535b7fecoar manually, the following procedure will work: Disable dynamic updates
07021d9f405849228b859d9fb4b877f20e4fbba3jerenkrantz to the zone using
07021d9f405849228b859d9fb4b877f20e4fbba3jerenkrantz <span><strong class="command">rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>.
07021d9f405849228b859d9fb4b877f20e4fbba3jerenkrantz This will also remove the zone's <code class="filename">.jnl</code> file
07021d9f405849228b859d9fb4b877f20e4fbba3jerenkrantz and update the master file. Edit the zone file. Run
f126ee03179eb54308118f1ec3de5a7b461685d8aaron <span><strong class="command">rndc thaw <em class="replaceable"><code>zone</code></em></strong></span>
f126ee03179eb54308118f1ec3de5a7b461685d8aaron to reload the changed zone and re-enable dynamic updates.
f126ee03179eb54308118f1ec3de5a7b461685d8aaron<div class="titlepage"><div><div><h2 class="title" style="clear: both">
f126ee03179eb54308118f1ec3de5a7b461685d8aaron<a name="incremental_zone_transfers"></a>Incremental Zone Transfers (IXFR)</h2></div></div></div>
f126ee03179eb54308118f1ec3de5a7b461685d8aaron The incremental zone transfer (IXFR) protocol is a way for
f126ee03179eb54308118f1ec3de5a7b461685d8aaron slave servers to transfer only changed data, instead of having to
f126ee03179eb54308118f1ec3de5a7b461685d8aaron transfer the entire zone. The IXFR protocol is specified in RFC
f126ee03179eb54308118f1ec3de5a7b461685d8aaron 1995. See <a href="Bv9ARM.ch09.html#proposed_standards">Proposed Standards</a>.
109faf633e12ab0bbdd602c7addc795cce59e8addreid When acting as a master, <acronym class="acronym">BIND</acronym> 9
109faf633e12ab0bbdd602c7addc795cce59e8addreid supports IXFR for those zones
109faf633e12ab0bbdd602c7addc795cce59e8addreid where the necessary change history information is available. These
109faf633e12ab0bbdd602c7addc795cce59e8addreid include master zones maintained by dynamic update and slave zones
109faf633e12ab0bbdd602c7addc795cce59e8addreid whose data was obtained by IXFR. For manually maintained master
109faf633e12ab0bbdd602c7addc795cce59e8addreid zones, and for slave zones obtained by performing a full zone
109faf633e12ab0bbdd602c7addc795cce59e8addreid transfer (AXFR), IXFR is supported only if the option
109faf633e12ab0bbdd602c7addc795cce59e8addreid <span><strong class="command">ixfr-from-differences</strong></span> is set
109faf633e12ab0bbdd602c7addc795cce59e8addreid to <strong class="userinput"><code>yes</code></strong>.
109faf633e12ab0bbdd602c7addc795cce59e8addreid When acting as a slave, <acronym class="acronym">BIND</acronym> 9 will
109faf633e12ab0bbdd602c7addc795cce59e8addreid attempt to use IXFR unless
109faf633e12ab0bbdd602c7addc795cce59e8addreid it is explicitly disabled. For more information about disabling
4ca13a5e126946272f02637e268a8e09193c553ecoar IXFR, see the description of the <span><strong class="command">request-ixfr</strong></span> clause
4ca13a5e126946272f02637e268a8e09193c553ecoar of the <span><strong class="command">server</strong></span> statement.
48c0c81cd6fabac9d3386406d97633780365b839coar<div class="titlepage"><div><div><h2 class="title" style="clear: both">
48c0c81cd6fabac9d3386406d97633780365b839coar<a name="id2571285"></a>Split DNS</h2></div></div></div>
48c0c81cd6fabac9d3386406d97633780365b839coar Setting up different views, or visibility, of the DNS space to
48c0c81cd6fabac9d3386406d97633780365b839coar internal and external resolvers is usually referred to as a
48c0c81cd6fabac9d3386406d97633780365b839coar <span class="emphasis"><em>Split DNS</em></span> setup. There are several
48c0c81cd6fabac9d3386406d97633780365b839coar reasons an organization would want to set up its DNS this way.
b84f66c93f820824b1d5455181f55598b766319cwrowe One common reason for setting up a DNS system this way is
b84f66c93f820824b1d5455181f55598b766319cwrowe to hide "internal" DNS information from "external" clients on the
b84f66c93f820824b1d5455181f55598b766319cwrowe Internet. There is some debate as to whether or not this is actually
7fe18c15b669db9d191859695901dc4fcf3829dawrowe Internal DNS information leaks out in many ways (via email headers,
7fe18c15b669db9d191859695901dc4fcf3829dawrowe for example) and most savvy "attackers" can find the information
7fe18c15b669db9d191859695901dc4fcf3829dawrowe they need using other means.
7fe18c15b669db9d191859695901dc4fcf3829dawrowe However, since listing addresses of internal servers that
b84f66c93f820824b1d5455181f55598b766319cwrowe external clients cannot possibly reach can result in
60d567a0c2aae815ee6fc20c0d65032bea52c92cwrowe connection delays and other annoyances, an organization may
60d567a0c2aae815ee6fc20c0d65032bea52c92cwrowe choose to use a Split DNS to present a consistent view of itself
60d567a0c2aae815ee6fc20c0d65032bea52c92cwrowe to the outside world.
48c0c81cd6fabac9d3386406d97633780365b839coar Another common reason for setting up a Split DNS system is
48c0c81cd6fabac9d3386406d97633780365b839coar to allow internal networks that are behind filters or in RFC 1918
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe space (reserved IP space, as documented in RFC 1918) to resolve DNS
2fb49a1d25f38421a68d31b4cbb5d9293fdeafbewrowe on the Internet. Split DNS can also be used to allow mail from outside
60d567a0c2aae815ee6fc20c0d65032bea52c92cwrowe back in to the internal network.
60d567a0c2aae815ee6fc20c0d65032bea52c92cwrowe<a name="id2571303"></a>Example split DNS setup</h3></div></div></div>
d180ec1b29106f4fec480ef7fcdb04df078010cerse Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
3913a3b7e7c72ea11d05da36275db39c2dc39b68jwoolley has several corporate sites that have an internal network with
3913a3b7e7c72ea11d05da36275db39c2dc39b68jwoolley Internet Protocol (IP) space and an external demilitarized zone (DMZ),
57710387e669ee41fb211458efe09c4c73194a66jwoolley or "outside" section of a network, that is available to the public.
3913a3b7e7c72ea11d05da36275db39c2dc39b68jwoolley <span class="emphasis"><em>Example, Inc.</em></span> wants its internal clients
d180ec1b29106f4fec480ef7fcdb04df078010cerse to be able to resolve external hostnames and to exchange mail with
7bce59d998f2e5ca1cb60038ef6c1d0817605d62stoddard people on the outside. The company also wants its internal resolvers
49facccad3f5c3e9e49311487b5069699c3bf3fdjwoolley to have access to certain internal-only zones that are not available
7bce59d998f2e5ca1cb60038ef6c1d0817605d62stoddard at all outside of the internal network.
7bce59d998f2e5ca1cb60038ef6c1d0817605d62stoddard In order to accomplish this, the company will set up two sets
7bce59d998f2e5ca1cb60038ef6c1d0817605d62stoddard of name servers. One set will be on the inside network (in the
1b9744b72f26e9a0e935f9c08d49feb1fcce72f9jwoolley IP space) and the other set will be on bastion hosts, which are
1b9744b72f26e9a0e935f9c08d49feb1fcce72f9jwoolley hosts that can talk to both sides of its network, in the DMZ.
1b9744b72f26e9a0e935f9c08d49feb1fcce72f9jwoolley The internal servers will be configured to forward all queries,
1b9744b72f26e9a0e935f9c08d49feb1fcce72f9jwoolley except queries for <code class="filename">site1.internal</code>, <code class="filename">site2.internal</code>, <code class="filename">site1.example.com</code>,
1b9744b72f26e9a0e935f9c08d49feb1fcce72f9jwoolley and <code class="filename">site2.example.com</code>, to the servers
19cbe4d7b7c931723e7249de6829bf965a1fee72stoddard DMZ. These internal servers will have complete sets of information
19cbe4d7b7c931723e7249de6829bf965a1fee72stoddard for <code class="filename">site1.example.com</code>, <code class="filename">site2.example.com</code>, <code class="filename">site1.internal</code>,
1c6fb1e726ce22694de0e9a957adb67b929e5d4fstoddard To protect the <code class="filename">site1.internal</code> and <code class="filename">site2.internal</code> domains,
1c6fb1e726ce22694de0e9a957adb67b929e5d4fstoddard the internal name servers must be configured to disallow all queries
a5ed555df952c85bc1b179f5981e8a6c54ba16e6stoddard to these domains from any external hosts, including the bastion
0bff2f28ef945280c17099c142126178a78e1e54manoj The external servers, which are on the bastion hosts, will
0bff2f28ef945280c17099c142126178a78e1e54manoj be configured to serve the "public" version of the <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones.
0bff2f28ef945280c17099c142126178a78e1e54manoj This could include things such as the host records for public servers
1e585ba09ea32272e63c4c39c35491e975d21d98stoddard (<code class="filename">www.example.com</code> and <code class="filename">ftp.example.com</code>),
0bff2f28ef945280c17099c142126178a78e1e54manoj and mail exchange (MX) records (<code class="filename">a.mx.example.com</code> and <code class="filename">b.mx.example.com</code>).
9c09943bad734ebd5c7cc10bd6d63b75c4c6e056stoddard In addition, the public <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones
ff849e4163ed879288f0df15f78b6c9d278ec804fanf should have special MX records that contain wildcard (`*') records
ff849e4163ed879288f0df15f78b6c9d278ec804fanf pointing to the bastion hosts. This is needed because external mail
447c6ce3ff08073c44f6785d5256271fcb877512wrowe servers do not have any other way of looking up how to deliver mail
e0427bf8e52a8fb920cb8b6adb5cdb3b6535b7fecoar to those internal hosts. With the wildcard records, the mail will
e0427bf8e52a8fb920cb8b6adb5cdb3b6535b7fecoar be delivered to the bastion host, which can then forward it on to
e0427bf8e52a8fb920cb8b6adb5cdb3b6535b7fecoar internal hosts.
6758b07b4b79f898b0f56375016cea7da0bfb495wrowe Here's an example of a wildcard MX record:
7fe18c15b669db9d191859695901dc4fcf3829dawrowe<pre class="programlisting">* IN MX 10 external1.example.com.</pre>
dd4713dc5b186f4d1be7b88f86608fdb84cbe5d5gstein Now that they accept mail on behalf of anything in the internal
48c0c81cd6fabac9d3386406d97633780365b839coar network, the bastion hosts will need to know how to deliver mail
48c0c81cd6fabac9d3386406d97633780365b839coar to internal hosts. In order for this to work properly, the resolvers
48c0c81cd6fabac9d3386406d97633780365b839coar the bastion hosts will need to be configured to point to the internal
db3ccce11afac4fc1d4f51a65424412f7480c46cgstein name servers for DNS resolution.
79d5106a9b65b956d646f5daae4b94bc79e315b8trawick Queries for internal hostnames will be answered by the internal
cf6bf6c34c936e6a6fe731dbce4a5c3c8bf8e9a3gstein servers, and queries for external hostnames will be forwarded back
cf6bf6c34c936e6a6fe731dbce4a5c3c8bf8e9a3gstein out to the DNS servers on the bastion hosts.
93c5cba06b623ebe8e4372e886eece12d9a80c3egstein In order for all this to work properly, internal clients will
14cccaddba3a9263cf0d0ddc311e18f3e3dc9b0fgstein need to be configured to query <span class="emphasis"><em>only</em></span> the internal
14cccaddba3a9263cf0d0ddc311e18f3e3dc9b0fgstein name servers for DNS queries. This could also be enforced via
14cccaddba3a9263cf0d0ddc311e18f3e3dc9b0fgstein filtering on the network.
823c303d33c9e637a83d82208bcbafaf5f532d7bgstein If everything has been set properly, <span class="emphasis"><em>Example, Inc.</em></span>'s
823c303d33c9e637a83d82208bcbafaf5f532d7bgstein internal clients will now be able to:
281da4c02cf40c663298ded7e4e5b913a8f8b814gstein Look up any hostnames in the <code class="literal">site1</code>
60d567a0c2aae815ee6fc20c0d65032bea52c92cwrowe Look up any hostnames in the <code class="literal">site1.internal</code> and
60d567a0c2aae815ee6fc20c0d65032bea52c92cwrowe<li>Exchange mail with both internal and external people.</li>
60d567a0c2aae815ee6fc20c0d65032bea52c92cwrowe Hosts on the Internet will be able to:
fdff4ace2701177219fe1c444f69242372423354aaron Look up any hostnames in the <code class="literal">site1</code>
27757f6699a924d4b493a1b6cceb27df27a43287dreid Exchange mail with anyone in the <code class="literal">site1</code> and
7169eebe7cef1a6bbd082f28b1906f91b6fc6621stoddard Here is an example configuration for the setup we just
7169eebe7cef1a6bbd082f28b1906f91b6fc6621stoddard described above. Note that this is only configuration information;
21e01f13f717faeca3e498d7d9c9b4d3af98ae27trawick for information on how to configure your zone files, see <a href="Bv9ARM.ch03.html#sample_configuration" title="Sample Configurations">the section called “Sample Configurations”</a>.
21e01f13f717faeca3e498d7d9c9b4d3af98ae27trawick Internal DNS server config:
64ad864fa0f4493eebb181e393b40a8a90beccb9coaracl externals { <code class="varname">bastion-ips-go-here</code>; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar forward only;
64ad864fa0f4493eebb181e393b40a8a90beccb9coar // forward to external servers
48c0c81cd6fabac9d3386406d97633780365b839coar forwarders {
64ad864fa0f4493eebb181e393b40a8a90beccb9coar // sample allow-transfer (no one)
48c0c81cd6fabac9d3386406d97633780365b839coar allow-transfer { none; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar // restrict query access
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-query { internals; externals; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar // restrict recursion
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-recursion { internals; };
48c0c81cd6fabac9d3386406d97633780365b839coar// sample master zone
64ad864fa0f4493eebb181e393b40a8a90beccb9coar type master;
48c0c81cd6fabac9d3386406d97633780365b839coar // do normal iterative resolution (do not forward)
64ad864fa0f4493eebb181e393b40a8a90beccb9coar forwarders { };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-query { internals; externals; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-transfer { internals; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar// sample slave zone
64ad864fa0f4493eebb181e393b40a8a90beccb9coar type slave;
64ad864fa0f4493eebb181e393b40a8a90beccb9coar masters { 172.16.72.3; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar forwarders { };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-query { internals; externals; };
48c0c81cd6fabac9d3386406d97633780365b839coar allow-transfer { internals; };
48c0c81cd6fabac9d3386406d97633780365b839coar type master;
64ad864fa0f4493eebb181e393b40a8a90beccb9coar forwarders { };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-query { internals; };
48c0c81cd6fabac9d3386406d97633780365b839coar allow-transfer { internals; }
48c0c81cd6fabac9d3386406d97633780365b839coar type slave;
64ad864fa0f4493eebb181e393b40a8a90beccb9coar masters { 172.16.72.3; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar forwarders { };
48c0c81cd6fabac9d3386406d97633780365b839coar allow-query { internals };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-transfer { internals; }
64ad864fa0f4493eebb181e393b40a8a90beccb9coar External (bastion host) DNS server config:
64ad864fa0f4493eebb181e393b40a8a90beccb9coaracl externals { bastion-ips-go-here; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar // sample allow-transfer (no one)
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-transfer { none; };
48c0c81cd6fabac9d3386406d97633780365b839coar // default query access
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-query { any; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar // restrict cache access
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-query-cache { internals; externals; };
48c0c81cd6fabac9d3386406d97633780365b839coar // restrict recursion
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-recursion { internals; externals; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar// sample slave zone
48c0c81cd6fabac9d3386406d97633780365b839coar type master;
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-transfer { internals; externals; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar type slave;
48c0c81cd6fabac9d3386406d97633780365b839coar masters { another_bastion_host_maybe; };
64ad864fa0f4493eebb181e393b40a8a90beccb9coar allow-transfer { internals; externals; }
64ad864fa0f4493eebb181e393b40a8a90beccb9coar In the <code class="filename">resolv.conf</code> (or equivalent) on
64ad864fa0f4493eebb181e393b40a8a90beccb9coar the bastion host(s):
64ad864fa0f4493eebb181e393b40a8a90beccb9coarnameserver 172.16.72.2
64ad864fa0f4493eebb181e393b40a8a90beccb9coarnameserver 172.16.72.3
48c0c81cd6fabac9d3386406d97633780365b839coarnameserver 172.16.72.4
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<div class="titlepage"><div><div><h2 class="title" style="clear: both">
48c0c81cd6fabac9d3386406d97633780365b839coar This is a short guide to setting up Transaction SIGnatures
64ad864fa0f4493eebb181e393b40a8a90beccb9coar (TSIG) based transaction security in <acronym class="acronym">BIND</acronym>. It describes changes
64ad864fa0f4493eebb181e393b40a8a90beccb9coar to the configuration file as well as what changes are required for
64ad864fa0f4493eebb181e393b40a8a90beccb9coar different features, including the process of creating transaction
48c0c81cd6fabac9d3386406d97633780365b839coar keys and using transaction signatures with <acronym class="acronym">BIND</acronym>.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar <acronym class="acronym">BIND</acronym> primarily supports TSIG for server
48c0c81cd6fabac9d3386406d97633780365b839coar to server communication.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar This includes zone transfer, notify, and recursive query messages.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar Resolvers based on newer versions of <acronym class="acronym">BIND</acronym> 8 have limited support
64ad864fa0f4493eebb181e393b40a8a90beccb9coar TSIG can also be useful for dynamic update. A primary
64ad864fa0f4493eebb181e393b40a8a90beccb9coar server for a dynamic zone should control access to the dynamic
48c0c81cd6fabac9d3386406d97633780365b839coar update service, but IP-based access control is insufficient.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar The cryptographic access control provided by TSIG
6694e265e9a71ceaedbe1f1aa4db4d9ba42fb866wrowe is far superior. The <span><strong class="command">nsupdate</strong></span>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar program supports TSIG via the <code class="option">-k</code> and
48c0c81cd6fabac9d3386406d97633780365b839coar <code class="option">-y</code> command line options or inline by use
64ad864fa0f4493eebb181e393b40a8a90beccb9coar of the <span><strong class="command">key</strong></span>.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<a name="id2571873"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
48c0c81cd6fabac9d3386406d97633780365b839coar An arbitrary key name is chosen: "host1-host2.". The key name must
64ad864fa0f4493eebb181e393b40a8a90beccb9coar be the same on both hosts.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<a name="id2571890"></a>Automatic Generation</h4></div></div></div>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar The following command will generate a 128-bit (16 byte) HMAC-SHA256
48c0c81cd6fabac9d3386406d97633780365b839coar key as described above. Longer keys are better, but shorter keys
64ad864fa0f4493eebb181e393b40a8a90beccb9coar are easier to read. Note that the maximum key length is the digest
64ad864fa0f4493eebb181e393b40a8a90beccb9coar length, here 256 bits.
48c0c81cd6fabac9d3386406d97633780365b839coar <strong class="userinput"><code>dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2.</code></strong>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar The key is in the file <code class="filename">Khost1-host2.+163+00000.private</code>.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar Nothing directly uses this file, but the base-64 encoded string
64ad864fa0f4493eebb181e393b40a8a90beccb9coar can be extracted from the file and used as a shared secret:
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<pre class="programlisting">Key: La/E5CjG9O+os1jq0a2jdA==</pre>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar The string "<code class="literal">La/E5CjG9O+os1jq0a2jdA==</code>" can
64ad864fa0f4493eebb181e393b40a8a90beccb9coar be used as the shared secret.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<a name="id2571928"></a>Manual Generation</h4></div></div></div>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar The shared secret is simply a random sequence of bits, encoded
64ad864fa0f4493eebb181e393b40a8a90beccb9coar in base-64. Most ASCII strings are valid base-64 strings (assuming
64ad864fa0f4493eebb181e393b40a8a90beccb9coar the length is a multiple of 4 and only valid characters are used),
48c0c81cd6fabac9d3386406d97633780365b839coar so the shared secret can be manually generated.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar Also, a known string can be run through <span><strong class="command">mmencode</strong></span> or
64ad864fa0f4493eebb181e393b40a8a90beccb9coar a similar program to generate base-64 encoded data.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<a name="id2563959"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar This is beyond the scope of DNS. A secure transport mechanism
48c0c81cd6fabac9d3386406d97633780365b839coar should be used. This could be secure FTP, ssh, telephone, etc.
48c0c81cd6fabac9d3386406d97633780365b839coar<a name="id2563970"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span>
48c0c81cd6fabac9d3386406d97633780365b839coar both servers. The following is added to each server's <code class="filename">named.conf</code> file:
64ad864fa0f4493eebb181e393b40a8a90beccb9coarkey host1-host2. {
48c0c81cd6fabac9d3386406d97633780365b839coar algorithm hmac-sha256;
64ad864fa0f4493eebb181e393b40a8a90beccb9coar The secret is the one generated above. Since this is a secret, it
64ad864fa0f4493eebb181e393b40a8a90beccb9coar is recommended that either <code class="filename">named.conf</code> be
64ad864fa0f4493eebb181e393b40a8a90beccb9coar non-world readable, or the key directive be added to a non-world
48c0c81cd6fabac9d3386406d97633780365b839coar readable file that is included by <code class="filename">named.conf</code>.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar At this point, the key is recognized. This means that if the
48c0c81cd6fabac9d3386406d97633780365b839coar server receives a message signed by this key, it can verify the
64ad864fa0f4493eebb181e393b40a8a90beccb9coar signature. If the signature is successfully verified, the
64ad864fa0f4493eebb181e393b40a8a90beccb9coar response is signed by the same key.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<a name="id2564006"></a>Instructing the Server to Use the Key</h3></div></div></div>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar Since keys are shared between two hosts only, the server must
64ad864fa0f4493eebb181e393b40a8a90beccb9coar be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file
64ad864fa0f4493eebb181e393b40a8a90beccb9coar for <span class="emphasis"><em>host1</em></span>, if the IP address of <span class="emphasis"><em>host2</em></span> is
64ad864fa0f4493eebb181e393b40a8a90beccb9coarserver 10.1.2.3 {
48c0c81cd6fabac9d3386406d97633780365b839coar keys { host1-host2. ;};
48c0c81cd6fabac9d3386406d97633780365b839coar Multiple keys may be present, but only the first is used.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar This directive does not contain any secrets, so it may be in a
64ad864fa0f4493eebb181e393b40a8a90beccb9coar world-readable
64ad864fa0f4493eebb181e393b40a8a90beccb9coar If <span class="emphasis"><em>host1</em></span> sends a message that is a request
64ad864fa0f4493eebb181e393b40a8a90beccb9coar to that address, the message will be signed with the specified key. <span class="emphasis"><em>host1</em></span> will
48c0c81cd6fabac9d3386406d97633780365b839coar expect any responses to signed messages to be signed with the same
48c0c81cd6fabac9d3386406d97633780365b839coar A similar statement must be present in <span class="emphasis"><em>host2</em></span>'s
64ad864fa0f4493eebb181e393b40a8a90beccb9coar configuration file (with <span class="emphasis"><em>host1</em></span>'s address) for <span class="emphasis"><em>host2</em></span> to
64ad864fa0f4493eebb181e393b40a8a90beccb9coar sign request messages to <span class="emphasis"><em>host1</em></span>.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<a name="id2564064"></a>TSIG Key Based Access Control</h3></div></div></div>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar <acronym class="acronym">BIND</acronym> allows IP addresses and ranges
64ad864fa0f4493eebb181e393b40a8a90beccb9coar to be specified in ACL
64ad864fa0f4493eebb181e393b40a8a90beccb9coar definitions and
48c0c81cd6fabac9d3386406d97633780365b839coar <span><strong class="command">allow-{ query | transfer | update }</strong></span>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar directives.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar This has been extended to allow TSIG keys also. The above key would
64ad864fa0f4493eebb181e393b40a8a90beccb9coar be denoted <span><strong class="command">key host1-host2.</strong></span>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar An example of an <span><strong class="command">allow-update</strong></span> directive would be:
64ad864fa0f4493eebb181e393b40a8a90beccb9coarallow-update { key host1-host2. ;};
48c0c81cd6fabac9d3386406d97633780365b839coar This allows dynamic updates to succeed only if the request
64ad864fa0f4493eebb181e393b40a8a90beccb9coar was signed by a key named "<span><strong class="command">host1-host2.</strong></span>".
64ad864fa0f4493eebb181e393b40a8a90beccb9coar See <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called “Dynamic Update Policies”</a> for a discussion of
48c0c81cd6fabac9d3386406d97633780365b839coar the more flexible <span><strong class="command">update-policy</strong></span> statement.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar The processing of TSIG signed messages can result in
64ad864fa0f4493eebb181e393b40a8a90beccb9coar several errors. If a signed message is sent to a non-TSIG aware
48c0c81cd6fabac9d3386406d97633780365b839coar server, a FORMERR (format error) will be returned, since the server will not
64ad864fa0f4493eebb181e393b40a8a90beccb9coar understand the record. This is a result of misconfiguration,
64ad864fa0f4493eebb181e393b40a8a90beccb9coar since the server must be explicitly configured to send a TSIG
64ad864fa0f4493eebb181e393b40a8a90beccb9coar signed message to a specific server.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar If a TSIG aware server receives a message signed by an
64ad864fa0f4493eebb181e393b40a8a90beccb9coar unknown key, the response will be unsigned with the TSIG
48c0c81cd6fabac9d3386406d97633780365b839coar extended error code set to BADKEY. If a TSIG aware server
64ad864fa0f4493eebb181e393b40a8a90beccb9coar receives a message with a signature that does not validate, the
64ad864fa0f4493eebb181e393b40a8a90beccb9coar response will be unsigned with the TSIG extended error code set
64ad864fa0f4493eebb181e393b40a8a90beccb9coar to BADSIG. If a TSIG aware server receives a message with a time
48c0c81cd6fabac9d3386406d97633780365b839coar outside of the allowed range, the response will be signed with
64ad864fa0f4493eebb181e393b40a8a90beccb9coar the TSIG extended error code set to BADTIME, and the time values
64ad864fa0f4493eebb181e393b40a8a90beccb9coar will be adjusted so that the response can be successfully
64ad864fa0f4493eebb181e393b40a8a90beccb9coar verified. In any of these cases, the message's rcode (response code) is set to
48c0c81cd6fabac9d3386406d97633780365b839coar NOTAUTH (not authenticated).
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<div class="titlepage"><div><div><h2 class="title" style="clear: both">
64ad864fa0f4493eebb181e393b40a8a90beccb9coar is a mechanism for automatically generating a shared secret
48c0c81cd6fabac9d3386406d97633780365b839coar between two hosts. There are several "modes" of
64ad864fa0f4493eebb181e393b40a8a90beccb9coar <span><strong class="command">TKEY</strong></span> that specify how the key is generated
64ad864fa0f4493eebb181e393b40a8a90beccb9coar or assigned. <acronym class="acronym">BIND</acronym> 9 implements only one of
64ad864fa0f4493eebb181e393b40a8a90beccb9coar these modes, the Diffie-Hellman key exchange. Both hosts are
48c0c81cd6fabac9d3386406d97633780365b839coar required to have a Diffie-Hellman KEY record (although this
64ad864fa0f4493eebb181e393b40a8a90beccb9coar record is not required to be present in a zone). The
64ad864fa0f4493eebb181e393b40a8a90beccb9coar <span><strong class="command">TKEY</strong></span> process must use signed messages,
64ad864fa0f4493eebb181e393b40a8a90beccb9coar signed either by TSIG or SIG(0). The result of
48c0c81cd6fabac9d3386406d97633780365b839coar <span><strong class="command">TKEY</strong></span> is a shared secret that can be used to
64ad864fa0f4493eebb181e393b40a8a90beccb9coar sign messages with TSIG. <span><strong class="command">TKEY</strong></span> can also be
64ad864fa0f4493eebb181e393b40a8a90beccb9coar used to delete shared secrets that it had previously
64ad864fa0f4493eebb181e393b40a8a90beccb9coar generated.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar The <span><strong class="command">TKEY</strong></span> process is initiated by a
64ad864fa0f4493eebb181e393b40a8a90beccb9coar or server by sending a signed <span><strong class="command">TKEY</strong></span>
64ad864fa0f4493eebb181e393b40a8a90beccb9coar (including any appropriate KEYs) to a TKEY-aware server. The
64ad864fa0f4493eebb181e393b40a8a90beccb9coar server response, if it indicates success, will contain a
64ad864fa0f4493eebb181e393b40a8a90beccb9coar <span><strong class="command">TKEY</strong></span> record and any appropriate keys.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar this exchange, both participants have enough information to
64ad864fa0f4493eebb181e393b40a8a90beccb9coar determine the shared secret; the exact process depends on the
64ad864fa0f4493eebb181e393b40a8a90beccb9coar <span><strong class="command">TKEY</strong></span> mode. When using the
48c0c81cd6fabac9d3386406d97633780365b839coar Diffie-Hellman
64ad864fa0f4493eebb181e393b40a8a90beccb9coar <span><strong class="command">TKEY</strong></span> mode, Diffie-Hellman keys are
64ad864fa0f4493eebb181e393b40a8a90beccb9coar exchanged,
64ad864fa0f4493eebb181e393b40a8a90beccb9coar and the shared secret is derived by both participants.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar<div class="titlepage"><div><div><h2 class="title" style="clear: both">
64ad864fa0f4493eebb181e393b40a8a90beccb9coar <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
64ad864fa0f4493eebb181e393b40a8a90beccb9coar transaction signatures as specified in RFC 2535 and RFC 2931.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar uses public/private keys to authenticate messages. Access control
48c0c81cd6fabac9d3386406d97633780365b839coar is performed in the same manner as TSIG keys; privileges can be
64ad864fa0f4493eebb181e393b40a8a90beccb9coar granted or denied based on the key name.
64ad864fa0f4493eebb181e393b40a8a90beccb9coar When a SIG(0) signed message is received, it will only be
48c0c81cd6fabac9d3386406d97633780365b839coar verified if the key is known and trusted by the server; the server
48c0c81cd6fabac9d3386406d97633780365b839coar SIG(0) signing of multiple-message TCP streams is not
64ad864fa0f4493eebb181e393b40a8a90beccb9coar supported.
48c0c81cd6fabac9d3386406d97633780365b839coar The only tool shipped with <acronym class="acronym">BIND</acronym> 9 that
64ad864fa0f4493eebb181e393b40a8a90beccb9coar generates SIG(0) signed messages is <span><strong class="command">nsupdate</strong></span>.
6758b07b4b79f898b0f56375016cea7da0bfb495wrowe<div class="titlepage"><div><div><h2 class="title" style="clear: both">
64ad864fa0f4493eebb181e393b40a8a90beccb9coar Cryptographic authentication of DNS information is possible
64ad864fa0f4493eebb181e393b40a8a90beccb9coar through the DNS Security (<span class="emphasis"><em>DNSSEC-bis</em></span>) extensions,
48c0c81cd6fabac9d3386406d97633780365b839coar defined in RFC 4033, RFC 4034, and RFC 4035.
28d1da9ca818f831ea491f110dafcc10f7f07050coar This section describes the creation and use of DNSSEC signed zones.
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj In order to set up a DNSSEC secure zone, there are a series
d5defd5a0c5cdbaf74b85939484dc2b6c8317d19manoj of steps which must be followed. <acronym class="acronym">BIND</acronym>
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj with several tools
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj that are used in this process, which are explained in more detail
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj below. In all cases, the <code class="option">-h</code> option prints a
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj full list of parameters. Note that the DNSSEC tools require the
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj keyset files to be in the working directory or the
6758b07b4b79f898b0f56375016cea7da0bfb495wrowe directory specified by the <code class="option">-d</code> option, and
6758b07b4b79f898b0f56375016cea7da0bfb495wrowe that the tools shipped with BIND 9.2.x and earlier are not compatible
6758b07b4b79f898b0f56375016cea7da0bfb495wrowe with the current ones.
0bff2f28ef945280c17099c142126178a78e1e54manoj There must also be communication with the administrators of
0bff2f28ef945280c17099c142126178a78e1e54manoj the parent and/or child zone to transmit keys. A zone's security
d6b3cb141f0667101c1bca883ad15b383402c93bfielding status must be indicated by the parent zone for a DNSSEC capable
ec0315cdf832eac2b78e50ad636af84fe4c9118cgstein resolver to trust its data. This is done through the presence
ec0315cdf832eac2b78e50ad636af84fe4c9118cgstein or absence of a <code class="literal">DS</code> record at the
ec0315cdf832eac2b78e50ad636af84fe4c9118cgstein For other servers to trust data in this zone, they must
ec0315cdf832eac2b78e50ad636af84fe4c9118cgstein either be statically configured with this zone's zone key or the
ec0315cdf832eac2b78e50ad636af84fe4c9118cgstein zone key of another zone above this one in the DNS tree.
40a5b7189dbbb28e107bf008ee625f2f0142c2ccdgaudet<a name="id2572504"></a>Generating Keys</h3></div></div></div>
dbf0c7bef06259486cd2748a2d0e82f27e099d6efielding The <span><strong class="command">dnssec-keygen</strong></span> program is used to
dbf0c7bef06259486cd2748a2d0e82f27e099d6efielding generate keys.
3e17185356213124b2e18ecaf1678a676f8e9ba5rbb A secure zone must contain one or more zone keys. The
3e17185356213124b2e18ecaf1678a676f8e9ba5rbb zone keys will sign all other records in the zone, as well as
48c0c81cd6fabac9d3386406d97633780365b839coar the zone keys of any secure delegated zones. Zone keys must
48c0c81cd6fabac9d3386406d97633780365b839coar have the same name as the zone, a name type of
3e17185356213124b2e18ecaf1678a676f8e9ba5rbb <span><strong class="command">ZONE</strong></span>, and must be usable for
863ec32e13d6c9619414c48b51109f3dca99cbc6wrowe authentication.
863ec32e13d6c9619414c48b51109f3dca99cbc6wrowe It is recommended that zone keys use a cryptographic algorithm
863ec32e13d6c9619414c48b51109f3dca99cbc6wrowe designated as "mandatory to implement" by the IETF; currently
863ec32e13d6c9619414c48b51109f3dca99cbc6wrowe the only one is RSASHA1.
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj The following command will generate a 768-bit RSASHA1 key for
ae6907470ddf23ab7c6b506e6407cc5372f9c0dftrawick <strong class="userinput"><code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</code></strong>
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj Two output files will be produced:
ef7ff29d74b8684761de5758423f1cc5a49f48e3rbb <code class="filename">Kchild.example.+005+12345.key</code> and
ef7ff29d74b8684761de5758423f1cc5a49f48e3rbb <code class="filename">Kchild.example.+005+12345.private</code>
ef7ff29d74b8684761de5758423f1cc5a49f48e3rbb 12345 is an example of a key tag). The key filenames contain
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj the key name (<code class="filename">child.example.</code>),
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj algorithm (3
2a6c49cfaef5979a5a06098f3ce987cd76769409manoj is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
<strong class="userinput"><code>yes</code></strong> or <strong class="userinput"><code>auto</code></strong>.
example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
<a name="dnssec.dynamic.zones"></a>DNSSEC, Dynamic Zones, and Automatic Signing</h2></div></div></div>
zone example.net {
> update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfBfL8eQ8al35zz3Y I1m/SAQBxIqMfLtIwqWPdgthsu36azGQAX8=
> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
> update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfBfL8eQ8al35zz3Y I1m/SAQBxIqMfLtIwqWPdgthsu36azGQAX8=
> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
> update add example.net NSEC3PARAM 1 1 100 1234567890
(See <a href="man.dnssec-keygen.html" title="dnssec-keygen"><span class="refentrytitle"><span class="application">dnssec-keygen</span></span>(8)</a> and
<a href="man.dnssec-settime.html" title="dnssec-settime"><span class="refentrytitle"><span class="application">dnssec-settime</span></span>(8)</a> for more information.)
<span><strong class="command">rndc sign</strong></span> or <span><strong class="command">rndc loadkeys</strong></span>
<span><strong class="command">dnssec-keygen</strong></span> or <span><strong class="command">dnssec-settime</strong></span>),
and Usage">the section called “<span><strong class="command">managed-keys</strong></span> Statement Definition
$ <strong class="userinput"><code>dnssec-keygen -K keys -f KSK -P now -A now+2y example.net</code></strong>
$ <strong class="userinput"><code>wget <a href="" target="_top">http://www.openssl.org/source/openssl-0.9.8s.tar.gz</a></code></strong>
$ <strong class="userinput"><code>cp pkcs11.GCC4.0.2.so.4.05 /opt/pkcs11/usr/lib/libpkcs11.so</code></strong>
and "<span><strong class="command">make test</strong></span>". If "<span><strong class="command">make
project (http://www.opendnssec.org) which provides a PKCS#11
$ <strong class="userinput"><code> echo "0:/opt/pkcs11/softhsm.db" > $SOFTHSM_CONF </code></strong>
$ <strong class="userinput"><code> /opt/pkcs11/usr/bin/softhsm --init-token 0 --slot 0 --label softhsm </code></strong>
$ <strong class="userinput"><code>export LD_LIBRARY_PATH=/opt/pkcs11/usr/lib:${LD_LIBRARY_PATH}</code></strong>
$ <strong class="userinput"><code>export KEYPER_LIBRARY_PATH=/opt/Keyper/PKCS11Provider</code></strong>
$ <strong class="userinput"><code>dnssec-keyfromlabel -l sample-ksk -f KSK example.net</code></strong>
by placing the PIN into the openssl.cnf file (in the above
dynamically-linkable DLZ module--i.e., one which can be
"example.nil", which can answer queries and AXFR requests, and
example.nil. 1800 IN A 10.53.0.1
e.g., by providing different address records for a particular name
<a name="id2572956"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
see <a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (AAAA)">the section called “IPv6 addresses (AAAA)”</a>.
$ORIGIN example.com.