diff options
Diffstat (limited to 'contrib/bind9/doc/arm/Bv9ARM-book.xml')
| -rw-r--r-- | contrib/bind9/doc/arm/Bv9ARM-book.xml | 6571 |
1 files changed, 6571 insertions, 0 deletions
diff --git a/contrib/bind9/doc/arm/Bv9ARM-book.xml b/contrib/bind9/doc/arm/Bv9ARM-book.xml new file mode 100644 index 0000000..2a03a9e --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM-book.xml @@ -0,0 +1,6571 @@ + +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN" + "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"> + +<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.49 2004/08/16 00:55:29 marka Exp $ --> + +<book> +<title>BIND 9 Administrator Reference Manual</title> + +<bookinfo> +<copyright> +<year>2004</year> +<holder>Internet Systems Consortium, Inc. ("ISC")</holder> +</copyright> +<copyright> +<year>2000-2003</year> +<holder>Internet Software Consortium</holder> +</copyright> +</bookinfo> + + <chapter id="ch01"> + <title>Introduction </title> + <para>The Internet Domain Name System (<acronym>DNS</acronym>) consists of the syntax + to specify the names of entities in the Internet in a hierarchical + manner, the rules used for delegating authority over names, and the + system implementation that actually maps names to Internet + addresses. <acronym>DNS</acronym> data is maintained in a group of distributed + hierarchical databases.</para> + + <sect1> + <title>Scope of Document</title> + + <para>The Berkeley Internet Name Domain (<acronym>BIND</acronym>) implements an + domain name server for a number of operating systems. This + document provides basic information about the installation and + care of the Internet Software Consortium (<acronym>ISC</acronym>) + <acronym>BIND</acronym> version 9 software package for system + administrators.</para> + + <para>This version of the manual corresponds to BIND version 9.3.</para> + + </sect1> + <sect1><title>Organization of This Document</title> + <para>In this document, <emphasis>Section 1</emphasis> introduces + the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Section 2</emphasis> + describes resource requirements for running <acronym>BIND</acronym> in various + environments. Information in <emphasis>Section 3</emphasis> is + <emphasis>task-oriented</emphasis> in its presentation and is + organized functionally, to aid in the process of installing the + <acronym>BIND</acronym> 9 software. The task-oriented section is followed by + <emphasis>Section 4</emphasis>, which contains more advanced + concepts that the system administrator may need for implementing + certain options. <emphasis>Section 5</emphasis> + describes the <acronym>BIND</acronym> 9 lightweight + resolver. The contents of <emphasis>Section 6</emphasis> are + organized as in a reference manual to aid in the ongoing + maintenance of the software. <emphasis>Section 7 + </emphasis>addresses security considerations, and + <emphasis>Section 8</emphasis> contains troubleshooting help. The + main body of the document is followed by several + <emphasis>Appendices</emphasis> which contain useful reference + information, such as a <emphasis>Bibliography</emphasis> and + historic information related to <acronym>BIND</acronym> and the Domain Name + System.</para> + </sect1> + <sect1><title>Conventions Used in This Document</title> + + <para>In this document, we use the following general typographic + conventions:</para> + +<informaltable> + <tgroup cols = "2"> + <colspec colname = "1" colnum = "1" colwidth = "3.000in"/> + <colspec colname = "2" colnum = "2" colwidth = "2.625in"/> + <tbody> + <row> + <entry colname = "1"> +<para><emphasis>To +describe:</emphasis></para></entry> + <entry colname = "2"> +<para><emphasis>We use the style:</emphasis></para></entry> + </row> + <row> + <entry colname = "1"> +<para>a pathname, filename, URL, hostname, +mailing list name, or new term or concept</para></entry> + <entry colname = "2"><para><filename>Fixed width</filename></para></entry> + </row> + <row> + <entry colname = "1"><para>literal user +input</para></entry> + <entry colname = "2"><para><userinput>Fixed Width Bold</userinput></para></entry> + </row> + <row> + <entry colname = "1"><para>program output</para></entry> + <entry colname = "2"><para><computeroutput>Fixed Width</computeroutput></para></entry> + </row> + </tbody> + </tgroup> +</informaltable> + + <para>The following conventions are used in descriptions of the +<acronym>BIND</acronym> configuration file:<informaltable colsep = "0" frame = "all" rowsep = "0"> + <tgroup cols = "2" colsep = "0" rowsep = "0" + tgroupstyle = "2Level-table"> + <colspec colname = "1" colnum = "1" colsep = "0" colwidth = "3.000in"/> + <colspec colname = "2" colnum = "2" colsep = "0" colwidth = "2.625in"/> + <tbody> + <row rowsep = "0"> + <entry colname = "1" colsep = "1" rowsep = "1"><para><emphasis>To +describe:</emphasis></para></entry> + <entry colname = "2" rowsep = "1"><para><emphasis>We use the style:</emphasis></para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1" colsep = "1" rowsep = "1"><para>keywords</para></entry> + <entry colname = "2" rowsep = "1"><para><literal>Fixed Width</literal></para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1" colsep = "1" rowsep = "1"><para>variables</para></entry> + <entry colname = "2" rowsep = "1"><para><varname>Fixed Width</varname></para></entry> + </row> +<row rowsep = "0"> +<entry colname = "1" colsep = "1"><para>Optional input</para></entry> + <entry colname = "2"><para><optional>Text is enclosed in square brackets</optional></para></entry> +</row> +</tbody> +</tgroup></informaltable></para></sect1> +<sect1><title>The Domain Name System (<acronym>DNS</acronym>)</title> +<para>The purpose of this document is to explain the installation +and upkeep of the <acronym>BIND</acronym> software package, and we +begin by reviewing the fundamentals of the Domain Name System +(<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>. +</para> + +<sect2> +<title>DNS Fundamentals</title> + +<para>The Domain Name System (DNS) is the hierarchical, distributed +database. It stores information for mapping Internet host names to IP +addresses and vice versa, mail routing information, and other data +used by Internet applications.</para> + +<para>Clients look up information in the DNS by calling a +<emphasis>resolver</emphasis> library, which sends queries to one or +more <emphasis>name servers</emphasis> and interprets the responses. +The <acronym>BIND</acronym> 9 software distribution contains a +name server, <command>named</command>, and two resolver +libraries, <command>liblwres</command> and <command>libbind</command>. +</para> + +</sect2><sect2> +<title>Domains and Domain Names</title> + +<para>The data stored in the DNS is identified by <emphasis>domain +names</emphasis> that are organized as a tree according to +organizational or administrative boundaries. Each node of the tree, +called a <emphasis>domain</emphasis>, is given a label. The domain name of the +node is the concatenation of all the labels on the path from the +node to the <emphasis>root</emphasis> node. This is represented +in written form as a string of labels listed from right to left and +separated by dots. A label need only be unique within its parent +domain.</para> + +<para>For example, a domain name for a host at the +company <emphasis>Example, Inc.</emphasis> could be +<literal>mail.example.com</literal>, +where <literal>com</literal> is the +top level domain to which +<literal>ourhost.example.com</literal> belongs, +<literal>example</literal> is +a subdomain of <literal>com</literal>, and +<literal>ourhost</literal> is the +name of the host.</para> + +<para>For administrative purposes, the name space is partitioned into +areas called <emphasis>zones</emphasis>, each starting at a node and +extending down to the leaf nodes or to nodes where other zones start. +The data for each zone is stored in a <emphasis>name +server</emphasis>, which answers queries about the zone using the +<emphasis>DNS protocol</emphasis>. +</para> + +<para>The data associated with each domain name is stored in the +form of <emphasis>resource records</emphasis> (<acronym>RR</acronym>s). +Some of the supported resource record types are described in +<xref linkend="types_of_resource_records_and_when_to_use_them"/>.</para> + +<para>For more detailed information about the design of the DNS and +the DNS protocol, please refer to the standards documents listed in +<xref linkend="rfcs"/>.</para> +</sect2> + +<sect2><title>Zones</title> +<para>To properly operate a name server, it is important to understand +the difference between a <emphasis>zone</emphasis> +and a <emphasis>domain</emphasis>.</para> + +<para>As we stated previously, a zone is a point of delegation in +the <acronym>DNS</acronym> tree. A zone consists of +those contiguous parts of the domain +tree for which a name server has complete information and over which +it has authority. It contains all domain names from a certain point +downward in the domain tree except those which are delegated to +other zones. A delegation point is marked by one or more +<emphasis>NS records</emphasis> in the +parent zone, which should be matched by equivalent NS records at +the root of the delegated zone.</para> + +<para>For instance, consider the <literal>example.com</literal> +domain which includes names +such as <literal>host.aaa.example.com</literal> and +<literal>host.bbb.example.com</literal> even though +the <literal>example.com</literal> zone includes +only delegations for the <literal>aaa.example.com</literal> and +<literal>bbb.example.com</literal> zones. A zone can map +exactly to a single domain, but could also include only part of a +domain, the rest of which could be delegated to other +name servers. Every name in the <acronym>DNS</acronym> tree is a +<emphasis>domain</emphasis>, even if it is +<emphasis>terminal</emphasis>, that is, has no +<emphasis>subdomains</emphasis>. Every subdomain is a domain and +every domain except the root is also a subdomain. The terminology is +not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to +gain a complete understanding of this difficult and subtle +topic.</para> + +<para>Though <acronym>BIND</acronym> is called a "domain name server", +it deals primarily in terms of zones. The master and slave +declarations in the <filename>named.conf</filename> file specify +zones, not domains. When you ask some other site if it is willing to +be a slave server for your <emphasis>domain</emphasis>, you are +actually asking for slave service for some collection of zones.</para> +</sect2> + +<sect2><title>Authoritative Name Servers</title> + +<para>Each zone is served by at least +one <emphasis>authoritative name server</emphasis>, +which contains the complete data for the zone. +To make the DNS tolerant of server and network failures, +most zones have two or more authoritative servers. +</para> + +<para>Responses from authoritative servers have the "authoritative +answer" (AA) bit set in the response packets. This makes them +easy to identify when debugging DNS configurations using tools like +<command>dig</command> (<xref linkend="diagnostic_tools"/>).</para> + +<sect3><title>The Primary Master</title> + +<para> +The authoritative server where the master copy of the zone data is maintained is +called the <emphasis>primary master</emphasis> server, or simply the +<emphasis>primary</emphasis>. It loads the zone contents from some +local file edited by humans or perhaps generated mechanically from +some other local file which is edited by humans. This file is called +the <emphasis>zone file</emphasis> or <emphasis>master file</emphasis>.</para> +</sect3> + +<sect3><title>Slave Servers</title> +<para>The other authoritative servers, the <emphasis>slave</emphasis> +servers (also known as <emphasis>secondary</emphasis> servers) load +the zone contents from another server using a replication process +known as a <emphasis>zone transfer</emphasis>. Typically the data are +transferred directly from the primary master, but it is also possible +to transfer it from another slave. In other words, a slave server +may itself act as a master to a subordinate slave server.</para> +</sect3> + +<sect3><title>Stealth Servers</title> + +<para>Usually all of the zone's authoritative servers are listed in +NS records in the parent zone. These NS records constitute +a <emphasis>delegation</emphasis> of the zone from the parent. +The authoritative servers are also listed in the zone file itself, +at the <emphasis>top level</emphasis> or <emphasis>apex</emphasis> +of the zone. You can list servers in the zone's top-level NS +records that are not in the parent's NS delegation, but you cannot +list servers in the parent's delegation that are not present at +the zone's top level.</para> + +<para>A <emphasis>stealth server</emphasis> is a server that is +authoritative for a zone but is not listed in that zone's NS +records. Stealth servers can be used for keeping a local copy of a +zone to speed up access to the zone's records or to make sure that the +zone is available even if all the "official" servers for the zone are +inaccessible.</para> + +<para>A configuration where the primary master server itself is a +stealth server is often referred to as a "hidden primary" +configuration. One use for this configuration is when the primary master +is behind a firewall and therefore unable to communicate directly +with the outside world.</para> + +</sect3> + +</sect2> +<sect2> + +<title>Caching Name Servers</title> + +<para>The resolver libraries provided by most operating systems are +<emphasis>stub resolvers</emphasis>, meaning that they are not capable of +performing the full DNS resolution process by themselves by talking +directly to the authoritative servers. Instead, they rely on a local +name server to perform the resolution on their behalf. Such a server +is called a <emphasis>recursive</emphasis> name server; it performs +<emphasis>recursive lookups</emphasis> for local clients.</para> + +<para>To improve performance, recursive servers cache the results of +the lookups they perform. Since the processes of recursion and +caching are intimately connected, the terms +<emphasis>recursive server</emphasis> and +<emphasis>caching server</emphasis> are often used synonymously.</para> + +<para>The length of time for which a record may be retained in +in the cache of a caching name server is controlled by the +Time To Live (TTL) field associated with each resource record. +</para> + +<sect3><title>Forwarding</title> + +<para>Even a caching name server does not necessarily perform +the complete recursive lookup itself. Instead, it can +<emphasis>forward</emphasis> some or all of the queries +that it cannot satisfy from its cache to another caching name server, +commonly referred to as a <emphasis>forwarder</emphasis>. +</para> + +<para>There may be one or more forwarders, +and they are queried in turn until the list is exhausted or an answer +is found. Forwarders are typically used when you do not +wish all the servers at a given site to interact directly with the rest of +the Internet servers. A typical scenario would involve a number +of internal <acronym>DNS</acronym> servers and an Internet firewall. Servers unable +to pass packets through the firewall would forward to the server +that can do it, and that server would query the Internet <acronym>DNS</acronym> servers +on the internal server's behalf. An added benefit of using the forwarding +feature is that the central machine develops a much more complete +cache of information that all the clients can take advantage +of.</para> +</sect3> + +</sect2> + +<sect2><title>Name Servers in Multiple Roles</title> + +<para>The <acronym>BIND</acronym> name server can simultaneously act as +a master for some zones, a slave for other zones, and as a caching +(recursive) server for a set of local clients.</para> + +<para>However, since the functions of authoritative name service +and caching/recursive name service are logically separate, it is +often advantageous to run them on separate server machines. + +A server that only provides authoritative name service +(an <emphasis>authoritative-only</emphasis> server) can run with +recursion disabled, improving reliability and security. + +A server that is not authoritative for any zones and only provides +recursive service to local +clients (a <emphasis>caching-only</emphasis> server) +does not need to be reachable from the Internet at large and can +be placed inside a firewall.</para> + + </sect2> + </sect1> + +</chapter> + +<chapter id="ch02"><title><acronym>BIND</acronym> Resource Requirements</title> + +<sect1> +<title>Hardware requirements</title> + +<para><acronym>DNS</acronym> hardware requirements have traditionally been quite modest. +For many installations, servers that have been pensioned off from +active duty have performed admirably as <acronym>DNS</acronym> servers.</para> +<para>The DNSSEC and IPv6 features of <acronym>BIND</acronym> 9 may prove to be quite +CPU intensive however, so organizations that make heavy use of these +features may wish to consider larger systems for these applications. +<acronym>BIND</acronym> 9 is fully multithreaded, allowing full utilization of +multiprocessor systems for installations that need it.</para></sect1> +<sect1><title>CPU Requirements</title> +<para>CPU requirements for <acronym>BIND</acronym> 9 range from i486-class machines +for serving of static zones without caching, to enterprise-class +machines if you intend to process many dynamic updates and DNSSEC +signed zones, serving many thousands of queries per second.</para></sect1> + +<sect1><title>Memory Requirements</title> +<para>The memory of the server has to be large enough to fit the +cache and zones loaded off disk. The <command>max-cache-size</command> +option can be used to limit the amount of memory used by the cache, +at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym> +traffic. It is still good practice to have enough memory to load +all zone and cache data into memory — unfortunately, the best way +to determine this for a given installation is to watch the name server +in operation. After a few weeks the server process should reach +a relatively stable size where entries are expiring from the cache as +fast as they are being inserted.</para></sect1> + +<sect1><title>Name Server Intensive Environment Issues</title> +<para>For name server intensive environments, there are two alternative +configurations that may be used. The first is where clients and +any second-level internal name servers query a main name server, which +has enough memory to build a large cache. This approach minimizes +the bandwidth used by external name lookups. The second alternative +is to set up second-level internal name servers to make queries independently. +In this configuration, none of the individual machines needs to +have as much memory or CPU power as in the first alternative, but +this has the disadvantage of making many more external queries, +as none of the name servers share their cached data.</para></sect1> + +<sect1><title>Supported Operating Systems</title> +<para>ISC <acronym>BIND</acronym> 9 compiles and runs on a large number +of Unix-like operating system and on Windows NT / 2000. For an up-to-date +list of supported systems, see the README file in the top level directory +of the BIND 9 source distribution.</para> +</sect1> +</chapter> + +<chapter id="ch03"> +<title>Name Server Configuration</title> +<para>In this section we provide some suggested configurations along +with guidelines for their use. We also address the topic of reasonable +option setting.</para> + +<sect1 id="sample_configuration"> +<title>Sample Configurations</title> +<sect2> +<title>A Caching-only Name Server</title> +<para>The following sample configuration is appropriate for a caching-only +name server for use by clients internal to a corporation. All queries +from outside clients are refused using the <command>allow-query</command> +option. Alternatively, the same effect could be achieved using suitable +firewall rules.</para> + +<programlisting> +// Two corporate subnets we wish to allow queries from. +acl corpnets { 192.168.4.0/24; 192.168.7.0/24; }; +options { + directory "/etc/namedb"; // Working directory + allow-query { corpnets; }; +}; +// Provide a reverse mapping for the loopback address 127.0.0.1 +zone "0.0.127.in-addr.arpa" { + type master; + file "localhost.rev"; + notify no; +}; +</programlisting> +</sect2> + +<sect2> +<title>An Authoritative-only Name Server</title> +<para>This sample configuration is for an authoritative-only server +that is the master server for "<filename>example.com</filename>" +and a slave for the subdomain "<filename>eng.example.com</filename>".</para> + +<programlisting> +options { + directory "/etc/namedb"; // Working directory + allow-query { any; }; // This is the default + recursion no; // Do not provide recursive service +}; + +// Provide a reverse mapping for the loopback address 127.0.0.1 +zone "0.0.127.in-addr.arpa" { + type master; + file "localhost.rev"; + notify no; +}; +// We are the master server for example.com +zone "example.com" { + type master; + file "example.com.db"; + // IP addresses of slave servers allowed to transfer example.com + allow-transfer { + 192.168.4.14; + 192.168.5.53; + }; +}; +// We are a slave server for eng.example.com +zone "eng.example.com" { + type slave; + file "eng.example.com.bk"; + // IP address of eng.example.com master server + masters { 192.168.4.12; }; +}; +</programlisting> +</sect2> +</sect1> + +<sect1> +<title>Load Balancing</title> + +<para>A primitive form of load balancing can be achieved in +the <acronym>DNS</acronym> by using multiple A records for one name.</para> + +<para>For example, if you have three WWW servers with network addresses +of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the +following means that clients will connect to each machine one third +of the time:</para> + +<informaltable colsep = "0" rowsep = "0"> +<tgroup cols = "5" colsep = "0" rowsep = "0" tgroupstyle = "2Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.500in"/> +<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "0.750in"/> +<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "0.750in"/> +<colspec colname = "5" colnum = "5" colsep = "0" colwidth = "2.028in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para>Name</para></entry> +<entry colname = "2"><para>TTL</para></entry> +<entry colname = "3"><para>CLASS</para></entry> +<entry colname = "4"><para>TYPE</para></entry> +<entry colname = "5"><para>Resource Record (RR) Data</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><literal>www</literal></para></entry> +<entry colname = "2"><para><literal>600</literal></para></entry> +<entry colname = "3"><para><literal>IN</literal></para></entry> +<entry colname = "4"><para><literal>A</literal></para></entry> +<entry colname = "5"><para><literal>10.0.0.1</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para><literal>600</literal></para></entry> +<entry colname = "3"><para><literal>IN</literal></para></entry> +<entry colname = "4"><para><literal>A</literal></para></entry> +<entry colname = "5"><para><literal>10.0.0.2</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para><literal>600</literal></para></entry> +<entry colname = "3"><para><literal>IN</literal></para></entry> +<entry colname = "4"><para><literal>A</literal></para></entry> +<entry colname = "5"><para><literal>10.0.0.3</literal></para></entry> + </row> + </tbody> + </tgroup> + </informaltable> + <para>When a resolver queries for these records, <acronym>BIND</acronym> will rotate + them and respond to the query with the records in a different + order. In the example above, clients will randomly receive + records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients + will use the first record returned and discard the rest.</para> + <para>For more detail on ordering responses, check the + <command>rrset-order</command> substatement in the + <command>options</command> statement, see + <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>. + This substatement is not supported in + <acronym>BIND</acronym> 9, and only the ordering scheme described above is + available.</para> + +</sect1> + +<sect1> +<title>Name Server Operations</title> + +<sect2> +<title>Tools for Use With the Name Server Daemon</title> +<para>There are several indispensable diagnostic, administrative +and monitoring tools available to the system administrator for controlling +and debugging the name server daemon. We describe several in this +section </para> +<sect3 id="diagnostic_tools"> +<title>Diagnostic Tools</title> +<para>The <command>dig</command>, <command>host</command>, and +<command>nslookup</command> programs are all command line tools +for manually querying name servers. They differ in style and +output format. +</para> + +<variablelist> +<varlistentry> +<term id="dig"><command>dig</command></term> +<listitem> +<para>The domain information groper (<command>dig</command>) +is the most versatile and complete of these lookup tools. +It has two modes: simple interactive +mode for a single query, and batch mode which executes a query for +each in a list of several query lines. All query options are accessible +from the command line.</para> +<cmdsynopsis label="Usage"> + <command>dig</command> + <arg>@<replaceable>server</replaceable></arg> + <arg choice="plain"><replaceable>domain</replaceable></arg> + <arg><replaceable>query-type</replaceable></arg> + <arg><replaceable>query-class</replaceable></arg> + <arg>+<replaceable>query-option</replaceable></arg> + <arg>-<replaceable>dig-option</replaceable></arg> + <arg>%<replaceable>comment</replaceable></arg> +</cmdsynopsis> +<para>The usual simple use of dig will take the form</para> +<simpara><command>dig @server domain query-type query-class</command></simpara> +<para>For more information and a list of available commands and +options, see the <command>dig</command> man page.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term><command>host</command></term> +<listitem> +<para>The <command>host</command> utility emphasizes simplicity +and ease of use. By default, it converts +between host names and Internet addresses, but its functionality +can be extended with the use of options.</para> +<cmdsynopsis label="Usage"> + <command>host</command> + <arg>-aCdlrTwv</arg> + <arg>-c <replaceable>class</replaceable></arg> + <arg>-N <replaceable>ndots</replaceable></arg> + <arg>-t <replaceable>type</replaceable></arg> + <arg>-W <replaceable>timeout</replaceable></arg> + <arg>-R <replaceable>retries</replaceable></arg> + <arg choice="plain"><replaceable>hostname</replaceable></arg> + <arg><replaceable>server</replaceable></arg> +</cmdsynopsis> +<para>For more information and a list of available commands and +options, see the <command>host</command> man page.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term><command>nslookup</command></term> +<listitem> +<para><command>nslookup</command> has two modes: interactive +and non-interactive. Interactive mode allows the user to query name servers +for information about various hosts and domains or to print a list +of hosts in a domain. Non-interactive mode is used to print just +the name and requested information for a host or domain.</para> +<cmdsynopsis label="Usage"> + <command>nslookup</command> + <arg rep="repeat">-option</arg> + <group> + <arg><replaceable>host-to-find</replaceable></arg> + <arg>- <arg>server</arg></arg> + </group> +</cmdsynopsis> +<para>Interactive mode is entered when no arguments are given (the +default name server will be used) or when the first argument is a +hyphen (`-') and the second argument is the host name or Internet address +of a name server.</para> +<para>Non-interactive mode is used when the name or Internet address +of the host to be looked up is given as the first argument. The +optional second argument specifies the host name or address of a name server.</para> +<para>Due to its arcane user interface and frequently inconsistent +behavior, we do not recommend the use of <command>nslookup</command>. +Use <command>dig</command> instead.</para> +</listitem> + +</varlistentry> +</variablelist> +</sect3> + +<sect3 id="admin_tools"> + <title>Administrative Tools</title> + <para>Administrative tools play an integral part in the management +of a server.</para> + <variablelist> + <varlistentry id="named-checkconf" xreflabel="Named Configuration Checking application"> + <term><command>named-checkconf</command></term> + <listitem> + <para>The <command>named-checkconf</command> program + checks the syntax of a <filename>named.conf</filename> file.</para> + <cmdsynopsis label="Usage"> + <command>named-checkconf</command> + <arg>-t <replaceable>directory</replaceable></arg> + <arg><replaceable>filename</replaceable></arg> + </cmdsynopsis> + </listitem> + </varlistentry> + <varlistentry id="named-checkzone" xreflabel="Zone Checking application"> + <term><command>named-checkzone</command></term> + <listitem> + <para>The <command>named-checkzone</command> program checks a master file for + syntax and consistency.</para> + <cmdsynopsis label="Usage"> + <command>named-checkzone</command> + <arg>-dq</arg> + <arg>-c <replaceable>class</replaceable></arg> + <arg choice="plain"><replaceable>zone</replaceable></arg> + <arg><replaceable>filename</replaceable></arg> + </cmdsynopsis> + </listitem> + </varlistentry> + <varlistentry id="rndc" xreflabel="Remote Name Daemon Control application"> + <term><command>rndc</command></term> + <listitem> + <para>The remote name daemon control + (<command>rndc</command>) program allows the system + administrator to control the operation of a name server. + If you run <command>rndc</command> without any options + it will display a usage message as follows:</para> + <cmdsynopsis label="Usage"> + <command>rndc</command> + <arg>-c <replaceable>config</replaceable></arg> + <arg>-s <replaceable>server</replaceable></arg> + <arg>-p <replaceable>port</replaceable></arg> + <arg>-y <replaceable>key</replaceable></arg> + <arg choice="plain"><replaceable>command</replaceable></arg> + <arg rep="repeat"><replaceable>command</replaceable></arg> + </cmdsynopsis> + <para><command>command</command> is one of the following:</para> + +<variablelist> + + <varlistentry><term><userinput>reload</userinput></term> + <listitem><para>Reload configuration file and zones.</para></listitem> + </varlistentry> + + <varlistentry><term><userinput>reload <replaceable>zone</replaceable> + <optional><replaceable>class</replaceable> + <optional><replaceable>view</replaceable></optional></optional></userinput></term> + <listitem><para>Reload the given zone.</para></listitem> + </varlistentry> + + <varlistentry><term><userinput>refresh <replaceable>zone</replaceable> + <optional><replaceable>class</replaceable> + <optional><replaceable>view</replaceable></optional></optional></userinput></term> + <listitem><para>Schedule zone maintenance for the given zone.</para></listitem> + </varlistentry> + + <varlistentry><term><userinput>retransfer <replaceable>zone</replaceable> + <optional><replaceable>class</replaceable> + <optional><replaceable>view</replaceable></optional></optional></userinput></term> + <listitem><para>Retransfer the given zone from the master.</para></listitem> + </varlistentry> + + <varlistentry><term><userinput>freeze <replaceable>zone</replaceable> + <optional><replaceable>class</replaceable> + <optional><replaceable>view</replaceable></optional></optional></userinput></term> + <listitem><para>Suspend updates to a dynamic zone. This allows manual + edits to be made to a zone normally updated by dynamic update. It + also causes changes in the journal file to be synced into the master + and the journal file to be removed. All dynamic update attempts will + be refused while the zone is frozen.</para></listitem> + </varlistentry> + + <varlistentry><term><userinput>unfreeze <replaceable>zone</replaceable> + <optional><replaceable>class</replaceable> + <optional><replaceable>view</replaceable></optional></optional></userinput></term> + <listitem><para>Enable updates to a frozen dynamic zone. This causes + the server to reload the zone from disk, and re-enables dynamic updates + after the load has completed. After a zone is unfrozen, dynamic updates + will no longer be refused.</para></listitem> + </varlistentry> + + <varlistentry><term><userinput>reconfig</userinput></term> + <listitem><para>Reload the configuration file and load new zones, + but do not reload existing zone files even if they have changed. + This is faster than a full <command>reload</command> when there + is a large number of zones because it avoids the need to examine the + modification times of the zones files. + </para></listitem> + </varlistentry> + + <varlistentry><term><userinput>stats</userinput></term> + <listitem><para>Write server statistics to the statistics file.</para></listitem> + </varlistentry> + + <varlistentry><term><userinput>querylog</userinput></term> + <listitem><para>Toggle query logging. Query logging can also be enabled + by explicitly directing the <command>queries</command> + <command>category</command> to a <command>channel</command> in the + <command>logging</command> section of + <filename>named.conf</filename>.</para></listitem></varlistentry> + + <varlistentry><term><userinput>dumpdb</userinput></term> + <listitem><para>Dump the server's caches to the dump file. </para></listitem></varlistentry> + + <varlistentry><term><userinput>stop</userinput></term> + <listitem><para>Stop the server, + making sure any recent changes + made through dynamic update or IXFR are first saved to the master files + of the updated zones.</para></listitem></varlistentry> + + <varlistentry><term><userinput>halt</userinput></term> + <listitem><para>Stop the server immediately. Recent changes + made through dynamic update or IXFR are not saved to the master files, + but will be rolled forward from the journal files when the server + is restarted.</para></listitem></varlistentry> + + <varlistentry><term><userinput>trace</userinput></term> + <listitem><para>Increment the servers debugging level by one. </para></listitem></varlistentry> + + <varlistentry><term><userinput>trace <replaceable>level</replaceable></userinput></term> + <listitem><para>Sets the server's debugging level to an explicit + value.</para></listitem></varlistentry> + + <varlistentry><term><userinput>notrace</userinput></term> + <listitem><para>Sets the server's debugging level to 0.</para></listitem></varlistentry> + + <varlistentry><term><userinput>flush</userinput></term> + <listitem><para>Flushes the server's cache.</para></listitem></varlistentry> + + <varlistentry><term><userinput>status</userinput></term> + <listitem><para>Display status of the server. +Note the number of zones includes the internal <command>bind/CH</command> zone +and the default <command>./IN</command> hint zone if there is not a +explicit root zone configured.</para></listitem></varlistentry> + +</variablelist> + +<para>In <acronym>BIND</acronym> 9.2, <command>rndc</command> +supports all the commands of the BIND 8 <command>ndc</command> +utility except <command>ndc start</command> and +<command>ndc restart</command>, which were also +not supported in <command>ndc</command>'s channel mode.</para> + +<para>A configuration file is required, since all +communication with the server is authenticated with +digital signatures that rely on a shared secret, and +there is no way to provide that secret other than with a +configuration file. The default location for the +<command>rndc</command> configuration file is +<filename>/etc/rndc.conf</filename>, but an alternate +location can be specified with the <option>-c</option> +option. If the configuration file is not found, +<command>rndc</command> will also look in +<filename>/etc/rndc.key</filename> (or whatever +<varname>sysconfdir</varname> was defined when +the <acronym>BIND</acronym> build was configured). +The <filename>rndc.key</filename> file is generated by +running <command>rndc-confgen -a</command> as described in +<xref linkend="controls_statement_definition_and_usage"/>.</para> + +<para>The format of the configuration file is similar to +that of <filename>named.conf</filename>, but limited to +only four statements, the <command>options</command>, +<command>key</command>, <command>server</command> and +<command>include</command> +statements. These statements are what associate the +secret keys to the servers with which they are meant to +be shared. The order of statements is not +significant.</para> + +<para>The <command>options</command> statement has three clauses: +<command>default-server</command>, <command>default-key</command>, +and <command>default-port</command>. +<command>default-server</command> takes a +host name or address argument and represents the server that will +be contacted if no <option>-s</option> +option is provided on the command line. +<command>default-key</command> takes +the name of a key as its argument, as defined by a <command>key</command> statement. +<command>default-port</command> specifies the port to which +<command>rndc</command> should connect if no +port is given on the command line or in a +<command>server</command> statement.</para> + +<para>The <command>key</command> statement defines an key to be used +by <command>rndc</command> when authenticating with +<command>named</command>. Its syntax is identical to the +<command>key</command> statement in named.conf. +The keyword <userinput>key</userinput> is +followed by a key name, which must be a valid +domain name, though it need not actually be hierarchical; thus, +a string like "<userinput>rndc_key</userinput>" is a valid name. +The <command>key</command> statement has two clauses: +<command>algorithm</command> and <command>secret</command>. +While the configuration parser will accept any string as the argument +to algorithm, currently only the string "<userinput>hmac-md5</userinput>" +has any meaning. The secret is a base-64 encoded string.</para> + +<para>The <command>server</command> statement associates a key +defined using the <command>key</command> statement with a server. +The keyword <userinput>server</userinput> is followed by a +host name or address. The <command>server</command> statement +has two clauses: <command>key</command> and <command>port</command>. +The <command>key</command> clause specifies the name of the key +to be used when communicating with this server, and the +<command>port</command> clause can be used to +specify the port <command>rndc</command> should connect +to on the server.</para> + +<para>A sample minimal configuration file is as follows:</para> +<programlisting> +key rndc_key { + algorithm "hmac-md5"; + secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; +}; +options { + default-server 127.0.0.1; + default-key rndc_key; +}; +</programlisting> + +<para>This file, if installed as <filename>/etc/rndc.conf</filename>, +would allow the command:</para> + +<para><prompt>$ </prompt><userinput>rndc reload</userinput></para> + +<para>to connect to 127.0.0.1 port 953 and cause the name server +to reload, if a name server on the local machine were running with +following controls statements:</para> +<programlisting> +controls { + inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; +}; +</programlisting> +<para>and it had an identical key statement for +<literal>rndc_key</literal>.</para> + +<para>Running the <command>rndc-confgen</command> program will +conveniently create a <filename>rndc.conf</filename> +file for you, and also display the +corresponding <command>controls</command> statement that you need to +add to <filename>named.conf</filename>. Alternatively, +you can run <command>rndc-confgen -a</command> to set up +a <filename>rndc.key</filename> file and not modify +<filename>named.conf</filename> at all. +</para> + + </listitem> + </varlistentry> + </variablelist> + + </sect3> + </sect2> +<sect2> + +<title>Signals</title> +<para>Certain UNIX signals cause the name server to take specific +actions, as described in the following table. These signals can +be sent using the <command>kill</command> command.</para> +<informaltable frame = "all" ><tgroup cols = "2"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.125in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.000in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><command>SIGHUP</command></para></entry> +<entry colname = "2"><para>Causes the server to read <filename>named.conf</filename> and +reload the database. </para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>SIGTERM</command></para></entry> +<entry colname = "2"><para>Causes the server to clean up and exit.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"> +<para><command>SIGINT</command></para> +</entry> + <entry colname = "2"><para>Causes the server to clean up and exit.</para></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </sect2> + </sect1> + </chapter> + +<chapter id="ch04"> +<title>Advanced DNS Features</title> + +<sect1 id="notify"> + +<title>Notify</title> +<para><acronym>DNS</acronym> NOTIFY is a mechanism that allows master +servers to notify their slave servers of changes to a zone's data. In +response to a <command>NOTIFY</command> from a master server, the +slave will check to see that its version of the zone is the +current version and, if not, initiate a zone transfer.</para> + +<para><acronym>DNS</acronym> +For more information about +<command>NOTIFY</command>, see the description of the +<command>notify</command> option in <xref linkend="boolean_options"/> and +the description of the zone option <command>also-notify</command> in +<xref linkend="zone_transfers"/>. The <command>NOTIFY</command> +protocol is specified in RFC 1996. +</para> + +</sect1> + +<sect1 id="dynamic_update"> +<title>Dynamic Update</title> + + <para>Dynamic Update is a method for adding, replacing or deleting + records in a master server by sending it a special form of DNS + messages. The format and meaning of these messages is specified + in RFC 2136.</para> + + <para>Dynamic update is enabled on a zone-by-zone basis, by + including an <command>allow-update</command> or + <command>update-policy</command> clause in the + <command>zone</command> statement.</para> + + <para>Updating of secure zones (zones using DNSSEC) follows + RFC 3007: RRSIG and NSEC 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.</para> + + <sect2 id="journal"> + <title>The journal file</title> + + <para>All changes made to a zone using dynamic update are stored in the + zone's journal file. This file is automatically created by the + server when when the first dynamic update takes place. The name of + the journal file is formed by appending the + extension <filename>.jnl</filename> to the + name of the corresponding zone file. The journal file is in a + binary format and should not be edited manually.</para> + + <para>The server will also occasionally write ("dump") + the complete contents of the updated zone to its zone file. + This is not done immediately after + each dynamic update, because that would be too slow when a large + zone is updated frequently. Instead, the dump is delayed by + up to 15 minutes, allowing additional updates to take place.</para> + + <para>When a server is restarted after a shutdown or crash, it will replay + the journal file to incorporate into the zone any updates that took + place after the last zone dump.</para> + + <para>Changes that result from incoming incremental zone transfers are also + journalled in a similar way.</para> + + <para>The zone files of dynamic zones cannot normally be edited by + hand because they are not guaranteed to contain the most recent + dynamic changes - those are only in the journal file. + The only way to ensure that the zone file of a dynamic zone + is up to date is to run <command>rndc stop</command>.</para> + + <para>If you have to make changes to a dynamic zone + manually, the following procedure will work: Disable dynamic updates + to the zone using + <command>rndc freeze <replaceable>zone</replaceable></command>. + This will also remove the zone's <filename>.jnl</filename> file + and update the master file. Edit the zone file. Run + <command>rndc unfreeze <replaceable>zone</replaceable></command> + to reload the changed zone and re-enable dynamic updates.</para> + + </sect2> + +</sect1> + +<sect1 id="incremental_zone_transfers"> +<title>Incremental Zone Transfers (IXFR)</title> + +<para>The incremental zone transfer (IXFR) protocol is a way for +slave servers to transfer only changed data, instead of having to +transfer the entire zone. The IXFR protocol is specified in RFC +1995. See <xref linkend="proposed_standards"/>.</para> + +<para>When acting as a master, <acronym>BIND</acronym> 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. For manually maintained master +zones, and for slave zones obtained by performing a full zone +transfer (AXFR), IXFR is supported only if the option +<command>ixfr-from-differences</command> is set +to <userinput>yes</userinput>. +</para> + +<para>When acting as a slave, <acronym>BIND</acronym> 9 will +attempt to use IXFR unless +it is explicitly disabled. For more information about disabling +IXFR, see the description of the <command>request-ixfr</command> clause +of the <command>server</command> statement.</para> +</sect1> + +<sect1><title>Split DNS</title> +<para>Setting up different views, or visibility, of the DNS space to +internal and external resolvers is usually referred to as a <emphasis>Split +DNS</emphasis> setup. There are several reasons an organization +would want to set up its DNS this way.</para> +<para>One common reason for setting up a DNS system this way is +to hide "internal" DNS information from "external" clients on the +Internet. There is some debate as to whether or not this is actually useful. +Internal DNS information leaks out in many ways (via email headers, +for example) and most savvy "attackers" can find the information +they need using other means.</para> +<para>Another common reason for setting up a Split DNS system is +to allow internal networks that are behind filters or in RFC 1918 +space (reserved IP space, as documented in RFC 1918) to resolve DNS +on the Internet. Split DNS can also be used to allow mail from outside +back in to the internal network.</para> +<para>Here is an example of a split DNS setup:</para> +<para>Let's say a company named <emphasis>Example, Inc.</emphasis> +(<literal>example.com</literal>) +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.</para> +<para><emphasis>Example, Inc.</emphasis> 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.</para> +<para>In order to accomplish this, the company will set up two sets +of name servers. One set will be on the inside network (in the reserved +IP space) and the other set will be on bastion hosts, which are "proxy" +hosts that can talk to both sides of its network, in the DMZ.</para> +<para>The internal servers will be configured to forward all queries, +except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>, +and <filename>site2.example.com</filename>, to the servers in the +DMZ. These internal servers will have complete sets of information +for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>,<emphasis> </emphasis><filename>site1.internal</filename>, +and <filename>site2.internal</filename>.</para> +<para>To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains, +the internal name servers must be configured to disallow all queries +to these domains from any external hosts, including the bastion +hosts.</para> +<para>The external servers, which are on the bastion hosts, will +be configured to serve the "public" version of the <filename>site1</filename> and <filename>site2.example.com</filename> zones. +This could include things such as the host records for public servers +(<filename>www.example.com</filename> and <filename>ftp.example.com</filename>), +and mail exchange (MX) records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).</para> +<para>In addition, the public <filename>site1</filename> and <filename>site2.example.com</filename> 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.</para> +<para>Here's an example of a wildcard MX record:</para> +<programlisting><literal>* IN MX 10 external1.example.com.</literal></programlisting> +<para>Now that they accept mail on behalf of anything in the internal +network, the bastion hosts will need to know how to deliver mail +to internal hosts. In order for this to work properly, the resolvers on +the bastion hosts will need to be configured to point to the internal +name servers for DNS resolution.</para> +<para>Queries for internal hostnames will be answered by the internal +servers, and queries for external hostnames will be forwarded back +out to the DNS servers on the bastion hosts.</para> +<para>In order for all this to work properly, internal clients will +need to be configured to query <emphasis>only</emphasis> the internal +name servers for DNS queries. This could also be enforced via selective +filtering on the network.</para> +<para>If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s +internal clients will now be able to:</para> +<itemizedlist><listitem> + <simpara>Look up any hostnames in the <literal>site1</literal> and +<literal>site2.example.com</literal> zones.</simpara></listitem> +<listitem> + <simpara>Look up any hostnames in the <literal>site1.internal</literal> and +<literal>site2.internal</literal> domains.</simpara></listitem> +<listitem> + <simpara>Look up any hostnames on the Internet.</simpara></listitem> +<listitem> + <simpara>Exchange mail with internal AND external people.</simpara></listitem></itemizedlist> +<para>Hosts on the Internet will be able to:</para> +<itemizedlist><listitem> + <simpara>Look up any hostnames in the <literal>site1</literal> and +<literal>site2.example.com</literal> zones.</simpara></listitem> +<listitem> + <simpara>Exchange mail with anyone in the <literal>site1</literal> and +<literal>site2.example.com</literal> zones.</simpara></listitem></itemizedlist> + + <para>Here is an example configuration for the setup we just + described above. Note that this is only configuration information; + for information on how to configure your zone files, see <xref + linkend="sample_configuration"/></para> + +<para>Internal DNS server config:</para> +<programlisting> + +acl internals { 172.16.72.0/24; 192.168.1.0/24; }; + +acl externals { <varname>bastion-ips-go-here</varname>; }; + +options { + ... + ... + forward only; + forwarders { // forward to external servers + <varname>bastion-ips-go-here</varname>; + }; + allow-transfer { none; }; // sample allow-transfer (no one) + allow-query { internals; externals; }; // restrict query access + allow-recursion { internals; }; // restrict recursion + ... + ... +}; + +zone "site1.example.com" { // sample master zone + type master; + file "m/site1.example.com"; + forwarders { }; // do normal iterative + // resolution (do not forward) + allow-query { internals; externals; }; + allow-transfer { internals; }; +}; + +zone "site2.example.com" { // sample slave zone + type slave; + file "s/site2.example.com"; + masters { 172.16.72.3; }; + forwarders { }; + allow-query { internals; externals; }; + allow-transfer { internals; }; +}; + +zone "site1.internal" { + type master; + file "m/site1.internal"; + forwarders { }; + allow-query { internals; }; + allow-transfer { internals; } +}; + +zone "site2.internal" { + type slave; + file "s/site2.internal"; + masters { 172.16.72.3; }; + forwarders { }; + allow-query { internals }; + allow-transfer { internals; } +}; +</programlisting> + <para>External (bastion host) DNS server config:</para> +<programlisting> +acl internals { 172.16.72.0/24; 192.168.1.0/24; }; + +acl externals { bastion-ips-go-here; }; + +options { + ... + ... + allow-transfer { none; }; // sample allow-transfer (no one) + allow-query { internals; externals; }; // restrict query access + allow-recursion { internals; externals; }; // restrict recursion + ... + ... +}; + +zone "site1.example.com" { // sample slave zone + type master; + file "m/site1.foo.com"; + allow-query { any; }; + allow-transfer { internals; externals; }; +}; + +zone "site2.example.com" { + type slave; + file "s/site2.foo.com"; + masters { another_bastion_host_maybe; }; + allow-query { any; }; + allow-transfer { internals; externals; } +}; +</programlisting> +<para>In the <filename>resolv.conf</filename> (or equivalent) on +the bastion host(s):</para> +<programlisting> +search ... +nameserver 172.16.72.2 +nameserver 172.16.72.3 +nameserver 172.16.72.4 +</programlisting> +</sect1> +<sect1 id="tsig"><title>TSIG</title> +<para>This is a short guide to setting up Transaction SIGnatures +(TSIG) based transaction security in <acronym>BIND</acronym>. 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 <acronym>BIND</acronym>.</para> +<para><acronym>BIND</acronym> primarily supports TSIG for server to server communication. +This includes zone transfer, notify, and recursive query messages. +Resolvers based on newer versions of <acronym>BIND</acronym> 8 have limited support +for TSIG.</para> + + <para>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. + The cryptographic access control provided by TSIG + is far superior. The <command>nsupdate</command> + program supports TSIG via the <option>-k</option> and + <option>-y</option> command line options.</para> + +<sect2><title>Generate Shared Keys for Each Pair of Hosts</title> +<para>A shared secret is generated to be shared between <emphasis>host1</emphasis> and <emphasis>host2</emphasis>. +An arbitrary key name is chosen: "host1-host2.". The key name must +be the same on both hosts.</para> +<sect3><title>Automatic Generation</title> +<para>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.</para> + <para><userinput>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</userinput></para> +<para>The key is in the file <filename>Khost1-host2.+157+00000.private</filename>. +Nothing directly uses this file, but the base-64 encoded string +following "<literal>Key:</literal>" +can be extracted from the file and used as a shared secret:</para> +<programlisting>Key: La/E5CjG9O+os1jq0a2jdA==</programlisting> +<para>The string "<literal>La/E5CjG9O+os1jq0a2jdA==</literal>" can +be used as the shared secret.</para></sect3> +<sect3><title>Manual Generation</title> +<para>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.</para> +<para>Also, a known string can be run through <command>mmencode</command> or +a similar program to generate base-64 encoded data.</para></sect3></sect2> +<sect2><title>Copying the Shared Secret to Both Machines</title> +<para>This is beyond the scope of DNS. A secure transport mechanism +should be used. This could be secure FTP, ssh, telephone, etc.</para></sect2> +<sect2><title>Informing the Servers of the Key's Existence</title> +<para>Imagine <emphasis>host1</emphasis> and <emphasis>host 2</emphasis> are +both servers. The following is added to each server's <filename>named.conf</filename> file:</para> +<programlisting> +key host1-host2. { + algorithm hmac-md5; + secret "La/E5CjG9O+os1jq0a2jdA=="; +}; +</programlisting> +<para>The algorithm, hmac-md5, is the only one supported by <acronym>BIND</acronym>. +The secret is the one generated above. Since this is a secret, it +is recommended that either <filename>named.conf</filename> be non-world +readable, or the key directive be added to a non-world readable +file that is included by <filename>named.conf</filename>.</para> +<para>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 is successfully verified, the +response is signed by the same key.</para></sect2> + +<sect2><title>Instructing the Server to Use the Key</title> +<para>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 <filename>named.conf</filename> file +for <emphasis>host1</emphasis>, if the IP address of <emphasis>host2</emphasis> is +10.1.2.3:</para> +<programlisting> +server 10.1.2.3 { + keys { host1-host2. ;}; +}; +</programlisting> +<para>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.</para> +<para>If <emphasis>host1</emphasis> sends a message that is a request +to that address, the message will be signed with the specified key. <emphasis>host1</emphasis> will +expect any responses to signed messages to be signed with the same +key.</para> +<para>A similar statement must be present in <emphasis>host2</emphasis>'s +configuration file (with <emphasis>host1</emphasis>'s address) for <emphasis>host2</emphasis> to +sign request messages to <emphasis>host1</emphasis>.</para></sect2> +<sect2><title>TSIG Key Based Access Control</title> +<para><acronym>BIND</acronym> allows IP addresses and ranges to be specified in ACL +definitions and +<command>allow-{ query | transfer | update }</command> directives. +This has been extended to allow TSIG keys also. The above key would +be denoted <command>key host1-host2.</command></para> +<para>An example of an allow-update directive would be:</para> +<programlisting> +allow-update { key host1-host2. ;}; +</programlisting> + + <para>This allows dynamic updates to succeed only if the request + was signed by a key named + "<command>host1-host2.</command>".</para> <para>You may want to read about the more + powerful <command>update-policy</command> statement in <xref + linkend="dynamic_update_policies"/>.</para> + + </sect2> + <sect2> + <title>Errors</title> + + <para>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.</para> + + <para>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.</para> + + </sect2> + </sect1> + <sect1> + <title>TKEY</title> + + <para><command>TKEY</command> is a mechanism for automatically + generating a shared secret between two hosts. There are several + "modes" of <command>TKEY</command> that specify how the key is + generated or assigned. <acronym>BIND</acronym> 9 + 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 <command>TKEY</command> process + must use signed messages, signed either by TSIG or SIG(0). The + result of <command>TKEY</command> is a shared secret that can be + used to sign messages with TSIG. <command>TKEY</command> can also + be used to delete shared secrets that it had previously + generated.</para> + + <para>The <command>TKEY</command> process is initiated by a client + or server by sending a signed <command>TKEY</command> query + (including any appropriate KEYs) to a TKEY-aware server. The + server response, if it indicates success, will contain a + <command>TKEY</command> record and any appropriate keys. After + this exchange, both participants have enough information to + determine the shared secret; the exact process depends on the + <command>TKEY</command> mode. When using the Diffie-Hellman + <command>TKEY</command> mode, Diffie-Hellman keys are exchanged, + and the shared secret is derived by both participants.</para> + + </sect1> + <sect1> + <title>SIG(0)</title> + + <para><acronym>BIND</acronym> 9 partially supports DNSSEC SIG(0) + transaction signatures as specified in RFC 2535 and RFC2931. 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.</para> + + <para>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.</para> + + <para>SIG(0) signing of multiple-message TCP streams is not + supported.</para> + + <para>The only tool shipped with <acronym>BIND</acronym> 9 that + generates SIG(0) signed messages is <command>nsupdate</command>.</para> + + </sect1> + <sect1 id="DNSSEC"> + <title>DNSSEC</title> + + <para>Cryptographic authentication of DNS information is possible + through the DNS Security (<emphasis>DNSSEC-bis</emphasis>) extensions, + defined in RFC <TBA>. This section describes the creation and use + of DNSSEC signed zones.</para> + + <para>In order to set up a DNSSEC secure zone, there are a series + of steps which must be followed. <acronym>BIND</acronym> 9 ships + with several tools + that are used in this process, which are explained in more detail + below. In all cases, the <option>-h</option> option prints a + full list of parameters. Note that the DNSSEC tools require the + keyset files to be in the working directory or the + directory specified by the <option>-h</option> option, and + that the tools shipped with BIND 9.2.x and earlier are not compatible + with the current ones.</para> + + <para>There must also be communication with the administrators of + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presense + or absence of a <literal>DS</literal> record at the delegation + point.</para> + + <para>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.</para> + + <sect2> + <title>Generating Keys</title> + + <para>The <command>dnssec-keygen</command> program is used to + generate keys.</para> + + <para>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 + <command>ZONE</command>, and must be usable for authentication. + It is recommended that zone keys use a cryptographic algorithm + designated as "mandatory to implement" by the IETF; currently + the only one is RSASHA1.</para> + + <para>The following command will generate a 768 bit RSASHA1 key for + the <filename>child.example</filename> zone:</para> + + <para><userinput>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</userinput></para> + + <para>Two output files will be produced: + <filename>Kchild.example.+005+12345.key</filename> and + <filename>Kchild.example.+005+12345.private</filename> (where + 12345 is an example of a key tag). The key file names contain + the key name (<filename>child.example.</filename>), algorithm (3 + is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case). + The private key (in the <filename>.private</filename> file) is + used to generate signatures, and the public key (in the + <filename>.key</filename> file) is used for signature + verification.</para> + + <para>To generate another key with the same properties (but with + a different key tag), repeat the above command.</para> + + <para>The public keys should be inserted into the zone file by + including the <filename>.key</filename> files using + <command>$INCLUDE</command> statements. + </para> + + </sect2> + <sect2> + <title>Signing the Zone</title> + + <para>The <command>dnssec-signzone</command> program is used to + sign a zone.</para> + + <para>Any <filename>keyset</filename> files corresponding + to secure subzones should be present. The zone signer will + generate <literal>NSEC</literal> and <literal>RRSIG</literal> + records for the zone, as well as <literal>DS</literal> for + the child zones if <literal>'-d'</literal> is specified. + If <literal>'-d'</literal> is not specified then DS RRsets for + the secure child zones need to be added manually.</para> + + <para>The following command signs the zone, assuming it is in a + file called <filename>zone.child.example</filename>. By + default, all zone keys which have an available private key are + used to generate signatures.</para> + +<para><userinput>dnssec-signzone -o child.example zone.child.example</userinput></para> + + <para>One output file is produced: + <filename>zone.child.example.signed</filename>. This file + should be referenced by <filename>named.conf</filename> as the + input file for the zone.</para> + + <para><command>dnssec-signzone</command> will also produce a + keyset and dsset files and optionally a dlvset file. These + are used to provide the parent zone administators with the + <literal>DNSKEYs</literal> (or their corresponding <literal>DS</literal> + records) that are the secure entry point to the zone.</para> + + </sect2> + +<sect2><title>Configuring Servers</title> + +<para>Unlike <acronym>BIND</acronym> 8, +<acronym>BIND</acronym> 9 does not verify signatures on load, +so zone keys for authoritative zones do not need to be specified +in the configuration file.</para> + +<para>The public key for any security root must be present in +the configuration file's <command>trusted-keys</command> +statement, as described later in this document. </para> + +</sect2> + +</sect1> + <sect1> + <title>IPv6 Support in <acronym>BIND</acronym> 9</title> + + <para><acronym>BIND</acronym> 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.</para> + + <para>For forward lookups, <acronym>BIND</acronym> 9 supports only AAAA + records. The use of A6 records is deprecated by RFC 3363, and the + support for forward lookups in <acronym>BIND</acronym> 9 is + removed accordingly. + However, authoritative <acronym>BIND</acronym> 9 name servers still + load zone files containing A6 records correctly, answer queries + for A6 records, and accept zone transfer for a zone containing A6 + records.</para> + + <para>For IPv6 reverse lookups, <acronym>BIND</acronym> 9 supports + the traditional "nibble" format used in the + <emphasis>ip6.arpa</emphasis> domain, as well as the older, deprecated + <emphasis>ip6.int</emphasis> domain. + <acronym>BIND</acronym> 9 formerly + supported the "binary label" (also known as "bitstring") format. + The support of binary labels, however, is now completely removed + according to the changes in RFC 3363. + Any applications in <acronym>BIND</acronym> 9 do not understand + the format any more, and will return an error if given. + In particular, an authoritative <acronym>BIND</acronym> 9 name + server rejects to load a zone file containing binary labels.</para> + + <para>For an overview of the format and structure of IPv6 addresses, + see <xref linkend="ipv6addresses"/>.</para> + + <sect2> + <title>Address Lookups Using AAAA Records</title> + + <para>The AAAA record is a parallel to the IPv4 A record. It + specifies the entire address in a single record. For + example,</para> + +<programlisting> +$ORIGIN example.com. +host 3600 IN AAAA 2001:db8::1 +</programlisting> + + <para>It is recommended that IPv4-in-IPv6 mapped addresses not + be used. If a host has an IPv4 address, use an A record, not + a AAAA, with <literal>::ffff:192.168.42.1</literal> as the + address.</para> + </sect2> + <sect2> + <title>Address to Name Lookups Using Nibble Format</title> + + <para>When looking up an address in nibble format, the address + components are simply reversed, just as in IPv4, and + <literal>ip6.arpa.</literal> is appended to the resulting name. + For example, the following would provide reverse name lookup for + a host with address + <literal>2001:db8::1</literal>.</para> + +<programlisting> +$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. +1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR host.example.com. +</programlisting> + </sect2> + </sect1> + </chapter> + + <chapter id="ch05"><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title> +<sect1><title>The Lightweight Resolver Library</title> +<para>Traditionally applications have been linked with a stub resolver +library that sends recursive DNS queries to a local caching name +server.</para> +<para>IPv6 once introduced new complexity into the resolution process, +such as following A6 chains and DNAME records, and simultaneous +lookup of IPv4 and IPv6 addresses. Though most of the complexity was +then removed, these are hard or impossible +to implement in a traditional stub resolver.</para> +<para>Instead, <acronym>BIND</acronym> 9 provides resolution services to local clients +using a combination of a lightweight resolver library and a resolver +daemon process running on the local host. These communicate using +a simple UDP-based protocol, the "lightweight resolver protocol" +that is distinct from and simpler than the full DNS protocol.</para></sect1> +<sect1 id="lwresd"><title>Running a Resolver Daemon</title> + +<para>To use the lightweight resolver interface, the system must +run the resolver daemon <command>lwresd</command> or a local +name server configured with a <command>lwres</command> statement.</para> + +<para>By default, applications using the lightweight resolver library will make +UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. The +address can be overridden by <command>lwserver</command> lines in +<filename>/etc/resolv.conf</filename>.</para> + +<para>The daemon currently only looks in the DNS, but in the future +it may use other sources such as <filename>/etc/hosts</filename>, +NIS, etc.</para> + +<para>The <command>lwresd</command> daemon is essentially a +caching-only name server that responds to requests using the lightweight +resolver protocol rather than the DNS protocol. Because it needs +to run on each host, it is designed to require no or minimal configuration. +Unless configured otherwise, it uses the name servers listed on +<command>nameserver</command> lines in <filename>/etc/resolv.conf</filename> +as forwarders, but is also capable of doing the resolution autonomously if +none are specified.</para> +<para>The <command>lwresd</command> daemon may also be configured with a +<filename>named.conf</filename> style configuration file, in +<filename>/etc/lwresd.conf</filename> by default. A name server may also +be configured to act as a lightweight resolver daemon using the +<command>lwres</command> statement in <filename>named.conf</filename>.</para> + +</sect1></chapter> + +<chapter id="ch06"><title><acronym>BIND</acronym> 9 Configuration Reference</title> + +<para><acronym>BIND</acronym> 9 configuration is broadly similar +to <acronym>BIND</acronym> 8; however, there are a few new areas +of configuration, such as views. <acronym>BIND</acronym> +8 configuration files should work with few alterations in <acronym>BIND</acronym> +9, although more complex configurations should be reviewed to check +if they can be more efficiently implemented using the new features +found in <acronym>BIND</acronym> 9.</para> + +<para><acronym>BIND</acronym> 4 configuration files can be converted to the new format +using the shell script +<filename>contrib/named-bootconf/named-bootconf.sh</filename>.</para> +<sect1 id="configuration_file_elements"><title>Configuration File Elements</title> +<para>Following is a list of elements used throughout the <acronym>BIND</acronym> configuration +file documentation:</para> +<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2" + colsep = "0" rowsep = "0" tgroupstyle = "2Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.855in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.770in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><varname>acl_name</varname></para></entry> +<entry colname = "2"><para>The name of an <varname>address_match_list</varname> as +defined by the <command>acl</command> statement.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>address_match_list</varname></para></entry> +<entry colname = "2"><para>A list of one or more <varname>ip_addr</varname>, +<varname>ip_prefix</varname>, <varname>key_id</varname>, +or <varname>acl_name</varname> elements, see +<xref linkend="address_match_lists"/>.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>domain_name</varname></para></entry> +<entry colname = "2"><para>A quoted string which will be used as +a DNS name, for example "<literal>my.test.domain</literal>".</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>dotted_decimal</varname></para></entry> +<entry colname = "2"><para>One to four integers valued 0 through +255 separated by dots (`.'), such as <command>123</command>, +<command>45.67</command> or <command>89.123.45.67</command>.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>ip4_addr</varname></para></entry> +<entry colname = "2"><para>An IPv4 address with exactly four elements +in <varname>dotted_decimal</varname> notation.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>ip6_addr</varname></para></entry> +<entry colname = "2"><para>An IPv6 address, such as <command>2001:db8::1234</command>. +IPv6 scoped addresses that have ambiguity on their scope zones must be +disambiguated by an appropriate zone ID with the percent character +(`%') as delimiter. +It is strongly recommended to use string zone names rather than +numeric identifiers, in order to be robust against system +configuration changes. +However, since there is no standard mapping for such names and +identifier values, currently only interface names as link identifiers +are supported, assuming one-to-one mapping between interfaces and links. +For example, a link-local address <command>fe80::1</command> on the +link attached to the interface <command>ne0</command> +can be specified as <command>fe80::1%ne0</command>. +Note that on most systems link-local addresses always have the +ambiguity, and need to be disambiguated.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>ip_addr</varname></para></entry> +<entry colname = "2"><para>An <varname>ip4_addr</varname> or <varname>ip6_addr</varname>.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>ip_port</varname></para></entry> +<entry colname = "2"><para>An IP port <varname>number</varname>. +<varname>number</varname> is limited to 0 through 65535, with values +below 1024 typically restricted to use by processes running as root. +In some cases an asterisk (`*') character can be used as a placeholder to +select a random high-numbered port.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>ip_prefix</varname></para></entry> +<entry colname = "2"><para>An IP network specified as an <varname>ip_addr</varname>, +followed by a slash (`/') and then the number of bits in the netmask. +Trailing zeros in a <varname>ip_addr</varname> may omitted. +For example, <command>127/8</command> is the network <command>127.0.0.0</command> with +netmask <command>255.0.0.0</command> and <command>1.2.3.0/28</command> is +network <command>1.2.3.0</command> with netmask <command>255.255.255.240</command>.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>key_id</varname></para></entry> +<entry colname = "2"><para>A <varname>domain_name</varname> representing +the name of a shared key, to be used for transaction security.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>key_list</varname></para></entry> +<entry colname = "2"><para>A list of one or more <varname>key_id</varname>s, +separated by semicolons and ending with a semicolon.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>number</varname></para></entry> +<entry colname = "2"><para>A non-negative 32 bit integer +(i.e., a number between 0 and 4294967295, inclusive). +Its acceptable value might further +be limited by the context in which it is used.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>path_name</varname></para></entry> +<entry colname = "2"><para>A quoted string which will be used as +a pathname, such as <filename>zones/master/my.test.domain</filename>.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>size_spec</varname></para></entry> +<entry colname = "2"><para>A number, the word <userinput>unlimited</userinput>, +or the word <userinput>default</userinput>.</para><para> +An <varname>unlimited</varname> <varname>size_spec</varname> requests unlimited +use, or the maximum available amount. A <varname>default size_spec</varname> uses +the limit that was in force when the server was started.</para><para>A <varname>number</varname> can +optionally be followed by a scaling factor: <userinput>K</userinput> or <userinput>k</userinput> for +kilobytes, <userinput>M</userinput> or <userinput>m</userinput> for +megabytes, and <userinput>G</userinput> or <userinput>g</userinput> for gigabytes, +which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.</para> +<para>The value must be representable as a 64-bit unsigned integer +(0 to 18446744073709551615, inclusive). +Using <varname>unlimited</varname> is the best way +to safely set a really large number.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>yes_or_no</varname></para></entry> +<entry colname = "2"><para>Either <userinput>yes</userinput> or <userinput>no</userinput>. +The words <userinput>true</userinput> and <userinput>false</userinput> are +also accepted, as are the numbers <userinput>1</userinput> and <userinput>0</userinput>.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>dialup_option</varname></para></entry> +<entry colname = "2"><para>One of <userinput>yes</userinput>, +<userinput>no</userinput>, <userinput>notify</userinput>, +<userinput>notify-passive</userinput>, <userinput>refresh</userinput> or +<userinput>passive</userinput>. +When used in a zone, <userinput>notify-passive</userinput>, +<userinput>refresh</userinput>, and <userinput>passive</userinput> +are restricted to slave and stub zones.</para></entry> +</row> +</tbody> +</tgroup></informaltable> +<sect2 id="address_match_lists"><title>Address Match Lists</title> +<sect3><title>Syntax</title> + <programlisting><varname>address_match_list</varname> = address_match_list_element ; + <optional> address_match_list_element; ... </optional> +<varname>address_match_list_element</varname> = <optional> ! </optional> (ip_address <optional>/length</optional> | + key key_id | acl_name | { address_match_list } ) +</programlisting> +</sect3> +<sect3><title>Definition and Usage</title> +<para>Address match lists are primarily used to determine access +control for various server operations. They are also used in +the <command>listen-on</command> and <command>sortlist</command> +statements. The elements +which constitute an address match list can be any of the following:</para> +<itemizedlist><listitem> + <simpara>an IP address (IPv4 or IPv6)</simpara></listitem> +<listitem> + <simpara>an IP prefix (in `/' notation)</simpara></listitem> +<listitem> + <simpara>a key ID, as defined by the <command>key</command> statement</simpara></listitem> +<listitem> + <simpara>the name of an address match list previously defined with +the <command>acl</command> statement</simpara></listitem> +<listitem> + <simpara>a nested address match list enclosed in braces</simpara></listitem></itemizedlist> + +<para>Elements can be negated with a leading exclamation mark (`!'), +and the match list names "any", "none", "localhost", and "localnets" +are predefined. More information on those names can be found in +the description of the acl statement.</para> + +<para>The addition of the key clause made the name of this syntactic +element something of a misnomer, since security keys can be used +to validate access without regard to a host or network address. Nonetheless, +the term "address match list" is still used throughout the documentation.</para> + +<para>When a given IP address or prefix is compared to an address +match list, the list is traversed in order until an element matches. +The interpretation of a match depends on whether the list is being used +for access control, defining listen-on ports, or in a sortlist, +and whether the element was negated.</para> + +<para>When used as an access control list, a non-negated match allows +access and a negated match denies access. If there is no match, +access is denied. The clauses <command>allow-notify</command>, +<command>allow-query</command>, <command>allow-transfer</command>, +<command>allow-update</command>, <command>allow-update-forwarding</command>, +and <command>blackhole</command> all +use address match lists this. Similarly, the listen-on option will cause +the server to not accept queries on any of the machine's addresses +which do not match the list.</para> + +<para>Because of the first-match aspect of the algorithm, an element +that defines a subset of another element in the list should come +before the broader element, regardless of whether either is negated. For +example, in +<command>1.2.3/24; ! 1.2.3.13;</command> the 1.2.3.13 element is +completely useless because the algorithm will match any lookup for +1.2.3.13 to the 1.2.3/24 element. +Using <command>! 1.2.3.13; 1.2.3/24</command> fixes +that problem by having 1.2.3.13 blocked by the negation but all +other 1.2.3.* hosts fall through.</para> +</sect3> +</sect2> + +<sect2> +<title>Comment Syntax</title> + +<para>The <acronym>BIND</acronym> 9 comment syntax allows for comments to appear +anywhere that white space may appear in a <acronym>BIND</acronym> configuration +file. To appeal to programmers of all kinds, they can be written +in the C, C++, or shell/perl style.</para> + +<sect3> +<title>Syntax</title> + +<para><programlisting>/* This is a <acronym>BIND</acronym> comment as in C */</programlisting> +<programlisting>// This is a <acronym>BIND</acronym> comment as in C++</programlisting> +<programlisting># This is a <acronym>BIND</acronym> comment as in common UNIX shells and perl</programlisting> + </para> + </sect3> + <sect3> + <title>Definition and Usage</title> +<para>Comments may appear anywhere that whitespace may appear in +a <acronym>BIND</acronym> configuration file.</para> +<para>C-style comments start with the two characters /* (slash, +star) and end with */ (star, slash). Because they are completely +delimited with these characters, they can be used to comment only +a portion of a line or to span multiple lines.</para> +<para>C-style comments cannot be nested. For example, the following +is not valid because the entire comment ends with the first */:</para> + <para><programlisting>/* This is the start of a comment. + This is still part of the comment. +/* This is an incorrect attempt at nesting a comment. */ + This is no longer in any comment. */ +</programlisting></para> + +<para>C++-style comments start with the two characters // (slash, +slash) and continue to the end of the physical line. They cannot +be continued across multiple physical lines; to have one logical +comment span multiple lines, each line must use the // pair.</para> +<para>For example:</para> + <para><programlisting>// This is the start of a comment. The next line +// is a new comment, even though it is logically +// part of the previous comment. +</programlisting></para> +<para>Shell-style (or perl-style, if you prefer) comments start +with the character <literal>#</literal> (number sign) and continue to the end of the +physical line, as in C++ comments.</para> +<para>For example:</para> + +<para><programlisting># This is the start of a comment. The next line +# is a new comment, even though it is logically +# part of the previous comment. +</programlisting> +</para> + +<warning> + <para>You cannot use the semicolon (`;') character + to start a comment such as you would in a zone file. The + semicolon indicates the end of a configuration + statement.</para> +</warning> +</sect3> +</sect2> +</sect1> + +<sect1 id="Configuration_File_Grammar"> +<title>Configuration File Grammar</title> + + <para>A <acronym>BIND</acronym> 9 configuration consists of statements and comments. + Statements end with a semicolon. Statements and comments are the + only elements that can appear without enclosing braces. Many + statements contain a block of sub-statements, which are also + terminated with a semicolon.</para> + + <para>The following statements are supported:</para> + + <informaltable colsep = "0" rowsep = "0"> + <tgroup cols = "2" colsep = "0" rowsep = "0" tgroupstyle = + "2Level-table"> + <colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.336in"/> + <colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.778in"/> + <tbody> + <row rowsep = "0"> + <entry colname = "1"><para><command>acl</command></para></entry> + <entry colname = "2"><para>defines a named IP address +matching list, for access control and other uses.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>controls</command></para></entry> + <entry colname = "2"><para>declares control channels to be used +by the <command>rndc</command> utility.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>include</command></para></entry> + <entry colname = "2"><para>includes a file.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>key</command></para></entry> + <entry colname = "2"><para>specifies key information for use in +authentication and authorization using TSIG.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>logging</command></para></entry> + <entry colname = "2"><para>specifies what the server logs, and where +the log messages are sent.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>lwres</command></para></entry> + <entry colname = "2"><para>configures <command>named</command> to +also act as a light weight resolver daemon (<command>lwresd</command>).</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>masters</command></para></entry> + <entry colname = "2"><para>defines a named masters list for +inclusion in stub and slave zone masters clauses.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>options</command></para></entry> + <entry colname = "2"><para>controls global server configuration +options and sets defaults for other statements.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>server</command></para></entry> + <entry colname = "2"><para>sets certain configuration options on +a per-server basis.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>trusted-keys</command></para></entry> + <entry colname = "2"><para>defines trusted DNSSEC keys.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>view</command></para></entry> + <entry colname = "2"><para>defines a view.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>zone</command></para></entry> + <entry colname = "2"><para>defines a zone.</para></entry> + </row> + </tbody> + </tgroup></informaltable> + + <para>The <command>logging</command> and + <command>options</command> statements may only occur once per + configuration.</para> + + <sect2> + <title><command>acl</command> Statement Grammar</title> + + <programlisting><command>acl</command> acl-name { + address_match_list +}; +</programlisting> + </sect2> + <sect2 id="acl"> + <title><command>acl</command> Statement Definition and +Usage</title> + + <para>The <command>acl</command> statement assigns a symbolic + name to an address match list. It gets its name from a primary + use of address match lists: Access Control Lists (ACLs).</para> + + <para>Note that an address match list's name must be defined + with <command>acl</command> before it can be used elsewhere; no + forward references are allowed.</para> + + <para>The following ACLs are built-in:</para> + +<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2" + colsep = "0" rowsep = "0" tgroupstyle = "3Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.130in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.000in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><command>any</command></para></entry> +<entry colname = "2"><para>Matches all hosts.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>none</command></para></entry> +<entry colname = "2"><para>Matches no hosts.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>localhost</command></para></entry> +<entry colname = "2"><para>Matches the IPv4 and IPv6 addresses of all network +interfaces on the system.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>localnets</command></para></entry> +<entry colname = "2"><para>Matches any host on an IPv4 or IPv6 network +for which the system has an interface. +Some systems do not provide a way to determine the prefix lengths of +local IPv6 addresses. +In such a case, <command>localnets</command> only matches the local +IPv6 addresses, just like <command>localhost</command>. +</para></entry> +</row> +</tbody> +</tgroup></informaltable> + +</sect2> +<sect2> + <title><command>controls</command> Statement Grammar</title> +<programlisting><command>controls</command> { + inet ( ip_addr | * ) <optional> port ip_port </optional> allow { <replaceable> address_match_list </replaceable> } + keys { <replaceable> key_list </replaceable> }; + <optional> inet ...; </optional> +}; +</programlisting> +</sect2> + +<sect2 id="controls_statement_definition_and_usage"> +<title><command>controls</command> Statement Definition and Usage</title> + + <para>The <command>controls</command> statement declares control + channels to be used by system administrators to control the + operation of the name server. These control channels are + used by the <command>rndc</command> utility to send commands to + and retrieve non-DNS results from a name server.</para> + + <para>An <command>inet</command> control channel is a TCP + socket listening at the specified + <command>ip_port</command> on the specified + <command>ip_addr</command>, which can be an IPv4 or IPv6 + address. An <command>ip_addr</command> + of <literal>*</literal> is interpreted as the IPv4 wildcard + address; connections will be accepted on any of the system's + IPv4 addresses. To listen on the IPv6 wildcard address, + use an <command>ip_addr</command> of <literal>::</literal>. + If you will only use <command>rndc</command> on the local host, + using the loopback address (<literal>127.0.0.1</literal> + or <literal>::1</literal>) is recommended for maximum + security. + </para> + + <para> + If no port is specified, port 953 + is used. "<literal>*</literal>" cannot be used for + <command>ip_port</command>.</para> + + <para>The ability to issue commands over the control channel is + restricted by the <command>allow</command> and + <command>keys</command> clauses. Connections to the control + channel are permitted based on the + <command>address_match_list</command>. This is for simple + IP address based filtering only; any <command>key_id</command> + elements of the <command>address_match_list</command> are + ignored. + </para> + + <para>The primary authorization mechanism of the command + channel is the <command>key_list</command>, which contains + a list of <command>key_id</command>s. + Each <command>key_id</command> in + the <command>key_list</command> is authorized to execute + commands over the control channel. + See <xref linkend="rndc"/> in + <xref linkend="admin_tools"/>) for information about + configuring keys in <command>rndc</command>.</para> + +<para> +If no <command>controls</command> statement is present, +<command>named</command> will set up a default +control channel listening on the loopback address 127.0.0.1 +and its IPv6 counterpart ::1. +In this case, and also when the <command>controls</command> statement +is present but does not have a <command>keys</command> clause, +<command>named</command> will attempt to load the command channel key +from the file <filename>rndc.key</filename> in +<filename>/etc</filename> (or whatever <varname>sysconfdir</varname> +was specified as when <acronym>BIND</acronym> was built). +To create a <filename>rndc.key</filename> file, run +<userinput>rndc-confgen -a</userinput>. +</para> + + <para>The <filename>rndc.key</filename> feature was created to + ease the transition of systems from <acronym>BIND</acronym> 8, + which did not have digital signatures on its command channel messages + and thus did not have a <command>keys</command> clause. + +It makes it possible to use an existing <acronym>BIND</acronym> 8 +configuration file in <acronym>BIND</acronym> 9 unchanged, +and still have <command>rndc</command> work the same way +<command>ndc</command> worked in BIND 8, simply by executing the +command <userinput>rndc-confgen -a</userinput> after BIND 9 is +installed. +</para> + + <para> + Since the <filename>rndc.key</filename> feature + is only intended to allow the backward-compatible usage of + <acronym>BIND</acronym> 8 configuration files, this feature does not + have a high degree of configurability. You cannot easily change + the key name or the size of the secret, so you should make a + <filename>rndc.conf</filename> with your own key if you wish to change + those things. The <filename>rndc.key</filename> file also has its + permissions set such that only the owner of the file (the user that + <command>named</command> is running as) can access it. If you + desire greater flexibility in allowing other users to access + <command>rndc</command> commands then you need to create an + <filename>rndc.conf</filename> and make it group readable by a group + that contains the users who should have access.</para> + + <para>The UNIX control channel type of <acronym>BIND</acronym> 8 is not supported + in <acronym>BIND</acronym> 9, and is not expected to be added in future + releases. If it is present in the controls statement from a + <acronym>BIND</acronym> 8 configuration file, it is ignored + and a warning is logged.</para> + +<para> +To disable the command channel, use an empty <command>controls</command> +statement: <command>controls { };</command>. +</para> + + </sect2> + <sect2> + <title><command>include</command> Statement Grammar</title> + <programlisting>include <replaceable>filename</replaceable>;</programlisting> + </sect2> + <sect2> + <title><command>include</command> Statement Definition and Usage</title> + + <para>The <command>include</command> statement inserts the + specified file at the point where the <command>include</command> + statement is encountered. The <command>include</command> + statement facilitates the administration of configuration files + by permitting the reading or writing of some things but not + others. For example, the statement could include private keys + that are readable only by the name server.</para> + + </sect2> + <sect2> + <title><command>key</command> Statement Grammar</title> +<programlisting>key <replaceable>key_id</replaceable> { + algorithm <replaceable>string</replaceable>; + secret <replaceable>string</replaceable>; +}; +</programlisting> + </sect2> + +<sect2> +<title><command>key</command> Statement Definition and Usage</title> + +<para>The <command>key</command> statement defines a shared +secret key for use with TSIG (see <xref linkend="tsig"/>) +or the command channel +(see <xref linkend="controls_statement_definition_and_usage"/>). +</para> + +<para> +The <command>key</command> statement can occur at the top level +of the configuration file or inside a <command>view</command> +statement. Keys defined in top-level <command>key</command> +statements can be used in all views. Keys intended for use in +a <command>controls</command> statement +(see <xref linkend="controls_statement_definition_and_usage"/>) +must be defined at the top level. +</para> + +<para>The <replaceable>key_id</replaceable>, also known as the +key name, is a domain name uniquely identifying the key. It can +be used in a <command>server</command> +statement to cause requests sent to that +server to be signed with this key, or in address match lists to +verify that incoming requests have been signed with a key +matching this name, algorithm, and secret.</para> + +<para>The <replaceable>algorithm_id</replaceable> is a string +that specifies a security/authentication algorithm. The only +algorithm currently supported with TSIG authentication is +<literal>hmac-md5</literal>. The +<replaceable>secret_string</replaceable> is the secret to be +used by the algorithm, and is treated as a base-64 encoded +string.</para> + +</sect2> + <sect2> + <title><command>logging</command> Statement Grammar</title> + <programlisting><command>logging</command> { + [ <command>channel</command> <replaceable>channel_name</replaceable> { + ( <command>file</command> <replaceable>path name</replaceable> + [ <command>versions</command> ( <replaceable>number</replaceable> | <literal>unlimited</literal> ) ] + [ <command>size</command> <replaceable>size spec</replaceable> ] + | <command>syslog</command> <replaceable>syslog_facility</replaceable> + | <command>stderr</command> + | <command>null</command> ); + [ <command>severity</command> (<option>critical</option> | <option>error</option> | <option>warning</option> | <option>notice</option> | + <option>info</option> | <option>debug</option> [ <replaceable>level</replaceable> ] | <option>dynamic</option> ); ] + [ <command>print-category</command> <option>yes</option> or <option>no</option>; ] + [ <command>print-severity</command> <option>yes</option> or <option>no</option>; ] + [ <command>print-time</command> <option>yes</option> or <option>no</option>; ] + }; ] + [ <command>category</command> <replaceable>category_name</replaceable> { + <replaceable>channel_name</replaceable> ; [ <replaceable>channel_nam</replaceable>e ; ... ] + }; ] + ... +}; +</programlisting> +</sect2> + +<sect2> +<title><command>logging</command> Statement Definition and Usage</title> + +<para>The <command>logging</command> statement configures a wide +variety of logging options for the name server. Its <command>channel</command> phrase +associates output methods, format options and severity levels with +a name that can then be used with the <command>category</command> phrase +to select how various classes of messages are logged.</para> +<para>Only one <command>logging</command> statement is used to define +as many channels and categories as are wanted. If there is no <command>logging</command> statement, +the logging configuration will be:</para> + +<programlisting>logging { + category default { default_syslog; default_debug; }; + category unmatched { null; }; +}; +</programlisting> + +<para>In <acronym>BIND</acronym> 9, the logging configuration is only established when +the entire configuration file has been parsed. In <acronym>BIND</acronym> 8, it was +established as soon as the <command>logging</command> statement +was parsed. When the server is starting up, all logging messages +regarding syntax errors in the configuration file go to the default +channels, or to standard error if the "<option>-g</option>" option +was specified.</para> + +<sect3> +<title>The <command>channel</command> Phrase</title> + +<para>All log output goes to one or more <emphasis>channels</emphasis>; +you can make as many of them as you want.</para> + +<para>Every channel definition must include a destination clause that +says whether messages selected for the channel go to a file, to a +particular syslog facility, to the standard error stream, or are +discarded. It can optionally also limit the message severity level +that will be accepted by the channel (the default is +<command>info</command>), and whether to include a +<command>named</command>-generated time stamp, the category name +and/or severity level (the default is not to include any).</para> + +<para>The <command>null</command> destination clause +causes all messages sent to the channel to be discarded; +in that case, other options for the channel are meaningless.</para> + +<para>The <command>file</command> destination clause directs the channel +to a disk file. It can include limitations +both on how large the file is allowed to become, and how many versions +of the file will be saved each time the file is opened.</para> + +<para>If you use the <command>versions</command> log file option, then +<command>named</command> will retain that many backup versions of the file by +renaming them when opening. For example, if you choose to keep 3 old versions +of the file <filename>lamers.log</filename> then just before it is opened +<filename>lamers.log.1</filename> is renamed to +<filename>lamers.log.2</filename>, <filename>lamers.log.0</filename> is renamed +to <filename>lamers.log.1</filename>, and <filename>lamers.log</filename> is +renamed to <filename>lamers.log.0</filename>. +You can say <command>versions unlimited</command> to not limit +the number of versions. +If a <command>size</command> option is associated with the log file, +then renaming is only done when the file being opened exceeds the +indicated size. No backup versions are kept by default; any existing +log file is simply appended.</para> + +<para>The <command>size</command> option for files is used to limit log +growth. If the file ever exceeds the size, then <command>named</command> will +stop writing to the file unless it has a <command>versions</command> option +associated with it. If backup versions are kept, the files are rolled as +described above and a new one begun. If there is no +<command>versions</command> option, no more data will be written to the log +until some out-of-band mechanism removes or truncates the log to less than the +maximum size. The default behavior is not to limit the size of the +file.</para> + +<para>Example usage of the <command>size</command> and +<command>versions</command> options:</para> + +<programlisting>channel an_example_channel { + file "example.log" versions 3 size 20m; + print-time yes; + print-category yes; +}; +</programlisting> + +<para>The <command>syslog</command> destination clause directs the +channel to the system log. Its argument is a +syslog facility as described in the <command>syslog</command> man +page. Known facilities are <command>kern</command>, <command>user</command>, +<command>mail</command>, <command>daemon</command>, <command>auth</command>, +<command>syslog</command>, <command>lpr</command>, <command>news</command>, +<command>uucp</command>, <command>cron</command>, <command>authpriv</command>, +<command>ftp</command>, <command>local0</command>, <command>local1</command>, +<command>local2</command>, <command>local3</command>, <command>local4</command>, +<command>local5</command>, <command>local6</command> and +<command>local7</command>, however not all facilities are supported on +all operating systems. +How <command>syslog</command> will handle messages sent to +this facility is described in the <command>syslog.conf</command> man +page. If you have a system which uses a very old version of <command>syslog</command> that +only uses two arguments to the <command>openlog()</command> function, +then this clause is silently ignored.</para> +<para>The <command>severity</command> clause works like <command>syslog</command>'s +"priorities", except that they can also be used if you are writing +straight to a file rather than using <command>syslog</command>. +Messages which are not at least of the severity level given will +not be selected for the channel; messages of higher severity levels +will be accepted.</para> +<para>If you are using <command>syslog</command>, then the <command>syslog.conf</command> priorities +will also determine what eventually passes through. For example, +defining a channel facility and severity as <command>daemon</command> and <command>debug</command> but +only logging <command>daemon.warning</command> via <command>syslog.conf</command> will +cause messages of severity <command>info</command> and <command>notice</command> to +be dropped. If the situation were reversed, with <command>named</command> writing +messages of only <command>warning</command> or higher, then <command>syslogd</command> would +print all messages it received from the channel.</para> + +<para>The <command>stderr</command> destination clause directs the +channel to the server's standard error stream. This is intended for +use when the server is running as a foreground process, for example +when debugging a configuration.</para> + +<para>The server can supply extensive debugging information when +it is in debugging mode. If the server's global debug level is greater +than zero, then debugging mode will be active. The global debug +level is set either by starting the <command>named</command> server +with the <option>-d</option> flag followed by a positive integer, +or by running <command>rndc trace</command>. +The global debug level +can be set to zero, and debugging mode turned off, by running <command>ndc +notrace</command>. All debugging messages in the server have a debug +level, and higher debug levels give more detailed output. Channels +that specify a specific debug severity, for example:</para> +<programlisting>channel specific_debug_level { + file "foo"; + severity debug 3; +}; +</programlisting> + <para>will get debugging output of level 3 or less any time the +server is in debugging mode, regardless of the global debugging +level. Channels with <command>dynamic</command> severity use the +server's global debug level to determine what messages to print.</para> + <para>If <command>print-time</command> has been turned on, then +the date and time will be logged. <command>print-time</command> may +be specified for a <command>syslog</command> channel, but is usually +pointless since <command>syslog</command> also prints the date and +time. If <command>print-category</command> is requested, then the +category of the message will be logged as well. Finally, if <command>print-severity</command> is +on, then the severity level of the message will be logged. The <command>print-</command> options may +be used in any combination, and will always be printed in the following +order: time, category, severity. Here is an example where all three <command>print-</command> options +are on:</para> + +<para><computeroutput>28-Feb-2000 15:05:32.863 general: notice: running</computeroutput></para> + +<para>There are four predefined channels that are used for +<command>named</command>'s default logging as follows. How they are +used is described in <xref linkend="the_category_phrase"/>. +</para> + +<programlisting>channel default_syslog { + syslog daemon; // send to syslog's daemon + // facility + severity info; // only send priority info + // and higher +}; + +channel default_debug { + file "named.run"; // write to named.run in + // the working directory + // Note: stderr is used instead + // of "named.run" + // if the server is started + // with the '-f' option. + severity dynamic; // log at the server's + // current debug level +}; + +channel default_stderr { + stderr; // writes to stderr + severity info; // only send priority info + // and higher +}; + +channel null { + null; // toss anything sent to + // this channel +}; +</programlisting> + +<para>The <command>default_debug</command> channel has the special +property that it only produces output when the server's debug level is +nonzero. It normally writes to a file <filename>named.run</filename> +in the server's working directory.</para> + +<para>For security reasons, when the "<option>-u</option>" +command line option is used, the <filename>named.run</filename> file +is created only after <command>named</command> has changed to the +new UID, and any debug output generated while <command>named</command> is +starting up and still running as root is discarded. If you need +to capture this output, you must run the server with the "<option>-g</option>" +option and redirect standard error to a file.</para> + +<para>Once a channel is defined, it cannot be redefined. Thus you +cannot alter the built-in channels directly, but you can modify +the default logging by pointing categories at channels you have defined.</para> +</sect3> + +<sect3 id="the_category_phrase"><title>The <command>category</command> Phrase</title> + +<para>There are many categories, so you can send the logs you want +to see wherever you want, without seeing logs you don't want. If +you don't specify a list of channels for a category, then log messages +in that category will be sent to the <command>default</command> category +instead. If you don't specify a default category, the following +"default default" is used:</para> +<programlisting>category default { default_syslog; default_debug; }; +</programlisting> +<para>As an example, let's say you want to log security events to +a file, but you also want keep the default logging behavior. You'd +specify the following:</para> +<programlisting>channel my_security_channel { + file "my_security_file"; + severity info; +}; +category security { + my_security_channel; + default_syslog; + default_debug; +};</programlisting> +<para>To discard all messages in a category, specify the <command>null</command> channel:</para> +<programlisting>category xfer-out { null; }; +category notify { null; }; +</programlisting> +<para>Following are the available categories and brief descriptions +of the types of log information they contain. More +categories may be added in future <acronym>BIND</acronym> releases.</para> +<informaltable + colsep = "0" rowsep = "0"><tgroup cols = "2" + colsep = "0" rowsep = "0" tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.150in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.350in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><command>default</command></para></entry> +<entry colname = "2"><para>The default category defines the logging +options for those categories where no specific configuration has been +defined.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>general</command></para></entry> +<entry colname = "2"><para>The catch-all. Many things still aren't +classified into categories, and they all end up here.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>database</command></para></entry> +<entry colname = "2"><para>Messages relating to the databases used +internally by the name server to store zone and cache data.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>security</command></para></entry> +<entry colname = "2"><para>Approval and denial of requests.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>config</command></para></entry> +<entry colname = "2"><para>Configuration file parsing and processing.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>resolver</command></para></entry> +<entry colname = "2"><para>DNS resolution, such as the recursive +lookups performed on behalf of clients by a caching name server.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>xfer-in</command></para></entry> +<entry colname = "2"><para>Zone transfers the server is receiving.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>xfer-out</command></para></entry> +<entry colname = "2"><para>Zone transfers the server is sending.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>notify</command></para></entry> +<entry colname = "2"><para>The NOTIFY protocol.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>client</command></para></entry> +<entry colname = "2"><para>Processing of client requests.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>unmatched</command></para></entry> +<entry colname = "2"><para>Messages that named was unable to determine the +class of or for which there was no matching <command>view</command>. +A one line summary is also logged to the <command>client</command> category. +This category is best sent to a file or stderr, by default it is sent to +the <command>null</command> channel.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>network</command></para></entry> +<entry colname = "2"><para>Network operations.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>update</command></para></entry> +<entry colname = "2"><para>Dynamic updates.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>update-security</command></para></entry> +<entry colname = "2"><para>Approval and denial of update requests.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>queries</command></para></entry> +<entry colname = "2"><para>Specify where queries should be logged to.</para> +<para> +At startup, specifing the category <command>queries</command> will also +enable query logging unless <command>querylog</command> option has been +specified. +</para> +<para> +The query log entry reports the client's IP address and port number. The +query name, class and type. It also reports whether the Recursion Desired +flag was set (+ if set, - if not set), EDNS was in use (E) or if the +query was signed (S).</para> +<programlisting><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput> +<computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput> +</programlisting> +</entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>dispatch</command></para></entry> +<entry colname = "2"><para>Dispatching of incoming packets to the +server modules where they are to be processed. +</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>dnssec</command></para></entry> +<entry colname = "2"><para>DNSSEC and TSIG protocol processing. +</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>lame-servers</command></para></entry> +<entry colname = "2"><para>Lame servers. These are misconfigurations +in remote servers, discovered by BIND 9 when trying to query +those servers during resolution. +</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>delegation-only</command></para></entry> +<entry colname = "2"><para>Delegation only. Logs queries that have have +been forced to NXDOMAIN as the result of a delegation-only zone or +a <command>delegation-only</command> in a hint or stub zone declaration. +</para></entry> +</row> +</tbody> +</tgroup></informaltable> +</sect3> +</sect2> + +<sect2> +<title><command>lwres</command> Statement Grammar</title> + +<para> This is the grammar of the <command>lwres</command> +statement in the <filename>named.conf</filename> file:</para> + +<programlisting><command>lwres</command> { + <optional> listen-on { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional> + <optional> view <replaceable>view_name</replaceable>; </optional> + <optional> search { <replaceable>domain_name</replaceable> ; <optional> <replaceable>domain_name</replaceable> ; ... </optional> }; </optional> + <optional> ndots <replaceable>number</replaceable>; </optional> +}; +</programlisting> + +</sect2> +<sect2> +<title><command>lwres</command> Statement Definition and Usage</title> + +<para>The <command>lwres</command> statement configures the name +server to also act as a lightweight resolver server, see +<xref linkend="lwresd"/>. There may be be multiple +<command>lwres</command> statements configuring +lightweight resolver servers with different properties.</para> + +<para>The <command>listen-on</command> statement specifies a list of +addresses (and ports) that this instance of a lightweight resolver daemon +should accept requests on. If no port is specified, port 921 is used. +If this statement is omitted, requests will be accepted on 127.0.0.1, +port 921.</para> + +<para>The <command>view</command> statement binds this instance of a +lightweight resolver daemon to a view in the DNS namespace, so that the +response will be constructed in the same manner as a normal DNS query +matching this view. If this statement is omitted, the default view is +used, and if there is no default view, an error is triggered.</para> + +<para>The <command>search</command> statement is equivalent to the +<command>search</command> statement in +<filename>/etc/resolv.conf</filename>. It provides a list of domains +which are appended to relative names in queries.</para> + +<para>The <command>ndots</command> statement is equivalent to the +<command>ndots</command> statement in +<filename>/etc/resolv.conf</filename>. It indicates the minimum +number of dots in a relative domain name that should result in an +exact match lookup before search path elements are appended.</para> +</sect2> +<sect2> + <title><command>masters</command> Statement Grammar</title> +<programlisting> +<command>masters</command> <replaceable>name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> } ; +</programlisting> +</sect2> +<sect2> + <title><command>masters</command> Statement Definition and Usage </title> +<para><command>masters</command> lists allow for a common set of masters +to be easily used by multiple stub and slave zones.</para> +</sect2> +<sect2> +<title><command>options</command> Statement Grammar</title> + +<para>This is the grammar of the <command>options</command> +statement in the <filename>named.conf</filename> file:</para> + +<programlisting>options { + <optional> version <replaceable>version_string</replaceable>; </optional> + <optional> hostname <replaceable>hostname_string</replaceable>; </optional> + <optional> server-id <replaceable>server_id_string</replaceable>; </optional> + <optional> directory <replaceable>path_name</replaceable>; </optional> + <optional> key-directory <replaceable>path_name</replaceable>; </optional> + <optional> named-xfer <replaceable>path_name</replaceable>; </optional> + <optional> tkey-domain <replaceable>domainname</replaceable>; </optional> + <optional> tkey-dhkey <replaceable>key_name</replaceable> <replaceable>key_tag</replaceable>; </optional> + <optional> dump-file <replaceable>path_name</replaceable>; </optional> + <optional> memstatistics-file <replaceable>path_name</replaceable>; </optional> + <optional> pid-file <replaceable>path_name</replaceable>; </optional> + <optional> statistics-file <replaceable>path_name</replaceable>; </optional> + <optional> zone-statistics <replaceable>yes_or_no</replaceable>; </optional> + <optional> auth-nxdomain <replaceable>yes_or_no</replaceable>; </optional> + <optional> deallocate-on-exit <replaceable>yes_or_no</replaceable>; </optional> + <optional> dialup <replaceable>dialup_option</replaceable>; </optional> + <optional> fake-iquery <replaceable>yes_or_no</replaceable>; </optional> + <optional> fetch-glue <replaceable>yes_or_no</replaceable>; </optional> + <optional> flush-zones-on-shutdown <replaceable>yes_or_no</replaceable>; </optional> + <optional> has-old-clients <replaceable>yes_or_no</replaceable>; </optional> + <optional> host-statistics <replaceable>yes_or_no</replaceable>; </optional> + <optional> minimal-responses <replaceable>yes_or_no</replaceable>; </optional> + <optional> multiple-cnames <replaceable>yes_or_no</replaceable>; </optional> + <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable>; </optional> + <optional> recursion <replaceable>yes_or_no</replaceable>; </optional> + <optional> rfc2308-type1 <replaceable>yes_or_no</replaceable>; </optional> + <optional> use-id-pool <replaceable>yes_or_no</replaceable>; </optional> + <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable>; </optional> + <optional> dnssec-enable <replaceable>yes_or_no</replaceable>; </optional> + <optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional> + <optional> dnssec-must-be-secure <replaceable>domain yes_or_no</replaceable>; </optional> + <optional> forward ( <replaceable>only</replaceable> | <replaceable>first</replaceable> ); </optional> + <optional> forwarders { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional> + <optional> dual-stack-servers <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>domain_name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ) ; ... }; </optional> + <optional> check-names ( <replaceable>master</replaceable> | <replaceable>slave</replaceable> | <replaceable> response</replaceable> )( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional> + <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional> + <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional> + <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional> + <optional> allow-recursion { <replaceable>address_match_list</replaceable> }; </optional> + <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional> + <optional> allow-v6-synthesis { <replaceable>address_match_list</replaceable> }; </optional> + <optional> blackhole { <replaceable>address_match_list</replaceable> }; </optional> + <optional> avoid-v4-udp-ports { <replaceable>port_list</replaceable> }; </optional> + <optional> avoid-v6-udp-ports { <replaceable>port_list</replaceable> }; </optional> + <optional> listen-on <optional> port <replaceable>ip_port</replaceable> </optional> { <replaceable>address_match_list</replaceable> }; </optional> + <optional> listen-on-v6 <optional> port <replaceable>ip_port</replaceable> </optional> { <replaceable>address_match_list</replaceable> }; </optional> + <optional> query-source <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional> + <optional> query-source-v6 <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional> + <optional> max-transfer-time-in <replaceable>number</replaceable>; </optional> + <optional> max-transfer-time-out <replaceable>number</replaceable>; </optional> + <optional> max-transfer-idle-in <replaceable>number</replaceable>; </optional> + <optional> max-transfer-idle-out <replaceable>number</replaceable>; </optional> + <optional> tcp-clients <replaceable>number</replaceable>; </optional> + <optional> recursive-clients <replaceable>number</replaceable>; </optional> + <optional> serial-query-rate <replaceable>number</replaceable>; </optional> + <optional> serial-queries <replaceable>number</replaceable>; </optional> + <optional> tcp-listen-queue <replaceable>number</replaceable>; </optional> + <optional> transfer-format <replaceable>( one-answer | many-answers )</replaceable>; </optional> + <optional> transfers-in <replaceable>number</replaceable>; </optional> + <optional> transfers-out <replaceable>number</replaceable>; </optional> + <optional> transfers-per-ns <replaceable>number</replaceable>; </optional> + <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional> + <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional> + <optional> max-ixfr-log-size <replaceable>number</replaceable>; </optional> + <optional> max-journal-size <replaceable>size_spec</replaceable>; </optional> + <optional> coresize <replaceable>size_spec</replaceable> ; </optional> + <optional> datasize <replaceable>size_spec</replaceable> ; </optional> + <optional> files <replaceable>size_spec</replaceable> ; </optional> + <optional> stacksize <replaceable>size_spec</replaceable> ; </optional> + <optional> cleaning-interval <replaceable>number</replaceable>; </optional> + <optional> heartbeat-interval <replaceable>number</replaceable>; </optional> + <optional> interface-interval <replaceable>number</replaceable>; </optional> + <optional> statistics-interval <replaceable>number</replaceable>; </optional> + <optional> topology { <replaceable>address_match_list</replaceable> }</optional>; + <optional> sortlist { <replaceable>address_match_list</replaceable> }</optional>; + <optional> rrset-order { <replaceable>order_spec</replaceable> ; <optional> <replaceable>order_spec</replaceable> ; ... </optional> </optional> }; + <optional> lame-ttl <replaceable>number</replaceable>; </optional> + <optional> max-ncache-ttl <replaceable>number</replaceable>; </optional> + <optional> max-cache-ttl <replaceable>number</replaceable>; </optional> + <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional> + <optional> min-roots <replaceable>number</replaceable>; </optional> + <optional> use-ixfr <replaceable>yes_or_no</replaceable> ; </optional> + <optional> provide-ixfr <replaceable>yes_or_no</replaceable>; </optional> + <optional> request-ixfr <replaceable>yes_or_no</replaceable>; </optional> + <optional> treat-cr-as-space <replaceable>yes_or_no</replaceable> ; </optional> + <optional> min-refresh-time <replaceable>number</replaceable> ; </optional> + <optional> max-refresh-time <replaceable>number</replaceable> ; </optional> + <optional> min-retry-time <replaceable>number</replaceable> ; </optional> + <optional> max-retry-time <replaceable>number</replaceable> ; </optional> + <optional> port <replaceable>ip_port</replaceable>; </optional> + <optional> additional-from-auth <replaceable>yes_or_no</replaceable> ; </optional> + <optional> additional-from-cache <replaceable>yes_or_no</replaceable> ; </optional> + <optional> random-device <replaceable>path_name</replaceable> ; </optional> + <optional> max-cache-size <replaceable>size_spec</replaceable> ; </optional> + <optional> match-mapped-addresses <replaceable>yes_or_no</replaceable>; </optional> + <optional> preferred-glue ( <replaceable>A</replaceable> | <replaceable>AAAA</replaceable> | <replaceable>NONE</replaceable> ); </optional> + <optional> edns-udp-size <replaceable>number</replaceable>; </optional> + <optional> root-delegation-only <optional> exclude { <replaceable>namelist</replaceable> } </optional> ; </optional> + <optional> querylog <replaceable>yes_or_no</replaceable> ; </optional> +}; + <optional> disable-algorithms <replaceable>domain</replaceable> { <replaceable>algorithm</replaceable>; <optional> <replaceable>algorithm</replaceable>; </optional> }; </optional> +</programlisting> +</sect2> + +<sect2 id="options"><title><command>options</command> Statement Definition and Usage</title> + +<para>The <command>options</command> statement sets up global options +to be used by <acronym>BIND</acronym>. This statement may appear only +once in a configuration file. If there is no <command>options</command> +statement, an options block with each option set to its default will +be used.</para> + +<variablelist> + +<varlistentry><term><command>directory</command></term> +<listitem><para>The working directory of the server. +Any non-absolute pathnames in the configuration file will be taken +as relative to this directory. The default location for most server +output files (e.g. <filename>named.run</filename>) is this directory. +If a directory is not specified, the working directory defaults +to `<filename>.</filename>', the directory from which the server +was started. The directory specified should be an absolute path.</para> +</listitem></varlistentry> + +<varlistentry><term><command>key-directory</command></term> +<listitem><para>When performing dynamic update of secure zones, the +directory where the public and private key files should be found, +if different than the current working directory. The directory specified +must be an absolute path.</para> +</listitem></varlistentry> + +<varlistentry><term><command>named-xfer</command></term> +<listitem><para><emphasis>This option is obsolete.</emphasis> +It was used in <acronym>BIND</acronym> 8 to +specify the pathname to the <command>named-xfer</command> program. +In <acronym>BIND</acronym> 9, no separate <command>named-xfer</command> program is +needed; its functionality is built into the name server.</para> + +</listitem></varlistentry> + +<varlistentry><term><command>tkey-domain</command></term> +<listitem><para>The domain appended to the names of all +shared keys generated with <command>TKEY</command>. When a client +requests a <command>TKEY</command> exchange, it may or may not specify +the desired name for the key. If present, the name of the shared +key will be "<varname>client specified part</varname>" + +"<varname>tkey-domain</varname>". +Otherwise, the name of the shared key will be "<varname>random hex +digits</varname>" + "<varname>tkey-domain</varname>". In most cases, +the <command>domainname</command> should be the server's domain +name.</para> +</listitem></varlistentry> + +<varlistentry><term><command>tkey-dhkey</command></term> +<listitem><para>The Diffie-Hellman key used by the server +to generate shared keys with clients using the Diffie-Hellman mode +of <command>TKEY</command>. The server must be able to load the +public and private keys from files in the working directory. In +most cases, the keyname should be the server's host name.</para> +</listitem></varlistentry> + +<varlistentry><term><command>dump-file</command></term> +<listitem><para>The pathname of the file the server dumps +the database to when instructed to do so with +<command>rndc dumpdb</command>. +If not specified, the default is <filename>named_dump.db</filename>.</para> +</listitem></varlistentry> +<varlistentry><term><command>memstatistics-file</command></term> +<listitem><para>The pathname of the file the server writes memory +usage statistics to on exit. If not specified, +the default is <filename>named.memstats</filename>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>pid-file</command></term> +<listitem><para>The pathname of the file the server writes its process ID +in. If not specified, the default is <filename>/var/run/named.pid</filename>. +The pid-file is used by programs that want to send signals to the running +name server. Specifying <command>pid-file none</command> disables the +use of a PID file — no file will be written and any +existing one will be removed. Note that <command>none</command> +is a keyword, not a file name, and therefore is not enclosed in +double quotes.</para> +</listitem></varlistentry> + +<varlistentry><term><command>statistics-file</command></term> +<listitem><para>The pathname of the file the server appends statistics +to when instructed to do so using <command>rndc stats</command>. +If not specified, the default is <filename>named.stats</filename> in the +server's current directory. The format of the file is described +in <xref linkend="statsfile"/></para> +</listitem></varlistentry> + +<varlistentry><term><command>port</command></term> +<listitem><para> +The UDP/TCP port number the server uses for +receiving and sending DNS protocol traffic. +The default is 53. This option is mainly intended for server testing; +a server using a port other than 53 will not be able to communicate with +the global DNS. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>random-device</command></term> +<listitem><para> +The source of entropy to be used by the server. Entropy is primarily needed +for DNSSEC operations, such as TKEY transactions and dynamic update of signed +zones. This options specifies the device (or file) from which to read +entropy. If this is a file, operations requiring entropy will fail when the +file has been exhausted. If not specified, the default value is +<filename>/dev/random</filename> +(or equivalent) when present, and none otherwise. The +<command>random-device</command> option takes effect during +the initial configuration load at server startup time and +is ignored on subsequent reloads.</para> +</listitem></varlistentry> + +<varlistentry><term><command>preferred-glue</command></term> +<listitem><para> +If specified the listed type (A or AAAA) will be emitted before other glue +in the additional section of a query response. +The default is not to preference any type (NONE). +</para> +</listitem></varlistentry> + +<varlistentry><term><command>root-delegation-only</command></term> +<listitem><para> +Turn on enforcement of delegation-only in TLDs and root zones with an optional +exclude list. +</para> +<para> +Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM"). +</para> +<programlisting> +options { + root-delegation-only exclude { "de"; "lv"; "us"; "museum"; }; +}; +</programlisting> +</listitem></varlistentry> + +<varlistentry><term><command>disable-algorithms</command></term> +<listitem><para> +Disable the specified DNSSEC algorithms at and below the specified name. +Multiple <command>disable-algorithms</command> statements are allowed. +Only the most specific will be applied. +</para></listitem></varlistentry> + +<varlistentry><term><command>dnssec-lookaside</command></term> +<listitem><para> +When set <command>dnssec-lookaside</command> provides the +validator with an alternate method to validate DNSKEY records at the +top of a zone. When a DNSKEY is at or below a domain specified by the +deepest <command>dnssec-lookaside</command>, and the normal dnssec validation +has left the key untrusted, the trust-anchor will be append to the key +name and a DLV record will be looked up to see if it can validate the +key. If the DLV record validates a DNSKEY (similarly to the way a DS +record does) the DNSKEY RRset is deemed to be trusted. +</para></listitem></varlistentry> + +<varlistentry><term><command>dnssec-must-be-secure</command></term> +<listitem><para> +Specify heirachies which must / may not be secure (signed and validated). +If <userinput>yes</userinput> then named will only accept answers if they +are secure. +If <userinput>no</userinput> then normal dnssec validation applies +allowing for insecure answers to be accepted. +The specified domain must be under a <command>trusted-key</command> or +<command>dnssec-lookaside</command> must be active. +</para></listitem></varlistentry> + +</variablelist> + +<sect3 id="boolean_options"><title>Boolean Options</title> + +<variablelist> + +<varlistentry><term><command>auth-nxdomain</command></term> +<listitem><para>If <userinput>yes</userinput>, then the <command>AA</command> bit +is always set on NXDOMAIN responses, even if the server is not actually +authoritative. The default is <userinput>no</userinput>; this is +a change from <acronym>BIND</acronym> 8. If you are using very old DNS software, you +may need to set it to <userinput>yes</userinput>.</para></listitem></varlistentry> + +<varlistentry><term><command>deallocate-on-exit</command></term> +<listitem><para>This option was used in <acronym>BIND</acronym> 8 to enable checking +for memory leaks on exit. <acronym>BIND</acronym> 9 ignores the option and always performs +the checks.</para></listitem></varlistentry> + +<varlistentry><term><command>dialup</command></term> +<listitem><para>If <userinput>yes</userinput>, then the +server treats all zones as if they are doing zone transfers across +a dial on demand dialup link, which can be brought up by traffic +originating from this server. This has different effects according +to zone type and concentrates the zone maintenance so that it all +happens in a short interval, once every <command>heartbeat-interval</command> and +hopefully during the one call. It also suppresses some of the normal +zone maintenance traffic. The default is <userinput>no</userinput>.</para> +<para>The <command>dialup</command> option +may also be specified in the <command>view</command> and +<command>zone</command> statements, +in which case it overrides the global <command>dialup</command> +option.</para> +<para>If the zone is a master zone then the server will send out a NOTIFY +request to all the slaves (default). This should trigger the zone serial +number check in the slave (providing it supports NOTIFY) allowing the slave +to verify the zone while the connection is active. +The set of servers to which NOTIFY is sent can be controlled by +<command>notify</command> and <command>also-notify</command>.</para> +<para>If the +zone is a slave or stub zone, then the server will suppress the regular +"zone up to date" (refresh) queries and only perform them when the +<command>heartbeat-interval</command> expires in addition to sending +NOTIFY requests.</para><para>Finer control can be achieved by using +<userinput>notify</userinput> which only sends NOTIFY messages, +<userinput>notify-passive</userinput> which sends NOTIFY messages and +suppresses the normal refresh queries, <userinput>refresh</userinput> +which suppresses normal refresh processing and sends refresh queries +when the <command>heartbeat-interval</command> expires, and +<userinput>passive</userinput> which just disables normal refresh +processing.</para> + +<informaltable colsep = "0" rowsep = "0"> +<tgroup cols = "4" colsep = "0" rowsep = "0" tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.150in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "1.150in"/> +<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "1.150in"/> +<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "1.150in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para>dialup mode</para></entry> +<entry colname = "2"><para>normal refresh</para></entry> +<entry colname = "3"><para>heart-beat refresh</para></entry> +<entry colname = "4"><para>heart-beat notify</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>no</command> (default)</para></entry> +<entry colname = "2"><para>yes</para></entry> +<entry colname = "3"><para>no</para></entry> +<entry colname = "4"><para>no</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>yes</command></para></entry> +<entry colname = "2"><para>no</para></entry> +<entry colname = "3"><para>yes</para></entry> +<entry colname = "4"><para>yes</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>notify</command></para></entry> +<entry colname = "2"><para>yes</para></entry> +<entry colname = "3"><para>no</para></entry> +<entry colname = "4"><para>yes</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>refresh</command></para></entry> +<entry colname = "2"><para>no</para></entry> +<entry colname = "3"><para>yes</para></entry> +<entry colname = "4"><para>no</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>passive</command></para></entry> +<entry colname = "2"><para>no</para></entry> +<entry colname = "3"><para>no</para></entry> +<entry colname = "4"><para>no</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>notify-passive</command></para></entry> +<entry colname = "2"><para>no</para></entry> +<entry colname = "3"><para>no</para></entry> +<entry colname = "4"><para>yes</para></entry> +</row> +</tbody> +</tgroup></informaltable> + +<para>Note that normal NOTIFY processing is not affected by +<command>dialup</command>.</para> + +</listitem></varlistentry> + +<varlistentry><term><command>fake-iquery</command></term> +<listitem><para>In <acronym>BIND</acronym> 8, this option +enabled simulating the obsolete DNS query type +IQUERY. <acronym>BIND</acronym> 9 never does IQUERY simulation. +</para></listitem></varlistentry> + +<varlistentry><term><command>fetch-glue</command></term> +<listitem><para>This option is obsolete. +In BIND 8, <userinput>fetch-glue yes</userinput> +caused the server to attempt to fetch glue resource records it +didn't have when constructing the additional +data section of a response. This is now considered a bad idea +and BIND 9 never does it.</para></listitem></varlistentry> + +<varlistentry><term><command>flush-zones-on-shutdown</command></term> +<listitem><para>When the nameserver exits due receiving SIGTERM, +flush / do not flush any pending zone writes. The default is +<command>flush-zones-on-shutdown</command> <userinput>no</userinput>. +</para></listitem></varlistentry> + +<varlistentry><term><command>has-old-clients</command></term> +<listitem><para>This option was incorrectly implemented +in <acronym>BIND</acronym> 8, and is ignored by <acronym>BIND</acronym> 9. +To achieve the intended effect +of +<command>has-old-clients</command> <userinput>yes</userinput>, specify +the two separate options <command>auth-nxdomain</command> <userinput>yes</userinput> +and <command>rfc2308-type1</command> <userinput>no</userinput> instead. +</para></listitem></varlistentry> + +<varlistentry><term><command>host-statistics</command></term> +<listitem><para>In BIND 8, this enables keeping of +statistics for every host that the name server interacts with. +Not implemented in BIND 9. +</para></listitem></varlistentry> + +<varlistentry><term><command>maintain-ixfr-base</command></term> +<listitem><para><emphasis>This option is obsolete</emphasis>. + It was used in <acronym>BIND</acronym> 8 to determine whether a transaction log was +kept for Incremental Zone Transfer. <acronym>BIND</acronym> 9 maintains a transaction +log whenever possible. If you need to disable outgoing incremental zone +transfers, use <command>provide-ixfr</command> <userinput>no</userinput>. +</para></listitem></varlistentry> + +<varlistentry><term><command>minimal-responses</command></term> +<listitem><para>If <userinput>yes</userinput>, then when generating +responses the server will only add records to the authority and +additional data sections when they are required (e.g. delegations, +negative responses). This may improve the performance of the server. +The default is <userinput>no</userinput>. +</para></listitem></varlistentry> + +<varlistentry><term><command>multiple-cnames</command></term> +<listitem><para>This option was used in <acronym>BIND</acronym> 8 to allow +a domain name to have multiple CNAME records in violation of the +DNS standards. <acronym>BIND</acronym> 9.2 always strictly +enforces the CNAME rules both in master files and dynamic updates. +</para></listitem></varlistentry> + +<varlistentry><term><command>notify</command></term> +<listitem><para>If <userinput>yes</userinput> (the default), +DNS NOTIFY messages are sent when a zone the server is authoritative for +changes, see <xref linkend="notify"/>. The messages are sent to the +servers listed in the zone's NS records (except the master server identified +in the SOA MNAME field), and to any servers listed in the +<command>also-notify</command> option. +</para><para> +If <userinput>explicit</userinput>, notifies are sent only to +servers explicitly listed using <command>also-notify</command>. +If <userinput>no</userinput>, no notifies are sent. +</para><para> +The <command>notify</command> option may also be +specified in the <command>zone</command> statement, +in which case it overrides the <command>options notify</command> statement. +It would only be necessary to turn off this option if it caused slaves +to crash.</para></listitem></varlistentry> + +<varlistentry><term><command>recursion</command></term> +<listitem><para>If <userinput>yes</userinput>, and a +DNS query requests recursion, then the server will attempt to do +all the work required to answer the query. If recursion is off +and the server does not already know the answer, it will return a +referral response. The default is <userinput>yes</userinput>. +Note that setting <command>recursion no</command> does not prevent +clients from getting data from the server's cache; it only +prevents new data from being cached as an effect of client queries. +Caching may still occur as an effect the server's internal +operation, such as NOTIFY address lookups. +See also <command>fetch-glue</command> above. +</para></listitem></varlistentry> + +<varlistentry><term><command>rfc2308-type1</command></term> +<listitem><para>Setting this to <userinput>yes</userinput> will +cause the server to send NS records along with the SOA record for negative +answers. The default is <userinput>no</userinput>.</para> +<note><simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note> +</listitem></varlistentry> + +<varlistentry><term><command>use-id-pool</command></term> +<listitem><para><emphasis>This option is obsolete</emphasis>. +<acronym>BIND</acronym> 9 always allocates query IDs from a pool. +</para></listitem></varlistentry> + +<varlistentry><term><command>zone-statistics</command></term> +<listitem><para>If <userinput>yes</userinput>, the server will collect +statistical data on all zones (unless specifically turned off +on a per-zone basis by specifying <command>zone-statistics no</command> +in the <command>zone</command> statement). These statistics may be accessed +using <command>rndc stats</command>, which will dump them to the file listed +in the <command>statistics-file</command>. See also <xref linkend="statsfile"/>. +</para></listitem></varlistentry> + +<varlistentry><term><command>use-ixfr</command></term> +<listitem><para><emphasis>This option is obsolete</emphasis>. +If you need to disable IXFR to a particular server or servers see +the information on the <command>provide-ixfr</command> option +in <xref linkend="server_statement_definition_and_usage"/>. See also +<xref linkend="incremental_zone_transfers"/>. +</para></listitem></varlistentry> + +<varlistentry><term><command>provide-ixfr</command></term> +<listitem> +<para> +See the description of +<command>provide-ixfr</command> in +<xref linkend="server_statement_definition_and_usage"/> +</para></listitem></varlistentry> + +<varlistentry><term><command>request-ixfr</command></term> +<listitem> +<para> +See the description of +<command>request-ixfr</command> in +<xref linkend="server_statement_definition_and_usage"/> +</para></listitem></varlistentry> + +<varlistentry><term><command>treat-cr-as-space</command></term> +<listitem><para>This option was used in <acronym>BIND</acronym> 8 to make +the server treat carriage return ("<command>\r</command>") characters the same way +as a space or tab character, +to facilitate loading of zone files on a UNIX system that were generated +on an NT or DOS machine. In <acronym>BIND</acronym> 9, both UNIX "<command>\n</command>" +and NT/DOS "<command>\r\n</command>" newlines are always accepted, +and the option is ignored.</para></listitem></varlistentry> + +<varlistentry> +<term><command>additional-from-auth</command></term> +<term><command>additional-from-cache</command></term> +<listitem> + +<para> +These options control the behavior of an authoritative server when +answering queries which have additional data, or when following CNAME +and DNAME chains. +</para> + +<para> +When both of these options are set to <userinput>yes</userinput> +(the default) and a +query is being answered from authoritative data (a zone +configured into the server), the additional data section of the +reply will be filled in using data from other authoritative zones +and from the cache. In some situations this is undesirable, such +as when there is concern over the correctness of the cache, or +in servers where slave zones may be added and modified by +untrusted third parties. Also, avoiding +the search for this additional data will speed up server operations +at the possible expense of additional queries to resolve what would +otherwise be provided in the additional section. +</para> + +<para> +For example, if a query asks for an MX record for host <literal>foo.example.com</literal>, +and the record found is "<literal>MX 10 mail.example.net</literal>", normally the address +records (A and AAAA) for <literal>mail.example.net</literal> will be provided as well, +if known, even though they are not in the example.com zone. +Setting these options to <command>no</command> disables this behavior and makes +the server only search for additional data in the zone it answers from. +</para> + +<para> +These options are intended for use in authoritative-only +servers, or in authoritative-only views. Attempts to set +them to <command>no</command> without also specifying +<command>recursion no</command> will cause the server to +ignore the options and log a warning message. +</para> + +<para> +Specifying <command>additional-from-cache no</command> actually +disables the use of the cache not only for additional data lookups +but also when looking up the answer. This is usually the desired +behavior in an authoritative-only server where the correctness of +the cached data is an issue. +</para> + +<para> +When a name server is non-recursively queried for a name that is not +below the apex of any served zone, it normally answers with an +"upwards referral" to the root servers or the servers of some other +known parent of the query name. Since the data in an upwards referral +comes from the cache, the server will not be able to provide upwards +referrals when <command>additional-from-cache no</command> +has been specified. Instead, it will respond to such queries +with REFUSED. This should not cause any problems since +upwards referrals are not required for the resolution process. +</para> + +</listitem></varlistentry> + +<varlistentry><term><command>match-mapped-addresses</command></term> +<listitem><para>If <userinput>yes</userinput>, then an +IPv4-mapped IPv6 address will match any address match +list entries that match the corresponding IPv4 address. +Enabling this option is sometimes useful on IPv6-enabled Linux +systems, to work around a kernel quirk that causes IPv4 +TCP connections such as zone transfers to be accepted +on an IPv6 socket using mapped addresses, causing +address match lists designed for IPv4 to fail to match. +The use of this option for any other purpose is discouraged. +</para></listitem></varlistentry> + +<varlistentry><term><command>ixfr-from-differences</command></term> +<listitem> +<para> +When 'yes' and the server loads a new version of a master +zone from its zone file or receives a new version of a slave +file by a non-incremental zone transfer, it will compare +the new version to the previous one and calculate a set +of differences. The differences are then logged in the +zone's journal file such that the changes can be transmitted +to downstream slaves as an incremental zone transfer. +</para><para> +By allowing incremental zone transfers to be used for +non-dynamic zones, this option saves bandwidth at the +expense of increased CPU and memory consumption at the master. +In particular, if the new version of a zone is completely +different from the previous one, the set of differences +will be of a size comparable to the combined size of the +old and new zone version, and the server will need to +temporarily allocate memory to hold this complete +difference set. +</para></listitem></varlistentry> + +<varlistentry><term><command>multi-master</command></term> +<listitem> +<para> +This should be set when you have multiple masters for a zone and the +addresses refer to different machines. If 'yes' named will not log +when the serial number on the master is less than what named currently +has. The default is <userinput>no</userinput>. +</para></listitem></varlistentry> + +<varlistentry><term><command>dnssec-enable</command></term> +<listitem> +<para> +Enable DNSSEC support in named. Unless set to <userinput>yes</userinput> +named behaves as if it does not support DNSSEC. +The default is <userinput>no</userinput>. +</para></listitem></varlistentry> + +<varlistentry><term><command>querylog</command></term> +<listitem> +<para> +Specify whether query logging should be started when named start. +If <command>querylog</command> is not specified then the query logging +is determined by the presence of the logging category <command>queries</command>. +</para></listitem></varlistentry> + +</variablelist> + +</sect3> + +<sect3><title>Forwarding</title> +<para>The forwarding facility can be used to create a large site-wide +cache on a few servers, reducing traffic over links to external +name servers. It can also be used to allow queries by servers that +do not have direct access to the Internet, but wish to look up exterior +names anyway. Forwarding occurs only on those queries for which +the server is not authoritative and does not have the answer in +its cache.</para> + +<variablelist> +<varlistentry><term><command>forward</command></term> +<listitem><para>This option is only meaningful if the +forwarders list is not empty. A value of <varname>first</varname>, +the default, causes the server to query the forwarders first, and +if that doesn't answer the question the server will then look for +the answer itself. If <varname>only</varname> is specified, the +server will only query the forwarders. +</para></listitem></varlistentry> + +<varlistentry><term><command>forwarders</command></term> +<listitem><para>Specifies the IP addresses to be used +for forwarding. The default is the empty list (no forwarding). +</para></listitem></varlistentry> + +</variablelist> + +<para>Forwarding can also be configured on a per-domain basis, allowing +for the global forwarding options to be overridden in a variety +of ways. You can set particular domains to use different forwarders, +or have a different <command>forward only/first</command> behavior, +or not forward at all, see <xref linkend="zone_statement_grammar"/>.</para> +</sect3> + +<sect3><title>Dual-stack Servers</title> +<para>Dual-stack servers are used as servers of last resort to work around +problems in reachability due the lack of support for either IPv4 or IPv6 +on the host machine.</para> + +<variablelist> +<varlistentry><term><command>dual-stack-servers</command></term> +<listitem><para>Specifies host names / addresses of machines with access to +both IPv4 and IPv6 transports. If a hostname is used the server must be able +to resolve the name using only the transport it has. If the machine is dual +stacked then the <command>dual-stack-servers</command> have no effect unless +access to a transport has been disabled on the command line +(e.g. <command>named -4</command>).</para></listitem> +</varlistentry> +</variablelist> +</sect3> + +<sect3 id="access_control"><title>Access Control</title> + +<para>Access to the server can be restricted based on the IP address +of the requesting system. See <xref linkend="address_match_lists"/> for +details on how to specify IP address lists.</para> + +<variablelist> + +<varlistentry><term><command>allow-notify</command></term> +<listitem><para>Specifies which hosts are allowed to +notify this server, a slave, of zone changes in addition +to the zone masters. +<command>allow-notify</command> may also be specified in the +<command>zone</command> statement, in which case it overrides the +<command>options allow-notify</command> statement. It is only meaningful +for a slave zone. If not specified, the default is to process notify messages +only from a zone's master.</para> +</listitem></varlistentry> + +<varlistentry><term><command>allow-query</command></term> +<listitem><para>Specifies which hosts are allowed to +ask ordinary DNS questions. <command>allow-query</command> may also +be specified in the <command>zone</command> statement, in which +case it overrides the <command>options allow-query</command> statement. If +not specified, the default is to allow queries from all hosts.</para> +</listitem></varlistentry> + + +<varlistentry><term><command>allow-recursion</command></term> +<listitem><para>Specifies which hosts are allowed to +make recursive queries through this server. If not specified, the +default is to allow recursive queries from all hosts. +Note that disallowing recursive queries for a host does not prevent the +host from retrieving data that is already in the server's cache. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>allow-update-forwarding</command></term> +<listitem><para>Specifies which hosts are allowed to +submit Dynamic DNS updates to slave zones to be forwarded to the +master. The default is <userinput>{ none; }</userinput>, which +means that no update forwarding will be performed. To enable +update forwarding, specify +<userinput>allow-update-forwarding { any; };</userinput>. +Specifying values other than <userinput>{ none; }</userinput> or +<userinput>{ any; }</userinput> is usually counterproductive, since +the responsibility for update access control should rest with the +master server, not the slaves.</para> +<para>Note that enabling the update forwarding feature on a slave server +may expose master servers relying on insecure IP address based +access control to attacks; see <xref linkend="dynamic_update_security"/> +for more details.</para> +</listitem></varlistentry> + +<varlistentry><term><command>allow-v6-synthesis</command></term> +<listitem><para>This option was introduced for the smooth transition from AAAA +to A6 and from "nibble labels" to binary labels. +However, since both A6 and binary labels were then deprecated, +this option was also deprecated. +It is now ignored with some warning messages. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>allow-transfer</command></term> +<listitem><para>Specifies which hosts are allowed to +receive zone transfers from the server. <command>allow-transfer</command> may +also be specified in the <command>zone</command> statement, in which +case it overrides the <command>options allow-transfer</command> statement. +If not specified, the default is to allow transfers to all hosts.</para> +</listitem></varlistentry> + +<varlistentry><term><command>blackhole</command></term> +<listitem><para>Specifies a list of addresses that the +server will not accept queries from or use to resolve a query. Queries +from these addresses will not be responded to. The default is <userinput>none</userinput>.</para> +</listitem></varlistentry> + +</variablelist> + +</sect3> + +<sect3><title>Interfaces</title> +<para>The interfaces and ports that the server will answer queries +from may be specified using the <command>listen-on</command> option. <command>listen-on</command> takes +an optional port, and an <varname>address_match_list</varname>. +The server will listen on all interfaces allowed by the address +match list. If a port is not specified, port 53 will be used.</para> +<para>Multiple <command>listen-on</command> statements are allowed. +For example,</para> + +<programlisting>listen-on { 5.6.7.8; }; +listen-on port 1234 { !1.2.3.4; 1.2/16; }; +</programlisting> + +<para>will enable the name server on port 53 for the IP address +5.6.7.8, and on port 1234 of an address on the machine in net +1.2 that is not 1.2.3.4.</para> + +<para>If no <command>listen-on</command> is specified, the +server will listen on port 53 on all interfaces.</para> + +<para>The <command>listen-on-v6</command> option is used to +specify the interfaces and the ports on which the server will listen +for incoming queries sent using IPv6.</para> + +<para>When <programlisting>{ any; }</programlisting> is specified +as the <varname>address_match_list</varname> for the +<command>listen-on-v6</command> option, +the server does not bind a separate socket to each IPv6 interface +address as it does for IPv4 if the operating system has enough API +support for IPv6 (specifically if it conforms to RFC 3493 and RFC 3542). +Instead, it listens on the IPv6 wildcard address. +If the system only has incomplete API support for IPv6, however, +the behavior is the same as that for IPv4.</para> + +<para>A list of particular IPv6 addresses can also be specified, in which case +the server listens on a separate socket for each specified address, +regardless of whether the desired API is supported by the system.</para> + +<para>Multiple <command>listen-on-v6</command> options can be used. +For example,</para> + +<programlisting>listen-on-v6 { any; }; +listen-on-v6 port 1234 { !2001:db8::/32; any; }; +</programlisting> + +<para>will enable the name server on port 53 for any IPv6 addresses +(with a single wildcard socket), +and on port 1234 of IPv6 addresses that is not in the prefix +2001:db8::/32 (with separate sockets for each matched address.)</para> + +<para>To make the server not listen on any IPv6 address, use</para> +<programlisting>listen-on-v6 { none; }; +</programlisting> +<para>If no <command>listen-on-v6</command> option is specified, +the server will not listen on any IPv6 address.</para></sect3> + +<sect3><title>Query Address</title> +<para>If the server doesn't know the answer to a question, it will +query other name servers. <command>query-source</command> specifies +the address and port used for such queries. For queries sent over +IPv6, there is a separate <command>query-source-v6</command> option. +If <command>address</command> is <command>*</command> or is omitted, +a wildcard IP address (<command>INADDR_ANY</command>) will be used. +If <command>port</command> is <command>*</command> or is omitted, +a random unprivileged port will be used, <command>avoid-v4-udp-ports</command> +and <command>avoid-v6-udp-ports</command> can be used to prevent named +from selecting certain ports. The defaults are</para> +<programlisting>query-source address * port *; +query-source-v6 address * port *; +</programlisting> +<note> +<para>The address specified in the <command>query-source</command> option +is used for both UDP and TCP queries, but the port applies only to +UDP queries. TCP queries always use a random +unprivileged port.</para></note> +<note> +<para>See also <command>transfer-source</command> and +<command>notify-source</command>.</para></note> +</sect3> + +<sect3 id="zone_transfers"><title>Zone Transfers</title> +<para><acronym>BIND</acronym> has mechanisms in place to facilitate zone transfers +and set limits on the amount of load that transfers place on the +system. The following options apply to zone transfers.</para> + +<variablelist> + +<varlistentry><term><command>also-notify</command></term> +<listitem><para>Defines a global list of IP addresses of name servers +that are also sent NOTIFY messages whenever a fresh copy of the +zone is loaded, in addition to the servers listed in the zone's NS records. +This helps to ensure that copies of the zones will +quickly converge on stealth servers. If an <command>also-notify</command> list +is given in a <command>zone</command> statement, it will override +the <command>options also-notify</command> statement. When a <command>zone notify</command> statement +is set to <command>no</command>, the IP addresses in the global <command>also-notify</command> list will +not be sent NOTIFY messages for that zone. The default is the empty +list (no global notification list).</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-transfer-time-in</command></term> +<listitem><para>Inbound zone transfers running longer than +this many minutes will be terminated. The default is 120 minutes +(2 hours). The maximum value is 28 days (40320 minutes).</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-transfer-idle-in</command></term> +<listitem><para>Inbound zone transfers making no progress +in this many minutes will be terminated. The default is 60 minutes +(1 hour). The maximum value is 28 days (40320 minutes).</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-transfer-time-out</command></term> +<listitem><para>Outbound zone transfers running longer than +this many minutes will be terminated. The default is 120 minutes +(2 hours). The maximum value is 28 days (40320 minutes).</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-transfer-idle-out</command></term> +<listitem><para>Outbound zone transfers making no progress +in this many minutes will be terminated. The default is 60 minutes (1 +hour). The maximum value is 28 days (40320 minutes).</para> +</listitem></varlistentry> + +<varlistentry><term><command>serial-query-rate</command></term> +<listitem><para>Slave servers will periodically query master servers +to find out if zone serial numbers have changed. Each such query uses +a minute amount of the slave server's network bandwidth. To limit the +amount of bandwidth used, BIND 9 limits the rate at which queries are +sent. The value of the <command>serial-query-rate</command> option, +an integer, is the maximum number of queries sent per second. +The default is 20. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>serial-queries</command></term> +<listitem><para>In BIND 8, the <command>serial-queries</command> option +set the maximum number of concurrent serial number queries +allowed to be outstanding at any given time. +BIND 9 does not limit the number of outstanding +serial queries and ignores the <command>serial-queries</command> option. +Instead, it limits the rate at which the queries are sent +as defined using the <command>serial-query-rate</command> option. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>transfer-format</command></term> +<listitem> + +<para> +Zone transfers can be sent using two different formats, +<command>one-answer</command> and <command>many-answers</command>. +The <command>transfer-format</command> option is used +on the master server to determine which format it sends. +<command>one-answer</command> uses one DNS message per +resource record transferred. +<command>many-answers</command> packs as many resource records as +possible into a message. <command>many-answers</command> is more +efficient, but is only supported by relatively new slave servers, +such as <acronym>BIND</acronym> 9, <acronym>BIND</acronym> 8.x and patched +versions of <acronym>BIND</acronym> 4.9.5. The default is +<command>many-answers</command>. <command>transfer-format</command> +may be overridden on a per-server basis by using the +<command>server</command> statement. +</para> + +</listitem></varlistentry> + +<varlistentry><term><command>transfers-in</command></term> +<listitem><para>The maximum number of inbound zone transfers +that can be running concurrently. The default value is <literal>10</literal>. +Increasing <command>transfers-in</command> may speed up the convergence +of slave zones, but it also may increase the load on the local system.</para> +</listitem></varlistentry> + +<varlistentry><term><command>transfers-out</command></term> +<listitem><para>The maximum number of outbound zone transfers +that can be running concurrently. Zone transfer requests in excess +of the limit will be refused. The default value is <literal>10</literal>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>transfers-per-ns</command></term> +<listitem><para>The maximum number of inbound zone transfers +that can be concurrently transferring from a given remote name server. +The default value is <literal>2</literal>. Increasing <command>transfers-per-ns</command> may +speed up the convergence of slave zones, but it also may increase +the load on the remote name server. <command>transfers-per-ns</command> may +be overridden on a per-server basis by using the <command>transfers</command> phrase +of the <command>server</command> statement.</para> +</listitem></varlistentry> + +<varlistentry><term><command>transfer-source</command></term> +<listitem><para><command>transfer-source</command> determines +which local address will be bound to IPv4 TCP connections used to +fetch zones transferred inbound by the server. It also determines +the source IPv4 address, and optionally the UDP port, used for the +refresh queries and forwarded dynamic updates. If not set, it defaults +to a system controlled value which will usually be the address of +the interface "closest to" the remote end. This address must appear +in the remote end's <command>allow-transfer</command> option for +the zone being transferred, if one is specified. This statement +sets the <command>transfer-source</command> for all zones, but can +be overridden on a per-view or per-zone basis by including a +<command>transfer-source</command> statement within the +<command>view</command> or <command>zone</command> block +in the configuration file.</para> +</listitem></varlistentry> + +<varlistentry><term><command>transfer-source-v6</command></term> +<listitem><para>The same as <command>transfer-source</command>, +except zone transfers are performed using IPv6.</para> + </listitem></varlistentry> + +<varlistentry><term><command>alt-transfer-source</command></term> +<listitem><para>An alternate transfer source if the one listed in +<command>transfer-source</command> fails and +<command>use-alt-transfer-source</command> is set.</para> + </listitem></varlistentry> + +<varlistentry><term><command>alt-transfer-source-v6</command></term> +<listitem><para>An alternate transfer source if the one listed in +<command>transfer-source-v6</command> fails and +<command>use-alt-transfer-source</command> is set.</para> + </listitem></varlistentry> + +<varlistentry><term><command>use-alt-transfer-source</command></term> +<listitem><para>Use the alternate transfer sources or not. If views are +specified this defaults to <command>no</command> otherwise it defaults to +<command>yes</command> (for BIND 8 compatibility).</para> +</listitem></varlistentry> + +<varlistentry><term><command>notify-source</command></term> +<listitem><para><command>notify-source</command> determines +which local source address, and optionally UDP port, will be used to +send NOTIFY messages. +This address must appear in the slave server's <command>masters</command> +zone clause or in an <command>allow-notify</command> clause. +This statement sets the <command>notify-source</command> for all zones, +but can be overridden on a per-zone / per-view basis by including a +<command>notify-source</command> statement within the <command>zone</command> +or <command>view</command> block in the configuration file.</para> +</listitem></varlistentry> + +<varlistentry><term><command>notify-source-v6</command></term> +<listitem><para>Like <command>notify-source</command>, +but applies to notify messages sent to IPv6 addresses.</para> +</listitem></varlistentry> + +</variablelist> + +</sect3> + +<sect3> +<title>Bad UDP Port Lists</title> +<para> +<command>avoid-v4-udp-ports</command> and <command>avoid-v6-udp-ports</command> +specify a list of IPv4 and IPv6 UDP ports that will not be used as system +assigned source ports for UDP sockets. These lists prevent named +from choosing as its random source port a port that is blocked by +your firewall. If a query went out with such a source port, the +answer would not get by the firewall and the name server would have +to query again. +</para> +</sect3> + +<sect3> +<title>Operating System Resource Limits</title> + +<para>The server's usage of many system resources can be limited. +Scaled values are allowed when specifying resource limits. For +example, <command>1G</command> can be used instead of +<command>1073741824</command> to specify a limit of one +gigabyte. <command>unlimited</command> requests unlimited use, or the +maximum available amount. <command>default</command> uses the limit +that was in force when the server was started. See the description of +<command>size_spec</command> in <xref +linkend="configuration_file_elements"/>.</para> + +<para>The following options set operating system resource limits for +the name server process. Some operating systems don't support some or +any of the limits. On such systems, a warning will be issued if the +unsupported limit is used.</para> + +<variablelist> + +<varlistentry><term><command>coresize</command></term> +<listitem><para>The maximum size of a core dump. The default +is <literal>default</literal>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>datasize</command></term> +<listitem><para>The maximum amount of data memory the server +may use. The default is <literal>default</literal>. +This is a hard limit on server memory usage. +If the server attempts to allocate memory in excess of this +limit, the allocation will fail, which may in turn leave +the server unable to perform DNS service. Therefore, +this option is rarely useful as a way of limiting the +amount of memory used by the server, but it can be used +to raise an operating system data size limit that is +too small by default. If you wish to limit the amount +of memory used by the server, use the +<command>max-cache-size</command> and +<command>recursive-clients</command> +options instead. +</para></listitem></varlistentry> + +<varlistentry><term><command>files</command></term> +<listitem><para>The maximum number of files the server +may have open concurrently. The default is <literal>unlimited</literal>. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>stacksize</command></term> +<listitem><para>The maximum amount of stack memory the server +may use. The default is <literal>default</literal>.</para> +</listitem></varlistentry> + +</variablelist> + +</sect3> + +<sect3> +<title>Server Resource Limits</title> + +<para>The following options set limits on the server's +resource consumption that are enforced internally by the +server rather than the operating system.</para> + +<variablelist> + +<varlistentry><term><command>max-ixfr-log-size</command></term> +<listitem><para>This option is obsolete; it is accepted +and ignored for BIND 8 compatibility. The option +<command>max-journal-size</command> performs a similar +function in BIND 8. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-journal-size</command></term> +<listitem><para>Sets a maximum size for each journal file +(<xref linkend="journal"/>). When the journal file approaches +the specified size, some of the oldest transactions in the journal +will be automatically removed. The default is +<literal>unlimited</literal>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>recursive-clients</command></term> +<listitem><para>The maximum number of simultaneous recursive lookups +the server will perform on behalf of clients. The default is +<literal>1000</literal>. Because each recursing client uses a fair +bit of memory, on the order of 20 kilobytes, the value of the +<command>recursive-clients</command> option may have to be decreased +on hosts with limited memory. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>tcp-clients</command></term> +<listitem><para>The maximum number of simultaneous client TCP +connections that the server will accept. +The default is <literal>100</literal>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-cache-size</command></term> +<listitem><para>The maximum amount of memory to use for the +server's cache, in bytes. When the amount of data in the cache +reaches this limit, the server will cause records to expire +prematurely so that the limit is not exceeded. In a server with +multiple views, the limit applies separately to the cache of each +view. The default is <literal>unlimited</literal>, meaning that +records are purged from the cache only when their TTLs expire. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>tcp-listen-queue</command></term> +<listitem><para>The listen queue depth. The default and minimum is 3. +If the kernel supports the accept filter "dataready" this also controls how +many TCP connections that will be queued in kernel space waiting for +some data before being passed to accept. Values less than 3 will be +silently raised. +</para> +</listitem></varlistentry> + +</variablelist> + +</sect3> + +<sect3><title>Periodic Task Intervals</title> + +<variablelist> + +<varlistentry><term><command>cleaning-interval</command></term> +<listitem><para>The server will remove expired resource records +from the cache every <command>cleaning-interval</command> minutes. +The default is 60 minutes. The maximum value is 28 days (40320 minutes). +If set to 0, no periodic cleaning will occur.</para> +</listitem></varlistentry> + +<varlistentry><term><command>heartbeat-interval</command></term> +<listitem><para>The server will perform zone maintenance tasks +for all zones marked as <command>dialup</command> whenever this +interval expires. The default is 60 minutes. Reasonable values are up +to 1 day (1440 minutes). The maximum value is 28 days (40320 minutes). +If set to 0, no zone maintenance for these zones will occur.</para> +</listitem></varlistentry> + +<varlistentry><term><command>interface-interval</command></term> +<listitem><para>The server will scan the network interface list +every <command>interface-interval</command> minutes. The default +is 60 minutes. The maximum value is 28 days (40320 minutes). +If set to 0, interface scanning will only occur when +the configuration file is loaded. After the scan, the server will +begin listening for queries on any newly discovered +interfaces (provided they are allowed by the +<command>listen-on</command> configuration), and will +stop listening on interfaces that have gone away.</para> +</listitem></varlistentry> + +<varlistentry><term><command>statistics-interval</command></term> +<listitem><para>Name server statistics will be logged +every <command>statistics-interval</command> minutes. The default is +60. The maximum value is 28 days (40320 minutes). +If set to 0, no statistics will be logged.</para><note> +<simpara>Not yet implemented in <acronym>BIND</acronym>9.</simpara></note> +</listitem></varlistentry> + +</variablelist> + +</sect3> + +<sect3 id="topology"><title>Topology</title> + +<para>All other things being equal, when the server chooses a name server +to query from a list of name servers, it prefers the one that is +topologically closest to itself. The <command>topology</command> statement +takes an <command>address_match_list</command> and interprets it +in a special way. Each top-level list element is assigned a distance. +Non-negated elements get a distance based on their position in the +list, where the closer the match is to the start of the list, the +shorter the distance is between it and the server. A negated match +will be assigned the maximum distance from the server. If there +is no match, the address will get a distance which is further than +any non-negated list element, and closer than any negated element. +For example,</para> +<programlisting>topology { + 10/8; + !1.2.3/24; + { 1.2/16; 3/8; }; +};</programlisting> +<para>will prefer servers on network 10 the most, followed by hosts +on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the +exception of hosts on network 1.2.3 (netmask 255.255.255.0), which +is preferred least of all.</para> +<para>The default topology is</para> +<programlisting> topology { localhost; localnets; }; +</programlisting> +<note><simpara>The <command>topology</command> option +is not implemented in <acronym>BIND</acronym> 9. +</simpara></note> +</sect3> + +<sect3 id="the_sortlist_statement"> + +<title>The <command>sortlist</command> Statement</title> + +<para>The response to a DNS query may consist of multiple resource +records (RRs) forming a resource records set (RRset). +The name server will normally return the +RRs within the RRset in an indeterminate order +(but see the <command>rrset-order</command> +statement in <xref linkend="rrset_ordering"/>). +The client resolver code should rearrange the RRs as appropriate, +that is, using any addresses on the local net in preference to other addresses. +However, not all resolvers can do this or are correctly configured. +When a client is using a local server the sorting can be performed +in the server, based on the client's address. This only requires +configuring the name servers, not all the clients.</para> + +<para>The <command>sortlist</command> statement (see below) takes +an <command>address_match_list</command> and interprets it even +more specifically than the <command>topology</command> statement +does (<xref linkend="topology"/>). +Each top level statement in the <command>sortlist</command> must +itself be an explicit <command>address_match_list</command> with +one or two elements. The first element (which may be an IP address, +an IP prefix, an ACL name or a nested <command>address_match_list</command>) +of each top level list is checked against the source address of +the query until a match is found.</para> +<para>Once the source address of the query has been matched, if +the top level statement contains only one element, the actual primitive +element that matched the source address is used to select the address +in the response to move to the beginning of the response. If the +statement is a list of two elements, then the second element is +treated the same as the <command>address_match_list</command> in +a <command>topology</command> statement. Each top level element +is assigned a distance and the address in the response with the minimum +distance is moved to the beginning of the response.</para> +<para>In the following example, any queries received from any of +the addresses of the host itself will get responses preferring addresses +on any of the locally connected networks. Next most preferred are addresses +on the 192.168.1/24 network, and after that either the 192.168.2/24 +or +192.168.3/24 network with no preference shown between these two +networks. Queries received from a host on the 192.168.1/24 network +will prefer other addresses on that network to the 192.168.2/24 +and +192.168.3/24 networks. Queries received from a host on the 192.168.4/24 +or the 192.168.5/24 network will only prefer other addresses on +their directly connected networks.</para> +<programlisting>sortlist { + { localhost; // IF the local host + { localnets; // THEN first fit on the + 192.168.1/24; // following nets + { 192.168.2/24; 192.168.3/24; }; }; }; + { 192.168.1/24; // IF on class C 192.168.1 + { 192.168.1/24; // THEN use .1, or .2 or .3 + { 192.168.2/24; 192.168.3/24; }; }; }; + { 192.168.2/24; // IF on class C 192.168.2 + { 192.168.2/24; // THEN use .2, or .1 or .3 + { 192.168.1/24; 192.168.3/24; }; }; }; + { 192.168.3/24; // IF on class C 192.168.3 + { 192.168.3/24; // THEN use .3, or .1 or .2 + { 192.168.1/24; 192.168.2/24; }; }; }; + { { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net + }; +};</programlisting> +<para>The following example will give reasonable behavior for the +local host and hosts on directly connected networks. It is similar +to the behavior of the address sort in <acronym>BIND</acronym> 4.9.x. Responses sent +to queries from the local host will favor any of the directly connected +networks. Responses sent to queries from any other hosts on a directly +connected network will prefer addresses on that same network. Responses +to other queries will not be sorted.</para> +<programlisting>sortlist { + { localhost; localnets; }; + { localnets; }; +}; +</programlisting> +</sect3> +<sect3 id="rrset_ordering"><title id="rrset_ordering_title">RRset Ordering</title> +<para>When multiple records are returned in an answer it may be +useful to configure the order of the records placed into the response. +The <command>rrset-order</command> statement permits configuration +of the ordering of the records in a multiple record response. +See also the <command>sortlist</command> statement, +<xref linkend="the_sortlist_statement"/>. +</para> + +<para>An <command>order_spec</command> is defined as follows:</para> +<programlisting><optional> class <replaceable>class_name</replaceable> </optional><optional> type <replaceable>type_name</replaceable> </optional><optional> name <replaceable>"domain_name"</replaceable></optional> + order <replaceable>ordering</replaceable> +</programlisting> +<para>If no class is specified, the default is <command>ANY</command>. +If no type is specified, the default is <command>ANY</command>. +If no name is specified, the default is "<command>*</command>".</para> +<para>The legal values for <command>ordering</command> are:</para> +<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2" + colsep = "0" rowsep = "0" tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.750in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.750in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><command>fixed</command></para></entry> +<entry colname = "2"><para>Records are returned in the order they +are defined in the zone file.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>random</command></para></entry> +<entry colname = "2"><para>Records are returned in some random order.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>cyclic</command></para></entry> +<entry colname = "2"><para>Records are returned in a round-robin +order.</para></entry> +</row> +</tbody> +</tgroup></informaltable> +<para>For example:</para> +<programlisting>rrset-order { + class IN type A name "host.example.com" order random; + order cyclic; +}; +</programlisting> +<para>will cause any responses for type A records in class IN that +have "<literal>host.example.com</literal>" as a suffix, to always be returned +in random order. All other records are returned in cyclic order.</para> +<para>If multiple <command>rrset-order</command> statements appear, +they are not combined — the last one applies.</para> + +<note> +<simpara>The <command>rrset-order</command> statement +is not yet fully implemented in <acronym>BIND</acronym> 9. +BIND 9 currently does not support "fixed" ordering. +</simpara></note> +</sect3> + +<sect3 id="tuning"><title>Tuning</title> + +<variablelist> + +<varlistentry><term><command>lame-ttl</command></term> +<listitem><para>Sets the number of seconds to cache a +lame server indication. 0 disables caching. (This is +<emphasis role="bold">NOT</emphasis> recommended.) +Default is <literal>600</literal> (10 minutes). Maximum value is +<literal>1800</literal> (30 minutes).</para> + +</listitem></varlistentry> + +<varlistentry><term><command>max-ncache-ttl</command></term> +<listitem><para>To reduce network traffic and increase performance +the server stores negative answers. <command>max-ncache-ttl</command> is +used to set a maximum retention time for these answers in the server +in seconds. The default +<command>max-ncache-ttl</command> is <literal>10800</literal> seconds (3 hours). +<command>max-ncache-ttl</command> cannot exceed 7 days and will +be silently truncated to 7 days if set to a greater value.</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-cache-ttl</command></term> +<listitem><para><command>max-cache-ttl</command> sets +the maximum time for which the server will cache ordinary (positive) +answers. The default is one week (7 days).</para> +</listitem></varlistentry> + +<varlistentry><term><command>min-roots</command></term> +<listitem><para>The minimum number of root servers that +is required for a request for the root servers to be accepted. Default +is <userinput>2</userinput>.</para> +<note> +<simpara>Not implemented in <acronym>BIND</acronym>9.</simpara></note> +</listitem></varlistentry> + +<varlistentry><term><command>sig-validity-interval</command></term> +<listitem><para>Specifies the number of days into the +future when DNSSEC signatures automatically generated as a result +of dynamic updates (<xref linkend="dynamic_update"/>) +will expire. The default is <literal>30</literal> days. +The maximum value is 10 years (3660 days). The signature +inception time is unconditionally set to one hour before the current time +to allow for a limited amount of clock skew.</para> +</listitem></varlistentry> + +<varlistentry> +<term><command>min-refresh-time</command></term> +<term><command>max-refresh-time</command></term> +<term><command>min-retry-time</command></term> +<term><command>max-retry-time</command></term> +<listitem><para> +These options control the server's behavior on refreshing a zone +(querying for SOA changes) or retrying failed transfers. +Usually the SOA values for the zone are used, but these values +are set by the master, giving slave server administrators little +control over their contents. +</para><para> +These options allow the administrator to set a minimum and maximum +refresh and retry time either per-zone, per-view, or globally. +These options are valid for slave and stub zones, +and clamp the SOA refresh and retry times to the specified values. +</para></listitem></varlistentry> + +<varlistentry> +<term><command>edns-udp-size</command></term> +<listitem><para> +<command>edns-udp-size</command> sets the advertised EDNS UDP buffer +size. Valid values are 512 to 4096 (values outside this range will be +silently adjusted). The default value is 4096. The usual reason for +setting edns-udp-size to a non default value it to get UDP answers to +pass through broken firewalls that block fragmented packets and/or +block UDP packets that are greater than 512 bytes. +</para></listitem></varlistentry> +</variablelist> + +</sect3> + +<sect3 id="builtin"> +<title>Built-in server information zones</title> + +<para>The server provides some helpful diagnostic information +through a number of built-in zones under the +pseudo-top-level-domain <literal>bind</literal> in the +<command>CHAOS</command> class. These zones are part of a +built-in view (see <xref linkend="view_statement_grammar"/>) of class +<command>CHAOS</command> which is separate from the default view of +class <command>IN</command>; therefore, any global server options +such as <command>allow-query</command> do not apply the these zones. +If you feel the need to disable these zones, use the options +below, or hide the built-in <command>CHAOS</command> view by +defining an explicit view of class <command>CHAOS</command> +that matches all clients.</para> + +<variablelist> + +<varlistentry><term><command>version</command></term> +<listitem><para>The version the server should report +via a query of the name <literal>version.bind</literal> +with type <command>TXT</command>, class <command>CHAOS</command>. +The default is the real version number of this server. +Specifying <command>version none</command> +disables processing of the queries.</para> +</listitem></varlistentry> + +<varlistentry><term><command>hostname</command></term> +<listitem><para>The hostname the server should report via a query of +the name <filename>hostname.bind</filename> +with type <command>TXT</command>, class <command>CHAOS</command>. +This defaults to the hostname of the machine hosting the name server as +found by gethostname(). The primary purpose of such queries is to +identify which of a group of anycast servers is actually +answering your queries. Specifying <command>hostname none;</command> +disables processing of the queries.</para> +</listitem></varlistentry> + +<varlistentry><term><command>server-id</command></term> +<listitem><para>The ID of the server should report via a query of +the name <filename>ID.SERVER</filename> +with type <command>TXT</command>, class <command>CHAOS</command>. +The primary purpose of such queries is to +identify which of a group of anycast servers is actually +answering your queries. Specifying <command>server-id none;</command> +disables processing of the queries. +Specifying <command>server-id hostname;</command> will cause named to +use the hostname as found by gethostname(). +The default <command>server-id</command> is <command>none</command>. +</para> +</listitem></varlistentry> + +</variablelist> + +</sect3> + +<sect3 id="statsfile"> +<title>The Statistics File</title> + +<para>The statistics file generated by <acronym>BIND</acronym> 9 +is similar, but not identical, to that +generated by <acronym>BIND</acronym> 8. +</para> +<para>The statistics dump begins with the line <command>+++ Statistics Dump ++++ (973798949)</command>, where the number in parentheses is a standard +Unix-style timestamp, measured as seconds since January 1, 1970. Following +that line are a series of lines containing a counter type, the value of the +counter, optionally a zone name, and optionally a view name. +The lines without view and zone listed are global statistics for the entire server. +Lines with a zone and view name for the given view and zone (the view name is +omitted for the default view). The statistics dump ends +with the line <command>--- Statistics Dump --- (973798949)</command>, where the +number is identical to the number in the beginning line.</para> +<para>The following statistics counters are maintained:</para> +<informaltable + colsep = "0" rowsep = "0"><tgroup cols = "2" + colsep = "0" rowsep = "0" tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.150in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.350in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><command>success</command></para></entry> +<entry colname = "2"><para>The number of +successful queries made to the server or zone. A successful query +is defined as query which returns a NOERROR response with at least +one answer RR.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>referral</command></para></entry> +<entry colname = "2"><para>The number of queries which resulted +in referral responses.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>nxrrset</command></para></entry> +<entry colname = "2"><para>The number of queries which resulted in +NOERROR responses with no data.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>nxdomain</command></para></entry> +<entry colname = "2"><para>The number +of queries which resulted in NXDOMAIN responses.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>failure</command></para></entry> +<entry colname = "2"><para>The number of queries which resulted in a +failure response other than those above.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><command>recursion</command></para></entry> +<entry colname = "2"><para>The number of queries which caused the server +to perform recursion in order to find the final answer.</para></entry> +</row> +</tbody> +</tgroup></informaltable> + +<para> +Each query received by the server will cause exactly one of +<command>success</command>, +<command>referral</command>, +<command>nxrrset</command>, +<command>nxdomain</command>, or +<command>failure</command> +to be incremented, and may additionally cause the +<command>recursion</command> counter to be incremented. +</para> + +</sect3> + +</sect2> + +<sect2 id="server_statement_grammar"> +<title><command>server</command> Statement Grammar</title> + +<programlisting>server <replaceable>ip_addr</replaceable> { + <optional> bogus <replaceable>yes_or_no</replaceable> ; </optional> + <optional> provide-ixfr <replaceable>yes_or_no</replaceable> ; </optional> + <optional> request-ixfr <replaceable>yes_or_no</replaceable> ; </optional> + <optional> edns <replaceable>yes_or_no</replaceable> ; </optional> + <optional> transfers <replaceable>number</replaceable> ; </optional> + <optional> transfer-format <replaceable>( one-answer | many-answers )</replaceable> ; ]</optional> + <optional> keys <replaceable>{ string ; <optional> string ; <optional>...</optional></optional> }</replaceable> ; </optional> + <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> +}; +</programlisting> + +</sect2> + +<sect2 id="server_statement_definition_and_usage"> +<title><command>server</command> Statement Definition and Usage</title> + +<para>The <command>server</command> statement defines characteristics +to be associated with a remote name server.</para> + +<para> +The <command>server</command> statement can occur at the top level of the +configuration file or inside a <command>view</command> statement. +If a <command>view</command> statement contains +one or more <command>server</command> statements, only those +apply to the view and any top-level ones are ignored. +If a view contains no <command>server</command> statements, +any top-level <command>server</command> statements are used as +defaults. +</para> + +<para>If you discover that a remote server is giving out bad data, +marking it as bogus will prevent further queries to it. The default +value of <command>bogus</command> is <command>no</command>.</para> +<para>The <command>provide-ixfr</command> clause determines whether +the local server, acting as master, will respond with an incremental +zone transfer when the given remote server, a slave, requests it. +If set to <command>yes</command>, incremental transfer will be provided +whenever possible. If set to <command>no</command>, all transfers +to the remote server will be non-incremental. If not set, the value +of the <command>provide-ixfr</command> option in the view or +global options block is used as a default.</para> + +<para>The <command>request-ixfr</command> clause determines whether +the local server, acting as a slave, will request incremental zone +transfers from the given remote server, a master. If not set, the +value of the <command>request-ixfr</command> option in the view or +global options block is used as a default.</para> + +<para>IXFR requests to servers that do not support IXFR will automatically +fall back to AXFR. Therefore, there is no need to manually list +which servers support IXFR and which ones do not; the global default +of <command>yes</command> should always work. +The purpose of the <command>provide-ixfr</command> and +<command>request-ixfr</command> clauses is +to make it possible to disable the use of IXFR even when both master +and slave claim to support it, for example if one of the servers +is buggy and crashes or corrupts data when IXFR is used.</para> + +<para>The <command>edns</command> clause determines whether the local server +will attempt to use EDNS when communicating with the remote server. The +default is <command>yes</command>.</para> + +<para>The server supports two zone transfer methods. The first, <command>one-answer</command>, +uses one DNS message per resource record transferred. <command>many-answers</command> packs +as many resource records as possible into a message. <command>many-answers</command> is +more efficient, but is only known to be understood by <acronym>BIND</acronym> 9, <acronym>BIND</acronym> +8.x, and patched versions of <acronym>BIND</acronym> 4.9.5. You can specify which method +to use for a server with the <command>transfer-format</command> option. +If <command>transfer-format</command> is not specified, the <command>transfer-format</command> specified +by the <command>options</command> statement will be used.</para> + +<para><command>transfers</command> is used to limit the number of +concurrent inbound zone transfers from the specified server. If +no <command>transfers</command> clause is specified, the limit is +set according to the <command>transfers-per-ns</command> option.</para> + +<para>The <command>keys</command> clause identifies a +<command>key_id</command> defined by the <command>key</command> statement, +to be used for transaction security (TSIG, <xref linkend="tsig"/>) +when talking to the remote server. +When a request is sent to the remote server, a request signature +will be generated using the key specified here and appended to the +message. A request originating from the remote server is not required +to be signed by this key.</para> + +<para>Although the grammar of the <command>keys</command> clause +allows for multiple keys, only a single key per server is currently +supported.</para> + +<para>The <command>transfer-source</command> and +<command>transfer-source-v6</command> clauses specify the IPv4 and IPv6 source +address to be used for zone transfer with the remote server, respectively. +For an IPv4 remote server, only <command>transfer-source</command> can +be specified. +Similarly, for an IPv6 remote server, only +<command>transfer-source-v6</command> can be specified. +Form more details, see the description of +<command>transfer-source</command> and +<command>transfer-source-v6</command> in +<xref linkend="zone_transfers"/>.</para> + +</sect2> + +<sect2><title><command>trusted-keys</command> Statement Grammar</title> +<programlisting>trusted-keys { + <replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; + <optional> <replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; <optional>...</optional></optional> +}; +</programlisting> +</sect2> +<sect2><title><command>trusted-keys</command> Statement Definition +and Usage</title> +<para>The <command>trusted-keys</command> statement defines DNSSEC +security roots. DNSSEC is described in <xref linkend="DNSSEC"/>. A security root is defined when the public key for a non-authoritative +zone is known, but cannot be securely obtained through DNS, either +because it is the DNS root zone or because its parent zone is unsigned. +Once a key has been configured as a trusted key, it is treated as +if it had been validated and proven secure. The resolver attempts +DNSSEC validation on all DNS data in subdomains of a security root.</para> +<para>The <command>trusted-keys</command> statement can contain +multiple key entries, each consisting of the key's domain name, +flags, protocol, algorithm, and the base-64 representation of the +key data.</para></sect2> + +<sect2 id="view_statement_grammar"> +<title><command>view</command> Statement Grammar</title> +<programlisting>view <replaceable>view_name</replaceable> + <optional><replaceable>class</replaceable></optional> { + match-clients { <replaceable>address_match_list</replaceable> } ; + match-destinations { <replaceable>address_match_list</replaceable> } ; + match-recursive-only <replaceable>yes_or_no</replaceable> ; + <optional> <replaceable>view_option</replaceable>; ...</optional> + <optional> <replaceable>zone_statement</replaceable>; ...</optional> +}; +</programlisting></sect2> +<sect2><title><command>view</command> Statement Definition and Usage</title> + +<para>The <command>view</command> statement is a powerful new feature +of <acronym>BIND</acronym> 9 that lets a name server answer a DNS query differently +depending on who is asking. It is particularly useful for implementing +split DNS setups without having to run multiple servers.</para> + +<para>Each <command>view</command> statement defines a view of the +DNS namespace that will be seen by a subset of clients. A client matches +a view if its source IP address matches the +<varname>address_match_list</varname> of the view's +<command>match-clients</command> clause and its destination IP address matches +the <varname>address_match_list</varname> of the view's +<command>match-destinations</command> clause. If not specified, both +<command>match-clients</command> and <command>match-destinations</command> +default to matching all addresses. In addition to checking IP addresses +<command>match-clients</command> and <command>match-destinations</command> +can also take <command>keys</command> which provide an mechanism for the +client to select the view. A view can also be specified +as <command>match-recursive-only</command>, which means that only recursive +requests from matching clients will match that view. +The order of the <command>view</command> statements is significant — +a client request will be resolved in the context of the first +<command>view</command> that it matches.</para> + +<para>Zones defined within a <command>view</command> statement will +be only be accessible to clients that match the <command>view</command>. + By defining a zone of the same name in multiple views, different +zone data can be given to different clients, for example, "internal" +and "external" clients in a split DNS setup.</para> + +<para>Many of the options given in the <command>options</command> statement +can also be used within a <command>view</command> statement, and then +apply only when resolving queries with that view. When no view-specific +value is given, the value in the <command>options</command> statement +is used as a default. Also, zone options can have default values specified +in the <command>view</command> statement; these view-specific defaults +take precedence over those in the <command>options</command> statement.</para> + +<para>Views are class specific. If no class is given, class IN +is assumed. Note that all non-IN views must contain a hint zone, +since only the IN class has compiled-in default hints.</para> + +<para>If there are no <command>view</command> statements in the config +file, a default view that matches any client is automatically created +in class IN. Any <command>zone</command> statements specified on +the top level of the configuration file are considered to be part of +this default view, and the <command>options</command> statement will +apply to the default view. If any explicit <command>view</command> +statements are present, all <command>zone</command> statements must +occur inside <command>view</command> statements.</para> + +<para>Here is an example of a typical split DNS setup implemented +using <command>view</command> statements.</para> +<programlisting>view "internal" { + // This should match our internal networks. + match-clients { 10.0.0.0/8; }; + + // Provide recursive service to internal clients only. + recursion yes; + + // Provide a complete view of the example.com zone + // including addresses of internal hosts. + zone "example.com" { + type master; + file "example-internal.db"; + }; +}; + +view "external" { + // Match all clients not matched by the previous view. + match-clients { any; }; + + // Refuse recursive service to external clients. + recursion no; + + // Provide a restricted view of the example.com zone + // containing only publicly accessible hosts. + zone "example.com" { + type master; + file "example-external.db"; + }; +}; +</programlisting> +</sect2> +<sect2 id="zone_statement_grammar"><title><command>zone</command> +Statement Grammar</title> + <programlisting>zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> <optional>{ + type ( master | slave | hint | stub | forward | delegation-only ) ; + <optional> allow-notify { <replaceable>address_match_list</replaceable> } ; </optional> + <optional> allow-query { <replaceable>address_match_list</replaceable> } ; </optional> + <optional> allow-transfer { <replaceable>address_match_list</replaceable> } ; </optional> + <optional> allow-update { <replaceable>address_match_list</replaceable> } ; </optional> + <optional> update-policy { <replaceable>update_policy_rule</replaceable> <optional>...</optional> } ; </optional> + <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> } ; </optional> + <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional> + <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional> + <optional> dialup <replaceable>dialup_option</replaceable> ; </optional> + <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional> + <optional> file <replaceable>string</replaceable> ; </optional> + <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional> + <optional> forwarders { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional> + <optional> ixfr-base <replaceable>string</replaceable> ; </optional> + <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional> + <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional> + <optional> masters <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> } ; </optional> + <optional> max-ixfr-log-size <replaceable>number</replaceable> ; </optional> + <optional> max-transfer-idle-in <replaceable>number</replaceable> ; </optional> + <optional> max-transfer-idle-out <replaceable>number</replaceable> ; </optional> + <optional> max-transfer-time-in <replaceable>number</replaceable> ; </optional> + <optional> max-transfer-time-out <replaceable>number</replaceable> ; </optional> + <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> ; </optional> + <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional> + <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional> + <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional> + <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional> + <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional> + <optional> database <replaceable>string</replaceable> ; </optional> + <optional> min-refresh-time <replaceable>number</replaceable> ; </optional> + <optional> max-refresh-time <replaceable>number</replaceable> ; </optional> + <optional> min-retry-time <replaceable>number</replaceable> ; </optional> + <optional> max-retry-time <replaceable>number</replaceable> ; </optional> + <optional> multi-master <replaceable>yes_or_no</replaceable> ; </optional> + <optional> key-directory <replaceable>path_name</replaceable>; </optional> + +}</optional>; +</programlisting> +</sect2> +<sect2><title><command>zone</command> Statement Definition and Usage</title> +<sect3><title>Zone Types</title> +<informaltable colsep = "0" rowsep = "0"> +<tgroup cols = "2" colsep = "0" rowsep = "0" + tgroupstyle = "3Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.908in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.217in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><varname>master</varname></para></entry> +<entry colname = "2"><para>The server has a master copy of the data +for the zone and will be able to provide authoritative answers for +it.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>slave</varname></para></entry> +<entry colname = "2"><para>A slave zone is a replica of a master +zone. The <command>masters</command> list specifies one or more IP addresses +of master servers that the slave contacts to update its copy of the zone. +Masters list elements can also be names of other masters lists. +By default, transfers are made from port 53 on the servers; this can +be changed for all servers by specifying a port number before the +list of IP addresses, or on a per-server basis after the IP address. +Authentication to the master can also be done with per-server TSIG keys. +If a file is specified, then the +replica will be written to this file whenever the zone is changed, +and reloaded from this file on a server restart. Use of a file is +recommended, since it often speeds server start-up and eliminates +a needless waste of bandwidth. Note that for large numbers (in the +tens or hundreds of thousands) of zones per server, it is best to +use a two level naming scheme for zone file names. For example, +a slave server for the zone <literal>example.com</literal> might place +the zone contents into a file called +<filename>ex/example.com</filename> where <filename>ex/</filename> is +just the first two letters of the zone name. (Most operating systems +behave very slowly if you put 100 000 files into +a single directory.)</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>stub</varname></para></entry> +<entry colname = "2"><para>A stub zone is similar to a slave zone, +except that it replicates only the NS records of a master zone instead +of the entire zone. Stub zones are not a standard part of the DNS; +they are a feature specific to the <acronym>BIND</acronym> implementation. +</para> + +<para>Stub zones can be used to eliminate the need for glue NS record +in a parent zone at the expense of maintaining a stub zone entry and +a set of name server addresses in <filename>named.conf</filename>. +This usage is not recommended for new configurations, and BIND 9 +supports it only in a limited way. +In <acronym>BIND</acronym> 4/8, zone transfers of a parent zone +included the NS records from stub children of that zone. This meant +that, in some cases, users could get away with configuring child stubs +only in the master server for the parent zone. <acronym>BIND</acronym> +9 never mixes together zone data from different zones in this +way. Therefore, if a <acronym>BIND</acronym> 9 master serving a parent +zone has child stub zones configured, all the slave servers for the +parent zone also need to have the same child stub zones +configured.</para> + +<para>Stub zones can also be used as a way of forcing the resolution +of a given domain to use a particular set of authoritative servers. +For example, the caching name servers on a private network using +RFC1981 addressing may be configured with stub zones for +<literal>10.in-addr.arpa</literal> +to use a set of internal name servers as the authoritative +servers for that domain.</para> +</entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>forward</varname></para></entry> +<entry colname = "2"><para>A "forward zone" is a way to configure +forwarding on a per-domain basis. A <command>zone</command> statement +of type <command>forward</command> can contain a <command>forward</command> and/or <command>forwarders</command> statement, +which will apply to queries within the domain given by the zone +name. If no <command>forwarders</command> statement is present or +an empty list for <command>forwarders</command> is given, then no +forwarding will be done for the domain, canceling the effects of +any forwarders in the <command>options</command> statement. Thus +if you want to use this type of zone to change the behavior of the +global <command>forward</command> option (that is, "forward first +to", then "forward only", or vice versa, but want to use the same +servers as set globally) you need to re-specify the global forwarders.</para> +</entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>hint</varname></para></entry> +<entry colname = "2"><para>The initial set of root name servers is +specified using a "hint zone". When the server starts up, it uses +the root hints to find a root name server and get the most recent +list of root name servers. If no hint zone is specified for class +IN, the server uses a compiled-in default set of root servers hints. +Classes other than IN have no built-in defaults hints.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>delegation-only</varname></para></entry> +<entry colname = "2"><para>This is used to enforce the delegation only +status of infrastructure zones (e.g. COM, NET, ORG). Any answer that +is received without a explicit or implicit delegation in the authority +section will be treated as NXDOMAIN. This does not apply to the zone +apex. This SHOULD NOT be applied to leaf zones.</para> +<para><varname>delegation-only</varname> has no effect on answers received +from forwarders.</para></entry> +</row> +</tbody> +</tgroup></informaltable></sect3> + +<sect3><title>Class</title> +<para>The zone's name may optionally be followed by a class. If +a class is not specified, class <literal>IN</literal> (for <varname>Internet</varname>), +is assumed. This is correct for the vast majority of cases.</para> +<para>The <literal>hesiod</literal> class is +named for an information service from MIT's Project Athena. It is +used to share information about various systems databases, such +as users, groups, printers and so on. The keyword +<literal>HS</literal> is +a synonym for hesiod.</para> +<para>Another MIT development is CHAOSnet, a LAN protocol created +in the mid-1970s. Zone data for it can be specified with the <literal>CHAOS</literal> class.</para></sect3> +<sect3> + +<title>Zone Options</title> + +<variablelist> + +<varlistentry><term><command>allow-notify</command></term> +<listitem><para>See the description of +<command>allow-notify</command> in <xref linkend="access_control"/></para> +</listitem></varlistentry> + +<varlistentry><term><command>allow-query</command></term> +<listitem><para>See the description of +<command>allow-query</command> in <xref linkend="access_control"/></para> +</listitem></varlistentry> + +<varlistentry><term><command>allow-transfer</command></term> +<listitem><para>See the description of <command>allow-transfer</command> +in <xref linkend="access_control"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>allow-update</command></term> +<listitem><para>Specifies which hosts are allowed to +submit Dynamic DNS updates for master zones. The default is to deny +updates from all hosts. Note that allowing updates based +on the requestor's IP address is insecure; see +<xref linkend="dynamic_update_security"/> for details. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>update-policy</command></term> +<listitem><para>Specifies a "Simple Secure Update" policy. See +<xref linkend="dynamic_update_policies"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>allow-update-forwarding</command></term> +<listitem><para>See the description of <command>allow-update-forwarding</command> +in <xref linkend="access_control"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>also-notify</command></term> +<listitem><para>Only meaningful if <command>notify</command> is +active for this zone. The set of machines that will receive a +<literal>DNS NOTIFY</literal> message +for this zone is made up of all the listed name servers (other than +the primary master) for the zone plus any IP addresses specified +with <command>also-notify</command>. A port may be specified +with each <command>also-notify</command> address to send the notify +messages to a port other than the default of 53. +<command>also-notify</command> is not meaningful for stub zones. +The default is the empty list.</para> +</listitem></varlistentry> + +<varlistentry><term><command>check-names</command></term> +<listitem><para> +This option is used to restrict the character set and syntax of +certain domain names in master files and/or DNS responses received from the +network. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>database</command></term> +<listitem><para>Specify the type of database to be used for storing the +zone data. The string following the <command>database</command> keyword +is interpreted as a list of whitespace-delimited words. The first word +identifies the database type, and any subsequent words are passed +as arguments to the database to be interpreted in a way specific +to the database type.</para> +<para>The default is <userinput>"rbt"</userinput>, BIND 9's native in-memory +red-black-tree database. This database does not take arguments.</para> +<para>Other values are possible if additional database drivers +have been linked into the server. Some sample drivers are included +with the distribution but none are linked in by default.</para> +</listitem></varlistentry> + +<varlistentry><term><command>dialup</command></term> +<listitem><para>See the description of +<command>dialup</command> in <xref linkend="boolean_options"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>delegation-only</command></term> +<listitem><para>The flag only applies to hint and stub zones. If set +to <userinput>yes</userinput> then the zone will also be treated as if it +is also a delegation-only type zone. +</para> +</listitem></varlistentry> + +<varlistentry><term><command>forward</command></term> +<listitem><para>Only meaningful if the zone has a forwarders +list. The <command>only</command> value causes the lookup to fail +after trying the forwarders and getting no answer, while <command>first</command> would +allow a normal lookup to be tried.</para> +</listitem></varlistentry> + +<varlistentry><term><command>forwarders</command></term> +<listitem><para>Used to override the list of global forwarders. +If it is not specified in a zone of type <command>forward</command>, +no forwarding is done for the zone; the global options are not used.</para> +</listitem></varlistentry> + +<varlistentry><term><command>ixfr-base</command></term> +<listitem><para>Was used in <acronym>BIND</acronym> 8 to specify the name +of the transaction log (journal) file for dynamic update and IXFR. +<acronym>BIND</acronym> 9 ignores the option and constructs the name of the journal +file by appending "<filename>.jnl</filename>" to the name of the +zone file.</para> +</listitem></varlistentry> + +<varlistentry><term><command>ixfr-tmp-file</command></term> +<listitem><para>Was an undocumented option in <acronym>BIND</acronym> 8. +Ignored in <acronym>BIND</acronym> 9.</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-transfer-time-in</command></term> +<listitem><para>See the description of +<command>max-transfer-time-in</command> in <xref linkend="zone_transfers"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-transfer-idle-in</command></term> +<listitem><para>See the description of +<command>max-transfer-idle-in</command> in <xref linkend="zone_transfers"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-transfer-time-out</command></term> +<listitem><para>See the description of +<command>max-transfer-time-out</command> in <xref linkend="zone_transfers"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>max-transfer-idle-out</command></term> +<listitem><para>See the description of +<command>max-transfer-idle-out</command> in <xref linkend="zone_transfers"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>notify</command></term> +<listitem><para>See the description of +<command>notify</command> in <xref linkend="boolean_options"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>pubkey</command></term> +<listitem><para>In <acronym>BIND</acronym> 8, this option was intended for specifying +a public zone key for verification of signatures in DNSSEC signed +zones when they are loaded from disk. <acronym>BIND</acronym> 9 does not verify signatures +on load and ignores the option.</para> +</listitem></varlistentry> + +<varlistentry><term><command>zone-statistics</command></term> +<listitem><para>If <userinput>yes</userinput>, the server will keep statistical +information for this zone, which can be dumped to the +<command>statistics-file</command> defined in the server options.</para> +</listitem></varlistentry> + +<varlistentry><term><command>sig-validity-interval</command></term> +<listitem><para>See the description of +<command>sig-validity-interval</command> in <xref linkend="tuning"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>transfer-source</command></term> +<listitem><para>See the description of +<command>transfer-source</command> in <xref linkend="zone_transfers"/> +</para> +</listitem></varlistentry> + +<varlistentry><term><command>transfer-source-v6</command></term> +<listitem><para>See the description of +<command>transfer-source-v6</command> in <xref linkend="zone_transfers"/> +</para> +</listitem></varlistentry> + +<varlistentry><term><command>alt-transfer-source</command></term> +<listitem><para>See the description of +<command>alt-transfer-source</command> in <xref linkend="zone_transfers"/> +</para> +</listitem></varlistentry> + +<varlistentry><term><command>alt-transfer-source-v6</command></term> +<listitem><para>See the description of +<command>alt-transfer-source-v6</command> in <xref linkend="zone_transfers"/> +</para> +</listitem></varlistentry> + +<varlistentry><term><command>use-alt-transfer-source</command></term> +<listitem><para>See the description of +<command>use-alt-transfer-source</command> in <xref linkend="zone_transfers"/> +</para> +</listitem></varlistentry> + + +<varlistentry><term><command>notify-source</command></term> +<listitem><para>See the description of +<command>notify-source</command> in <xref linkend="zone_transfers"/> +</para> +</listitem></varlistentry> + +<varlistentry><term><command>notify-source-v6</command></term> +<listitem><para>See the description of +<command>notify-source-v6</command> in <xref linkend="zone_transfers"/>. +</para> +</listitem></varlistentry> + +<varlistentry> +<term><command>min-refresh-time</command></term> +<term><command>max-refresh-time</command></term> +<term><command>min-retry-time</command></term> +<term><command>max-retry-time</command></term> +<listitem><para> +See the description in <xref linkend="tuning"/>. +</para></listitem></varlistentry> + +<varlistentry><term><command>ixfr-from-differences</command></term> +<listitem><para>See the description of +<command>ixfr-from-differences</command> in <xref linkend="boolean_options"/>.</para> +</listitem></varlistentry> + +<varlistentry><term><command>key-directory</command></term> +<listitem><para>See the description of +<command>key-directory</command> in <xref linkend="options"/></para> +</listitem></varlistentry> + +<varlistentry><term><command>multi-master</command></term> +<listitem><para>See the description of +<command>multi-master</command> in <xref linkend="boolean_options"/>.</para> +</listitem></varlistentry> + +</variablelist> + +</sect3> +<sect3 id="dynamic_update_policies"><title>Dynamic Update Policies</title> +<para><acronym>BIND</acronym> 9 supports two alternative methods of granting clients +the right to perform dynamic updates to a zone, +configured by the <command>allow-update</command> and +<command>update-policy</command> option, respectively.</para> +<para>The <command>allow-update</command> clause works the same +way as in previous versions of <acronym>BIND</acronym>. It grants given clients the +permission to update any record of any name in the zone.</para> +<para>The <command>update-policy</command> clause is new in <acronym>BIND</acronym> +9 and allows more fine-grained control over what updates are allowed. +A set of rules is specified, where each rule either grants or denies +permissions for one or more names to be updated by one or more identities. + If the dynamic update request message is signed (that is, it includes +either a TSIG or SIG(0) record), the identity of the signer can +be determined.</para> +<para>Rules are specified in the <command>update-policy</command> zone +option, and are only meaningful for master zones. When the <command>update-policy</command> statement +is present, it is a configuration error for the <command>allow-update</command> statement +to be present. The <command>update-policy</command> statement only +examines the signer of a message; the source address is not relevant.</para> +<para>This is how a rule definition looks:</para> +<programlisting> +( <command>grant</command> | <command>deny</command> ) <replaceable>identity</replaceable> <replaceable>nametype</replaceable> <replaceable>name</replaceable> <optional> <replaceable>types</replaceable> </optional> +</programlisting> +<para>Each rule grants or denies privileges. Once a message has +successfully matched a rule, the operation is immediately granted +or denied and no further rules are examined. A rule is matched +when the signer matches the identity field, the name matches the +name field in accordance with the nametype field, and the type matches +the types specified in the type field.</para> + +<para>The identity field specifies a name or a wildcard name. Normally, this +is the name of the TSIG or SIG(0) key used to sign the update request. When a +TKEY exchange has been used to create a shared secret, the identity of the +shared secret is the same as the identity of the key used to authenticate the +TKEY exchange. When the <replaceable>identity</replaceable> field specifies a +wildcard name, it is subject to DNS wildcard expansion, so the rule will apply +to multiple identities. The <replaceable>identity</replaceable> field must +contain a fully qualified domain name.</para> + +<para>The <replaceable>nametype</replaceable> field has 4 values: +<varname>name</varname>, <varname>subdomain</varname>, +<varname>wildcard</varname>, and <varname>self</varname>. +</para> +<informaltable> + <tgroup cols = "2" colsep = "0" + rowsep = "0" tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.819in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.681in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><varname>name</varname></para></entry> +<entry colname = "2"><para>Exact-match semantics. This rule matches when the +name being updated is identical to the contents of the +<replaceable>name</replaceable> field.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>subdomain</varname></para></entry> +<entry colname = "2"><para>This rule matches when the name being updated +is a subdomain of, or identical to, the contents of the +<replaceable>name</replaceable> field.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>wildcard</varname></para></entry> +<entry colname = "2"><para>The <replaceable>name</replaceable> field is +subject to DNS wildcard expansion, and this rule matches when the name +being updated name is a valid expansion of the wildcard.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><varname>self</varname></para></entry> +<entry colname = "2"><para>This rule matches when the name being updated +matches the contents of the <replaceable>identity</replaceable> field. +The <replaceable>name</replaceable> field is ignored, but should be +the same as the <replaceable>identity</replaceable> field. The +<varname>self</varname> nametype is most useful when allowing using +one key per name to update, where the key has the same name as the name +to be updated. The <replaceable>identity</replaceable> would be +specified as <constant>*</constant> in this case.</para></entry> +</row> +</tbody> +</tgroup></informaltable> + +<para>In all cases, the <replaceable>name</replaceable> field must +specify a fully qualified domain name.</para> + +<para>If no types are explicitly specified, this rule matches all types except +SIG, NS, SOA, and NXT. Types may be specified by name, including +"ANY" (ANY matches all types except NXT, which can never be updated). +Note that when an attempt is made to delete all records associated with a +name, the rules are checked for each existing record type. +</para> + </sect3> + </sect2> + </sect1> + <sect1> + <title>Zone File</title> + <sect2 id="types_of_resource_records_and_when_to_use_them"> + <title>Types of Resource Records and When to Use Them</title> +<para>This section, largely borrowed from RFC 1034, describes the +concept of a Resource Record (RR) and explains when each is used. +Since the publication of RFC 1034, several new RRs have been identified +and implemented in the DNS. These are also included.</para> + <sect3> + <title>Resource Records</title> + + <para>A domain name identifies a node. Each node has a set of + resource information, which may be empty. The set of resource + information associated with a particular name is composed of + separate RRs. The order of RRs in a set is not significant and + need not be preserved by name servers, resolvers, or other + parts of the DNS. However, sorting of multiple RRs is + permitted for optimization purposes, for example, to specify + that a particular nearby server be tried first. See <xref + linkend="the_sortlist_statement"/> and <xref + linkend="rrset_ordering"/>.</para> + +<para>The components of a Resource Record are:</para> +<informaltable colsep = "0" + rowsep = "0"><tgroup cols = "2" colsep = "0" + rowsep = "0" tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.000in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.500in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para>owner name</para></entry> +<entry colname = "2"><para>the domain name where the RR is found.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>type</para></entry> +<entry colname = "2"><para>an encoded 16 bit value that specifies +the type of the resource record.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>TTL</para></entry> +<entry colname = "2"><para>the time to live of the RR. This field +is a 32 bit integer in units of seconds, and is primarily used by +resolvers when they cache RRs. The TTL describes how long a RR can +be cached before it should be discarded.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>class</para></entry> +<entry colname = "2"><para>an encoded 16 bit value that identifies +a protocol family or instance of a protocol.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>RDATA</para></entry> +<entry colname = "2"><para>the resource data. The format of the +data is type (and sometimes class) specific.</para></entry> +</row> +</tbody> +</tgroup></informaltable> +<para>The following are <emphasis>types</emphasis> of valid RRs:</para> +<informaltable colsep = "0" + rowsep = "0"><tgroup cols = "2" colsep = "0" + rowsep = "0" tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.625in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para>A</para></entry> +<entry colname = "2"><para>a host address. In the IN class, this is a +32-bit IP address. Described in RFC 1035.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>AAAA</para></entry> +<entry colname = "2"><para>IPv6 address. Described in RFC 1886.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>A6</para></entry> +<entry colname = "2"><para>IPv6 address. This can be a partial +address (a suffix) and an indirection to the name where the rest of the +address (the prefix) can be found. Experimental. Described in RFC 2874.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>AFSDB</para></entry> +<entry colname = "2"><para>location of AFS database servers. +Experimental. Described in RFC 1183.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>APL</para></entry> +<entry colname = "2"><para>address prefix list. Experimental. +Described in RFC 3123.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>CERT</para></entry> +<entry colname = "2"><para>holds a digital certificate. +Described in RFC 2538.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>CNAME</para></entry> +<entry colname = "2"><para>identifies the canonical name of an alias. +Described in RFC 1035.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>DNAME</para></entry> +<entry colname = "2"><para>Replaces the domain name specified with +another name to be looked up, effectively aliasing an entire +subtree of the domain name space rather than a single record +as in the case of the CNAME RR. +Described in RFC 2672.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>GPOS</para></entry> +<entry colname = "2"><para>Specifies the global position. Superseded by LOC.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>HINFO</para></entry> +<entry colname = "2"><para>identifies the CPU and OS used by a host. +Described in RFC 1035.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>ISDN</para></entry> +<entry colname = "2"><para>representation of ISDN addresses. +Experimental. Described in RFC 1183.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>KEY</para></entry> +<entry colname = "2"><para>stores a public key associated with a +DNS name. Described in RFC 2535.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>KX</para></entry> +<entry colname = "2"><para>identifies a key exchanger for this +DNS name. Described in RFC 2230.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>LOC</para></entry> +<entry colname = "2"><para>for storing GPS info. Described in RFC 1876. +Experimental.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>MX</para></entry> +<entry colname = "2"><para>identifies a mail exchange for the domain. +a 16 bit preference value (lower is better) +followed by the host name of the mail exchange. +Described in RFC 974, RFC 1035.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>NAPTR</para></entry> +<entry colname = "2"><para>name authority pointer. Described in RFC 2915.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>NSAP</para></entry> +<entry colname = "2"><para>a network service access point. +Described in RFC 1706.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>NS</para></entry> +<entry colname = "2"><para>the authoritative name server for the +domain. Described in RFC 1035.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>NXT</para></entry> +<entry colname = "2"><para>used in DNSSEC to securely indicate that +RRs with an owner name in a certain name interval do not exist in +a zone and indicate what RR types are present for an existing name. +Described in RFC 2535.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>PTR</para></entry> +<entry colname = "2"><para>a pointer to another part of the domain +name space. Described in RFC 1035.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>PX</para></entry> +<entry colname = "2"><para>provides mappings between RFC 822 and X.400 +addresses. Described in RFC 2163.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>RP</para></entry> +<entry colname = "2"><para>information on persons responsible +for the domain. Experimental. Described in RFC 1183.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>RT</para></entry> +<entry colname = "2"><para>route-through binding for hosts that +do not have their own direct wide area network addresses. +Experimental. Described in RFC 1183.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>SIG</para></entry> +<entry colname = "2"><para>("signature") contains data authenticated +in the secure DNS. Described in RFC 2535.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>SOA</para></entry> +<entry colname = "2"><para>identifies the start of a zone of authority. +Described in RFC 1035.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>SRV</para></entry> +<entry colname = "2"><para>information about well known network +services (replaces WKS). Described in RFC 2782.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>TXT</para></entry> +<entry colname = "2"><para>text records. Described in RFC 1035.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>WKS</para></entry> +<entry colname = "2"><para>information about which well known +network services, such as SMTP, that a domain supports. Historical. +</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>X25</para></entry> +<entry colname = "2"><para>representation of X.25 network addresses. +Experimental. Described in RFC 1183.</para></entry> +</row> +</tbody> +</tgroup></informaltable> +<para>The following <emphasis>classes</emphasis> of resource records +are currently valid in the DNS:</para><informaltable colsep = "0" + rowsep = "0"><tgroup cols = "2" colsep = "0" rowsep = "0" + tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.625in"/> +<tbody> + +<row rowsep = "0"> +<entry colname = "1"><para>IN</para></entry> +<entry colname = "2"><para>The Internet.</para></entry> +</row> + +<row rowsep = "0"> +<entry colname = "1"><para>CH</para></entry> +<entry colname = "2"><para> +CHAOSnet, a LAN protocol created at MIT in the mid-1970s. +Rarely used for its historical purpose, but reused for BIND's +built-in server information zones, e.g., +<literal>version.bind</literal>. +</para></entry> +</row> + +<row rowsep = "0"> +<entry colname = "1"><para>HS</para></entry> +<entry colname = "2"><para> +Hesiod, an information service +developed by MIT's Project Athena. It is used to share information +about various systems databases, such as users, groups, printers +and so on. +</para></entry> +</row> + +</tbody> +</tgroup></informaltable> + +<para>The owner name is often implicit, rather than forming an integral +part of the RR. For example, many name servers internally form tree +or hash structures for the name space, and chain RRs off nodes. + The remaining RR parts are the fixed header (type, class, TTL) +which is consistent for all RRs, and a variable part (RDATA) that +fits the needs of the resource being described.</para> +<para>The meaning of the TTL field is a time limit on how long an +RR can be kept in a cache. This limit does not apply to authoritative +data in zones; it is also timed out, but by the refreshing policies +for the zone. The TTL is assigned by the administrator for the +zone where the data originates. While short TTLs can be used to +minimize caching, and a zero TTL prohibits caching, the realities +of Internet performance suggest that these times should be on the +order of days for the typical host. If a change can be anticipated, +the TTL can be reduced prior to the change to minimize inconsistency +during the change, and then increased back to its former value following +the change.</para> +<para>The data in the RDATA section of RRs is carried as a combination +of binary strings and domain names. The domain names are frequently +used as "pointers" to other data in the DNS.</para></sect3> +<sect3><title>Textual expression of RRs</title> +<para>RRs are represented in binary form in the packets of the DNS +protocol, and are usually represented in highly encoded form when +stored in a name server or resolver. In the examples provided in +RFC 1034, a style similar to that used in master files was employed +in order to show the contents of RRs. In this format, most RRs +are shown on a single line, although continuation lines are possible +using parentheses.</para> +<para>The start of the line gives the owner of the RR. If a line +begins with a blank, then the owner is assumed to be the same as +that of the previous RR. Blank lines are often included for readability.</para> +<para>Following the owner, we list the TTL, type, and class of the +RR. Class and type use the mnemonics defined above, and TTL is +an integer before the type field. In order to avoid ambiguity in +parsing, type and class mnemonics are disjoint, TTLs are integers, +and the type mnemonic is always last. The IN class and TTL values +are often omitted from examples in the interests of clarity.</para> +<para>The resource data or RDATA section of the RR are given using +knowledge of the typical representation for the data.</para> +<para>For example, we might show the RRs carried in a message as:</para> <informaltable + colsep = "0" rowsep = "0"><tgroup cols = "3" + colsep = "0" rowsep = "0" tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.381in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "1.020in"/> +<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "2.099in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><literal>ISI.EDU.</literal></para></entry> +<entry colname = "2"><para><literal>MX</literal></para></entry> +<entry colname = "3"><para><literal>10 VENERA.ISI.EDU.</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para><literal>MX</literal></para></entry> +<entry colname = "3"><para><literal>10 VAXA.ISI.EDU</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><literal>VENERA.ISI.EDU</literal></para></entry> +<entry colname = "2"><para><literal>A</literal></para></entry> +<entry colname = "3"><para><literal>128.9.0.32</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para><literal>A</literal></para></entry> +<entry colname = "3"><para><literal>10.1.0.52</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><literal>VAXA.ISI.EDU</literal></para></entry> +<entry colname = "2"><para><literal>A</literal></para></entry> +<entry colname = "3"><para><literal>10.2.0.27</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para><literal>A</literal></para></entry> +<entry colname = "3"><para><literal>128.9.0.33</literal></para></entry> +</row> +</tbody> +</tgroup></informaltable> +<para>The MX RRs have an RDATA section which consists of a 16 bit +number followed by a domain name. The address RRs use a standard +IP address format to contain a 32 bit internet address.</para> +<para>This example shows six RRs, with two RRs at each of three +domain names.</para> +<para>Similarly we might see:</para><informaltable colsep = "0" + rowsep = "0"><tgroup cols = "3" colsep = "0" rowsep = "0" + tgroupstyle = "4Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.491in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "1.067in"/> +<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "2.067in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><literal>XX.LCS.MIT.EDU. IN</literal></para></entry> +<entry colname = "2"><para><literal>A</literal></para></entry> +<entry colname = "3"><para><literal>10.0.0.44</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><literal>CH</literal></para></entry> +<entry colname = "2"><para><literal>A</literal></para></entry> +<entry colname = "3"><para><literal>MIT.EDU. 2420</literal></para></entry> +</row> +</tbody> +</tgroup></informaltable> +<para>This example shows two addresses for <literal>XX.LCS.MIT.EDU</literal>, +each of a different class.</para></sect3></sect2> + +<sect2><title>Discussion of MX Records</title> + +<para>As described above, domain servers store information as a +series of resource records, each of which contains a particular +piece of information about a given domain name (which is usually, +but not always, a host). The simplest way to think of a RR is as +a typed pair of data, a domain name matched with a relevant datum, +and stored with some additional type information to help systems +determine when the RR is relevant.</para> + +<para>MX records are used to control delivery of email. The data +specified in the record is a priority and a domain name. The priority +controls the order in which email delivery is attempted, with the +lowest number first. If two priorities are the same, a server is +chosen randomly. If no servers at a given priority are responding, +the mail transport agent will fall back to the next largest priority. +Priority numbers do not have any absolute meaning — they are relevant +only respective to other MX records for that domain name. The domain +name given is the machine to which the mail will be delivered. It <emphasis>must</emphasis> have +an associated A record — CNAME is not sufficient.</para> +<para>For a given domain, if there is both a CNAME record and an +MX record, the MX record is in error, and will be ignored. Instead, +the mail will be delivered to the server specified in the MX record +pointed to by the CNAME.</para> +<informaltable colsep = "0" rowsep = "0"><tgroup cols = "5" + colsep = "0" rowsep = "0" tgroupstyle = "3Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.708in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.444in"/> +<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "0.444in"/> +<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "0.976in"/> +<colspec colname = "5" colnum = "5" colsep = "0" colwidth = "1.553in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><literal>example.com.</literal></para></entry> +<entry colname = "2"><para><literal>IN</literal></para></entry> +<entry colname = "3"><para><literal>MX</literal></para></entry> +<entry colname = "4"><para><literal>10</literal></para></entry> +<entry colname = "5"><para><literal>mail.example.com.</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para><literal>IN</literal></para></entry> +<entry colname = "3"><para><literal>MX</literal></para></entry> +<entry colname = "4"><para><literal>10</literal></para></entry> +<entry colname = "5"><para><literal>mail2.example.com.</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para><literal>IN</literal></para></entry> +<entry colname = "3"><para><literal>MX</literal></para></entry> +<entry colname = "4"><para><literal>20</literal></para></entry> +<entry colname = "5"><para><literal>mail.backup.org.</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><literal>mail.example.com.</literal></para></entry> +<entry colname = "2"><para><literal>IN</literal></para></entry> +<entry colname = "3"><para><literal>A</literal></para></entry> +<entry colname = "4"><para><literal>10.0.0.1</literal></para></entry> +<entry colname = "5"><para></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><literal>mail2.example.com.</literal></para></entry> +<entry colname = "2"><para><literal>IN</literal></para></entry> +<entry colname = "3"><para><literal>A</literal></para></entry> +<entry colname = "4"><para><literal>10.0.0.2</literal></para></entry> +<entry colname = "5"><para></para></entry> +</row> +</tbody> +</tgroup></informaltable><para>For example:</para> +<para>Mail delivery will be attempted to <literal>mail.example.com</literal> and +<literal>mail2.example.com</literal> (in +any order), and if neither of those succeed, delivery to <literal>mail.backup.org</literal> will +be attempted.</para></sect2> +<sect2 id="Setting_TTLs"><title>Setting TTLs</title> +<para>The time to live of the RR field is a 32 bit integer represented +in units of seconds, and is primarily used by resolvers when they +cache RRs. The TTL describes how long a RR can be cached before it +should be discarded. The following three types of TTL are currently +used in a zone file.</para> +<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2" + colsep = "0" rowsep = "0" tgroupstyle = "3Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.750in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.375in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para>SOA</para></entry> +<entry colname = "2"><para>The last field in the SOA is the negative +caching TTL. This controls how long other servers will cache no-such-domain +(NXDOMAIN) responses from you.</para><para>The maximum time for +negative caching is 3 hours (3h).</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>$TTL</para></entry> +<entry colname = "2"><para>The $TTL directive at the top of the +zone file (before the SOA) gives a default TTL for every RR without +a specific TTL set.</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>RR TTLs</para></entry> +<entry colname = "2"><para>Each RR can have a TTL as the second +field in the RR, which will control how long other servers can cache +the it.</para></entry> +</row> +</tbody> +</tgroup></informaltable> +<para>All of these TTLs default to units of seconds, though units +can be explicitly specified, for example, <literal>1h30m</literal>. </para></sect2> +<sect2><title>Inverse Mapping in IPv4</title> +<para>Reverse name resolution (that is, translation from IP address +to name) is achieved by means of the <emphasis>in-addr.arpa</emphasis> domain +and PTR records. Entries in the in-addr.arpa domain are made in +least-to-most significant order, read left to right. This is the +opposite order to the way IP addresses are usually written. Thus, +a machine with an IP address of 10.1.2.3 would have a corresponding +in-addr.arpa name of +3.2.1.10.in-addr.arpa. This name should have a PTR resource record +whose data field is the name of the machine or, optionally, multiple +PTR records if the machine has more than one name. For example, +in the <optional>example.com</optional> domain:</para> +<informaltable colsep = "0" rowsep = "0"> +<tgroup cols = "2" colsep = "0" rowsep = "0" + tgroupstyle = "3Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.125in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.000in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para><literal>$ORIGIN</literal></para></entry> +<entry colname = "2"><para><literal>2.1.10.in-addr.arpa</literal></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para><literal>3</literal></para></entry> +<entry colname = "2"><para><literal>IN PTR foo.example.com.</literal></para></entry> +</row> +</tbody> +</tgroup></informaltable> + <note> +<para>The <command>$ORIGIN</command> lines in the examples +are for providing context to the examples only-they do not necessarily +appear in the actual usage. They are only used here to indicate +that the example is relative to the listed origin.</para></note></sect2> +<sect2><title>Other Zone File Directives</title> +<para>The Master File Format was initially defined in RFC 1035 and +has subsequently been extended. While the Master File Format itself +is class independent all records in a Master File must be of the same +class.</para> +<para>Master File Directives include <command>$ORIGIN</command>, <command>$INCLUDE</command>, +and <command>$TTL.</command></para> +<sect3><title>The <command>$ORIGIN</command> Directive</title> +<para>Syntax: <command>$ORIGIN +</command><replaceable>domain-name</replaceable> <optional> <replaceable>comment</replaceable></optional></para> +<para><command>$ORIGIN</command> sets the domain name that will +be appended to any unqualified records. When a zone is first read +in there is an implicit <command>$ORIGIN</command> <<varname>zone-name</varname>><command>.</command> The +current <command>$ORIGIN</command> is appended to the domain specified +in the <command>$ORIGIN</command> argument if it is not absolute.</para> +<programlisting><literal>$ORIGIN example.com. +WWW CNAME MAIN-SERVER</literal></programlisting> +<para>is equivalent to</para> +<programlisting><literal>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</literal></programlisting></sect3> +<sect3><title>The <command>$INCLUDE</command> Directive</title> +<para>Syntax: <command>$INCLUDE</command> +<replaceable>filename</replaceable> <optional> +<replaceable>origin</replaceable> </optional> <optional> <replaceable>comment</replaceable> </optional></para> +<para>Read and process the file <filename>filename</filename> as +if it were included into the file at this point. If <command>origin</command> is +specified the file is processed with <command>$ORIGIN</command> set +to that value, otherwise the current <command>$ORIGIN</command> is +used.</para> +<para>The origin and the current domain name +revert to the values they had prior to the <command>$INCLUDE</command> once +the file has been read.</para> +<note><para> +RFC 1035 specifies that the current origin should be restored after +an <command>$INCLUDE</command>, but it is silent on whether the current +domain name should also be restored. BIND 9 restores both of them. +This could be construed as a deviation from RFC 1035, a feature, or both. +</para></note> +</sect3> +<sect3><title>The <command>$TTL</command> Directive</title> +<para>Syntax: <command>$TTL</command> +<replaceable>default-ttl</replaceable> <optional> +<replaceable>comment</replaceable> </optional></para> +<para>Set the default Time To Live (TTL) for subsequent records +with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.</para> +<para><command>$TTL</command> is defined in RFC 2308.</para></sect3></sect2> +<sect2><title><acronym>BIND</acronym> Master File Extension: the <command>$GENERATE</command> Directive</title> + <para>Syntax: <command>$GENERATE</command> <replaceable>range</replaceable> <replaceable>lhs</replaceable> <optional><replaceable>ttl</replaceable></optional> <optional><replaceable>class</replaceable></optional> <replaceable>type</replaceable> <replaceable>rhs</replaceable> <optional> <replaceable>comment</replaceable> </optional></para> +<para><command>$GENERATE</command> is used to create a series of +resource records that only differ from each other by an iterator. <command>$GENERATE</command> can +be used to easily generate the sets of records required to support +sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA +delegation.</para> +<programlisting><literal>$ORIGIN 0.0.192.IN-ADDR.ARPA. +$GENERATE 1-2 0 NS SERVER$.EXAMPLE. +$GENERATE 1-127 $ CNAME $.0</literal></programlisting> +<para>is equivalent to</para> +<programlisting><literal>0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE. +0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE. +1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA. +2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA. +... +127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA. +</literal></programlisting> + <informaltable colsep = "0" rowsep = "0"> + <tgroup cols = "2" colsep = "0" rowsep = "0" tgroupstyle = "3Level-table"> + <colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/> + <colspec colname = "2" colnum = "2" colsep = "0" colwidth = "4.250in"/> + <tbody> + <row rowsep = "0"> + <entry colname = "1"><para><command>range</command></para></entry> + <entry colname = "2"><para>This can be one of two forms: start-stop +or start-stop/step. If the first form is used then step is set to + 1. All of start, stop and step must be positive.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>lhs</command></para></entry> + <entry colname = "2"><para><command>lhs</command> describes the +owner name of the resource records to be created. Any single <command>$</command> symbols +within the <command>lhs</command> side are replaced by the iterator +value. +To get a $ in the output you need to escape the <command>$</command> +using a backslash <command>\</command>, +e.g. <command>\$</command>. The <command>$</command> may optionally be followed +by modifiers which change the offset from the iterator, field width and base. +Modifiers are introduced by a <command>{</command> immediately following the +<command>$</command> as <command>${offset[,width[,base]]}</command>. +e.g. <command>${-20,3,d}</command> which subtracts 20 from the current value, +prints the result as a decimal in a zero padded field of with 3. Available +output forms are decimal (<command>d</command>), octal (<command>o</command>) +and hexadecimal (<command>x</command> or <command>X</command> for uppercase). +The default modifier is <command>${0,0,d}</command>. +If the <command>lhs</command> is not +absolute, the current <command>$ORIGIN</command> is appended to +the name.</para> +<para>For compatibility with earlier versions <command>$$</command> is still +recognized a indicating a literal $ in the output.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>ttl</command></para></entry> + <entry colname = "2"><para><command>ttl</command> specifies the + ttl of the generated records. If not specified this will be + inherited using the normal ttl inheritance rules.</para> + <para><command>class</command> and <command>ttl</command> can be + entered in either order.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>class</command></para></entry> + <entry colname = "2"><para><command>class</command> specifies the + class of the generated records. This must match the zone class if + it is specified.</para> + <para><command>class</command> and <command>ttl</command> can be + entered in either order.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>type</command></para></entry> + <entry colname = "2"><para>At present the only supported types are +PTR, CNAME, DNAME, A, AAAA and NS.</para></entry> + </row> + <row rowsep = "0"> + <entry colname = "1"><para><command>rhs</command></para></entry> + <entry colname = "2"><para>rhs is a domain name. It is processed +similarly to lhs.</para></entry> + </row> + </tbody> + </tgroup></informaltable> + <para>The <command>$GENERATE</command> directive is a <acronym>BIND</acronym> extension +and not part of the standard zone file format.</para> + <para>BIND 8 does not support the optional TTL and CLASS fields.</para> + </sect2> + </sect1> +</chapter> +<chapter id="ch07"><title><acronym>BIND</acronym> 9 Security Considerations</title> +<sect1 id="Access_Control_Lists"><title>Access Control Lists</title> +<para>Access Control Lists (ACLs), are address match lists that +you can set up and nickname for future use in <command>allow-notify</command>, +<command>allow-query</command>, <command>allow-recursion</command>, +<command>blackhole</command>, <command>allow-transfer</command>, +etc.</para> +<para>Using ACLs allows you to have finer control over who can access +your name server, without cluttering up your config files with huge +lists of IP addresses.</para> +<para>It is a <emphasis>good idea</emphasis> to use ACLs, and to +control access to your server. Limiting access to your server by +outside parties can help prevent spoofing and DoS attacks against +your server.</para> +<para>Here is an example of how to properly apply ACLs:</para> +<programlisting> +// Set up an ACL named "bogusnets" that will block RFC1918 space, +// which is commonly used in spoofing attacks. +acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; +// Set up an ACL called our-nets. Replace this with the real IP numbers. +acl our-nets { x.x.x.x/24; x.x.x.x/21; }; +options { + ... + ... + allow-query { our-nets; }; + allow-recursion { our-nets; }; + ... + blackhole { bogusnets; }; + ... +}; +zone "example.com" { + type master; + file "m/example.com"; + allow-query { any; }; +}; +</programlisting> +<para>This allows recursive queries of the server from the outside +unless recursion has been previously disabled.</para> +<para>For more information on how to use ACLs to protect your server, +see the <emphasis>AUSCERT</emphasis> advisory at +<ulink url="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos">ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</ulink></para></sect1> +<sect1><title><command>chroot</command> and <command>setuid</command> (for +UNIX servers)</title> +<para>On UNIX servers, it is possible to run <acronym>BIND</acronym> in a <emphasis>chrooted</emphasis> environment +(<command>chroot()</command>) by specifying the "<option>-t</option>" +option. This can help improve system security by placing <acronym>BIND</acronym> in +a "sandbox", which will limit the damage done if a server is compromised.</para> +<para>Another useful feature in the UNIX version of <acronym>BIND</acronym> is the +ability to run the daemon as an unprivileged user ( <option>-u</option> <replaceable>user</replaceable> ). +We suggest running as an unprivileged user when using the <command>chroot</command> feature.</para> +<para>Here is an example command line to load <acronym>BIND</acronym> in a <command>chroot()</command> sandbox, +<command>/var/named</command>, and to run <command>named</command> <command>setuid</command> to +user 202:</para> +<para><userinput>/usr/local/bin/named -u 202 -t /var/named</userinput></para> + +<sect2><title>The <command>chroot</command> Environment</title> + +<para>In order for a <command>chroot()</command> environment to +work properly in a particular directory +(for example, <filename>/var/named</filename>), +you will need to set up an environment that includes everything +<acronym>BIND</acronym> needs to run. +From <acronym>BIND</acronym>'s point of view, <filename>/var/named</filename> is +the root of the filesystem. You will need to adjust the values of options like +like <command>directory</command> and <command>pid-file</command> to account +for this. +</para> +<para> +Unlike with earlier versions of BIND, you will typically +<emphasis>not</emphasis> need to compile <command>named</command> +statically nor install shared libraries under the new root. +However, depending on your operating system, you may need +to set up things like +<filename>/dev/zero</filename>, +<filename>/dev/random</filename>, +<filename>/dev/log</filename>, and/or +<filename>/etc/localtime</filename>. +</para> +</sect2> + +<sect2><title>Using the <command>setuid</command> Function</title> + +<para>Prior to running the <command>named</command> daemon, use +the <command>touch</command> utility (to change file access and +modification times) or the <command>chown</command> utility (to +set the user id and/or group id) on files +to which you want <acronym>BIND</acronym> +to write. Note that if the <command>named</command> daemon is running as an +unprivileged user, it will not be able to bind to new restricted ports if the +server is reloaded.</para> +</sect2> +</sect1> + +<sect1 id="dynamic_update_security"><title>Dynamic Update Security</title> + +<para>Access to the dynamic +update facility should be strictly limited. In earlier versions of +<acronym>BIND</acronym> the only way to do this was based on the IP +address of the host requesting the update, by listing an IP address or +network prefix in the <command>allow-update</command> zone option. +This method is insecure since the source address of the update UDP packet +is easily forged. Also note that if the IP addresses allowed by the +<command>allow-update</command> option include the address of a slave +server which performs forwarding of dynamic updates, the master can be +trivially attacked by sending the update to the slave, which will +forward it to the master with its own source IP address causing the +master to approve it without question.</para> + +<para>For these reasons, we strongly recommend that updates be +cryptographically authenticated by means of transaction signatures +(TSIG). That is, the <command>allow-update</command> option should +list only TSIG key names, not IP addresses or network +prefixes. Alternatively, the new <command>update-policy</command> +option can be used.</para> + +<para>Some sites choose to keep all dynamically updated DNS data +in a subdomain and delegate that subdomain to a separate zone. This +way, the top-level zone containing critical data such as the IP addresses +of public web and mail servers need not allow dynamic update at +all.</para> + +</sect1></chapter> + +<chapter id="ch08"> + <title>Troubleshooting</title> + <sect1> + <title>Common Problems</title> + <sect2> + <title>It's not working; how can I figure out what's wrong?</title> + + <para>The best solution to solving installation and + configuration issues is to take preventative measures by setting + up logging files beforehand. The log files provide a + source of hints and information that can be used to figure out + what went wrong and how to fix the problem.</para> + + </sect2> + </sect1> + <sect1> + <title>Incrementing and Changing the Serial Number</title> + + <para>Zone serial numbers are just numbers-they aren't date + related. A lot of people set them to a number that represents a + date, usually of the form YYYYMMDDRR. A number of people have been + testing these numbers for Y2K compliance and have set the number + to the year 2000 to see if it will work. They then try to restore + the old serial number. This will cause problems because serial + numbers are used to indicate that a zone has been updated. If the + serial number on the slave server is lower than the serial number + on the master, the slave server will attempt to update its copy of + the zone.</para> + + <para>Setting the serial number to a lower number on the master + server than the slave server means that the slave will not perform + updates to its copy of the zone.</para> + + <para>The solution to this is to add 2147483647 (2^31-1) to the + number, reload the zone and make sure all slaves have updated to + the new zone serial number, then reset the number to what you want + it to be, and reload the zone again.</para> + + </sect1> + <sect1> + <title>Where Can I Get Help?</title> + + <para>The Internet Software Consortium (<acronym>ISC</acronym>) offers a wide range + of support and service agreements for <acronym>BIND</acronym> and <acronym>DHCP</acronym> servers. Four + levels of premium support are available and each level includes + support for all <acronym>ISC</acronym> programs, significant discounts on products + and training, and a recognized priority on bug fixes and + non-funded feature requests. In addition, <acronym>ISC</acronym> offers a standard + support agreement package which includes services ranging from bug + fix announcements to remote support. It also includes training in + <acronym>BIND</acronym> and <acronym>DHCP</acronym>.</para> + + <para>To discuss arrangements for support, contact + <ulink url="mailto:info@isc.org">info@isc.org</ulink> or visit the + <acronym>ISC</acronym> web page at <ulink + url="http://www.isc.org/services/support/">http://www.isc.org/services/support/</ulink> + to read more.</para> + </sect1> +</chapter> +<appendix id="ch09"> + <title>Appendices</title> + <sect1> + <title>Acknowledgments</title> + <sect2> + <title>A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym></title> + + <para>Although the "official" beginning of the Domain Name + System occurred in 1984 with the publication of RFC 920, the + core of the new system was described in 1983 in RFCs 882 and + 883. From 1984 to 1987, the ARPAnet (the precursor to today's + Internet) became a testbed of experimentation for developing the + new naming/addressing scheme in an rapidly expanding, + operational network environment. New RFCs were written and + published in 1987 that modified the original documents to + incorporate improvements based on the working model. RFC 1034, + "Domain Names-Concepts and Facilities", and RFC 1035, "Domain + Names-Implementation and Specification" were published and + became the standards upon which all <acronym>DNS</acronym> implementations are + built. +</para> + + <para>The first working domain name server, called "Jeeves", was +written in 1983-84 by Paul Mockapetris for operation on DEC Tops-20 +machines located at the University of Southern California's Information +Sciences Institute (USC-ISI) and SRI International's Network Information +Center (SRI-NIC). A <acronym>DNS</acronym> server for Unix machines, the Berkeley Internet +Name Domain (<acronym>BIND</acronym>) package, was written soon after by a group of +graduate students at the University of California at Berkeley under +a grant from the US Defense Advanced Research Projects Administration +(DARPA). Versions of <acronym>BIND</acronym> through 4.8.3 were maintained by the Computer +Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark +Painter, David Riggle and Songnian Zhou made up the initial <acronym>BIND</acronym> +project team. After that, additional work on the software package +was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation +employee on loan to the CSRG, worked on <acronym>BIND</acronym> for 2 years, from 1985 +to 1987. Many other people also contributed to <acronym>BIND</acronym> development +during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, +Mike Muuss, Jim Bloom and Mike Schwartz. <acronym>BIND</acronym> maintenance was subsequently +handled by Mike Karels and O. Kure.</para> + <para><acronym>BIND</acronym> versions 4.9 and 4.9.1 were released by Digital Equipment +Corporation (now Compaq Computer Corporation). Paul Vixie, then +a DEC employee, became <acronym>BIND</acronym>'s primary caretaker. Paul was assisted +by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew +Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat +Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe +Wolfhugel, and others.</para> + <para><acronym>BIND</acronym> Version 4.9.2 was sponsored by Vixie Enterprises. Paul +Vixie became <acronym>BIND</acronym>'s principal architect/programmer.</para> + <para><acronym>BIND</acronym> versions from 4.9.3 onward have been developed and maintained +by the Internet Software Consortium with support being provided +by ISC's sponsors. As co-architects/programmers, Bob Halley and +Paul Vixie released the first production-ready version of <acronym>BIND</acronym> version +8 in May 1997.</para> + <para><acronym>BIND</acronym> development work is made possible today by the sponsorship +of several corporations, and by the tireless work efforts of numerous +individuals.</para> + </sect2> + </sect1> +<sect1 id="historical_dns_information"> + +<title>General <acronym>DNS</acronym> Reference Information</title> + <sect2 id="ipv6addresses"> + <title>IPv6 addresses (AAAA)</title> + <para>IPv6 addresses are 128-bit identifiers for interfaces and +sets of interfaces which were introduced in the <acronym>DNS</acronym> to facilitate +scalable Internet routing. There are three types of addresses: <emphasis>Unicast</emphasis>, +an identifier for a single interface; <emphasis>Anycast</emphasis>, +an identifier for a set of interfaces; and <emphasis>Multicast</emphasis>, +an identifier for a set of interfaces. Here we describe the global +Unicast address scheme. For more information, see RFC 2374.</para> +<para>The aggregatable global Unicast address format is as follows:</para> +<informaltable colsep = "0" rowsep = "0"><tgroup cols = "6" + colsep = "0" rowsep = "0" tgroupstyle = "1Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.477in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.501in"/> +<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "0.523in"/> +<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "0.731in"/> +<colspec colname = "5" colnum = "5" colsep = "0" colwidth = "1.339in"/> +<colspec colname = "6" colnum = "6" colsep = "0" colwidth = "2.529in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1" colsep = "1" rowsep = "1"><para>3</para></entry> +<entry colname = "2" colsep = "1" rowsep = "1"><para>13</para></entry> +<entry colname = "3" colsep = "1" rowsep = "1"><para>8</para></entry> +<entry colname = "4" colsep = "1" rowsep = "1"><para>24</para></entry> +<entry colname = "5" colsep = "1" rowsep = "1"><para>16</para></entry> +<entry colname = "6" rowsep = "1"><para>64 bits</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1" colsep = "1"><para>FP</para></entry> +<entry colname = "2" colsep = "1"><para>TLA ID</para></entry> +<entry colname = "3" colsep = "1"><para>RES</para></entry> +<entry colname = "4" colsep = "1"><para>NLA ID</para></entry> +<entry colname = "5" colsep = "1"><para>SLA ID</para></entry> +<entry colname = "6"><para>Interface ID</para></entry> +</row> +<row rowsep = "0"> +<entry nameend = "4" namest = "1"><para><------ Public Topology +------></para></entry> +<entry colname = "5"><para></para></entry> +<entry colname = "6"><para></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para></para></entry> +<entry colname = "3"><para></para></entry> +<entry colname = "4"><para></para></entry> +<entry colname = "5"><para><-Site Topology-></para></entry> +<entry colname = "6"><para></para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para></para></entry> +<entry colname = "2"><para></para></entry> +<entry colname = "3"><para></para></entry> +<entry colname = "4"><para></para></entry> +<entry colname = "5"><para></para></entry> +<entry colname = "6"><para><------ Interface Identifier ------></para></entry> +</row> +</tbody> +</tgroup></informaltable> + <para>Where +<informaltable colsep = "0" rowsep = "0"><tgroup + cols = "3" colsep = "0" rowsep = "0" tgroupstyle = "2Level-table"> +<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "1.375in"/> +<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.250in"/> +<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "3.500in"/> +<tbody> +<row rowsep = "0"> +<entry colname = "1"><para>FP</para></entry> +<entry colname = "2"><para>=</para></entry> +<entry colname = "3"><para>Format Prefix (001)</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>TLA ID</para></entry> +<entry colname = "2"><para>=</para></entry> +<entry colname = "3"><para>Top-Level Aggregation Identifier</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>RES</para></entry> +<entry colname = "2"><para>=</para></entry> +<entry colname = "3"><para>Reserved for future use</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>NLA ID</para></entry> +<entry colname = "2"><para>=</para></entry> +<entry colname = "3"><para>Next-Level Aggregation Identifier</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>SLA ID</para></entry> +<entry colname = "2"><para>=</para></entry> +<entry colname = "3"><para>Site-Level Aggregation Identifier</para></entry> +</row> +<row rowsep = "0"> +<entry colname = "1"><para>INTERFACE ID</para></entry> +<entry colname = "2"><para>=</para></entry> +<entry colname = "3"><para>Interface Identifier</para></entry> +</row> +</tbody> +</tgroup></informaltable></para> + <para>The <emphasis>Public Topology</emphasis> is provided by the +upstream provider or ISP, and (roughly) corresponds to the IPv4 <emphasis>network</emphasis> section +of the address range. The <emphasis>Site Topology</emphasis> is +where you can subnet this space, much the same as subnetting an +IPv4 /16 network into /24 subnets. The <emphasis>Interface Identifier</emphasis> is +the address of an individual interface on a given network. (With +IPv6, addresses belong to interfaces rather than machines.)</para> + <para>The subnetting capability of IPv6 is much more flexible than +that of IPv4: subnetting can now be carried out on bit boundaries, +in much the same way as Classless InterDomain Routing (CIDR).</para> +<para>The Interface Identifier must be unique on that network. On +ethernet networks, one way to ensure this is to set the address +to the first three bytes of the hardware address, "FFFE", then the +last three bytes of the hardware address. The lowest significant +bit of the first byte should then be complemented. Addresses are +written as 32-bit blocks separated with a colon, and leading zeros +of a block may be omitted, for example:</para> +<para><command>2001:db8:201:9:a00:20ff:fe81:2b32</command></para> +<para>IPv6 address specifications are likely to contain long strings +of zeros, so the architects have included a shorthand for specifying +them. The double colon (`::') indicates the longest possible string +of zeros that can fit, and can be used only once in an address.</para> + </sect2> + </sect1> + <sect1 id="bibliography"> + <title>Bibliography (and Suggested Reading)</title> + <sect2 id="rfcs"> + <title>Request for Comments (RFCs)</title> + <para>Specification documents for the Internet protocol suite, including +the <acronym>DNS</acronym>, are published as part of the Request for Comments (RFCs) +series of technical notes. The standards themselves are defined +by the Internet Engineering Task Force (IETF) and the Internet Engineering +Steering Group (IESG). RFCs can be obtained online via FTP at +<ulink url="ftp://www.isi.edu/in-notes/">ftp://www.isi.edu/in-notes/RFC<replaceable>xxx</replaceable>.txt</ulink> (where <replaceable>xxx</replaceable> is +the number of the RFC). RFCs are also available via the Web at +<ulink url="http://www.ietf.org/rfc/">http://www.ietf.org/rfc/</ulink>. +</para> + <bibliography> + <bibliodiv> + <!-- one of (BIBLIOENTRY BIBLIOMIXED) --> + <title>Standards</title> + <biblioentry> + <abbrev>RFC974</abbrev> + <author> + <surname>Partridge</surname> + <firstname>C.</firstname> + </author> + <title>Mail Routing and the Domain System</title> + <pubdate>January 1986</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1034</abbrev> + <author> + <surname>Mockapetris</surname> + <firstname>P.V.</firstname> + </author> + <title>Domain Names — Concepts and Facilities</title> + <pubdate>November 1987</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1035</abbrev> + <author> + <surname>Mockapetris</surname> + <firstname>P. V.</firstname> + </author> <title>Domain Names — Implementation and +Specification</title> + <pubdate>November 1987</pubdate> + </biblioentry> + </bibliodiv> + <bibliodiv id="proposed_standards" xreflabel="Proposed Standards"> + + <title>Proposed Standards</title> + <!-- one of (BIBLIOENTRY BIBLIOMIXED) --> + <biblioentry> + <abbrev>RFC2181</abbrev> + <author> + <surname>Elz</surname> + <firstname>R., R. Bush</firstname> + </author> + <title>Clarifications to the <acronym>DNS</acronym> Specification</title> + <pubdate>July 1997</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2308</abbrev> + <author> + <surname>Andrews</surname> + <firstname>M.</firstname> + </author> + <title>Negative Caching of <acronym>DNS</acronym> Queries</title> + <pubdate>March 1998</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1995</abbrev> + <author> + <surname>Ohta</surname> + <firstname>M.</firstname> + </author> + <title>Incremental Zone Transfer in <acronym>DNS</acronym></title> + <pubdate>August 1996</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1996</abbrev> + <author> + <surname>Vixie</surname> + <firstname>P.</firstname> + </author> + <title>A Mechanism for Prompt Notification of Zone Changes</title> + <pubdate>August 1996</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2136</abbrev> + <authorgroup> + <author> + <surname>Vixie</surname> + <firstname>P.</firstname> + </author> + <author> + <firstname>S.</firstname> + <surname>Thomson</surname> + </author> + <author> + <firstname>Y.</firstname> + <surname>Rekhter</surname> + </author> + <author> + <firstname>J.</firstname> + <surname>Bound</surname> + </author> + </authorgroup> + <title>Dynamic Updates in the Domain Name System</title> + <pubdate>April 1997</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2845</abbrev> + <authorgroup> + <author> + <surname>Vixie</surname> + <firstname>P.</firstname> + </author> + <author> + <firstname>O.</firstname> + <surname>Gudmundsson</surname> + </author> + <author> + <firstname>D.</firstname> + <surname>Eastlake</surname> + <lineage>3rd</lineage></author> + <author> + <firstname>B.</firstname> + <surname>Wellington</surname> + </author></authorgroup> + <title>Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG)</title> + <pubdate>May 2000</pubdate> + </biblioentry> + </bibliodiv> + <bibliodiv> + <title>Proposed Standards Still Under Development</title> + <note> + <para><emphasis>Note:</emphasis> the following list of +RFCs are undergoing major revision by the IETF.</para> + </note> + <biblioentry> + <abbrev>RFC1886</abbrev> + <authorgroup> + <author> + <surname>Thomson</surname> + <firstname>S.</firstname> + </author> + <author> + <firstname>C.</firstname> + <surname>Huitema</surname> + </author> + </authorgroup> + <title><acronym>DNS</acronym> Extensions to support IP version 6</title> + <pubdate>December 1995</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2065</abbrev> + <authorgroup> + <author> + <surname>Eastlake</surname> + <lineage>3rd</lineage> + <firstname>D.</firstname> + </author> + <author> + <firstname>C.</firstname> + <surname>Kaufman</surname> + </author> + </authorgroup> + <title>Domain Name System Security Extensions</title> + <pubdate>January 1997</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2137</abbrev> + <author> + <surname>Eastlake</surname> + <lineage>3rd</lineage> + <firstname>D.</firstname> + </author> + <title>Secure Domain Name System Dynamic Update</title> + <pubdate>April 1997</pubdate> + </biblioentry> + </bibliodiv> + <bibliodiv> + <title>Other Important RFCs About <acronym>DNS</acronym> Implementation</title> + <biblioentry> + <abbrev>RFC1535</abbrev> + <author> + <surname>Gavron</surname> + <firstname>E.</firstname> + </author> + <title>A Security Problem and Proposed Correction With Widely Deployed <acronym>DNS</acronym> Software.</title> + <pubdate>October 1993</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1536</abbrev> + <authorgroup> + <author> + <surname>Kumar</surname> + <firstname>A.</firstname> + </author> + <author> + <firstname>J.</firstname> + <surname>Postel</surname> + </author> + <author> + <firstname>C.</firstname> + <surname>Neuman</surname></author> + <author> + <firstname>P.</firstname> + <surname>Danzig</surname> + </author> + <author> + <firstname>S.</firstname> + <surname>Miller</surname> + </author> + </authorgroup> + <title>Common <acronym>DNS</acronym> Implementation Errors and Suggested Fixes</title> + <pubdate>October 1993</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1982</abbrev> + <authorgroup> + <author> + <surname>Elz</surname> + <firstname>R.</firstname> + </author> + <author> + <firstname>R.</firstname> + <surname>Bush</surname> + </author> + </authorgroup> + <title>Serial Number Arithmetic</title> + <pubdate>August 1996</pubdate> + </biblioentry> + </bibliodiv> + <bibliodiv> + <title>Resource Record Types</title> + <biblioentry> + <abbrev>RFC1183</abbrev> + <authorgroup> + <author> + <surname>Everhart</surname> + <firstname>C.F.</firstname> + </author> + <author> + <firstname>L. A.</firstname> + <surname>Mamakos</surname> + </author> + <author> + <firstname>R.</firstname> + <surname>Ullmann</surname> + </author> + <author> + <firstname>P.</firstname> + <surname>Mockapetris</surname> + </author> + </authorgroup> + <title>New <acronym>DNS</acronym> RR Definitions</title> + <pubdate>October 1990</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1706</abbrev> + <authorgroup> + <author> + <surname>Manning</surname> + <firstname>B.</firstname> + </author> + <author> + <firstname>R.</firstname> + <surname>Colella</surname> + </author> + </authorgroup> + <title><acronym>DNS</acronym> NSAP Resource Records</title> + <pubdate>October 1994</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2168</abbrev> + <authorgroup> + <author> + <surname>Daniel</surname> + <firstname>R.</firstname> + </author> + <author> + <firstname>M.</firstname> + <surname>Mealling</surname> + </author> + </authorgroup> + <title>Resolution of Uniform Resource Identifiers using +the Domain Name System</title> + <pubdate>June 1997</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1876</abbrev> + <authorgroup> + <author> + <surname>Davis</surname> + <firstname>C.</firstname> + </author> + <author> + <firstname>P.</firstname> + <surname>Vixie</surname> + </author> + <author> + <firstname>T.</firstname> + <firstname>Goodwin</firstname> + </author> + <author> + <firstname>I.</firstname> + <surname>Dickinson</surname> + </author> + </authorgroup> + <title>A Means for Expressing Location Information in the Domain +Name System</title> + <pubdate>January 1996</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2052</abbrev> + <authorgroup> + <author> + <surname>Gulbrandsen</surname> + <firstname>A.</firstname> + </author> + <author> + <firstname>P.</firstname> + <surname>Vixie</surname> + </author> + </authorgroup> + <title>A <acronym>DNS</acronym> RR for Specifying the Location of +Services.</title> + <pubdate>October 1996</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2163</abbrev> + <author> + <surname>Allocchio</surname> + <firstname>A.</firstname> + </author> + <title>Using the Internet <acronym>DNS</acronym> to Distribute MIXER +Conformant Global Address Mapping</title> + <pubdate>January 1998</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2230</abbrev> + <author> + <surname>Atkinson</surname> + <firstname>R.</firstname> + </author> + <title>Key Exchange Delegation Record for the <acronym>DNS</acronym></title> + <pubdate>October 1997</pubdate> + </biblioentry> + </bibliodiv> + <bibliodiv> + <title><acronym>DNS</acronym> and the Internet</title> + <biblioentry> + <abbrev>RFC1101</abbrev> + <author> + <surname>Mockapetris</surname> + <firstname>P. V.</firstname> + </author> + <title><acronym>DNS</acronym> Encoding of Network Names and Other Types</title> + <pubdate>April 1989</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1123</abbrev> + <author> + <surname>Braden</surname> + <surname>R.</surname> + </author> + <title>Requirements for Internet Hosts - Application and Support</title> + <pubdate>October 1989</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1591</abbrev> + <author> + <surname>Postel</surname> + <firstname>J.</firstname></author> + <title>Domain Name System Structure and Delegation</title> + <pubdate>March 1994</pubdate></biblioentry> + <biblioentry> + <abbrev>RFC2317</abbrev> + <authorgroup> + <author> + <surname>Eidnes</surname> + <firstname>H.</firstname> + </author> + <author> + <firstname>G.</firstname> + <surname>de Groot</surname> + </author> + <author> + <firstname>P.</firstname> + <surname>Vixie</surname> + </author> + </authorgroup> + <title>Classless IN-ADDR.ARPA Delegation</title> + <pubdate>March 1998</pubdate> + </biblioentry> + </bibliodiv> + <bibliodiv> + <title><acronym>DNS</acronym> Operations</title> + <biblioentry> + <abbrev>RFC1537</abbrev> + <author> + <surname>Beertema</surname> + <firstname>P.</firstname> + </author> + <title>Common <acronym>DNS</acronym> Data File Configuration Errors</title> + <pubdate>October 1993</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1912</abbrev> + <author> + <surname>Barr</surname> + <firstname>D.</firstname> + </author> + <title>Common <acronym>DNS</acronym> Operational and Configuration Errors</title> + <pubdate>February 1996</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2010</abbrev> + <authorgroup> + <author> + <surname>Manning</surname> + <firstname>B.</firstname> + </author> + <author> + <firstname>P.</firstname> + <surname>Vixie</surname> + </author> + </authorgroup> + <title>Operational Criteria for Root Name Servers.</title> + <pubdate>October 1996</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2219</abbrev> + <authorgroup> + <author> + <surname>Hamilton</surname> + <firstname>M.</firstname> + </author> + <author> + <firstname>R.</firstname> + <surname>Wright</surname> + </author> + </authorgroup> + <title>Use of <acronym>DNS</acronym> Aliases for Network Services.</title> + <pubdate>October 1997</pubdate> + </biblioentry> + </bibliodiv> + <bibliodiv> + <title>Other <acronym>DNS</acronym>-related RFCs</title> + <note> + <para>Note: the following list of RFCs, although +<acronym>DNS</acronym>-related, are not concerned with implementing software.</para> + </note> + <biblioentry> + <abbrev>RFC1464</abbrev> + <author> + <surname>Rosenbaum</surname> + <firstname>R.</firstname> + </author> + <title>Using the Domain Name System To Store Arbitrary String Attributes</title> + <pubdate>May 1993</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC1713</abbrev> + <author> + <surname>Romao</surname> + <firstname>A.</firstname> + </author> + <title>Tools for <acronym>DNS</acronym> Debugging</title> + <pubdate>November 1994</pubdate></biblioentry> + <biblioentry> + <abbrev>RFC1794</abbrev> + <author> + <surname>Brisco</surname> + <firstname>T.</firstname> + </author> + <title><acronym>DNS</acronym> Support for Load Balancing</title> + <pubdate>April 1995</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2240</abbrev> + <author> + <surname>Vaughan</surname> + <firstname>O.</firstname></author> + <title>A Legal Basis for Domain Name Allocation</title> + <pubdate>November 1997</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2345</abbrev> + <authorgroup> + <author> + <surname>Klensin</surname> + <firstname>J.</firstname> + </author> + <author> + <firstname>T.</firstname> + <surname>Wolf</surname> + </author> + <author> + <firstname>G.</firstname> + <surname>Oglesby</surname> + </author> + </authorgroup> + <title>Domain Names and Company Name Retrieval</title> + <pubdate>May 1998</pubdate> + </biblioentry> + <biblioentry> + <abbrev>RFC2352</abbrev> + <author> + <surname>Vaughan</surname> + <firstname>O.</firstname> + </author> + <title>A Convention For Using Legal Names as Domain Names</title> + <pubdate>May 1998</pubdate> + </biblioentry> + </bibliodiv> + <bibliodiv> + <title>Obsolete and Unimplemented Experimental RRs</title> + <biblioentry> + <abbrev>RFC1712</abbrev> + <authorgroup> + <author> + <surname>Farrell</surname> + <firstname>C.</firstname> + </author> + <author> + <firstname>M.</firstname> + <surname>Schulze</surname> + </author> + <author> + <firstname>S.</firstname> + <surname>Pleitner</surname> + </author> + <author> + <firstname>D.</firstname> + <surname>Baldoni</surname> + </author> + </authorgroup> + <title><acronym>DNS</acronym> Encoding of Geographical +Location</title> + <pubdate>November 1994</pubdate> + </biblioentry> + </bibliodiv> + </bibliography> + </sect2> + <sect2 id="internet_drafts"> + <title>Internet Drafts</title> + <para>Internet Drafts (IDs) are rough-draft working documents of +the Internet Engineering Task Force. They are, in essence, RFCs +in the preliminary stages of development. Implementors are cautioned not +to regard IDs as archival, and they should not be quoted or cited +in any formal documents unless accompanied by the disclaimer that +they are "works in progress." IDs have a lifespan of six months +after which they are deleted unless updated by their authors. +</para> + </sect2> + <sect2> + <title>Other Documents About <acronym>BIND</acronym></title> + <para></para> + <bibliography> + <biblioentry> + <authorgroup> + <author> + <surname>Albitz</surname> + <firstname>Paul</firstname> + </author> + <author> + <firstname>Cricket</firstname> + <surname>Liu</surname> + </author> + </authorgroup> + <title><acronym>DNS</acronym> and <acronym>BIND</acronym></title> + <copyright> + <year>1998</year> + <holder>Sebastopol, CA: O'Reilly and Associates</holder> + </copyright> + </biblioentry> + </bibliography> + </sect2> + </sect1> + +</appendix> + +</book> |
