1N/A>Advanced Concepts</
TITLE 1N/ACONTENT="Modular DocBook HTML Stylesheet Version 1.54"><
LINK 1N/ATITLE="Nameserver Configuration" 1N/ATITLE="The BIND 9 Lightweight Resolver" 1N/A>Chapter 4. Advanced Concepts</
A 1N/A>Table of Contents</
B 1N/A>Incremental Zone Transfers (IXFR)</
A 1N/A>IPv6 Support in <
SPAN 1N/ANAME="dynamic_update" 1N/A>4.1. Dynamic Update</
A 1N/A>Dynamic update is the term used for the ability under
1N/A certain specified conditions to add, modify or delete records or
1N/A RRsets in the master zone files. Dynamic update is fully described
1N/A>Dynamic update is enabled on a zone-by-zone basis, by
1N/A>Updating of secure zones (zones using DNSSEC) is modelled
1N/A>simple-secure-update</
I 1N/A work in progress in the DNS Extensions working group of the IETF.
1N/A for information about the DNS Extensions working group.) SIG and
1N/A NXT records affected by updates are automatically regenerated by
1N/A the server using an online zone key. Update authorization is based
1N/A on transaction signatures and an explicit server policy.</
P 1N/A>The zone files of dynamic zones must not be edited by hand.
1N/A The zone file on disk at any given time may not contain the latest
1N/A changes performed by dynamic update. The zone file is written to
1N/A disk only periodically, and changes that have occurred since the
1N/A zone file was last written to disk are stored only in the zone's
1N/A not update the zone file when it exits as <
SPAN 1N/A the zone file manually is unsafe even when the server has been
1N/ANAME="incremental_zone_transfers" 1N/A>4.2. Incremental Zone Transfers (IXFR)</
A 1N/A>The incremental zone transfer (IXFR) protocol is a way for
1N/A slave servers to transfer only changed data, instead of having to
1N/A transfer the entire zone. The IXFR protocol is documented in RFC
1N/A>When acting as a master, <
SPAN 1N/A> 9 supports IXFR for those zones
1N/Awhere the necessary change history information is available. These
1N/Ainclude master zones maintained by dynamic update and slave zones
1N/Awhose data was obtained by IXFR, but not manually maintained master
1N/Azones nor slave zones obtained by performing a full zone transfer
1N/A>When acting as a slave, <
SPAN 1N/A> 9 will attempt to use IXFR unless
1N/Ait is explicitly disabled. For more information about disabling
1N/AIXFR, see the description of the <
B 1N/A>Setting up different views, or visibility, of DNS space to
1N/Ainternal and external resolvers is usually referred to as a <
I 1N/A> setup. There are several reasons an organization
1N/Awould want to set up its DNS this way.</
P 1N/A>One common reason for setting up a DNS system this way is
1N/Ato hide "internal" DNS information from "external" clients on the
1N/AInternet. There is some debate as to whether or not this is actually useful.
1N/AInternal DNS information leaks out in many ways (via email headers,
1N/Afor example) and most savvy "attackers" can find the information
1N/Athey need using other means.</
P 1N/A>Another common reason for setting up a Split DNS system is
1N/Ato allow internal networks that are behind filters or in RFC 1918
1N/Aspace (reserved IP space, as documented in RFC 1918) to resolve DNS
1N/Aon the Internet. Split DNS can also be used to allow mail from outside
1N/Aback in to the internal network.</
P 1N/A>Here is an example of a split DNS setup:</
P 1N/A>Let's say a company named <
I 1N/Ahas several corporate sites that have an internal network with reserved
1N/AInternet Protocol (IP) space and an external demilitarized zone (DMZ),
1N/Aor "outside" section of a network, that is available to the public.</
P 1N/A> wants its internal clients
1N/Ato be able to resolve external hostnames and to exchange mail with
1N/Apeople on the outside. The company also wants its internal resolvers
1N/Ato have access to certain internal-only zones that are not available
1N/Aat all outside of the internal network.</
P 1N/A>In order to accomplish this, the company will set up two sets
1N/Aof nameservers. One set will be on the inside network (in the reserved
1N/AIP space) and the other set will be on bastion hosts, which are "proxy"
1N/Ahosts that can talk to both sides of its network, in the DMZ.</
P 1N/A>The internal servers will be configured to forward all queries,
1N/Aexcept queries for <
TT 1N/A>, to the servers in the
1N/ADMZ. These internal servers will have complete sets of information
1N/Athe internal nameservers must be configured to disallow all queries
1N/Ato these domains from any external hosts, including the bastion
1N/A>The external servers, which are on the bastion hosts, will
1N/Abe configured to serve the "public" version of the <
TT 1N/AThis could include things such as the host records for public servers
1N/Aand mail exchange (MX) records (<
TT 1N/A>In addition, the public <
TT 1N/Ashould have special MX records that contain wildcard (`*') records
1N/Apointing to the bastion hosts. This is needed because external mail
1N/Aservers do not have any other way of looking up how to deliver mail
1N/Ato those internal hosts. With the wildcard records, the mail will
1N/Abe delivered to the bastion host, which can then forward it on to
1N/A>Here's an example of a wildcard MX record:</
P 1N/ACLASS="programlisting" 1N/A>Now that they accept mail on behalf of anything in the internal
1N/Anetwork, the bastion hosts will need to know how to deliver mail
1N/Ato internal hosts. In order for this to work properly, the resolvers on
1N/Athe bastion hosts will need to be configured to point to the internal
1N/Anameservers for DNS resolution.</
P 1N/A>Queries for internal hostnames will be answered by the internal
1N/Aservers, and queries for external hostnames will be forwarded back
1N/Aout to the DNS servers on the bastion hosts.</
P 1N/A>In order for all this to work properly, internal clients will
1N/Aneed to be configured to query <
I 1N/Anameservers for DNS queries. This could also be enforced via selective
1N/Afiltering on the network.</
P 1N/A>If everything has been set properly, <
I 1N/Ainternal clients will now be able to:</
P 1N/A>Look up any hostnames in the <
SPAN 1N/A>Look up any hostnames in the <
SPAN 1N/A>Look up any hostnames on the Internet.</
P 1N/A>Exchange mail with internal AND external people.</
P 1N/A>Hosts on the Internet will be able to:</
P 1N/A>Look up any hostnames in the <
SPAN 1N/A>Exchange mail with anyone in the <
SPAN 1N/A>Here is an example configuration for the setup we just
1N/A described above. Note that this is only configuration information;
1N/A for information on how to configure your zone files, see <
A 1N/A>Internal DNS server config:</
P 1N/ACLASS="programlisting" 1N/A>bastion-ips-go-here</
TT 1N/A forwarders { // forward to external servers
1N/A>bastion-ips-go-here</
TT 1N/A allow-transfer { none; }; // sample allow-transfer (no one)
1N/A allow-query { internals; externals; }; // restrict query access
1N/A allow-recursion { internals; }; // restrict recursion
1N/A forwarders { }; // do normal iterative
1N/A // resolution (do not forward)
1N/A allow-query { internals; externals; };
1N/A allow-transfer { internals; };
1N/A masters { 172.16.72.3; };
1N/A allow-query { internals; externals; };
1N/A allow-transfer { internals; };
1N/A allow-query { internals; };
1N/A allow-transfer { internals; }
1N/A masters { 172.16.72.3; };
1N/A allow-query { internals };
1N/A allow-transfer { internals; }
1N/A>External (bastion host) DNS server config:</
P 1N/ACLASS="programlisting" 1N/Aacl externals { bastion-ips-go-here; };
1N/A allow-transfer { none; }; // sample allow-transfer (no one)
1N/A allow-query { internals; externals; }; // restrict query access
1N/A allow-recursion { internals; externals; }; // restrict recursion
1N/A allow-query { any; };
1N/A allow-transfer { internals; externals; };
1N/A masters { another_bastion_host_maybe; };
1N/A allow-query { any; };
1N/A allow-transfer { internals; externals; }
1N/Athe bastion host(s):</
P 1N/ACLASS="programlisting" 1N/Anameserver 172.16.72.2
1N/Anameserver 172.16.72.3
1N/Anameserver 172.16.72.4
1N/A>This is a short guide to setting up Transaction SIGnatures
1N/A(TSIG) based transaction security in <
SPAN 1N/A>. It describes changes
1N/Ato the configuration file as well as what changes are required for
1N/Adifferent features, including the process of creating transaction
1N/Akeys and using transaction signatures with <
SPAN 1N/A> primarily supports TSIG for server to server communication.
1N/AThis includes zone transfer, notify, and recursive query messages.
1N/AResolvers based on newer versions of <
SPAN 1N/A> 8 have limited support
1N/A>TSIG might be most useful for dynamic update. A primary
1N/A server for a dynamic zone should use access control to control
1N/A updates, but IP-based access control is insufficient. Key-based
1N/A access control is far superior, see . The <
B 1N/A program supports TSIG via the <
TT 1N/A> command line options.</
P 1N/A>4.4.1. Generate Shared Keys for Each Pair of Hosts</
A 1N/A>A shared secret is generated to be shared between <
I 1N/AAn arbitrary key name is chosen: "host1-host2.". The key name must
1N/Abe the same on both hosts.</
P 1N/A>4.4.1.1. Automatic Generation</
A 1N/A>The following command will generate a 128 bit (16 byte) HMAC-MD5
1N/Akey as described above. Longer keys are better, but shorter keys
1N/Aare easier to read. Note that the maximum key length is 512 bits;
1N/Akeys longer than that will be digested with MD5 to produce a 128
1N/A>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</
B 1N/A>The key is in the file <
TT 1N/ANothing directly uses this file, but the base-64 encoded string
1N/Acan be extracted from the file and used as a shared secret:</
P 1N/ACLASS="programlisting" 1N/Abe used as the shared secret.</
P 1N/A>4.4.1.2. Manual Generation</
A 1N/A>The shared secret is simply a random sequence of bits, encoded
1N/Ain base-64. Most ASCII strings are valid base-64 strings (assuming
1N/Athe length is a multiple of 4 and only valid characters are used),
1N/Aso the shared secret can be manually generated.</
P 1N/A>Also, a known string can be run through <
B 1N/Aa similar program to generate base-64 encoded data.</
P 1N/A>4.4.2. Copying the Shared Secret to Both Machines</
A 1N/A>This is beyond the scope of DNS. A secure transport mechanism
1N/Ashould be used. This could be secure FTP, ssh, telephone, etc.</
P 1N/A>4.4.3. Informing the Servers of the Key's Existence</
A 1N/Aboth servers. The following is added to each server's <
TT 1N/ACLASS="programlisting" 1N/A> key host1-host2. {
1N/A>The algorithm, hmac-md5, is the only one supported by <
SPAN 1N/AThe secret is the one generated above. Since this is a secret, it
1N/Ais recommended that either <
TT 1N/Areadable, or the key directive be added to a non-world readable
1N/Afile that is included by <
TT 1N/A>At this point, the key is recognized. This means that if the
1N/Aserver receives a message signed by this key, it can verify the
1N/Asignature. If the signature succeeds, the response is signed by
1N/A>4.4.4. Instructing the Server to Use the Key</
A 1N/A>Since keys are shared between two hosts only, the server must
1N/Abe told when keys are to be used. The following is added to the <
TT 1N/A>, if the IP address of <
I 1N/ACLASS="programlisting" 1N/A> server 10.1.2.3 {
1N/A keys { host1-host2. ;};
1N/A>Multiple keys may be present, but only the first is used.
1N/AThis directive does not contain any secrets, so it may be in a world-readable
1N/A> sends a message that is a response
1N/Ato that address, the message will be signed with the specified key. <
I 1N/Aexpect any responses to signed messages to be signed with the same
1N/A>A similar statement must be present in <
I 1N/Aconfiguration file (with <
I 1N/Asign non-response messages to <
I 1N/A>4.4.5. TSIG Key Based Access Control</
A 1N/A> allows IP addresses and ranges to be specified in ACL
1N/A>allow-{ query | transfer | update } </
B 1N/AThis has been extended to allow TSIG keys also. The above key would
1N/A>An example of an allow-update directive would be:</
P 1N/ACLASS="programlisting" 1N/A> allow-update { key host1-host2. ;};
1N/A>This allows dynamic updates to succeed only if the request
1N/A was signed by a key named
1N/A>You may want to read about the more
1N/A>The processing of TSIG signed messages can result in
1N/A several errors. If a signed message is sent to a non-TSIG aware
1N/A server, a FORMERR will be returned, since the server will not
1N/A understand the record. This is a result of misconfiguration,
1N/A since the server must be explicitly configured to send a TSIG
1N/A signed message to a specific server.</
P 1N/A>If a TSIG aware server receives a message signed by an
1N/A unknown key, the response will be unsigned with the TSIG
1N/A extended error code set to BADKEY. If a TSIG aware server
1N/A receives a message with a signature that does not validate, the
1N/A response will be unsigned with the TSIG extended error code set
1N/A to BADSIG. If a TSIG aware server receives a message with a time
1N/A outside of the allowed range, the response will be signed with
1N/A the TSIG extended error code set to BADTIME, and the time values
1N/A will be adjusted so that the response can be successfully
1N/A verified. In any of these cases, the message's rcode is set to
1N/A> is a mechanism for automatically
1N/A generating a shared secret between two hosts. There are several
1N/A> that specify how the key is
1N/A generated or assigned. <
SPAN 1N/A> implements only one of these modes,
1N/A the Diffie-Hellman key exchange. Both hosts are required to have
1N/A a Diffie-Hellman KEY record (although this record is not required
1N/A to be present in a zone). The <
B 1N/A must use signed messages, signed either by TSIG or SIG(0). The
1N/A> is a shared secret that can be
1N/A used to sign messages with TSIG. <
B 1N/A be used to delete shared secrets that it had previously
1N/A> process is initiated by a client
1N/A or server by sending a signed <
B 1N/A (including any appropriate KEYs) to a TKEY-aware server. The
1N/A server response, if it indicates success, will contain a
1N/A> record and any appropriate keys. After
1N/A this exchange, both participants have enough information to
1N/A determine the shared secret; the exact process depends on the
1N/A> mode. When using the Diffie-Hellman
1N/A> mode, Diffie-Hellman keys are exchanged,
1N/A and the shared secret is derived by both participants.</
P 1N/A> 9 partially supports DNSSEC SIG(0) transaction
1N/A keys to authenticate messages. Access control is performed in the
1N/A same manner as TSIG keys; privileges can be granted or denied
1N/A based on the key name.</
P 1N/A>When a SIG(0) signed message is received, it will only be
1N/A verified if the key is known and trusted by the server; the server
1N/A will not attempt to locate
and/
or validate the key.</
P 1N/A> 9 does not ship with any tools that generate SIG(0)
1N/A>Cryptographic authentication of DNS information is possible
1N/A through the DNS Security (<
I 1N/A defined in RFC 2535. This section describes the creation and use
1N/A of DNSSEC signed zones.</
P 1N/A>In order to set up a DNSSEC secure zone, there are a series
1N/A of steps which must be followed. <
SPAN 1N/A> 9 ships with several tools
1N/A that are used in this process, which are explained in more detail
1N/A below. In all cases, the "<
TT 1N/A full list of parameters.</
P 1N/A>There must also be communication with the administrators of
1N/A the parent
and/
or child zone to transmit keys and signatures. A
1N/A zone's security status must be indicated by the parent zone for a
1N/A DNSSEC capable resolver to trust its data.</
P 1N/A>For other servers to trust data in this zone, they must
1N/A either be statically configured with this zone's zone key or the
1N/A zone key of another zone above this one in the DNS tree.</
P 1N/A>4.7.1. Generating Keys</
A 1N/A>A secure zone must contain one or more zone keys. The
1N/A zone keys will sign all other records in the zone, as well as
1N/A the zone keys of any secure delegated zones. Zone keys must
1N/A have the same name as the zone, a name type of
1N/A>, and must be usable for authentication.
1N/A It is recommended that zone keys be mandatory to implement a
1N/A cryptographic algorithm; currently the only key mandatory to
1N/A implement an algorithm is DSA.</
P 1N/A>The following command will generate a 768 bit DSA key for
1N/A>Two output files will be produced:
1N/A 12345 is an example of a key tag). The key file names contain
1N/A is DSA, 1 is RSA, etc.), and the key tag (12345 in this case).
1N/A The private key (in the <
TT 1N/A used to generate signatures, and the public key (in the
1N/A> file) is used for signature
1N/A>To generate another key with the same properties (but with
1N/A a different key tag), repeat the above command.</
P 1N/A>The public keys should be inserted into the zone file with
1N/A> statements, including the
1N/A>4.7.2. Creating a Keyset</
A 1N/A>dnssec-makekeyset</
B 1N/A to create a key set from one or more keys.</
P 1N/A>Once the zone keys have been generated, a key set must be
1N/A built for transmission to the administrator of the parent zone,
1N/A so that the parent zone can sign the keys with its own zone key
1N/A and correctly indicate the security status of this zone. When
1N/A building a key set, the list of keys to be included and the TTL
1N/A of the set must be specified, and the desired signature validity
1N/A period of the parent's signature may also be specified.</
P 1N/A>The list of keys to be inserted into the key set may also
1N/A included non-zone keys present at the top of the zone.
1N/A>dnssec-makekeyset</
B 1N/A> may also be used at other
1N/A names in the zone.</
P 1N/A>The following command generates a key set containing the
1N/A above key and another key similarly generated, with a TTL of
1N/A 3600 and a signature validity period of 10 days starting from
1N/A>One output file is produced:
1N/A>. This file should be
1N/A transmitted to the parent to be signed. It includes the keys,
1N/A as well as signatures over the key set generated by the zone
1N/A keys themselves, which are used to prove ownership of the
1N/A private keys and encode the desired validity period.</
P 1N/A>4.7.3. Signing the Child's Keyset</
A 1N/A sign one child's keyset.</
P 1N/A delegations which are secure, for example,
1N/A> administrator should receive
1N/A keyset files for each secure subzone. These keys must be signed
1N/A by this zone's zone keys.</
P 1N/A>The following command signs the child's key set with the
1N/A>One output file is produced:
1N/A should be both transmitted back to the child and retained. It
1N/A includes all keys (the child's keys) from the keyset file and
1N/A signatures generated by this zone's zone keys.</
P 1N/A>4.7.4. Signing the Zone</
A 1N/A> files corresponding to
1N/A secure subzones should be present, as well as a
1N/A> file for this zone generated by
1N/A the parent (if there is one). The zone signer will generate
1N/A the zone, as well as incorporate the zone key signature from the
1N/A parent and indicate the security status at all delegation
1N/A>The following command signs the zone, assuming it is in a
1N/A default, all zone keys which have an available private key are
1N/A used to generate signatures.</
P 1N/A>One output file is produced:
1N/A should be referenced by <
TT 1N/A input file for the zone.</
P 1N/A>4.7.5. Configuring Servers</
A 1N/A> 8, data is not verified on load in <
SPAN 1N/A so zone keys for authoritative zones do not need to be specified
1N/A in the configuration file.</
P 1N/A>The public key for any security root must be present in
1N/A the configuration file's <
B 1N/A statement, as described later in this document. </
P 1N/A>4.8. IPv6 Support in <
SPAN 1N/A> 9 fully supports all currently defined forms of IPv6
1N/A name to address and address to name lookups. It will also use
1N/A IPv6 addresses to make queries when running on an IPv6 capable
1N/A>For forward lookups, <
SPAN 1N/A> 9 supports both A6 and AAAA
1N/A records. The use of AAAA records is deprecated, but it is still
1N/A useful for hosts to have both AAAA and A6 records to maintain
1N/A backward compatibility with installations where AAAA records are
1N/A still used. In fact, the stub resolvers currently shipped with
1N/A most operating system support only AAAA lookups, because following
1N/A A6 chains is much harder than doing A or AAAA lookups.</
P 1N/A>For IPv6 reverse lookups, <
SPAN 1N/A "bitstring" format used in the <
I 1N/A domain, as well as the older, deprecated "nibble" format used in
1N/A> 9 includes a new lightweight resolver library and
1N/A resolver daemon which new applications may choose to use to avoid
1N/A the complexities of A6 chain following and bitstring labels, see <
A 1N/A>4.8.1. Address Lookups Using AAAA Records</
A 1N/A>The AAAA record is a parallel to the IPv4 A record. It
1N/A specifies the entire address in a single record. For
1N/ACLASS="programlisting" 1N/Ahost 3600 IN AAAA 3ffe:8050:201:1860:42::1
1N/A>While their use is deprecated, they are useful to support
1N/A older IPv6 applications. They should not be added where they
1N/A are not absolutely necessary.</
P 1N/A>4.8.2. Address Lookups Using A6 Records</
A 1N/A>The A6 record is more flexible than the AAAA record, and
1N/A is therefore more complicated. The A6 record can be used to
1N/A form a chain of A6 records, each specifying part of the IPv6
1N/A address. It can also be used to specify the entire record as
1N/A well. For example, this record supplies the same data as the
1N/A AAAA record in the previous example:</
P 1N/ACLASS="programlisting" 1N/Ahost 3600 IN A6 0 3ffe:8050:201:1860:42::1
1N/A>4.8.2.1. A6 Chains</
A 1N/A>A6 records are designed to allow network
1N/A renumbering. This works when an A6 record only specifies the
1N/A part of the address space the domain owner controls. For
1N/A example, a host may be at a company named "company." It has
1N/A two ISPs which provide IPv6 address space for it. These two
1N/A ISPs fully specify the IPv6 prefix they supply.</
P 1N/A>In the company's address space:</
P 1N/ACLASS="programlisting" 1N/ACLASS="programlisting" 1N/Acompany 3600 IN A6 0 3ffe:8050:201:1860::
1N/ACLASS="programlisting" 1N/Acompany 3600 IN A6 0 1234:5678:90ab:fffa::
1N/A the resolver (in the resolver daemon or caching name server)
1N/A will find two partial A6 records, and will use the additional
1N/A name to find the remainder of the data.</
P 1N/A>4.8.2.2. A6 Records for DNS Servers</
A 1N/A>When an A6 record specifies the address of a name
1N/A server, it should use the full address rather than specifying
1N/A a partial address. For example:</
P 1N/ACLASS="programlisting" 1N/Ans0 14400 IN A6 0 3ffe:8050:201:1860:42::1
1N/Ans1 14400 IN A 192.168.42.1
1N/A>It is recommended that IPv4-in-IPv6 mapped addresses not
1N/A be used. If a host has an IPv4 address, use an A record, not
1N/A>::ffff:192.168.42.1</
TT 1N/A>4.8.3. Address to Name Lookups Using Nibble Format</
A 1N/A>While the use of nibble format to look up names is
1N/A deprecated, it is supported for backwards compatiblity with
1N/A existing IPv6 applications.</
P 1N/A>When looking up an address in nibble format, the address
1N/A components are simply reversed, just as in IPv4, and
1N/A> is appended to the resulting name.
1N/A For example, the following would provide reverse name lookup for
1N/A>3ffe:8050:201:1860:42::1</
TT 1N/ACLASS="programlisting" 1N/A>4.8.4. Address to Name Lookups Using Bitstring Format</
A 1N/A>Bitstring labels can start and end on any bit boundary,
1N/A rather than on a multiple of 4 bits as in the nibble
1N/A format. They also use <
I 1N/A>To replicate the previous example using bitstrings:</
P 1N/ACLASS="programlisting" 1N/A>4.8.5. Using DNAME for Delegation of IPv6 Reverse Addresses</
A 1N/A>In IPV6, the same host may have many addresses from many
1N/A network providers. Since the trailing portion of the address
1N/A usually remains constant, <
B 1N/A reduce the number of zone files used for reverse mapping that
1N/A need to be maintained.</
P 1N/A>For example, consider a host which has two providers
1N/A therefore two IPv6 addresses. Since the host chooses its own 64
1N/A bit host address portion, the provider address is the only part
1N/ACLASS="programlisting" 1N/Aipv6net A6 0 aa:bb:cccc::
1N/Aipv6net2 A6 0 6666:5555:4::
1N/A>This sets up forward lookups. To handle the reverse lookups,
1N/ACLASS="programlisting" 1N/ACLASS="programlisting" 1N/A needs only one zone file to handle both of these reverse
1N/ACLASS="programlisting" 1N/A>Nameserver Configuration</
TD 1N/A> 9 Lightweight Resolver</
TD