Bv9ARM.4.html revision 40f53fa8d9c6a4fc38c0014495e7a42b08f52481
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
75c0816e8295e180f4bc7f10db3d0d880383bc1cMark Andrews - Copyright (C) 2000 Internet Software Consortium.
4a14ce5ba00ab7bc55c99ffdcf59c7a4ab902721Automatic Updater - Permission to use, copy, modify, and distribute this software for any
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - purpose with or without fee is hereby granted, provided that the above
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - copyright notice and this permission notice appear in all copies.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT,
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein - WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein<!-- $Id: Bv9ARM.4.html,v 1.10 2000/08/01 01:17:52 tale Exp $ -->
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein<META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein<TITLE> Section 4. Advanced Concepts</TITLE></HEAD>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinSection 4. Advanced Concepts</H1>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinDynamic Update</H3>
75c0816e8295e180f4bc7f10db3d0d880383bc1cMark AndrewsDynamic update is the term used for the ability under certain specified conditions to add, modify or delete records or RRsets in the master zone files. Dynamic update is fully described in RFC 2136.</P>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinDynamic update is enabled on a zone-by-zone basis, by including an <CODE CLASS="Program-Process">
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austeinallow-update</CODE>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austeinupdate-policy</CODE>
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox User statement.</P>
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox UserUpdating of secure zones (zones using DNSSEC) is modelled after the <EM CLASS="Emphasis">
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox Usersimple-secure-update</EM>
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox User proposal, a work in progress in the DNS Extensions working group of the IETF. (See<BR>
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox User<A HREF="http://www.ietf.org/html.charters/dnsext-charter.html">http://www.ietf.org/html.charters/dnsext-charter.html</A></EM>
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox User for information about the DNS Extensions working group.) SIG and NXT records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based on transaction signatures and an explicit server policy.</P>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinThe zone files of dynamic zones must not be edited by hand. The zone file on disk at any given time may not contain the latest changes performed by dynamic update. The zone file is written to disk only periodically, and changes that have occurred since the zone file was last written to disk are stored only in the zone's journal (<EM CLASS="pathname">
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox User) file. BIND 9 currently does not update the zone file when it exits as BIND 8 does, so editing the zone file manually is unsafe even when the server has been shut down. </P>
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox UserIncremental Zone Transfers (IXFR)</H3>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinThe 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 documented in RFC 1995. See the list of proposed standards in <A HREF="Bv9ARM.9.html#17631" CLASS="XRef">Appendix C
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinWhen acting as a master, BIND 9 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, but not manually maintained master zones nor slave zones obtained by performing a full zone transfer (AXFR).</P>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinWhen acting as a slave, BIND 9 will attempt to use IXFR unless it is explicitly disabled. For more information about disabling IXFR, see the description of the <CODE CLASS="Program-Process">
5d564da348e890e42f63eebf2dced9a05b41f4fbTinderbox Userrequest-ixfr</CODE>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austeinserver</CODE>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein statement.</P>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein4.3 Split DNS</H3>
5d564da348e890e42f63eebf2dced9a05b41f4fbTinderbox UserSetting up different views, or visibility, of DNS space to internal and external resolvers is usually referred to as a <EM CLASS="Emphasis">
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox UserSplit DNS</EM>
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox User setup. There are several reasons an organization would want to set up its DNS this way.</P>
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserOne 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.</P>
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserAnother 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>
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserHere is an example of a split DNS setup:</P>
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserLet's say a company named <EM CLASS="Emphasis">
6f64d4ab8e68f9b2333bcbfc755396d29a4a9d7cAutomatic UpdaterExample, Inc.</EM>
44d0f0256fbdce130a18655023c3b06bacacbd61Automatic Updater (example.com) 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>
bbbf2e27d3a981163dab139497d6b2dc85449db0Tinderbox UserExample, Inc.</EM>
bbbf2e27d3a981163dab139497d6b2dc85449db0Tinderbox User 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>
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserIn order to accomplish this, the company will set up two sets of nameservers. 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>
44d0f0256fbdce130a18655023c3b06bacacbd61Automatic UpdaterThe internal servers will be configured to forward all queries, except queries for <EM CLASS="pathname">
11e9368a226272085c337e9e74b79808c16fbdbaTinderbox User, to the servers in the DMZ. These internal servers will have complete sets of information for <EM CLASS="pathname">
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein domains, the internal nameservers must be configured to disallow all queries to these domains from any external hosts, including the bastion hosts.</P>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinThe external servers, which are on the bastion hosts, will be configured to serve the "public" version of the <EM CLASS="pathname">
d9184858dd5d7677050a813d444c281c56f697aaTinderbox User zones. This could include things such as the host records for public servers (<EM CLASS="pathname">
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austein), and mail exchange (MX) records (<EM CLASS="pathname">
a1ad6695ed6f988406cf155aa26376f84f73bcb9Automatic Updater 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>
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserHere's an example of a wildcard MX record:</P>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinNow 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 nameservers for DNS resolution.</P>
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinQueries 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>
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserIn order for all this to work properly, internal clients will need to be configured to query <EM CLASS="Emphasis">
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox User the internal nameservers for DNS queries. This could also be enforced via selective filtering on the network.</P>
507151045be68c671ffd4e2f37e17cdfa0376fc4Automatic UpdaterIf everything has been set properly, <EM CLASS="Emphasis">
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinExample, Inc.</EM>
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews's internal clients will now be able to:</P>
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserLook up any hostnames in the <EM CLASS="pathname">
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserLook up any hostnames in the <EM CLASS="pathname">
cd32f419a8a5432fbb139f56ee73cbf68b9350ccTinderbox User domains.</LI>
aa6c5a3e331958d3c92c2facdbd2b8daa55b5959Tinderbox UserLook up any hostnames on the Internet.</LI>
aa6c5a3e331958d3c92c2facdbd2b8daa55b5959Tinderbox UserExchange mail with internal AND external people.</LI>
aa6c5a3e331958d3c92c2facdbd2b8daa55b5959Tinderbox UserHosts on the Internet will be able to:</P>
cd32f419a8a5432fbb139f56ee73cbf68b9350ccTinderbox UserLook up any hostnames in the <EM CLASS="pathname">
cd32f419a8a5432fbb139f56ee73cbf68b9350ccTinderbox UserExchange mail with anyone in the <EM CLASS="pathname">
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox UserHere 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 the <A HREF="Bv9ARM.3.html#30164" CLASS="XRef">Sample Configurations
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark AndrewsInternal DNS server config:</P>
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews<CODE><STRONG>acl internals { 172.16.72.0/24; 192.168.1.0/24; };
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrewsacl externals { bastion-ips-go-here; };
6d382c9fcec316a84a237779fb64bb471b6f9d43Tinderbox User forward only;
f9aef05653eeb454c489d5bd2bde6daab774ad4aTinderbox User forwarders { bastion-ips-go-here; }; // forward to external servers
f9aef05653eeb454c489d5bd2bde6daab774ad4aTinderbox User allow-transfer { none; }; // sample allow-transfer (no one)
f9aef05653eeb454c489d5bd2bde6daab774ad4aTinderbox User allow-query { internal; externals; }; // restrict query access
f9aef05653eeb454c489d5bd2bde6daab774ad4aTinderbox User allow-recursion { internals; }; // restrict recursion
50066670817cdf9e86c832066d73715232b29680Tinderbox User<CODE><STRONG>zone "site1.example.com" { // sample slave zone
28b3569d6248168e6c00caab951521cc8141a49dAutomatic Updater forwarders { }; // do normal iterative
28b3569d6248168e6c00caab951521cc8141a49dAutomatic Updater // resolution (do not forward)
28b3569d6248168e6c00caab951521cc8141a49dAutomatic Updater allow-query { internals; externals; };
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews allow-transfer { internals; };
2cbb4ab75757fbb656997a82c14ca07db37d481aAutomatic Updater<CODE><STRONG>zone "site2.example.com" {
0a7ed88633a680bb881868b75ded4d09a7bbbc50Automatic Updater masters { 172.16.72.3; };
0a7ed88633a680bb881868b75ded4d09a7bbbc50Automatic Updater forwarders { };
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews allow-query { internals; externals; };
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews allow-transfer { internals; };
c3dc968140ab7f04795acc7835e4e89ccb0c0a27Tinderbox User<CODE><STRONG>zone "site1.internal" {
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews type master;
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews forwarders { };
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews allow-query { internals; };
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews allow-transfer { internals; }
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox User masters { 172.16.72.3; };
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox User forwarders { };
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox User allow-query { internals };
ad8f23aed6c75f94f238c1f23f4e17515d28eb55Tinderbox User allow-transfer { internals; }
e2e4d321999340802f77adaacd19c797d04b4b95Automatic UpdaterExternal (bastion host) DNS server config:
b6b8f8a0362da8c749021c4b6376cfb96047912bTinderbox User<CODE><STRONG>acl internals { 172.16.72.0/24; 192.168.1.0/24; };
0c6ada0a814f3c5417daa1654129bc2af56ed504Automatic Updateracl externals {
0c6ada0a814f3c5417daa1654129bc2af56ed504Automatic Updaterbastion-ips-go-here; };
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews allow-transfer { none; }; // sample allow-transfer (no one)
71c66a876ecca77923638d3f94cc0783152b2f03Mark Andrews allow-query { internals; externals; }; // restrict query access
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews allow-recursion { internals; externals; }; // restrict recursion
9b469e3c59015b1a4899c9d8395168126fe094fdAutomatic Updater<CODE><STRONG>zone "site1.example.com" { // sample slave zone
e2e4d321999340802f77adaacd19c797d04b4b95Automatic Updater allow-query { any; };
e2e4d321999340802f77adaacd19c797d04b4b95Automatic Updater allow-transfer { internals; externals; };
fdd80e9a55c70b36a3bf3e409b86897301c44ff8Automatic Updater<CODE><STRONG>zone "site2.example.com" {
e2e4d321999340802f77adaacd19c797d04b4b95Automatic Updater masters { another_bastion_host_maybe; };
e2e4d321999340802f77adaacd19c797d04b4b95Automatic Updater allow-query { any; };
5a4557e8de2951a2796676b5ec4b6a90caa5be14Mark Andrews allow-transfer { internals; externals; }
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob AusteinIn the resolv.conf (or equivalent) on the bastion host(s):
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austeinnameserver 172.16.72.2
60e5e10f8d2e2b0c41e8abad38cacd867caa6ab2Rob Austeinnameserver 172.16.72.3
This is a short guide to setting up Transaction SIGnatures (TSIG) based transaction security in BIND. It describes changes to the configuration file as well as what changes are required for different features, including the process of creating transaction keys and using transaction signatures with BIND.</P>
BIND primarily supports TSIG for server to server communication. This includes zone transfer, notify, and recursive query messages. Resolvers based on newer versions of BIND 8 have limited support for TSIG.</P>
TSIG might be most useful for dynamic update. A primary server for a dynamic zone should use access control to control updates, but IP-based access control is insufficient. Key-based access control is far superior. See RFC 2845 in the <A HREF="Bv9ARM.9.html#17631" CLASS="XRef">Proposed Standards
. An arbitrary key name is chosen: "host1-host2.". The key name must be the same on both hosts.</P>
The following command will generate a 128 bit (16 byte) HMAC-MD5 key as described above. Longer keys are better, but shorter keys are easier to read. Note that the maximum key length is 512 bits; keys longer than that will be digested with MD5 to produce a 128 bit key.</P>
. Nothing directly uses this file, but the base-64 encoded string following "<EM CLASS="grammar_literal">
The shared secret is simply a random sequence of bits, encoded in base-64. Most ASCII strings are valid base-64 strings (assuming the length is a multiple of 4 and only valid characters are used), so the shared secret can be manually generated.</P>
This is beyond the scope of DNS. A secure transport mechanism should be used. This could be secure FTP, ssh, telephone, etc.</P>
The algorithm, hmac-md5, is the only one supported by BIND. The secret is the one generated above. Since this is a secret, it is recommended that either <EM CLASS="pathname">
be non-world readable, or the key directive be added to a non-world readable file that is included by <EM CLASS="pathname">
At this point, the key is recognized. This means that if the server receives a message signed by this key, it can verify the signature. If the signature succeeds, the response is signed by the same key.</P>
Since keys are shared between two hosts only, the server must be told when keys are to be used. The following is added to the <EM CLASS="pathname">
Multiple keys may be present, but only the first is used. This directive does not contain any secrets, so it may be in a world-readable file.</P>
sends a message that is a response to that address, the message will be signed with the specified key. <EM CLASS="Emphasis">
directives. This has been extended to allow TSIG keys also. The above key would be denoted <CODE CLASS="Program-Process">
This allows dynamic updates to succeed only if the request was signed by a key named "<CODE CLASS="Program-Process">
The processing of TSIG signed messages can result in several errors. If a signed message is sent to a non-TSIG aware server, a FORMERR will be returned, since the server will not understand the record. This is a result of misconfiguration, since the server must be explicitly configured to send a TSIG signed message to a specific server.</P>
If a TSIG aware server receives a message signed by an unknown key, the response will be unsigned with the TSIG extended error code set to BADKEY. If a TSIG aware server receives a message with a signature that does not validate, the response will be unsigned with the TSIG extended error code set to BADSIG. If a TSIG aware server receives a message with a time outside of the allowed range, the response will be signed with the TSIG extended error code set to BADTIME, and the time values will be adjusted so that the response can be successfully verified. In any of these cases, the message's rcode is set to NOTAUTH.</P>
is a mechanism for automatically generating a shared secret between two hosts. There are several "modes" of <CODE CLASS="Program-Process">
that specify how the key is generated or assigned. BIND implements only one of these modes, the Diffie-Hellman key exchange. Both hosts are required to have a Diffie-Hellman KEY record (although this record is not required to be present in a zone). The <CODE CLASS="Program-Process">
process must use signed messages, signed either by TSIG or SIG(0). The result of <CODE CLASS="Program-Process">
query (including any appropriate KEYs) to a TKEY-aware server. The server response, if it indicates success, will contain a <CODE CLASS="Program-Process">
record and any appropriate keys. After this exchange, both participants have enough information to determine the shared secret; the exact process depends on the <CODE CLASS="Program-Process">
BIND 9 partially supports DNSSEC SIG(0) transaction signatures as specified in RFC 2535. SIG(0) uses public/private keys to authenticate messages. Access control is performed in the same manner as TSIG keys; privileges can be granted or denied based on the key name.</P>
When a SIG(0) signed message is received, it will only be verified if the key is known and trusted by the server; the server will not attempt to locate and/or validate the key.</P>
Cryptographic authentication of DNS information is possible through the DNS Security (<EM CLASS="Emphasis">
) extensions, defined in RFC 2535. This section describes the creation and use of DNSSEC signed zones.</P>
In order to set up a DNSSEC secure zone, there are a series of steps which must be followed. BIND 9 ships with several tools that are used in this process, which are explained in more detail below. In all cases, the "<CODE CLASS="Program-Process">
There must also be communication with the administrators of the parent and/or child zone to transmit keys and signatures. A zone's security status must be indicated by the parent zone for a DNSSEC capable resolver to trust its data.</P>
For other servers to trust data in this zone, they must either be statically configured with this zone's zone key or the zone key of another zone above this one in the DNS tree.</P>
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 <CODE CLASS="Program-Process">
, and must be usable for authentication. It is recommended that zone keys be mandatory to implement a cryptographic algorithm; currently the only key mandatory to implement an algorithm is DSA.</P>
(where 12345 is an example of a key identifier). The key file names contain the key name (<EM CLASS="pathname">
), algorithm (3 is DSA, 1 is RSA, etc.), and the key identifier (12345 in this case). The private key (in the <EM CLASS="pathname">
To generate another key with the same properties (but with a different key identifier), repeat the above command.</P>
Once the zone keys have been generated, a key set must be built for transmission to the administrator of the parent zone, so that the parent zone can sign the keys with its own zone key and correctly indicate the security status of this zone. When building a key set, the list of keys to be included and the TTL of the set must be specified, and the desired signature validity period of the parent's signature may also be specified.</P>
The list of keys to be inserted into the key set may also included non-zone keys present at the apex. <CODE CLASS="Program-Process">
The following command generates a key set containing the above key and another key similarly generated, with a TTL of 3600 and a signature validity period of 10 days starting from now.</P>
. This file should be transmitted to the parent to be signed. It includes the keys, as well as signatures over the key set generated by the zone keys themselves, which are used to prove ownership of the private keys and encode the desired validity period.</P>
administrator should receive keyset files for each secure subzone. These keys must be signed by this zone's zone keys.</P>
. This file should be both transmitted back to the child and retained. It includes all keys (the child's keys) from the keyset file and signatures generated by this zone's zone keys.</P>
file for this zone generated by the parent (if there is one). The zone signer will generate <CODE CLASS="Program-Process">
records for the zone, as well as incorporate the zone key signature from the parent and indicate the security status at all delegation points.</P>
. By default, all zone keys which have an available private key are used to generate signatures.</P>
Unlike in BIND 8, data is not verified on load in BIND 9, so zone keys for authoritative zones do not need to be specified in the configuration file.</P>
BIND 9 fully supports all currently defined forms of IPv6 name to address and address to name lookups. It will also use IPv6 addresses to make queries when running on an IPv6 capable system.</P>
For forward lookups, BIND 9 supports both A6 and AAAA records. The of AAAA records is deprecated, but it is still useful for hosts to have both AAAA and A6 records to maintain backward compatibility with installations where AAAA records are still used. In fact, the stub resolvers currently shipped with most operating system support only AAAA lookups, because following A6 chains is much harder than doing A or AAAA lookups.</P>
For IPv6 reverse lookups, BIND 9 supports the new "bitstring" format used in the <EM CLASS="URL">
BIND 9 includes a new lightweight resolver library and resolver daemon which new applications may choose to use to avoid the complexities of A6 chain following and bitstring labels. See <A HREF="Bv9ARM.5.html#22731" CLASS="XRef">
The AAAA record is a parallel to the IPv4 A record. It specifies the entire address in a single record. For example,</P>
$ORIGIN example.com.
While their use is deprecated, they are useful to support older IPv6 applications. They should not be added where they are not absolutely necessary.</P>
The A6 record is more flexible than the AAAA record, and is therefore more complicated. The A6 record can be used to form a chain of A6 records, each specifying part of the IPv6 address. It can also be used to specify the entire record as well. For example, this record supplies the same data as the AAAA record in the previous example:</P>
A6 records are designed to allow network renumbering. This works when an A6 record only specifies the part of the address space the domain owner controls. For example, a host may be at a company named "company." It has two ISPs which provide IPv6 address space for it. These two ISPs fully specify the IPv6 prefix they supply.</P>
host 1h IN A6 64 0:0:0:0:42::1 company.example1.net.
$ORIGIN example1.net.
$ORIGIN example2.net.
is looked up, the resolver (in the resolver daemon or caching name server) will find two partial A6 records, and will use the additional name to find the remainder of the data.</P>
When an A6 record specifies the address of a name server, it should use the full address rather than specifying a partial address. For example:</P>
It is recommended that IPv4-in-IPv6 mapped addresses not be used. If a host has an IPv4 address, use an A record, not an A6, with <EM CLASS="grammar_literal">
While the use of nibble format to look up names is deprecated, it is supported for backwards compatiblity with existing IPv6 applications.</P>
When looking up an address in nibble format, the address components are simply reversed, just as in IPv4, and <EM CLASS="grammar_literal">
is appended to the resulting name. For example, the following would provide reverse name lookup for a host with address <EM CLASS="grammar_literal">
1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 4h IN PTR host.example.com.
Bitstring labels can start and end on any bit boundary, rather than on a multiple of 4 bits as in the nibble format. They also use <EM CLASS="URL">
In IPV6, the same host may have many addresses from many network providers. Since the trailing portion of the address usually remains constant, DNAME can help reduce the number of zone files used for reverse mapping that need to be maintained.
For example, consider a host which has two providers (example.net and example2.net) and therefore two IPv6 addresses. Since the host chooses its own 64 bit host address portion, the provider address is the only part that changes:
host A6 64 ::1234:5678:1212:5675 cust1.example.net.
A6 64 ::1234:5678:1212:5675 subnet5.example2.net.
cust1 A6 48 0:0:0:dddd:: ipv6net.example.net.
subnet5 A6 48 0:0:0:1:: ipv6net2.example2.net.
This sets up forward lookups. To handle the reverse lookups, the provider example.net would have:
and example2.net would have:
example.com needs only one zone file to handle both of these reverse mappings: