diff options
Diffstat (limited to 'contrib/bind9/doc/arm/Bv9ARM-book.xml')
| -rw-r--r-- | contrib/bind9/doc/arm/Bv9ARM-book.xml | 6658 |
1 files changed, 0 insertions, 6658 deletions
diff --git a/contrib/bind9/doc/arm/Bv9ARM-book.xml b/contrib/bind9/doc/arm/Bv9ARM-book.xml deleted file mode 100644 index 28ccb360afe03..0000000000000 --- a/contrib/bind9/doc/arm/Bv9ARM-book.xml +++ /dev/null @@ -1,6658 +0,0 @@ -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN" - "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" - [<!ENTITY mdash "—">]> -<!-- - - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") - - Copyright (C) 2000-2003 Internet Software Consortium. - - - - Permission to use, copy, modify, and distribute this software for any - - purpose with or without fee is hereby granted, provided that the above - - copyright notice and this permission notice appear in all copies. - - - - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH - - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY - - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, - - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM - - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE - - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - - PERFORMANCE OF THIS SOFTWARE. ---> - -<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.59 2005/10/10 00:22:24 marka Exp $ --> - -<book> -<title>BIND 9 Administrator Reference Manual</title> - - <bookinfo> - <copyright> - <year>2004</year> - <year>2005</year> - <holder>Internet Systems Consortium, Inc. ("ISC")</holder> - </copyright> - <copyright> - <year>2000</year> - <year>2001</year> - <year>2002</year> - <year>2003</year> - <holder>Internet Software Consortium.</holder> - </copyright> - </bookinfo> - - <chapter id="Bv9ARM.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="Bv9ARM.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="Bv9ARM.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>-jvz</arg> - <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>-djqvD</arg> - <arg>-c <replaceable>class</replaceable></arg> - <arg>-o <replaceable>output</replaceable></arg> - <arg>-t <replaceable>directory</replaceable></arg> - <arg>-w <replaceable>directory</replaceable></arg> - <arg>-k <replaceable>(ignore|warn|fail)</replaceable></arg> - <arg>-n <replaceable>(ignore|warn|fail)</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 <optional><replaceable>zone</replaceable> - <optional><replaceable>class</replaceable> - <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term> - <listitem><para>Suspend updates to a dynamic zone. If no zone is specified - then all zones are suspended. 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>thaw <optional><replaceable>zone</replaceable> - <optional><replaceable>class</replaceable> - <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term> - <listitem><para>Enable updates to a frozen dynamic zone. If no zone is - specified then all frozen zones are enabled. This causes - the server to reload the zone from disk, and re-enables dynamic updates - after the load has completed. After a zone is thawed, dynamic updates - will no longer be refused.</para></listitem> - </varlistentry> - - <varlistentry><term><userinput>notify <replaceable>zone</replaceable> - <optional><replaceable>class</replaceable> - <optional><replaceable>view</replaceable></optional></optional></userinput></term> - <listitem><para>Resend NOTIFY messages for the zone</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 <optional>-all|-cache|-zone</optional> <optional><replaceable>view ...</replaceable></optional></userinput></term> - <listitem><para>Dump the server's caches (default) and / or zones to the - dump file for the specified views. If no view is specified all - views are dumped.</para></listitem></varlistentry> - - <varlistentry><term><userinput>stop <optional>-p</optional></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. If -p is specified named's process id is returned.</para></listitem></varlistentry> - - <varlistentry><term><userinput>halt <optional>-p</optional></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. If -p is specified named's process id is returned.</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>flushname</userinput> <replaceable>name</replaceable></term> - <listitem><para>Flushes the given name from 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> - - <varlistentry><term><userinput>recursing</userinput></term> - <listitem><para>Dump the list of queries named is currently recursing - on. - </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="Bv9ARM.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 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>* IN MX 10 external1.example.com.</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="Bv9ARM.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="Bv9ARM.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 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> -<para><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput> -</para> -<para><computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput> -</para> -</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> host-statistics-max <replaceable>number</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 { <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 heirarchies 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> - -<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. The default varies according to usage area. For -<command>master</command> zones the default is <command>fail</command>. -For <command>slave</command> zones the default is <command>warn</command>. -For answer received from the network (<command>response</command>) -the default is <command>ignore</command>. -</para> -<para>The rules for legal hostnames / mail domains are derived from RFC 952 -and RFC 821 as modified by RFC 1123. -</para> -<para><command>check-names</command> applies to the owner names of A, AAA and -MX records. It also applies to the domain names in the RDATA of NS, SOA and MX -records. It also applies to the RDATA of PTR records where the owner name -indicated that it is a reverse lookup of a hostname (the owner name ends in -IN-ADDR.ARPA, IP6.ARPA, IP6.INT). -</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> - <note> - If you do not wish the alternate transfer source - to be used you should set - <command>use-alt-transfer-source</command> - appropriately and you should not depend upon - getting a answer back to the first refresh - query. - </note> - </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>host-statistics-max</command></term> -<listitem><para>In BIND 8, specifies the maximum number of host statistic -entries to be kept. -Not implemented in BIND 9. -</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 { <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. The default varies according to zone type. For <command>master</command> zones the default is <command>fail</command>. For <command>slave</command> -zones the default is <command>warn</command>. -</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>$ORIGIN example.com. -WWW CNAME MAIN-SERVER</programlisting> -<para>is equivalent to</para> -<programlisting>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</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>$ORIGIN 0.0.192.IN-ADDR.ARPA. -$GENERATE 1-2 0 NS SERVER$.EXAMPLE. -$GENERATE 1-127 $ CNAME $.0</programlisting> -<para>is equivalent to</para> -<programlisting>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. -</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="Bv9ARM.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="Bv9ARM.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="Bv9ARM.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> |