[deployment-guide/comm-rel: 150/727] Adjusted the formatting a bit.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 12:36:53 UTC 2010
commit 33c54909726c5e7acbb4a55871bd931a6e40824b
Author: Jaromir Hradilek <jhradile at redhat.com>
Date: Mon Jul 26 18:13:52 2010 +0200
Adjusted the formatting a bit.
en-US/The_BIND_DNS_Server.xml | 2469 ++++++++++++++++++++++-------------------
1 files changed, 1322 insertions(+), 1147 deletions(-)
---
diff --git a/en-US/The_BIND_DNS_Server.xml b/en-US/The_BIND_DNS_Server.xml
index 84453c7..55058c9 100644
--- a/en-US/The_BIND_DNS_Server.xml
+++ b/en-US/The_BIND_DNS_Server.xml
@@ -2,283 +2,281 @@
<!-- vi: set tw=0: -->
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<chapter
- id="ch-The_BIND_DNS_Server">
+<chapter id="ch-The_BIND_DNS_Server">
<title>The BIND DNS Server</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>Berkeley Internet Name Domain</primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>introducing</secondary>
</indexterm>
- <para>On most modern networks, including the Internet, users locate other computers by name. This frees users from the daunting task of remembering the numerical network address of network resources. The most effective way to configure a network to allow such name-based connections is to set up a <firstterm>Domain Name Service</firstterm> (<firstterm>DNS</firstterm>) or a <firstterm>nameserver</firstterm>, which resolves hostnames on the network to numerical addresses and vice versa.</para>
- <para>This chapter reviews the nameserver included in &MAJOROS; and the <firstterm>Berkeley Internet Name Domain</firstterm> (<firstterm>BIND</firstterm>) DNS server, with an emphasis on the structure of its configuration files and how it may be administered both locally and remotely.</para>
+ <para>
+ On most modern networks, including the Internet, users locate other computers by name. This frees users from the daunting task of remembering the numerical network address of network resources. The most effective way to configure a network to allow such name-based connections is to set up a <firstterm>Domain Name Service</firstterm> (<firstterm>DNS</firstterm>) or a <firstterm>nameserver</firstterm>, which resolves hostnames on the network to numerical addresses and vice versa.
+ </para>
+ <para>
+ This chapter reviews the nameserver included in &MAJOROS; and the <firstterm>Berkeley Internet Name Domain</firstterm> (<firstterm>BIND</firstterm>) DNS server, with an emphasis on the structure of its configuration files and how it may be administered both locally and remotely.
+ </para>
<note>
<title>Note</title>
- <para>BIND is also known as the service <command>named</command> in &MAJOROS;. You can manage it via the Services Configuration Tool (<command>system-config-service</command>).</para>
+ <para>
+ BIND is also known as the service <command>named</command> in &MAJOROS;. You can manage it via the Services Configuration Tool (<command>system-config-service</command>).
+ </para>
</note>
- <section
- id="s1-bind-introduction">
+ <section id="s1-bind-introduction">
<title>Introduction to DNS</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>introducing</secondary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>DNS</primary>
<seealso>BIND</seealso>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>DNS</primary>
<secondary>introducing</secondary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>nameserver</primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>root nameserver</primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>nameserver</secondary>
<tertiary>definition of</tertiary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>root nameserver</secondary>
<tertiary>definition of</tertiary>
</indexterm>
- <para><!-- RHEL5: When hosts on a network connect to one another via a hostname, also called a <firstterm>fully qualified domain name (FQDN)</firstterm>, DNS is used to associate the names of machines to the IP address for the host. --> DNS associates hostnames with their respective IP addresses, so that when users want to connect to other machines on the network, they can refer to them by name, without having to remember IP addresses.</para>
- <para>Use of DNS also has advantages for system administrators, allowing the flexibility to change the IP address for a host without affecting name-based queries to the machine. Conversely, administrators can shuffle which machines handle a name-based query.</para>
- <para>DNS is normally implemented using centralized servers that are authoritative for some domains and refer to other DNS servers for other domains.</para>
- <para>When a client host requests information from a nameserver, it usually connects to port 53. The nameserver then attempts to resolve the name requested. If the nameserver does not have an authoritative answer about the name the which host requested, or does not already have the answer cached from an earlier query, it queries other nameservers, called <firstterm>root nameservers</firstterm>, to determine which nameservers are authoritative for the name in question. Then, with that information, it queries the authoritative nameservers to get the requested name.</para>
- <section
- id="s2-bind-introduction-zones">
+ <para>
+ <!-- RHEL5: When hosts on a network connect to one another via a hostname, also called a <firstterm>fully qualified domain name (FQDN)</firstterm>, DNS is used to associate the names of machines to the IP address for the host. --> DNS associates hostnames with their respective IP addresses, so that when users want to connect to other machines on the network, they can refer to them by name, without having to remember IP addresses.
+ </para>
+ <para>
+ Use of DNS also has advantages for system administrators, allowing the flexibility to change the IP address for a host without affecting name-based queries to the machine. Conversely, administrators can shuffle which machines handle a name-based query.
+ </para>
+ <para>
+ DNS is normally implemented using centralized servers that are authoritative for some domains and refer to other DNS servers for other domains.
+ </para>
+ <para>
+ When a client host requests information from a nameserver, it usually connects to port 53. The nameserver then attempts to resolve the name requested. If the nameserver does not have an authoritative answer about the name the which host requested, or does not already have the answer cached from an earlier query, it queries other nameservers, called <firstterm>root nameservers</firstterm>, to determine which nameservers are authoritative for the name in question. Then, with that information, it queries the authoritative nameservers to get the requested name.
+ </para>
+ <section id="s2-bind-introduction-zones">
<title>Nameserver Zones</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>zones</secondary>
<tertiary>definition of</tertiary>
</indexterm>
- <para>In a DNS server such as BIND, all information is stored in basic data elements called <firstterm>resource records</firstterm> (RR). A RR is usually the <firstterm>fully qualified domain name</firstterm> (FQDN) of a host. Resource records are broken down into multiple sections. These sections are organized into a tree-like hierarchy consisting of a main trunk, primary branches, secondary branches, and so forth. Consider the following RR:</para>
+ <para>
+ In a DNS server such as BIND, all information is stored in basic data elements called <firstterm>resource records</firstterm> (RR). A RR is usually the <firstterm>fully qualified domain name</firstterm> (FQDN) of a host. Resource records are broken down into multiple sections. These sections are organized into a tree-like hierarchy consisting of a main trunk, primary branches, secondary branches, and so forth. Consider the following RR:
+ </para>
<screen>bob.sales.example.com</screen>
- <para>When looking at how a RR is resolved to find, for example, the IP address that relates to a particular system, read the name from right to left. Each level of the hierarchy is divided by a period (often called a "dot": <quote><computeroutput>.</computeroutput>
- </quote>). In this example, therefore, <computeroutput>com</computeroutput> defines the <firstterm>top-level domain</firstterm> for this RR. The name <computeroutput>example</computeroutput> is a sub-domain under <computeroutput>com</computeroutput>, while <computeroutput>sales</computeroutput> is a sub-domain under <computeroutput>example</computeroutput>. The name furthest to the left, <computeroutput>bob</computeroutput>, identifies a RR which is part of the <computeroutput>sales.example.com</computeroutput> domain.</para>
- <para>Except for the first (leftmost) part of the RR (<computeroutput>bob</computeroutput>), each section is called a <firstterm>zone</firstterm>. Zone defines a specific <firstterm>namespace</firstterm>. A zone contains definitions of RRs, which usually contain host-to-IP address mappings and IP address-to-host mappings, which are called <firstterm>reverse records</firstterm>).</para>
- <para>Zones are defined on authoritative nameservers through the use of <firstterm>zone files</firstterm>, which define the RRs in that zone. Zone files are stored on <firstterm>primary nameservers</firstterm> (also called <firstterm>master nameservers</firstterm>), where changes are made to the files, and <firstterm>secondary nameservers</firstterm> (also called <firstterm>slave nameservers</firstterm>), which receive zone definitions from the primary nameservers. Both primary and secondary nameservers are authoritative for the zone and look the same to clients. Any nameserver can be a primary or secondary nameserver for multiple zones at the same time. It all depends on how the nameserver is configured.</para>
+ <para>
+ When looking at how a RR is resolved to find, for example, the IP address that relates to a particular system, read the name from right to left. Each level of the hierarchy is divided by a period (often called a "dot": <quote><computeroutput>.</computeroutput></quote>). In this example, therefore, <computeroutput>com</computeroutput> defines the <firstterm>top-level domain</firstterm> for this RR. The name <computeroutput>example</computeroutput> is a sub-domain under <computeroutput>com</computeroutput>, while <computeroutput>sales</computeroutput> is a sub-domain under <computeroutput>example</computeroutput>. The name furthest to the left, <computeroutput>bob</computeroutput>, identifies a RR which is part of the <computeroutput>sales.example.com</computeroutput> domain.
+ </para>
+ <para>
+ Except for the first (leftmost) part of the RR (<computeroutput>bob</computeroutput>), each section is called a <firstterm>zone</firstterm>. Zone defines a specific <firstterm>namespace</firstterm>. A zone contains definitions of RRs, which usually contain host-to-IP address mappings and IP address-to-host mappings, which are called <firstterm>reverse records</firstterm>).
+ </para>
+ <para>
+ Zones are defined on authoritative nameservers through the use of <firstterm>zone files</firstterm>, which define the RRs in that zone. Zone files are stored on <firstterm>primary nameservers</firstterm> (also called <firstterm>master nameservers</firstterm>), where changes are made to the files, and <firstterm>secondary nameservers</firstterm> (also called <firstterm>slave nameservers</firstterm>), which receive zone definitions from the primary nameservers. Both primary and secondary nameservers are authoritative for the zone and look the same to clients. Any nameserver can be a primary or secondary nameserver for multiple zones at the same time. It all depends on how the nameserver is configured.
+ </para>
</section>
- <section
- id="s2-bind-introduction-nameservers">
+ <section id="s2-bind-introduction-nameservers">
<title>Nameserver Types</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>nameserver types</secondary>
<tertiary>master</tertiary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>nameserver types</secondary>
<tertiary>slave</tertiary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>nameserver types</secondary>
<tertiary>caching-only</tertiary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>nameserver types</secondary>
<tertiary>forwarding</tertiary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>forwarding nameserver</primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>caching-only nameserver</primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>slave nameserver</primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>master nameserver</primary>
<see>BIND</see>
</indexterm>
- <para>There are two nameserver configuration types:</para>
+ <para>
+ There are two nameserver configuration types:
+ </para>
<variablelist>
<varlistentry>
<term>authoritative</term>
<listitem>
- <para>This category includes both primary (master) and secondary (slave) servers. Those servers answer only for RRs which are part of their zones.</para>
+ <para>
+ This category includes both primary (master) and secondary (slave) servers. Those servers answer only for RRs which are part of their zones.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
<term>recursive</term>
<listitem>
- <para>Offers resolution services, but is not authoritative for any zones. Answers for all resolutions are cached in memory for a fixed period of time, which is specified by the retrieved RR.</para>
+ <para>
+ Offers resolution services, but is not authoritative for any zones. Answers for all resolutions are cached in memory for a fixed period of time, which is specified by the retrieved RR.
+ </para>
</listitem>
</varlistentry>
</variablelist>
- <para>A nameserver may be one or both of these types. For example, a nameserver can be a master for some zones, a slave for others, and offer recursive services for others. However the best practice is not to combine authoritative and recursive servers due their absolutely different requirements. Authoritative servers are available for all clients and they should be available all the time otherwise it is not possible to resolve particular subtree of the DNS database. Recursive lookups take far more time than authoritative responses thus recursive servers should be available for a restricted number of clients. Otherwise recursive server could be easy target for <firstterm>distributed denial of service (DDoS)</firstterm> attack.</para>
+ <para>
+ A nameserver may be one or both of these types. For example, a nameserver can be a master for some zones, a slave for others, and offer recursive services for others. However the best practice is not to combine authoritative and recursive servers due their absolutely different requirements. Authoritative servers are available for all clients and they should be available all the time otherwise it is not possible to resolve particular subtree of the DNS database. Recursive lookups take far more time than authoritative responses thus recursive servers should be available for a restricted number of clients. Otherwise recursive server could be easy target for <firstterm>distributed denial of service (DDoS)</firstterm> attack.
+ </para>
</section>
- <section
- id="s2-bind-introduction-bind">
+ <section id="s2-bind-introduction-bind">
<title>BIND as a Nameserver</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
- <secondary>
- <command>named</command> daemon</secondary>
+ <secondary><command>named</command> daemon</secondary>
</indexterm>
- <indexterm
- significance="normal">
- <primary>
- <command>named</command> daemon</primary>
+ <indexterm>
+ <primary><command>named</command> daemon</primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration files</secondary>
- <tertiary>
- <filename>/etc/named.conf</filename>
- </tertiary>
+ <tertiary><filename>/etc/named.conf</filename></tertiary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration files</secondary>
- <tertiary>
- <filename>/var/named/</filename> directory</tertiary>
+ <tertiary><filename>/var/named/</filename> directory</tertiary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration files</secondary>
<tertiary>BIND as a Nameserver</tertiary>
</indexterm>
- <para>BIND is set of DNS related programs. It contains a monolithic nameserver called <command>/usr/sbin/named</command>, an administration utility called <command>/usr/sbin/rndc</command> and DNS debugging utility called <command>/usr/bin/dig</command>. More information about <command>rndc</command> can be found in <xref
- linkend="s1-bind-rndc"/>.</para>
-<!-- TODO: Add "dig" utility decription -->
- <para>BIND stores its configuration files in the following locations:</para>
+ <para>
+ BIND is set of DNS related programs. It contains a monolithic nameserver called <command>/usr/sbin/named</command>, an administration utility called <command>/usr/sbin/rndc</command> and DNS debugging utility called <command>/usr/bin/dig</command>. More information about <command>rndc</command> can be found in <xref linkend="s1-bind-rndc" />.
+ </para>
+ <!-- TODO: Add "dig" utility decription -->
+ <para>
+ BIND stores its configuration files in the following locations:
+ </para>
<variablelist>
<varlistentry>
- <term>
- <filename>/etc/named.conf</filename>
- </term>
+ <term><filename>/etc/named.conf</filename></term>
<listitem>
- <para>The configuration file for the <command>named</command> daemon</para>
+ <para>
+ The configuration file for the <command>named</command> daemon
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/etc/named/</filename> directory
- </term>
+ <term><filename>/etc/named/</filename> directory</term>
<listitem>
- <para>Auxiliary directory for configuration files which is included in the main named.conf file</para>
+ <para>
+ Auxiliary directory for configuration files which is included in the main named.conf file
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/var/named/</filename> directory</term>
+ <term><filename>/var/named/</filename> directory</term>
<listitem>
- <para>The <command>named</command> working directory which stores zones. This directory is not writable by <command>named</command></para>
+ <para>
+ The <command>named</command> working directory which stores zones. This directory is not writable by <command>named</command>
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/var/named/slaves</filename> directory</term>
+ <term><filename>/var/named/slaves</filename> directory</term>
<listitem>
- <para>This directory is writable by <command>named</command> and should be used to store secondary (slave) zones.</para>
+ <para>
+ This directory is writable by <command>named</command> and should be used to store secondary (slave) zones.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/var/named/dynamic</filename> directory</term>
+ <term><filename>/var/named/dynamic</filename> directory</term>
<listitem>
- <para>This directory is writable by <command>named</command> and should be used to store other writable files, like DDNS (dynamic DNS) zones or managed DNSSEC keys</para>
+ <para>
+ This directory is writable by <command>named</command> and should be used to store other writable files, like DDNS (dynamic DNS) zones or managed DNSSEC keys
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/var/named/data</filename> directory</term>
+ <term><filename>/var/named/data</filename> directory</term>
<listitem>
- <para>This directory is writable by <command>named</command> and should be used to store various statistics and debugging files</para>
+ <para>
+ This directory is writable by <command>named</command> and should be used to store various statistics and debugging files
+ </para>
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
- <itemizedlist>
- <listitem>
- <para><filename>/etc/named.conf</filename> — The configuration file for the <command>named</command> daemon.</para>
- </listitem>
- <listitem>
- <para><filename>/var/named/</filename> directory — The <command>named</command> working directory which stores zone, statistic, and cache files.</para>
- </listitem>
- </itemizedlist>
+ <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
+ <itemizedlist>
+ <listitem>
+ <para><filename>/etc/named.conf</filename> — The configuration file for the <command>named</command> daemon.</para>
+ </listitem>
+ <listitem>
+ <para><filename>/var/named/</filename> directory — The <command>named</command> working directory which stores zone, statistic, and cache files.</para>
+ </listitem>
+ </itemizedlist>
-->
<note>
<title>Note</title>
- <para>If you have installed the <filename>bind-chroot</filename> package, the BIND service will run in the <command>/var/named/chroot</command> environment. All configuration files will be automatically mounted (via <command>mount --bind</command>) there by initscript so you can manage your configuration in non-chroot environment. All files and directories written above are mounted.</para>
+ <para>
+ If you have installed the <filename>bind-chroot</filename> package, the BIND service will run in the <command>/var/named/chroot</command> environment. All configuration files will be automatically mounted (via <command>mount --bind</command>) there by initscript so you can manage your configuration in non-chroot environment. All files and directories written above are mounted.
+ </para>
</note>
- <para>The next few sections review the BIND configuration in more detail.</para>
+ <para>
+ The next few sections review the BIND configuration in more detail.
+ </para>
</section>
</section>
- <section
- id="s1-bind-namedconf">
- <title>
- <filename>/etc/named.conf</filename>
- </title>
- <indexterm
- significance="normal">
- <primary>
- <filename>named.conf</filename>
- </primary>
+ <section id="s1-bind-namedconf">
+ <title><filename>/etc/named.conf</filename></title>
+ <indexterm>
+ <primary><filename>named.conf</filename></primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
- <primary>
- <filename>/etc/named.conf</filename>
- </primary>
+ <indexterm>
+ <primary><filename>/etc/named.conf</filename></primary>
<see>BIND</see>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration files</secondary>
- <tertiary>
- <filename>/etc/named.conf</filename>
- </tertiary>
+ <tertiary><filename>/etc/named.conf</filename></tertiary>
</indexterm>
- <para>The <filename>named.conf</filename> file is a collection of statements using nested options surrounded by opening and closing ellipse characters, <command>{ }</command>. Administrators must be careful when editing <filename>named.conf</filename> to avoid syntax errors as many seemingly minor errors prevent the <command>named</command> service from starting.</para>
- <para>A typical <filename>named.conf</filename> file is organized similar to the following example:</para>
- <screen>
-<replaceable><statement-1></replaceable> ["<replaceable><statement-1-name></replaceable>"] [<replaceable><statement-1-class></replaceable>] {
+ <para>
+ The <filename>named.conf</filename> file is a collection of statements using nested options surrounded by opening and closing ellipse characters, <command>{ }</command>. Administrators must be careful when editing <filename>named.conf</filename> to avoid syntax errors as many seemingly minor errors prevent the <command>named</command> service from starting.
+ </para>
+ <para>
+ A typical <filename>named.conf</filename> file is organized similar to the following example:
+ </para>
+ <screen><replaceable><statement-1></replaceable> ["<replaceable><statement-1-name></replaceable>"] [<replaceable><statement-1-class></replaceable>] {
<replaceable><option-1></replaceable>;
<replaceable><option-2></replaceable>;
<replaceable><option-N></replaceable>;
@@ -293,896 +291,1022 @@
<replaceable><option-2></replaceable>;
<replaceable><option-N></replaceable>;
};</screen>
- <section
- id="s2-bind-namedconf-state">
+ <section id="s2-bind-namedconf-state">
<title>Common Statement Types</title>
- <para>The following types of statements are commonly used in <filename>/etc/named.conf</filename>:</para>
- <section
- id="s3-bind-namedconf-state-acl">
- <title>
- <command>acl</command> Statement</title>
- <para>The <command>acl</command> (Access Control List) statement defines groups of hosts which can then be permitted or denied access to the nameserver.</para>
- <para>An <command>acl</command> statement takes the following form:</para>
+ <para>
+ The following types of statements are commonly used in <filename>/etc/named.conf</filename>:
+ </para>
+ <section id="s3-bind-namedconf-state-acl">
+ <title><command>acl</command> Statement</title>
+ <para>
+ The <command>acl</command> (Access Control List) statement defines groups of hosts which can then be permitted or denied access to the nameserver.
+ </para>
+ <para>
+ An <command>acl</command> statement takes the following form:
+ </para>
<screen>acl <replaceable><acl-name></replaceable> {
<replaceable><match-element></replaceable>;
[<replaceable><match-element></replaceable>; ...]
};</screen>
- <para>In this statement, replace <replaceable><acl-name></replaceable> with the name of the access control list and replace <replaceable><match-element></replaceable> with a semi-colon separated list of IP addresses. Most of the time, an individual IP address or CIDR network notation (such as <command>10.0.1.0/24</command>) is used to identify the IP addresses within the <command>acl</command> statement.</para>
- <para>The following access control lists are already defined as keywords to simplify configuration:</para>
+ <para>
+ In this statement, replace <replaceable><acl-name></replaceable> with the name of the access control list and replace <replaceable><match-element></replaceable> with a semi-colon separated list of IP addresses. Most of the time, an individual IP address or CIDR network notation (such as <command>10.0.1.0/24</command>) is used to identify the IP addresses within the <command>acl</command> statement.
+ </para>
+ <para>
+ The following access control lists are already defined as keywords to simplify configuration:
+ </para>
<itemizedlist>
<listitem>
<para>
- <command>any</command> — Matches every IP address</para>
+ <command>any</command> — Matches every IP address
+ </para>
</listitem>
<listitem>
<para>
- <command>localhost</command> — Matches any IP address in use by the local system</para>
+ <command>localhost</command> — Matches any IP address in use by the local system
+ </para>
</listitem>
<listitem>
<para>
- <command>localnets</command> — Matches any IP address on any network to which the local system is connected</para>
+ <command>localnets</command> — Matches any IP address on any network to which the local system is connected
+ </para>
</listitem>
<listitem>
<para>
- <command>none</command> — Matches no IP addresses</para>
+ <command>none</command> — Matches no IP addresses
+ </para>
</listitem>
</itemizedlist>
- <para>When used in conjunction with other statements (such as the <command>options</command> statement), <command>acl</command> statements can be very useful in preventing the misuse of a BIND nameserver.</para>
- <para>The following example defines two access control lists and uses an <command>options</command> statement to define how they are treated by the nameserver:</para>
- <screen>
- acl black-hats {
- 10.0.2.0/24; 192.168.0.0/24; 1234:5678::9abc/24;};
- acl red-hats { 10.0.1.0/24; };
+ <para>
+ When used in conjunction with other statements (such as the <command>options</command> statement), <command>acl</command> statements can be very useful in preventing the misuse of a BIND nameserver.
+ </para>
+ <para>
+ The following example defines two access control lists and uses an <command>options</command> statement to define how they are treated by the nameserver:
+ </para>
+ <screen> acl black-hats {
+ 10.0.2.0/24; 192.168.0.0/24; 1234:5678::9abc/24;};
+ acl red-hats { 10.0.1.0/24; };
options {
- blackhole { black-hats; };
- allow-query { red-hats; };
- allow-query-cache { red-hats; };
-}
-</screen>
- <para>This example contains two access control lists, <command>black-hats</command> and <command>red-hats</command>. Hosts in the <command>black-hats</command> list are on the blacklist, while hosts in the <command>red-hats</command> list are given normal access.</para>
+ blackhole { black-hats; };
+ allow-query { red-hats; };
+ allow-query-cache { red-hats; };
+}</screen>
+ <para>
+ This example contains two access control lists, <command>black-hats</command> and <command>red-hats</command>. Hosts in the <command>black-hats</command> list are on the blacklist, while hosts in the <command>red-hats</command> list are given normal access.
+ </para>
<important>
<title>Important</title>
- <para>It is recommended to restrict recursive DNS services for only a particular subset of clients via allow-query-cache option. Otherwise nameserver will be easy target for DDoS attack.</para>
+ <para>
+ It is recommended to restrict recursive DNS services for only a particular subset of clients via allow-query-cache option. Otherwise nameserver will be easy target for DDoS attack.
+ </para>
</important>
</section>
- <section
- id="s3-bind-namedconf-state-inc">
- <title>
- <command>include</command> Statement</title>
- <para>The <command>include</command> statement allows files to be included in a <filename>named.conf</filename> file. In this way, sensitive configuration data (such as <command>keys</command>) can be placed in a separate file with restrictive permissions.</para>
- <para>An <command>include</command> statement takes the following form:</para>
+ <section id="s3-bind-namedconf-state-inc">
+ <title><command>include</command> Statement</title>
+ <para>
+ The <command>include</command> statement allows files to be included in a <filename>named.conf</filename> file. In this way, sensitive configuration data (such as <command>keys</command>) can be placed in a separate file with restrictive permissions.
+ </para>
+ <para>
+ An <command>include</command> statement takes the following form:
+ </para>
<screen>include "<replaceable><file-name></replaceable>"</screen>
- <para>In this statement, <replaceable><file-name></replaceable> is replaced with an absolute path to a file.</para>
+ <para>
+ In this statement, <replaceable><file-name></replaceable> is replaced with an absolute path to a file.
+ </para>
</section>
- <section
- id="s3-bind-namedconf-state-opt">
- <title>
- <command>options</command> Statement</title>
- <para>The <command>options</command> statement defines global server configuration options and sets defaults for other statements. It can be used to specify the location of the <command>named</command> working directory, the types of queries allowed, and much more.</para>
- <para>The <command>options</command> statement takes the following form:</para>
+ <section id="s3-bind-namedconf-state-opt">
+ <title><command>options</command> Statement</title>
+ <para>
+ The <command>options</command> statement defines global server configuration options and sets defaults for other statements. It can be used to specify the location of the <command>named</command> working directory, the types of queries allowed, and much more.
+ </para>
+ <para>
+ The <command>options</command> statement takes the following form:
+ </para>
<screen>options {
<replaceable><option></replaceable>;
[<replaceable><option></replaceable>; ...]
};</screen>
- <para>In this statement, the <replaceable><option></replaceable> directives are replaced with a valid option.</para>
- <para>The following are commonly used options:</para>
- <!-- RHEL5: ddomingo at redhat.com: replacement -->
+ <para>
+ In this statement, the <replaceable><option></replaceable> directives are replaced with a valid option.
+ </para>
+ <para>
+ The following are commonly used options:
+ </para>
+ <!-- RHEL5: ddomingo at redhat.com: replacement -->
<variablelist>
<varlistentry>
- <term>
- <command>allow-query</command>
- </term>
+ <term><command>allow-query</command></term>
<listitem>
- <para>Specifies which hosts are allowed to query this nameserver for authoritative RRs. By default, all hosts are allowed to query. An access control lists, or collection of IP addresses or networks, may be used here to allow only particular hosts to query the nameserver.</para>
+ <para>
+ Specifies which hosts are allowed to query this nameserver for authoritative RRs. By default, all hosts are allowed to query. An access control lists, or collection of IP addresses or networks, may be used here to allow only particular hosts to query the nameserver.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>allow-query-cache</command>
- </term>
+ <term><command>allow-query-cache</command></term>
<listitem>
- <para>Similar to <command>allow-query</command>, this option applies to non-authoritative data, like recursive queries. By default, only <command>localhost;</command> and <command>localnets;</command> are allowed to obtain non-authoritative data.</para>
+ <para>
+ Similar to <command>allow-query</command>, this option applies to non-authoritative data, like recursive queries. By default, only <command>localhost;</command> and <command>localnets;</command> are allowed to obtain non-authoritative data.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>blackhole</command>
- </term>
+ <term><command>blackhole</command></term>
<listitem>
- <para>Specifies which hosts are banned from the server. This option should be used when particular host or network floods the server with requests. Default is <command>none;</command>
+ <para>
+ Specifies which hosts are banned from the server. This option should be used when particular host or network floods the server with requests. Default is <command>none;</command>
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>directory</command>
- </term>
+ <term><command>directory</command></term>
<listitem>
- <para>Specifies the <command>named</command> working directory if different from the default value, <filename>/var/named/</filename>.</para>
+ <para>
+ Specifies the <command>named</command> working directory if different from the default value, <filename>/var/named/</filename>.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>forwarders</command>
- </term>
+ <term><command>forwarders</command></term>
<listitem>
- <para>Specifies a list of valid IP addresses for nameservers where requests should be forwarded for resolution.</para>
+ <para>
+ Specifies a list of valid IP addresses for nameservers where requests should be forwarded for resolution.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>forward</command>
- </term>
+ <term><command>forward</command></term>
<listitem>
- <para>Specifies the forwarding behavior of a <command>forwarders</command> directive.</para>
- <para>The following options are accepted:</para>
+ <para>
+ Specifies the forwarding behavior of a <command>forwarders</command> directive.
+ </para>
+ <para>
+ The following options are accepted:
+ </para>
<itemizedlist>
<listitem>
<para>
- <command>first</command> — Specifies that the nameservers listed in the <command>forwarders</command> directive be queried before <command>named</command> attempts to resolve the name itself.</para>
+ <command>first</command> — Specifies that the nameservers listed in the <command>forwarders</command> directive be queried before <command>named</command> attempts to resolve the name itself.
+ </para>
</listitem>
<listitem>
<para>
- <command>only</command> — Specifies that <command>named</command> does not attempt name resolution itself in the event that queries to nameservers specified in the <command>forwarders</command> directive fail.</para>
+ <command>only</command> — Specifies that <command>named</command> does not attempt name resolution itself in the event that queries to nameservers specified in the <command>forwarders</command> directive fail.
+ </para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>listen-on</command>
- </term>
+ <term><command>listen-on</command></term>
<listitem>
- <para>Specifies the IPv4 network interface on which <command>named</command> listens for queries. By default, all IPv4 interfaces are used.</para>
- <para>Using this directive on a DNS server which also acts a gateway, BIND can be configured to only answer queries that originate from one of the networks.</para>
- <para>The following is an example of a <command>listen-on</command> directive:</para>
- <!-- RHEL5: ddomingo at redhat.com: above <para>replaces below
- <para>A <command>listen-on</command> directive looks like the following example:</para>
+ <para>
+ Specifies the IPv4 network interface on which <command>named</command> listens for queries. By default, all IPv4 interfaces are used.
+ </para>
+ <para>
+ Using this directive on a DNS server which also acts a gateway, BIND can be configured to only answer queries that originate from one of the networks.
+ </para>
+ <para>
+ The following is an example of a <command>listen-on</command> directive:
+ </para>
+ <!-- RHEL5: ddomingo at redhat.com: above <para>replaces below
+ <para>A <command>listen-on</command> directive looks like the following example:</para>
-->
<screen>options { listen-on { 10.0.1.1; }; };</screen>
- <para>In this example, server listens only on (<command>10.0.1.1</command>) address.</para>
+ <para>
+ In this example, server listens only on (<command>10.0.1.1</command>) address.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>listen-on-v6</command>
- </term>
+ <term><command>listen-on-v6</command></term>
<listitem>
- <para>Same as <command>listen-on</command> except for IPv6 interfaces.</para>
- <para>The following is an example of a <command>listen-on-v6</command> directive:</para>
+ <para>
+ Same as <command>listen-on</command> except for IPv6 interfaces.
+ </para>
+ <para>
+ The following is an example of a <command>listen-on-v6</command> directive:
+ </para>
<screen>options { listen-on-v6 { 1234:5678::9abc; }; };</screen>
- <para>In this example, server listens only on (<command>1234:5678::9abc</command>) address.</para>
+ <para>
+ In this example, server listens only on (<command>1234:5678::9abc</command>) address.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>max-cache-size</command>
- </term>
+ <term><command>max-cache-size</command></term>
<listitem>
- <para>Specifies the maximum amount of memory to use for server caches. 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. Default is 32M.</para>
+ <para>
+ Specifies the maximum amount of memory to use for server caches. 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. Default is 32M.
+ </para>
<screen>options { max-cache-size 256M; };</screen>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>notify</command>
- </term>
+ <term><command>notify</command></term>
<listitem>
- <para>Controls whether <command>named</command> notifies the slave servers when a zone is updated. It accepts the following options:</para>
+ <para>
+ Controls whether <command>named</command> notifies the slave servers when a zone is updated. It accepts the following options:
+ </para>
<itemizedlist>
<listitem>
<para>
- <command>yes</command> — Notifies slave servers.</para>
+ <command>yes</command> — Notifies slave servers.
+ </para>
</listitem>
<listitem>
<para>
- <command>no</command> — Does not notify slave servers.</para>
+ <command>no</command> — Does not notify slave servers.
+ </para>
</listitem>
<listitem>
<para>
- <command>master-only</command> - Send notify only when
-server is a master server for the zone.</para>
+ <command>master-only</command> - Send notify only when server is a master server for the zone.
+ </para>
</listitem>
<listitem>
<para>
- <command>explicit</command> — Only notifies slave servers specified in an <command>also-notify</command> list within a zone statement.</para>
+ <command>explicit</command> — Only notifies slave servers specified in an <command>also-notify</command> list within a zone statement.
+ </para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>pid-file</command>
- </term>
+ <term><command>pid-file</command></term>
<listitem>
- <para>Specifies the location of the process ID file created by <command>named</command>.</para>
+ <para>
+ Specifies the location of the process ID file created by <command>named</command>.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>recursion</command>
- </term>
+ <term><command>recursion</command></term>
<listitem>
- <para>Specifies if <command>named</command> acts as a recursive server. The default is <command>yes</command>.</para>
+ <para>
+ Specifies if <command>named</command> acts as a recursive server. The default is <command>yes</command>.
+ </para>
<screen>options { recursion no; };</screen>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>statistics-file</command>
- </term>
+ <term><command>statistics-file</command></term>
<listitem>
- <para>Specifies an alternate location for statistics files. By default, <command>named</command> statistics are saved to the <filename>/var/named/named.stats</filename> file.</para>
+ <para>
+ Specifies an alternate location for statistics files. By default, <command>named</command> statistics are saved to the <filename>/var/named/named.stats</filename> file.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>dnssec-enable</command>
- </term>
+ <term><command>dnssec-enable</command></term>
<listitem>
- <para>Specifies if <command>named</command> returns DNSSEC related RRs. The default is <command>yes</command>.</para>
+ <para>
+ Specifies if <command>named</command> returns DNSSEC related RRs. The default is <command>yes</command>.
+ </para>
<screen>options { dnssec-enable yes; };</screen>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>dnssec-validation</command>
- </term>
+ <term><command>dnssec-validation</command></term>
<listitem>
- <para>Specifies if <command>named</command> should prove that RRs are authentic via DNSSEC. The default is <command>yes</command>.</para>
+ <para>
+ Specifies if <command>named</command> should prove that RRs are authentic via DNSSEC. The default is <command>yes</command>.
+ </para>
<screen>options { dnssec-validation yes; };</screen>
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces below <itemizedlist>:
- <itemizedlist>
- <listitem>
- <para><command>allow-query</command> — Specifies which hosts are allowed to query this nameserver. By default, all hosts are allowed to query. An access control list, or collection of IP addresses or networks may be used here to
- only allow particular hosts to query the nameserver.</para>
- </listitem>
- <listitem>
- <para><command>allow-recursion</command> — Similar to <command>allow-query</command>, this option applies to recursive queries. By default, all hosts are allowed to perform recursive queries on the nameserver.</para>
- </listitem>
- <listitem>
- <para><command>blackhole </command> — Specifies which hosts are not allowed to query the server.</para>
- </listitem>
- <listitem>
- <para><command>directory</command> — Specifies the <command>named</command> working directory if different from the default value, <filename>/var/named/</filename>.</para>
- </listitem>
- <listitem>
- <para><command>forward</command> — Specifies the forwarding behavior of a <command>forwarders</command> directive.</para>
- <para>The following options are accepted:</para>
- <itemizedlist>
- <listitem>
- <para><command>first</command> — Specifies that the nameservers listed in the <command>forwarders</command> directive be queried before <command>named</command> attempts to resolve the name itself.</para>
- </listitem>
- <listitem>
- <para><command>only</command> — Specifies that <command>named</command> does not attempt name resolution itself in the event queries to nameservers specified in the <command>forwarders</command>
- directive fail.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para><command>forwarders</command> — Specifies a list of valid IP addresses for nameservers where requests should be forwarded for resolution.</para>
- </listitem>
- <listitem>
- <para><command>listen-on</command> — Specifies the network interface on which <command>named</command> listens for queries. By default, all interfaces are used.</para>
- <para>Using this directive on a DNS server which also acts a gateway, BIND can be configured to only answer queries that originate from one of the networks.</para>
- <para>A <command>listen-on</command> directive looks like the following example:</para>
+ <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces below <itemizedlist>:
+ <itemizedlist>
+ <listitem>
+ <para><command>allow-query</command> — Specifies which hosts are allowed to query this nameserver. By default, all hosts are allowed to query. An access control list, or collection of IP addresses or networks may be used here to
+ only allow particular hosts to query the nameserver.</para>
+ </listitem>
+ <listitem>
+ <para><command>allow-recursion</command> — Similar to <command>allow-query</command>, this option applies to recursive queries. By default, all hosts are allowed to perform recursive queries on the nameserver.</para>
+ </listitem>
+ <listitem>
+ <para><command>blackhole </command> — Specifies which hosts are not allowed to query the server.</para>
+ </listitem>
+ <listitem>
+ <para><command>directory</command> — Specifies the <command>named</command> working directory if different from the default value, <filename>/var/named/</filename>.</para>
+ </listitem>
+ <listitem>
+ <para><command>forward</command> — Specifies the forwarding behavior of a <command>forwarders</command> directive.</para>
+ <para>The following options are accepted:</para>
+ <itemizedlist>
+ <listitem>
+ <para><command>first</command> — Specifies that the nameservers listed in the <command>forwarders</command> directive be queried before <command>named</command> attempts to resolve the name itself.</para>
+ </listitem>
+ <listitem>
+ <para><command>only</command> — Specifies that <command>named</command> does not attempt name resolution itself in the event queries to nameservers specified in the <command>forwarders</command>
+ directive fail.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para><command>forwarders</command> — Specifies a list of valid IP addresses for nameservers where requests should be forwarded for resolution.</para>
+ </listitem>
+ <listitem>
+ <para><command>listen-on</command> — Specifies the network interface on which <command>named</command> listens for queries. By default, all interfaces are used.</para>
+ <para>Using this directive on a DNS server which also acts a gateway, BIND can be configured to only answer queries that originate from one of the networks.</para>
+ <para>A <command>listen-on</command> directive looks like the following example:</para>
<screen>
<command>options { listen-on { 10.0.1.1; }; };</command>
</screen>
- <para>In this example, only requests that arrive from the network interface serving the private network (<command>10.0.1.1</command>) are accepted.</para>
- </listitem>
- <listitem>
- <para><command>notify</command> — Controls whether <command>named</command> notifies the slave servers when a zone is updated. It accepts the following options:</para>
- <itemizedlist>
- <listitem>
- <para><command>yes</command> — Notifies slave servers.</para>
- </listitem>
- <listitem>
- <para><command>no</command> — Does not notify slave servers.</para>
- </listitem>
- <listitem>
- <para><command>explicit</command> — Only notifies slave servers specified in an <command>also-notify</command> list within a zone statement.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para><command>pid-file</command> — Specifies the location of the process ID file created by <command>named</command>.</para>
- </listitem>
- <listitem>
- <para><command>root-delegation-only</command> — Turns on the enforcement of delegation properties in top-level domains (TLDs) and root zones with an optional exclude list. <firstterm>Delegation</firstterm> is the process of
- separating a single zone into multiple subzones. In order to create a delegated zone, items known as <firstterm>NS records</firstterm> are used. NameServer records (delegation records) announce the authoritative nameservers for a particular zone.</para>
- <para>The following <command>root-delegation-only</command> example specifies an exclude list of TLDs from whom undelegated responses are expected and trusted:</para>
+ <para>In this example, only requests that arrive from the network interface serving the private network (<command>10.0.1.1</command>) are accepted.</para>
+ </listitem>
+ <listitem>
+ <para><command>notify</command> — Controls whether <command>named</command> notifies the slave servers when a zone is updated. It accepts the following options:</para>
+ <itemizedlist>
+ <listitem>
+ <para><command>yes</command> — Notifies slave servers.</para>
+ </listitem>
+ <listitem>
+ <para><command>no</command> — Does not notify slave servers.</para>
+ </listitem>
+ <listitem>
+ <para><command>explicit</command> — Only notifies slave servers specified in an <command>also-notify</command> list within a zone statement.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para><command>pid-file</command> — Specifies the location of the process ID file created by <command>named</command>.</para>
+ </listitem>
+ <listitem>
+ <para><command>root-delegation-only</command> — Turns on the enforcement of delegation properties in top-level domains (TLDs) and root zones with an optional exclude list. <firstterm>Delegation</firstterm> is the process of
+ separating a single zone into multiple subzones. In order to create a delegated zone, items known as <firstterm>NS records</firstterm> are used. NameServer records (delegation records) announce the authoritative nameservers for a particular zone.</para>
+ <para>The following <command>root-delegation-only</command> example specifies an exclude list of TLDs from whom undelegated responses are expected and trusted:</para>
<screen>
-<command>options { root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id; "lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa"; "pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; }; };</command>
+<command>options { root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id; "lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa"; "pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; }; };</command>
</screen>
- </listitem>
- <listitem>
- <para><command>statistics-file</command> — Specifies an alternate location for statistics files. By default, <command>named</command> statistics are saved to the
- <filename>/var/named/named.stats</filename> file.</para>
- </listitem>
- </itemizedlist>
+ </listitem>
+ <listitem>
+ <para><command>statistics-file</command> — Specifies an alternate location for statistics files. By default, <command>named</command> statistics are saved to the
+ <filename>/var/named/named.stats</filename> file.</para>
+ </listitem>
+ </itemizedlist>
-->
- <para><!-- RHEL5: Dozens of other options are --> There are many other options also available, many of which rely upon one another to work properly. Refer to the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref
- linkend="s2-bind-installed-docs"/> and the <filename>named.conf</filename> man page for more details.</para>
+ <para>
+ <!-- RHEL5: Dozens of other options are --> There are many other options also available, many of which rely upon one another to work properly. Refer to the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs" /> and the <filename>named.conf</filename> man page for more details.
+ </para>
</section>
- <section
- id="s3-bind-namedconf-state-zone">
- <title>
- <command>zone</command> Statement</title>
- <para>A <command>zone</command> statement defines the characteristics of a zone, such as the location of its configuration file and zone-specific options. This statement can be used to override the global <command>options</command> statements.</para>
- <para>A <command>zone</command> statement takes the following form:</para>
+ <section id="s3-bind-namedconf-state-zone">
+ <title><command>zone</command> Statement</title>
+ <para>
+ A <command>zone</command> statement defines the characteristics of a zone, such as the location of its configuration file and zone-specific options. This statement can be used to override the global <command>options</command> statements.
+ </para>
+ <para>
+ A <command>zone</command> statement takes the following form:
+ </para>
<screen>zone <replaceable><zone-name></replaceable>
<replaceable><zone-class></replaceable>
<replaceable><zone-options></replaceable>;
[<replaceable><zone-options></replaceable>; ...]
};</screen>
- <para>In this statement, <replaceable><zone-name></replaceable> is the name of the zone, <replaceable><zone-class></replaceable> is the optional class of the zone, and <replaceable><zone-options></replaceable> is a list of options characterizing the zone.</para>
- <para>The <replaceable><zone-name></replaceable> attribute for the zone statement is particularly important. It is the default value assigned for the <command>$ORIGIN</command> directive used within the corresponding zone file located in the <filename>/var/named/</filename> directory. The <command>named</command> daemon appends the name of the zone to any non-fully qualified domain name listed in the zone file.</para>
- <para>For example, if a <command>zone</command> statement defines the namespace for <command>example.com</command>, use <command>example.com</command> as the <replaceable><zone-name></replaceable> so it is placed at the end of hostnames within the <command>example.com</command> zone file.</para>
- <para>For more information about zone files, <!-- RHEL5: see -->refer to <xref
- linkend="s1-bind-zone"/>.</para>
- <para>The most common <command>zone</command> statement options include the following:</para>
+ <para>
+ In this statement, <replaceable><zone-name></replaceable> is the name of the zone, <replaceable><zone-class></replaceable> is the optional class of the zone, and <replaceable><zone-options></replaceable> is a list of options characterizing the zone.
+ </para>
+ <para>
+ The <replaceable><zone-name></replaceable> attribute for the zone statement is particularly important. It is the default value assigned for the <command>$ORIGIN</command> directive used within the corresponding zone file located in the <filename>/var/named/</filename> directory. The <command>named</command> daemon appends the name of the zone to any non-fully qualified domain name listed in the zone file.
+ </para>
+ <para>
+ For example, if a <command>zone</command> statement defines the namespace for <command>example.com</command>, use <command>example.com</command> as the <replaceable><zone-name></replaceable> so it is placed at the end of hostnames within the <command>example.com</command> zone file.
+ </para>
+ <para>
+ For more information about zone files, <!-- RHEL5: see -->refer to <xref linkend="s1-bind-zone" />.
+ </para>
+ <para>
+ The most common <command>zone</command> statement options include the following:
+ </para>
<variablelist>
<varlistentry>
- <term>
- <command>allow-query</command>
- </term>
+ <term><command>allow-query</command></term>
<listitem>
- <para>Specifies the clients that are allowed to request information about this zone. Setting of this option overrides global <command>allow-query</command> option. The default is to allow all query requests.</para>
+ <para>
+ Specifies the clients that are allowed to request information about this zone. Setting of this option overrides global <command>allow-query</command> option. The default is to allow all query requests.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>allow-transfer</command>
- </term>
+ <term><command>allow-transfer</command></term>
<listitem>
- <para>Specifies the slave servers that are allowed to request a transfer of the zone's information. The default is to allow all transfer requests.</para>
+ <para>
+ Specifies the slave servers that are allowed to request a transfer of the zone's information. The default is to allow all transfer requests.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>allow-update</command>
- </term>
+ <term><command>allow-update</command></term>
<listitem>
- <para>Specifies the hosts that are allowed to dynamically update information in their zone. The default is to deny all dynamic update requests.</para>
- <para>Be careful when allowing hosts to update information about their zone. Do not set IP addresses in this option unless the server is in the trusted network. Use TSIG key instead <!-- TODO: refer to section 7.5.3, TSIG authentication-->.</para>
+ <para>
+ Specifies the hosts that are allowed to dynamically update information in their zone. The default is to deny all dynamic update requests.
+ </para>
+ <para>
+ Be careful when allowing hosts to update information about their zone. Do not set IP addresses in this option unless the server is in the trusted network. Use TSIG key instead <!-- TODO: refer to section 7.5.3, TSIG authentication-->.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>file</command>
- </term>
+ <term><command>file</command></term>
<listitem>
- <para>Specifies the name of the file in the <command>named</command> working directory that contains the zone's configuration data.</para>
+ <para>
+ Specifies the name of the file in the <command>named</command> working directory that contains the zone's configuration data.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>masters</command>
- </term>
+ <term><command>masters</command></term>
<listitem>
- <para>Specifies the IP addresses from which to request authoritative zone information and is used only if the zone is defined as <command>type</command>
- <command>slave</command>.</para>
+ <para>
+ Specifies the IP addresses from which to request authoritative zone information and is used only if the zone is defined as <command>type</command> <command>slave</command>.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>notify</command>
- </term>
+ <term><command>notify</command></term>
<listitem>
- <para>Specifies whether or not <command>named</command> notifies the slave servers when a zone is updated. This option has same parameters as a global <command>notify</command> parameter.</para>
+ <para>
+ Specifies whether or not <command>named</command> notifies the slave servers when a zone is updated. This option has same parameters as a global <command>notify</command> parameter.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>type</command>
- </term>
+ <term><command>type</command></term>
<listitem>
- <para>Defines the type of zone.</para>
- <para>Below is a list of valid options:</para>
+ <para>
+ Defines the type of zone.
+ </para>
+ <para>
+ Below is a list of valid options:
+ </para>
<itemizedlist>
<listitem>
<para>
- <command>delegation-only</command> — Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as <command>NXDOMAIN</command>. This option is only applicable in TLDs or root zone files used in recursive or caching implementations.</para>
+ <command>delegation-only</command> — Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as <command>NXDOMAIN</command>. This option is only applicable in TLDs or root zone files used in recursive or caching implementations.
+ </para>
</listitem>
<listitem>
<para>
- <command>forward</command> — Forwards all requests for information about this zone to other nameservers.</para>
+ <command>forward</command> — Forwards all requests for information about this zone to other nameservers.
+ </para>
</listitem>
<listitem>
<para>
- <command>hint</command> — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a <command>hint</command> zone.</para>
+ <command>hint</command> — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a <command>hint</command> zone.
+ </para>
</listitem>
<listitem>
<para>
- <command>master</command> — Designates the nameserver as authoritative for this zone. A zone should be set as the <command>master</command> if the zone's configuration files reside on the system.</para>
+ <command>master</command> — Designates the nameserver as authoritative for this zone. A zone should be set as the <command>master</command> if the zone's configuration files reside on the system.
+ </para>
</listitem>
<listitem>
<para>
- <command>slave</command> — Designates the nameserver as a slave server for this zone. Master server is specified in <command>masters</command> directive.</para>
+ <command>slave</command> — Designates the nameserver as a slave server for this zone. Master server is specified in <command>masters</command> directive.
+ </para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
- <itemizedlist>
- <listitem>
- <para><command>allow-query</command> — Specifies the clients that are allowed to request information about this zone. The default is to allow all query requests.</para>
- </listitem>
- <listitem>
- <para><command>allow-transfer</command> — Specifies the slave servers that are allowed to request a transfer of the zone's information. The default is to allow all transfer requests.</para>
- </listitem>
- <listitem>
- <para><command>allow-update</command> — Specifies the hosts that are allowed to dynamically update information in their zone. The default is to deny all dynamic update requests.</para>
- <para>Be careful when allowing hosts to update information about their zone. Do not enable this option unless the host specified is completely trusted. In general, it better to have an administrator manually update the records for a zone and reload the
- <command>named</command> service.</para>
- </listitem>
- <listitem>
- <para><command>file</command> — Specifies the name of the file in the <command>named</command> working directory that contains the zone's configuration data.</para>
- </listitem>
- <listitem>
- <para><command>masters</command> — Specifies the IP addresses from which to request authoritative zone information and is used only if the zone is defined as <command>type</command>
- <command>slave</command>.</para>
- </listitem>
- <listitem>
- <para><command>notify</command> — Specifies whether or not <command>named</command> notifies the slave servers when a zone is updated. This directive accepts the following options:</para>
- <itemizedlist>
- <listitem>
- <para><command>yes</command> — Notifies slave servers.</para>
- </listitem>
- <listitem>
- <para><command>no</command> — Does not notify slave servers.</para>
- </listitem>
- <listitem>
- <para><command>explicit</command> — Only notifies slave servers specified in an <command>also-notify</command> list within a zone statement.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para><command>type</command> — Defines the type of zone.</para>
- <para>Below is a list of valid options:</para>
- <itemizedlist>
- <listitem>
- <para><command>delegation-only</command> — Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as
- <command>NXDOMAIN</command>. This option is only applicable in TLDs or root zone files used in recursive or caching implementations.</para>
- </listitem>
- <listitem>
- <para><command>forward</command> — Forwards all requests for information about this zone to other nameservers.</para>
- </listitem>
- <listitem>
- <para><command>hint</command> — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a
- <command>hint</command> zone.</para>
- </listitem>
- <listitem>
- <para><command>master</command> — Designates the nameserver as authoritative for this zone. A zone should be set as the <command>master</command> if the zone's configuration files reside on the system.</para>
- </listitem>
- <listitem>
- <para><command>slave</command> — Designates the nameserver as a slave server for this zone. Also specifies the IP address of the master nameserver for the zone.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para><command>zone-statistics</command> — Configures <command>named</command> to keep statistics concerning this zone, writing them to either the default location
- (<filename>/var/named/named.stats</filename>) or the file listed in the <command>statistics-file</command> option in the <command>server</command> statement. Refer to
- <xref linkend="s2-bind-namedconf-state-other"/> for more information about the <command>server</command> statement.</para>
- </listitem>
- </itemizedlist>
+ <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
+ <itemizedlist>
+ <listitem>
+ <para><command>allow-query</command> — Specifies the clients that are allowed to request information about this zone. The default is to allow all query requests.</para>
+ </listitem>
+ <listitem>
+ <para><command>allow-transfer</command> — Specifies the slave servers that are allowed to request a transfer of the zone's information. The default is to allow all transfer requests.</para>
+ </listitem>
+ <listitem>
+ <para><command>allow-update</command> — Specifies the hosts that are allowed to dynamically update information in their zone. The default is to deny all dynamic update requests.</para>
+ <para>Be careful when allowing hosts to update information about their zone. Do not enable this option unless the host specified is completely trusted. In general, it better to have an administrator manually update the records for a zone and reload the
+ <command>named</command> service.</para>
+ </listitem>
+ <listitem>
+ <para><command>file</command> — Specifies the name of the file in the <command>named</command> working directory that contains the zone's configuration data.</para>
+ </listitem>
+ <listitem>
+ <para><command>masters</command> — Specifies the IP addresses from which to request authoritative zone information and is used only if the zone is defined as <command>type</command>
+ <command>slave</command>.</para>
+ </listitem>
+ <listitem>
+ <para><command>notify</command> — Specifies whether or not <command>named</command> notifies the slave servers when a zone is updated. This directive accepts the following options:</para>
+ <itemizedlist>
+ <listitem>
+ <para><command>yes</command> — Notifies slave servers.</para>
+ </listitem>
+ <listitem>
+ <para><command>no</command> — Does not notify slave servers.</para>
+ </listitem>
+ <listitem>
+ <para><command>explicit</command> — Only notifies slave servers specified in an <command>also-notify</command> list within a zone statement.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para><command>type</command> — Defines the type of zone.</para>
+ <para>Below is a list of valid options:</para>
+ <itemizedlist>
+ <listitem>
+ <para><command>delegation-only</command> — Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as
+ <command>NXDOMAIN</command>. This option is only applicable in TLDs or root zone files used in recursive or caching implementations.</para>
+ </listitem>
+ <listitem>
+ <para><command>forward</command> — Forwards all requests for information about this zone to other nameservers.</para>
+ </listitem>
+ <listitem>
+ <para><command>hint</command> — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a
+ <command>hint</command> zone.</para>
+ </listitem>
+ <listitem>
+ <para><command>master</command> — Designates the nameserver as authoritative for this zone. A zone should be set as the <command>master</command> if the zone's configuration files reside on the system.</para>
+ </listitem>
+ <listitem>
+ <para><command>slave</command> — Designates the nameserver as a slave server for this zone. Also specifies the IP address of the master nameserver for the zone.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para><command>zone-statistics</command> — Configures <command>named</command> to keep statistics concerning this zone, writing them to either the default location
+ (<filename>/var/named/named.stats</filename>) or the file listed in the <command>statistics-file</command> option in the <command>server</command> statement. Refer to
+ <xref linkend="s2-bind-namedconf-state-other"/> for more information about the <command>server</command> statement.</para>
+ </listitem>
+ </itemizedlist>
-->
</section>
- <section
- id="s3-bind-configuration-named-zone">
+ <section id="s3-bind-configuration-named-zone">
<title>Sample <command>zone</command> Statements</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration of</secondary>
- <tertiary>
- <command>zone</command> statements sample</tertiary>
+ <tertiary><command>zone</command> statements sample</tertiary>
</indexterm>
- <para>Most changes to the <filename>/etc/named.conf</filename> file of a master or slave nameserver involves adding, modifying, or deleting <command>zone</command> statements. While these <command>zone</command> statements can contain many options, most nameservers require only a small subset to function efficiently. The following <command>zone</command> statements are very basic examples illustrating a master-slave nameserver relationship.</para>
- <para>The following is an example of a <command>zone</command> statement for the primary nameserver hosting <command>example.com</command> (<command>192.168.0.1</command>):</para>
+ <para>
+ Most changes to the <filename>/etc/named.conf</filename> file of a master or slave nameserver involves adding, modifying, or deleting <command>zone</command> statements. While these <command>zone</command> statements can contain many options, most nameservers require only a small subset to function efficiently. The following <command>zone</command> statements are very basic examples illustrating a master-slave nameserver relationship.
+ </para>
+ <para>
+ The following is an example of a <command>zone</command> statement for the primary nameserver hosting <command>example.com</command> (<command>192.168.0.1</command>):
+ </para>
<screen>zone "example.com" IN {
type master;
file "example.com.zone";
allow-transfer { 192.168.0.2; };
};</screen>
- <para>In the statement, the zone is identified as <command>example.com</command>, the type is set to <command>master</command>, and the <command>named</command> service is instructed to read the <filename>/var/named/example.com.zone</filename> file. It also allows only slave nameserver (<command>192.168.0.2</command>) to transfer the zone.</para>
- <para>A slave server's <command>zone</command> statement for
-<command>example.com</command> is slightly different from the previous example. For a slave server, the type is set to <command>slave</command> and the <command>masters</command> directive is telling <command>named</command> the IP address of the master server.</para>
- <para>The following is an example slave server <command>zone</command> statement for <command>example.com</command> zone:</para>
+ <para>
+ In the statement, the zone is identified as <command>example.com</command>, the type is set to <command>master</command>, and the <command>named</command> service is instructed to read the <filename>/var/named/example.com.zone</filename> file. It also allows only slave nameserver (<command>192.168.0.2</command>) to transfer the zone.
+ </para>
+ <para>
+ A slave server's <command>zone</command> statement for <command>example.com</command> is slightly different from the previous example. For a slave server, the type is set to <command>slave</command> and the <command>masters</command> directive is telling <command>named</command> the IP address of the master server.
+ </para>
+ <para>
+ The following is an example slave server <command>zone</command> statement for <command>example.com</command> zone:
+ </para>
<screen>zone "example.com"{
type slave;
file "slaves/example.com.zone";
masters { 192.168.0.1; };
};</screen>
- <para>This <command>zone</command> statement configures <command>named</command> on the slave server to query the master server at the <command>192.168.0.1</command> IP address for information about the <command>example.com</command> zone. The information that the slave server receives from the master server is saved to the <filename>/var/named/slaves/example.com.zone</filename> file. Make sure you put all slave zones to <filename>/var/named/slaves</filename> directory otherwise <command>named</command> will fail to transfer the zone.</para>
+ <para>
+ This <command>zone</command> statement configures <command>named</command> on the slave server to query the master server at the <command>192.168.0.1</command> IP address for information about the <command>example.com</command> zone. The information that the slave server receives from the master server is saved to the <filename>/var/named/slaves/example.com.zone</filename> file. Make sure you put all slave zones to <filename>/var/named/slaves</filename> directory otherwise <command>named</command> will fail to transfer the zone.
+ </para>
</section>
</section>
- <section
- id="s2-bind-namedconf-state-other">
+ <section id="s2-bind-namedconf-state-other">
<title>Other Statement Types</title>
- <para>The following is a list of lesser used statement types available within <filename>named.conf</filename>:</para>
+ <para>
+ The following is a list of lesser used statement types available within <filename>named.conf</filename>:
+ </para>
<variablelist>
<varlistentry>
- <term>
- <command>controls</command>
- </term>
+ <term><command>controls</command></term>
<listitem>
- <para>Configures various security requirements necessary to use the <command>rndc</command> command to administer the <command>named</command> service.</para>
- <para>Refer to <xref
- linkend="s2-bind-rndc-configuration-namedconf"/> to learn more about how the <command>controls</command> statement is structured and <!-- RHEL5: available options -->what options are available.</para>
+ <para>
+ Configures various security requirements necessary to use the <command>rndc</command> command to administer the <command>named</command> service.
+ </para>
+ <para>
+ Refer to <xref linkend="s2-bind-rndc-configuration-namedconf" /> to learn more about how the <command>controls</command> statement is structured and <!-- RHEL5: available options -->what options are available.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>key "<replaceable><key-name></replaceable>"</command>
- </term>
+ <term><command>key "<replaceable><key-name></replaceable>"</command></term>
<listitem>
- <para>Defines a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the <command>rndc</command> command. Two options are used with <command>key</command>:</para>
+ <para>
+ Defines a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the <command>rndc</command> command. Two options are used with <command>key</command>:
+ </para>
<itemizedlist>
<listitem>
<para>
- <command>algorithm <replaceable><algorithm-name></replaceable>
- </command> — The type of algorithm used, such as <command>hmac-md5</command>.</para>
+ <command>algorithm <replaceable><algorithm-name></replaceable></command> — The type of algorithm used, such as <command>hmac-md5</command>.
+ </para>
</listitem>
<listitem>
<para>
- <command>secret "<replaceable><key-value></replaceable>"</command> — The encrypted key.</para>
+ <command>secret "<replaceable><key-value></replaceable>"</command> — The encrypted key.
+ </para>
</listitem>
</itemizedlist>
- <para>Refer to <xref
- linkend="s2-bind-rndc-configuration-rndcconf"/> for instructions on how to write a <command>key</command> statement.</para>
+ <para>
+ Refer to <xref linkend="s2-bind-rndc-configuration-rndcconf" /> for instructions on how to write a <command>key</command> statement.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>logging</command>
- </term>
+ <term><command>logging</command></term>
<listitem>
- <para>Allows for the use of multiple types of logs, called <firstterm>channels</firstterm>. By using the <command>channel</command> option within the <command>logging</command> statement, a customized type of log can be constructed — with its own file name (<command>file</command>), size limit (<command>size</command>), versioning (<command>version</command>), and level of importance (<command>severity</command>). Once a customized channel <!-- RHEL5: has been -->is defined, a <command>category</command> option is used to categorize the channel and begin logging when <command>named</command> is restarted.</para>
- <para>By default, <command>named</command> logs standard messages to the <command>rsyslog</command> daemon, which places them in <filename>/var/log/messages</filename>. This occurs because several standard channels are built into BIND with various severity levels, such as <command>default_syslog</command> (which handles informational logging messages) and <command>default_debug</command> (which specifically handles debugging messages). A default category, called <command>default</command>, uses the built-in channels to do normal logging without any special configuration.</para>
- <!-- RHEL5: ddomingo at redhat.com: above <para>replaces following:
- <para>By default, <command>named</command> logs standard messages to the <command>syslog</command> daemon, which places them in <filename>/var/log/messages</filename>. This occurs because several standard channels are built into BIND with various severity levels, such as one that handles informational logging messages (<command>default_syslog</command>) and another that specifically handles debugging messages (<command>default_debug</command>). A default category, called <command>default</command>, uses the built-in channels to do normal logging without any special configuration.</para>
+ <para>
+ Allows for the use of multiple types of logs, called <firstterm>channels</firstterm>. By using the <command>channel</command> option within the <command>logging</command> statement, a customized type of log can be constructed — with its own file name (<command>file</command>), size limit (<command>size</command>), versioning (<command>version</command>), and level of importance (<command>severity</command>). Once a customized channel <!-- RHEL5: has been -->is defined, a <command>category</command> option is used to categorize the channel and begin logging when <command>named</command> is restarted.
+ </para>
+ <para>
+ By default, <command>named</command> logs standard messages to the <command>rsyslog</command> daemon, which places them in <filename>/var/log/messages</filename>. This occurs because several standard channels are built into BIND with various severity levels, such as <command>default_syslog</command> (which handles informational logging messages) and <command>default_debug</command> (which specifically handles debugging messages). A default category, called <command>default</command>, uses the built-in channels to do normal logging without any special configuration.
+ </para>
+ <!-- RHEL5: ddomingo at redhat.com: above <para>replaces following:
+ <para>By default, <command>named</command> logs standard messages to the <command>syslog</command> daemon, which places them in <filename>/var/log/messages</filename>. This occurs because several standard channels are built into BIND with various severity levels, such as one that handles informational logging messages (<command>default_syslog</command>) and another that specifically handles debugging messages (<command>default_debug</command>). A default category, called <command>default</command>, uses the built-in channels to do normal logging without any special configuration.</para>
-->
- <para>Customizing the logging process can be a very detailed process and is beyond the scope of this chapter. For information on creating custom BIND logs, refer to the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref
- linkend="s2-bind-installed-docs"/>.</para>
+ <para>
+ Customizing the logging process can be a very detailed process and is beyond the scope of this chapter. For information on creating custom BIND logs, refer to the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/>.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>server</command>
- </term>
+ <term><command>server</command></term>
<listitem>
- <para>Specifies options that affect how <command>named</command> should respond to remote nameservers, especially <!-- RHEL5: in regards -->with regard to notifications and zone transfers.</para>
- <para>The <command>transfer-format</command> option controls whether one resource record is sent with each message (<command>one-answer</command>) or multiple resource records are sent with each message (<command>many-answers</command>). While <command>many-answers</command> is more efficient, only newer BIND nameservers understand it.</para>
+ <para>
+ Specifies options that affect how <command>named</command> should respond to remote nameservers, especially <!-- RHEL5: in regards -->with regard to notifications and zone transfers.
+ </para>
+ <para>
+ The <command>transfer-format</command> option controls whether one resource record is sent with each message (<command>one-answer</command>) or multiple resource records are sent with each message (<command>many-answers</command>). While <command>many-answers</command> is more efficient, only newer BIND nameservers understand it.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>trusted-keys</command>
- </term>
+ <term><command>trusted-keys</command></term>
<listitem>
- <para>Contains assorted public keys used for secure DNS (DNSSEC). Refer to <xref
- linkend="s2-bind-features-dnssec"/> for more information about DNSSEC.</para>
+ <para>
+ Contains assorted public keys used for secure DNS (DNSSEC). Refer to <xref linkend="s2-bind-features-dnssec" /> for more information about DNSSEC.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>view "<replaceable><view-name></replaceable>"</command>
- </term>
+ <term><command>view "<replaceable><view-name></replaceable>"</command></term>
<listitem>
- <para>Creates special views depending upon which network the host querying the nameserver is on. This allows some hosts to receive one answer regarding a zone while other hosts receive totally different information. Alternatively, certain zones may only be made available to particular trusted hosts while non-trusted hosts can only make queries for other zones.</para>
- <para>Multiple views may be used, but their names must be unique. The <command>match-clients</command> option specifies the IP addresses that apply to a particular view. Any <command>options</command> <!-- RHEL5: statements -->statement may also be used within a view, overriding the global options already configured for <command>named</command>. Most <command>view</command> statements contain multiple <command>zone</command> statements that apply to the <command>match-clients</command> list. The order in which <command>view</command> statements are listed is important, as the first <command>view</command> statement that matches a particular client's IP address is used.</para>
- <para>Refer to <xref
- linkend="s2-bind-features-views"/> for more information about the <command>view</command> statement.</para>
+ <para>
+ Creates special views depending upon which network the host querying the nameserver is on. This allows some hosts to receive one answer regarding a zone while other hosts receive totally different information. Alternatively, certain zones may only be made available to particular trusted hosts while non-trusted hosts can only make queries for other zones.
+ </para>
+ <para>
+ Multiple views may be used, but their names must be unique. The <command>match-clients</command> option specifies the IP addresses that apply to a particular view. Any <command>options</command> <!-- RHEL5: statements -->statement may also be used within a view, overriding the global options already configured for <command>named</command>. Most <command>view</command> statements contain multiple <command>zone</command> statements that apply to the <command>match-clients</command> list. The order in which <command>view</command> statements are listed is important, as the first <command>view</command> statement that matches a particular client's IP address is used.
+ </para>
+ <para>Refer to <xref linkend="s2-bind-features-views" /> for more information about the <command>view</command> statement.
+ </para>
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
- <itemizedlist>
- <listitem>
- <para><command>controls</command> — Configures various security requirements necessary to use the <command>rndc</command> command to administer the <command>named</command> service.</para>
- <para>Refer to <xref linkend="s2-bind-rndc-configuration-namedconf"/> to learn more about how the <command>controls</command> statement is structured and available options.</para>
- </listitem>
- <listitem>
- <para><command>key "<replaceable><key-name></replaceable>"</command> — Defines a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the
- <command>rndc</command> command. Two options are used with <command>key</command>:</para>
- <itemizedlist>
- <listitem>
- <para><command>algorithm <replaceable><algorithm-name></replaceable></command> — The type of algorithm used, such as <command>dsa</command> or <command>hmac-md5</command>.</para>
- </listitem>
- <listitem>
- <para><command>secret "<replaceable><key-value></replaceable>"</command> — The encrypted key.</para>
- </listitem>
- </itemizedlist>
- <para>Refer to <xref linkend="s2-bind-rndc-configuration-rndcconf"/> for instructions on how to write a <command>key</command> statement.</para>
- </listitem>
- <listitem>
- <para><command>logging</command> — Allows for the use of multiple types of logs, called <firstterm>channels</firstterm>. By using the <command>channel</command> option within the
- <command>logging</command> statement, a customized type of log, with its own file name (<command>file</command>), size limit (<command>size</command>), versioning
- (<command>version</command>), and level of importance (<command>severity</command>), can be constructed. Once a customized channel has been defined, a <command>category</command> option is used to
- categorize the channel and begin logging when <command>named</command> is restarted.</para>
- <para>By default, <command>named</command> logs standard messages to the <command>syslog</command> daemon, which places them in <filename>/var/log/messages</filename>. This occurs because several standard
- channels are built into BIND with various severity levels, such as one that handles informational logging messages (<command>default_syslog</command>) and another that specifically handles debugging messages
- (<command>default_debug</command>). A default category, called <command>default</command>, uses the built-in channels to do normal logging without any special configuration.</para>
- <para>Customizing the logging process can be a very detailed process and is beyond the scope of this chapter. For information on creating custom BIND logs, refer to the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in
- <xref linkend="s2-bind-installed-docs"/>.</para>
- </listitem>
- <listitem>
- <para><command>server</command> — Specifies options that affect how <command>named</command> should respond to remote nameservers, especially in regards to notifications and zone transfers.</para>
- <para>The <command>transfer-format</command> option controls whether one resource record is sent with each message (<command>one-answer</command>) or multiple resource records are sent with each message
- (<command>many-answers</command>). While <command>many-answers</command> is more efficient, only newer BIND nameservers understand it.</para>
- </listitem>
- <listitem>
- <para><command>trusted-keys</command> — Contains assorted public keys used for secure DNS (DNSSEC). Refer to <xref linkend="s2-bind-features-security"/> for more information concerning BIND security.</para>
- </listitem>
- <listitem>
- <para><command>view "<replaceable><view-name></replaceable>"</command> — Creates special views depending upon which network the host querying the nameserver is on. This allows some hosts to receive one answer regarding a zone
- while other hosts receive totally different information. Alternatively, certain zones may only be made available to particular trusted hosts while non-trusted hosts can only make queries for other zones.</para>
- <para>Multiple views may be used, but their names must be unique. The <command>match-clients</command> option specifies the IP addresses that apply to a particular view. Any <command>options</command> statements may also be
- used within a view, overriding the global options already configured for <command>named</command>. Most <command>view</command> statements contain multiple <command>zone</command> statements that apply
- to the <command>match-clients</command> list. The order in which <command>view</command> statements are listed is important, as the first <command>view</command> statement that matches a particular
- client's IP address is used.</para>
- <para>Refer to <xref linkend="s2-bind-features-views"/> for more information about the <command>view</command> statement.</para>
- </listitem>
- </itemizedlist>
+ <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
+ <itemizedlist>
+ <listitem>
+ <para><command>controls</command> — Configures various security requirements necessary to use the <command>rndc</command> command to administer the <command>named</command> service.</para>
+ <para>Refer to <xref linkend="s2-bind-rndc-configuration-namedconf"/> to learn more about how the <command>controls</command> statement is structured and available options.</para>
+ </listitem>
+ <listitem>
+ <para><command>key "<replaceable><key-name></replaceable>"</command> — Defines a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the
+ <command>rndc</command> command. Two options are used with <command>key</command>:</para>
+ <itemizedlist>
+ <listitem>
+ <para><command>algorithm <replaceable><algorithm-name></replaceable></command> — The type of algorithm used, such as <command>dsa</command> or <command>hmac-md5</command>.</para>
+ </listitem>
+ <listitem>
+ <para><command>secret "<replaceable><key-value></replaceable>"</command> — The encrypted key.</para>
+ </listitem>
+ </itemizedlist>
+ <para>Refer to <xref linkend="s2-bind-rndc-configuration-rndcconf"/> for instructions on how to write a <command>key</command> statement.</para>
+ </listitem>
+ <listitem>
+ <para><command>logging</command> — Allows for the use of multiple types of logs, called <firstterm>channels</firstterm>. By using the <command>channel</command> option within the
+ <command>logging</command> statement, a customized type of log, with its own file name (<command>file</command>), size limit (<command>size</command>), versioning
+ (<command>version</command>), and level of importance (<command>severity</command>), can be constructed. Once a customized channel has been defined, a <command>category</command> option is used to
+ categorize the channel and begin logging when <command>named</command> is restarted.</para>
+ <para>By default, <command>named</command> logs standard messages to the <command>syslog</command> daemon, which places them in <filename>/var/log/messages</filename>. This occurs because several standard
+ channels are built into BIND with various severity levels, such as one that handles informational logging messages (<command>default_syslog</command>) and another that specifically handles debugging messages
+ (<command>default_debug</command>). A default category, called <command>default</command>, uses the built-in channels to do normal logging without any special configuration.</para>
+ <para>Customizing the logging process can be a very detailed process and is beyond the scope of this chapter. For information on creating custom BIND logs, refer to the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in
+ <xref linkend="s2-bind-installed-docs"/>.</para>
+ </listitem>
+ <listitem>
+ <para><command>server</command> — Specifies options that affect how <command>named</command> should respond to remote nameservers, especially in regards to notifications and zone transfers.</para>
+ <para>The <command>transfer-format</command> option controls whether one resource record is sent with each message (<command>one-answer</command>) or multiple resource records are sent with each message
+ (<command>many-answers</command>). While <command>many-answers</command> is more efficient, only newer BIND nameservers understand it.</para>
+ </listitem>
+ <listitem>
+ <para><command>trusted-keys</command> — Contains assorted public keys used for secure DNS (DNSSEC). Refer to <xref linkend="s2-bind-features-security"/> for more information concerning BIND security.</para>
+ </listitem>
+ <listitem>
+ <para><command>view "<replaceable><view-name></replaceable>"</command> — Creates special views depending upon which network the host querying the nameserver is on. This allows some hosts to receive one answer regarding a zone
+ while other hosts receive totally different information. Alternatively, certain zones may only be made available to particular trusted hosts while non-trusted hosts can only make queries for other zones.</para>
+ <para>Multiple views may be used, but their names must be unique. The <command>match-clients</command> option specifies the IP addresses that apply to a particular view. Any <command>options</command> statements may also be
+ used within a view, overriding the global options already configured for <command>named</command>. Most <command>view</command> statements contain multiple <command>zone</command> statements that apply
+ to the <command>match-clients</command> list. The order in which <command>view</command> statements are listed is important, as the first <command>view</command> statement that matches a particular
+ client's IP address is used.</para>
+ <para>Refer to <xref linkend="s2-bind-features-views"/> for more information about the <command>view</command> statement.</para>
+ </listitem>
+ </itemizedlist>
-->
</section>
- <section
- id="s2-bind-namedconf-comm">
+ <section id="s2-bind-namedconf-comm">
<title>Comment Tags</title>
- <para>The following is a list of valid comment tags used within <filename>named.conf</filename>:</para>
+ <para>
+ The following is a list of valid comment tags used within <filename>named.conf</filename>:
+ </para>
<itemizedlist>
<listitem>
<para>
- <command>//</command> — When placed at the beginning of a line, that line is ignored by <command>named</command>.</para>
+ <command>//</command> — When placed at the beginning of a line, that line is ignored by <command>named</command>.
+ </para>
</listitem>
<listitem>
<para>
- <command>#</command> — When placed at the beginning of a line, that line is ignored by <command>named</command>.</para>
+ <command>#</command> — When placed at the beginning of a line, that line is ignored by <command>named</command>.
+ </para>
</listitem>
<listitem>
<para>
- <command>/*</command> and <command>*/</command> — When text is enclosed in these tags, the block of text is ignored by <command>named</command>.</para>
+ <command>/*</command> and <command>*/</command> — When text is enclosed in these tags, the block of text is ignored by <command>named</command>.
+ </para>
</listitem>
</itemizedlist>
</section>
</section>
- <section
- id="s1-bind-zone">
+ <section id="s1-bind-zone">
<title>Zone Files</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration files</secondary>
<tertiary>zone files</tertiary>
</indexterm>
<para>
- <firstterm>Zone files</firstterm> contain information about a namespace and are stored in the <command>named</command> working directory (<filename>/var/named/</filename>) by default. Each zone file is named according to the <command>file</command> option data in the <command>zone</command> statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as <filename>example.com.zone</filename>.</para>
- <para>Each zone file may contain <firstterm>directives</firstterm> and <firstterm>resource records</firstterm>. Directives tell the nameserver to perform tasks or apply special settings to the zone. Resource records define the parameters of the zone and assign identities to individual hosts. Directives are optional, but resource records are required to provide name service to a zone.</para>
- <para>All directives and resource records should be entered on individual lines.</para>
- <para>Comments can be placed after semicolon characters (<command>;</command>) in zone files.</para>
- <section
- id="s2-bind-zone-directives">
+ <firstterm>Zone files</firstterm> contain information about a namespace and are stored in the <command>named</command> working directory (<filename>/var/named/</filename>) by default. Each zone file is named according to the <command>file</command> option data in the <command>zone</command> statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as <filename>example.com.zone</filename>.
+ </para>
+ <para>
+ Each zone file may contain <firstterm>directives</firstterm> and <firstterm>resource records</firstterm>. Directives tell the nameserver to perform tasks or apply special settings to the zone. Resource records define the parameters of the zone and assign identities to individual hosts. Directives are optional, but resource records are required to provide name service to a zone.
+ </para>
+ <para>
+ All directives and resource records should be entered on individual lines.
+ </para>
+ <para>
+ Comments can be placed after semicolon characters (<command>;</command>) in zone files.
+ </para>
+ <section id="s2-bind-zone-directives">
<title>Zone File Directives</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration of</secondary>
<tertiary>zone file directives</tertiary>
</indexterm>
- <para>Directives begin with the dollar sign character (<command>$</command>) followed by the name of the directive. They usually appear at the top of the zone file.</para>
- <para>The following are commonly used directives:</para>
+ <para>
+ Directives begin with the dollar sign character (<command>$</command>) followed by the name of the directive. They usually appear at the top of the zone file.
+ </para>
+ <para>
+ The following are commonly used directives:
+ </para>
<variablelist>
<varlistentry>
- <term>
- <command>$INCLUDE</command>
- </term>
+ <term><command>$INCLUDE</command></term>
<listitem>
- <para>Configures <command>named</command> to include another zone file in this zone file at the place where the directive appears. This allows additional zone settings to be stored apart from the main zone file.</para>
+ <para>
+ Configures <command>named</command> to include another zone file in this zone file at the place where the directive appears. This allows additional zone settings to be stored apart from the main zone file.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>$ORIGIN</command>
- </term>
+ <term><command>$ORIGIN</command></term>
<listitem>
- <para>Appends the domain name to unqualified records, such as those with the hostname and nothing more.</para>
- <para>For example, a zone file may contain the following line:</para>
+ <para>
+ Appends the domain name to unqualified records, such as those with the hostname and nothing more.
+ </para>
+ <para>
+ For example, a zone file may contain the following line:
+ </para>
<screen>$ORIGIN example.com.</screen>
- <para>Any names used in resource records that do not end in a trailing period (<command>.</command>) are appended with <command>example.com</command>.</para>
+ <para>
+ Any names used in resource records that do not end in a trailing period (<command>.</command>) are appended with <command>example.com</command>.
+ </para>
<note>
<title>Note</title>
- <para>The use of the <command>$ORIGIN</command> directive is unnecessary if the zone is specified in <filename>/etc/named.conf</filename> because the zone name is used as the value for the <command>$ORIGIN</command> directive by default.</para>
+ <para>
+ The use of the <command>$ORIGIN</command> directive is unnecessary if the zone is specified in <filename>/etc/named.conf</filename> because the zone name is used as the value for the <command>$ORIGIN</command> directive by default.
+ </para>
</note>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>$TTL</command>
- </term>
+ <term><command>$TTL</command></term>
<listitem>
- <para>Sets the default <firstterm>Time to Live (TTL)</firstterm> value for the zone. This is the length of time, in seconds, that a zone resource record is valid. Each resource record can contain its own TTL value, which overrides this directive.</para>
- <para>Increasing this value allows remote nameservers to cache the zone information for a longer period of time, reducing the number of queries for the zone and lengthening the amount of time required to proliferate resource record changes.</para>
+ <para>
+ Sets the default <firstterm>Time to Live (TTL)</firstterm> value for the zone. This is the length of time, in seconds, that a zone resource record is valid. Each resource record can contain its own TTL value, which overrides this directive.
+ </para>
+ <para>
+ Increasing this value allows remote nameservers to cache the zone information for a longer period of time, reducing the number of queries for the zone and lengthening the amount of time required to proliferate resource record changes.
+ </para>
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
- <itemizedlist>
- <listitem>
- <para><command>$INCLUDE</command> — Configures <command>named</command> to include another zone file in this zone file at the place where the directive appears. This allows additional zone settings to be stored apart
- from the main zone file.</para>
- </listitem>
- <listitem>
- <para><command>$ORIGIN</command> — Appends the domain name to unqualified records, such as those with the hostname and nothing more.</para>
- <para>For example, a zone file may contain the following line:</para>
+ <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
+ <itemizedlist>
+ <listitem>
+ <para><command>$INCLUDE</command> — Configures <command>named</command> to include another zone file in this zone file at the place where the directive appears. This allows additional zone settings to be stored apart
+ from the main zone file.</para>
+ </listitem>
+ <listitem>
+ <para><command>$ORIGIN</command> — Appends the domain name to unqualified records, such as those with the hostname and nothing more.</para>
+ <para>For example, a zone file may contain the following line:</para>
<screen>
<command>$ORIGIN example.com.</command>
</screen>
- <para>Any names used in resource records that do not end in a trailing period (<command>.</command>) are appended with <command>example.com</command>.</para>
- <note>
- <title>Note</title>
- <para>The use of the <command>$ORIGIN</command> directive is unnecessary if the zone is specified in <filename>/etc/named.conf</filename> because the zone name is used as the value for the
- <command>$ORIGIN</command> directive by default.</para>
- </note>
- </listitem>
- <listitem>
- <para><command>$TTL</command> — Sets the default <firstterm>Time to Live (TTL)</firstterm> value for the zone. This is the length of time, in seconds, a zone resource record is valid. Each resource record can contain its own TTL
- value, which overrides this directive.</para>
- <para>Increasing this value allows remote nameservers to cache the zone information for a longer period of time, reducing the number of queries for the zone and lengthening the amount of time required to proliferate resource record changes.</para>
- </listitem>
- </itemizedlist>
+ <para>Any names used in resource records that do not end in a trailing period (<command>.</command>) are appended with <command>example.com</command>.</para>
+ <note>
+ <title>Note</title>
+ <para>The use of the <command>$ORIGIN</command> directive is unnecessary if the zone is specified in <filename>/etc/named.conf</filename> because the zone name is used as the value for the
+ <command>$ORIGIN</command> directive by default.</para>
+ </note>
+ </listitem>
+ <listitem>
+ <para><command>$TTL</command> — Sets the default <firstterm>Time to Live (TTL)</firstterm> value for the zone. This is the length of time, in seconds, a zone resource record is valid. Each resource record can contain its own TTL
+ value, which overrides this directive.</para>
+ <para>Increasing this value allows remote nameservers to cache the zone information for a longer period of time, reducing the number of queries for the zone and lengthening the amount of time required to proliferate resource record changes.</para>
+ </listitem>
+ </itemizedlist>
-->
</section>
- <section
- id="s3-bind-zone-rr">
+ <section id="s3-bind-zone-rr">
<title>Zone File Resource Records</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration of</secondary>
<tertiary>zone file resource records</tertiary>
</indexterm>
- <para>The primary component of a zone file is its resource records.</para>
- <para>There are many types of zone file resource records. The following are used most frequently:</para>
- <!-- RHEL5: ddomingo at redhat.com: replacement -->
+ <para>
+ The primary component of a zone file is its resource records.
+ </para>
+ <para>
+ There are many types of zone file resource records. The following are used most frequently:
+ </para>
+ <!-- RHEL5: ddomingo at redhat.com: replacement -->
<variablelist>
<varlistentry>
- <term>
- <command>A</command>
- </term>
+ <term><command>A</command></term>
<listitem>
- <para>This refers to the Address record, which specifies an IP address to assign to a name, as in this example:</para>
- <screen>
- <replaceable><host></replaceable> IN A <replaceable><IP-address></replaceable>
- </screen>
- <para>If the <replaceable><host></replaceable> value is omitted, then an <command>A</command> record points to the last specified <replaceable><host></replaceable>.</para>
- <para>Consider the following <command>A</command> record examples for the <command>example.com</command> zone file:</para>
- <screen>
-server1 IN A 10.0.1.3
- IN A 10.0.1.5
-</screen>
- <para>Requests for <command>server1.example.com</command> are pointed to 10.0.1.3 or 10.0.1.5.</para>
+ <para>
+ This refers to the Address record, which specifies an IP address to assign to a name, as in this example:
+ </para>
+ <screen><replaceable><host></replaceable> IN A <replaceable><IP-address></replaceable></screen>
+ <para>
+ If the <replaceable><host></replaceable> value is omitted, then an <command>A</command> record points to the last specified <replaceable><host></replaceable>.
+ </para>
+ <para>
+ Consider the following <command>A</command> record examples for the <command>example.com</command> zone file:
+ </para>
+ <screen>server1 IN A 10.0.1.3
+ IN A 10.0.1.5</screen>
+ <para>
+ Requests for <command>server1.example.com</command> are pointed to 10.0.1.3 or 10.0.1.5.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>CNAME</command>
- </term>
+ <term><command>CNAME</command></term>
<listitem>
- <para>This refers to the Canonical Name record, which maps one name to another. This type of record <!-- RHEL5: is also known --> can also be referred to as an <firstterm>alias record</firstterm>.</para>
- <para>The next example tells <command>named</command> that any requests sent to the <replaceable><alias-name></replaceable> should point to the host, <replaceable><real-name></replaceable>. <command>CNAME</command> records are most commonly used to point to services that use a common naming scheme, such as <command>www</command> for Web servers.</para>
- <screen>
- <replaceable><alias-name></replaceable> IN CNAME <replaceable><real-name></replaceable>
- </screen>
- <para>In the following example, an <command>A</command> record binds a hostname to an IP address, while a <command>CNAME</command> record points the commonly used <command>www</command> hostname to it.</para>
+ <para>
+ This refers to the Canonical Name record, which maps one name to another. This type of record <!-- RHEL5: is also known --> can also be referred to as an <firstterm>alias record</firstterm>.
+ </para>
+ <para>
+ The next example tells <command>named</command> that any requests sent to the <replaceable><alias-name></replaceable> should point to the host, <replaceable><real-name></replaceable>. <command>CNAME</command> records are most commonly used to point to services that use a common naming scheme, such as <command>www</command> for Web servers.
+ </para>
+ <screen><replaceable><alias-name></replaceable> IN CNAME <replaceable><real-name></replaceable></screen>
+ <para>
+ In the following example, an <command>A</command> record binds a hostname to an IP address, while a <command>CNAME</command> record points the commonly used <command>www</command> hostname to it.
+ </para>
<screen>server1 IN A 10.0.1.5
www IN CNAME server1</screen>
- <para>There are multiple restrictions for CNAME usage:</para>
+ <para>
+ There are multiple restrictions for CNAME usage:
+ </para>
<itemizedlist>
<listitem>
- <para>CNAME RRs should not point to other CNAME RRs. Particularly, it is possible to create infinite loops when CNAME points to another CNAME and vice-versa.</para>
+ <para>
+ CNAME RRs should not point to other CNAME RRs. Particularly, it is possible to create infinite loops when CNAME points to another CNAME and vice-versa.
+ </para>
</listitem>
<listitem>
- <para>CNAME RR mustn't contain other RR types (like A, NS, MX, etc.). The exception are DNSSEC related RRs (RRSIG, NSEC, etc.), when zone is signed.</para>
+ <para>
+ CNAME RR mustn't contain other RR types (like A, NS, MX, etc.). The exception are DNSSEC related RRs (RRSIG, NSEC, etc.), when zone is signed.
+ </para>
</listitem>
<listitem>
- <para>Other RRs which points to FQDN (like NS, MX, PTR) must not point to a CNAME.</para>
+ <para>
+ Other RRs which points to FQDN (like NS, MX, PTR) must not point to a CNAME.
+ </para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>MX</command>
- </term>
+ <term><command>MX</command></term>
<listitem>
- <para>This refers to the Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.</para>
+ <para>
+ This refers to the Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.
+ </para>
<screen>IN MX <replaceable><preference-value></replaceable>
- <replaceable><email-server-name></replaceable>
- </screen>
- <para><!-- RHEL5: In this example, -->Here, the <replaceable><preference-value></replaceable> allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The <command>MX</command> resource record with the lowest <replaceable><preference-value></replaceable> is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.</para>
- <para>The <replaceable><email-server-name></replaceable> is FQDN.</para>
- <screen>
-example.com. IN MX 10 mail.example.com.
- IN MX 20 mail2.example.com.</screen>
- <para>In this example, the first <command>mail.example.com</command> email server is preferred to the <command>mail2.example.com</command> email server when receiving email destined for the <command>example.com</command> domain.</para>
+ <replaceable><email-server-name></replaceable></screen>
+ <para>
+ <!-- RHEL5: In this example, -->Here, the <replaceable><preference-value></replaceable> allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The <command>MX</command> resource record with the lowest <replaceable><preference-value></replaceable> is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.
+ </para>
+ <para>
+ The <replaceable><email-server-name></replaceable> is FQDN.
+ </para>
+ <screen>example.com. IN MX 10 mail.example.com.
+ IN MX 20 mail2.example.com.</screen>
+ <para>
+ In this example, the first <command>mail.example.com</command> email server is preferred to the <command>mail2.example.com</command> email server when receiving email destined for the <command>example.com</command> domain.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>NS</command>
- </term>
+ <term><command>NS</command></term>
<listitem>
- <para>This refers to the NameServer record, which announces the authoritative nameservers for a particular zone.</para>
- <para><!-- RHEL5: This is an example -->The following illustrates the layout of an <command>NS</command> record:</para>
- <screen> IN NS <replaceable><nameserver-name></replaceable>
- </screen>
- <para><!-- RHEL5: The -->Here, <replaceable><nameserver-name></replaceable> should be an FQDN.</para>
- <para>Next, two nameservers are listed as authoritative for the domain. It is not important whether these nameservers are slaves or if one is a master; they are both still considered authoritative.</para>
+ <para>
+ This refers to the NameServer record, which announces the authoritative nameservers for a particular zone.
+ </para>
+ <para>
+ <!-- RHEL5: This is an example -->The following illustrates the layout of an <command>NS</command> record:
+ </para>
+ <screen> IN NS <replaceable><nameserver-name></replaceable></screen>
+ <para>
+ <!-- RHEL5: The -->Here, <replaceable><nameserver-name></replaceable> should be an FQDN.
+ </para>
+ <para>
+ Next, two nameservers are listed as authoritative for the domain. It is not important whether these nameservers are slaves or if one is a master; they are both still considered authoritative.
+ </para>
<screen>IN NS dns1.example.com.
IN NS dns2.example.com.</screen>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>PTR</command>
- </term>
+ <term><command>PTR</command></term>
<listitem>
- <para>This refers to the PoinTeR record, which is designed to point to another part of the namespace.</para>
<para>
- <command>PTR</command> records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to <xref
- linkend="s2-bind-configuration-zone-reverse"/> for more examples of <command>PTR</command> records in use.</para>
+ This refers to the PoinTeR record, which is designed to point to another part of the namespace.
+ </para>
+ <para>
+ <command>PTR</command> records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to <xref linkend="s2-bind-configuration-zone-reverse" /> for more examples of <command>PTR</command> records in use.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <command>SOA</command>
- </term>
+ <term><command>SOA</command></term>
<listitem>
- <para>This refers to the Start Of Authority resource record, which proclaims important authoritative information about a namespace to the nameserver.</para>
- <para>Located after the directives, an <command>SOA</command> resource record is the first resource record in a zone file.</para>
- <para>The following <!-- RHEL5: example -->shows the basic structure of an <command>SOA</command> resource record:</para>
- <screen>
-@ IN SOA <replaceable><primary-name-server></replaceable>
+ <para>
+ This refers to the Start Of Authority resource record, which proclaims important authoritative information about a namespace to the nameserver.
+ </para>
+ <para>
+ Located after the directives, an <command>SOA</command> resource record is the first resource record in a zone file.
+ </para>
+ <para>
+ The following <!-- RHEL5: example -->shows the basic structure of an <command>SOA</command> resource record:
+ </para>
+ <screen>@ IN SOA <replaceable><primary-name-server></replaceable>
<replaceable><hostmaster-email></replaceable> (
- <replaceable><serial-number></replaceable>
+ <replaceable><serial-number></replaceable>
<replaceable><time-to-refresh></replaceable>
<replaceable><time-to-retry></replaceable>
<replaceable><time-to-expire></replaceable>
- <replaceable><minimum-TTL> </replaceable>)
-</screen>
- <para>The <command>@</command> symbol places the <command>$ORIGIN</command> directive (or the zone's name, if the <command>$ORIGIN</command> directive is not set) as the namespace being defined by this <command>SOA</command> resource record. The hostname of the primary nameserver that is authoritative for this domain is the <replaceable><primary-name-server></replaceable> directive, and the email of the person to contact about this namespace is the <replaceable><hostmaster-email></replaceable> directive.</para>
- <para>The <replaceable><serial-number></replaceable> directive is a numerical value incremented every time the zone file is altered to indicate it is time for <command>named</command> to reload the zone. The <replaceable><time-to-refresh></replaceable> directive is the numerical value slave servers use to determine how long to wait before asking the master nameserver if any changes have been made to the zone. The <replaceable><serial-number></replaceable> directive is a numerical value used by the slave servers to determine if it is using outdated zone data and should therefore refresh it.</para>
- <para>The <replaceable><time-to-retry></replaceable> directive is a numerical value used by slave servers to determine the length of time to wait before issuing a refresh request in the event that the master nameserver is not answering. If the master has not replied to a refresh request before the amount of time specified in the <replaceable><time-to-expire></replaceable> directive elapses, the slave servers stop responding as an authority for requests concerning that namespace.</para>
- <para>In BIND 4 and 8, the <replaceable><minimum-TTL></replaceable> directive is the <!-- RHEL5: quantity -->amount of time other nameservers cache the zone's information. However, in BIND 9, the <replaceable><minimum-TTL></replaceable> directive defines how long negative answers are cached for. Caching of negative answers can be set to a maximum of 3 hours (<option>3H</option>).</para>
- <para>When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (<command>M</command>), hours (<command>H</command>), days (<command>D</command>), and weeks (<command>W</command>). The table in <xref
- linkend="tb-bind-seconds"/> shows an amount of time in seconds and the equivalent time in another format.</para>
- <table
- id="tb-bind-seconds">
+ <replaceable><minimum-TTL> </replaceable>)</screen>
+ <para>
+ The <command>@</command> symbol places the <command>$ORIGIN</command> directive (or the zone's name, if the <command>$ORIGIN</command> directive is not set) as the namespace being defined by this <command>SOA</command> resource record. The hostname of the primary nameserver that is authoritative for this domain is the <replaceable><primary-name-server></replaceable> directive, and the email of the person to contact about this namespace is the <replaceable><hostmaster-email></replaceable> directive.
+ </para>
+ <para>
+ The <replaceable><serial-number></replaceable> directive is a numerical value incremented every time the zone file is altered to indicate it is time for <command>named</command> to reload the zone. The <replaceable><time-to-refresh></replaceable> directive is the numerical value slave servers use to determine how long to wait before asking the master nameserver if any changes have been made to the zone. The <replaceable><serial-number></replaceable> directive is a numerical value used by the slave servers to determine if it is using outdated zone data and should therefore refresh it.
+ </para>
+ <para>
+ The <replaceable><time-to-retry></replaceable> directive is a numerical value used by slave servers to determine the length of time to wait before issuing a refresh request in the event that the master nameserver is not answering. If the master has not replied to a refresh request before the amount of time specified in the <replaceable><time-to-expire></replaceable> directive elapses, the slave servers stop responding as an authority for requests concerning that namespace.
+ </para>
+ <para>
+ In BIND 4 and 8, the <replaceable><minimum-TTL></replaceable> directive is the <!-- RHEL5: quantity -->amount of time other nameservers cache the zone's information. However, in BIND 9, the <replaceable><minimum-TTL></replaceable> directive defines how long negative answers are cached for. Caching of negative answers can be set to a maximum of 3 hours (<option>3H</option>).
+ </para>
+ <para>
+ When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (<command>M</command>), hours (<command>H</command>), days (<command>D</command>), and weeks (<command>W</command>). The table in <xref linkend="tb-bind-seconds" /> shows an amount of time in seconds and the equivalent time in another format.
+ </para>
+ <table id="tb-bind-seconds">
<title>Seconds compared to other time units</title>
- <tgroup
- cols="2">
- <colspec
- colname="seconds"
- colnum="1"
- colwidth="50*"/>
- <colspec
- colname="other"
- colnum="2"
- colwidth="50*"/>
+ <tgroup cols="2">
+ <colspec colname="seconds" colnum="1" colwidth="50*" />
+ <colspec colname="other" colnum="2" colwidth="50*" />
<thead>
<row>
<entry>
- Seconds
- </entry>
+ Seconds
+ </entry>
<entry>
- Other Time Units
- </entry>
+ Other Time Units
+ </entry>
</row>
</thead>
<tbody>
@@ -1269,568 +1393,615 @@ IN NS dns2.example.com.</screen>
</tbody>
</tgroup>
</table>
- <para>The following example illustrates the form an <command>SOA</command> resource record might take when it is populated with real values.</para>
- <screen>
-@ IN SOA dns1.example.com. hostmaster.example.com. (
- 2001062501 ; serial
- 21600 ; refresh after 6 hours
- 3600 ; retry after 1 hour
- 604800 ; expire after 1 week
- 86400 ) ; minimum TTL of 1 day
-</screen>
+ <para>
+ The following example illustrates the form an <command>SOA</command> resource record might take when it is populated with real values.
+ </para>
+ <screen>@ IN SOA dns1.example.com. hostmaster.example.com. (
+ 2001062501 ; serial
+ 21600 ; refresh after 6 hours
+ 3600 ; retry after 1 hour
+ 604800 ; expire after 1 week
+ 86400 ) ; minimum TTL of 1 day</screen>
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
- <itemizedlist>
- <listitem>
- <para><command>A</command> — Address record, which specifies an IP address to assign to a name, as in this example:</para>
+ <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
+ <itemizedlist>
+ <listitem>
+ <para><command>A</command> — Address record, which specifies an IP address to assign to a name, as in this example:</para>
<screen>
<command><replaceable><host></replaceable> IN A <replaceable><IP-address></replaceable></command>
</screen>
- <para>If the <replaceable><host></replaceable> value is omitted, then an <command>A</command> record points to a default IP address for the top of the namespace. This system is the target for all non-FQDN requests.</para>
- <para>Consider the following <command>A</command> record examples for the <command>example.com</command> zone file:</para>
+ <para>If the <replaceable><host></replaceable> value is omitted, then an <command>A</command> record points to a default IP address for the top of the namespace. This system is the target for all non-FQDN requests.</para>
+ <para>Consider the following <command>A</command> record examples for the <command>example.com</command> zone file:</para>
<screen>
<command> IN A 10.0.1.3 server1 IN A 10.0.1.5</command>
</screen>
- <para>Requests for <command>example.com</command> are pointed to 10.0.1.3, while requests for <command>server1.example.com</command> are pointed to 10.0.1.5.</para>
- </listitem>
- <listitem>
- <para><command>CNAME</command> — Canonical name record, maps one name to another. This type of record is also known as an alias record.</para>
- <para>The next example tells <command>named</command> that any requests sent to the <replaceable><alias-name></replaceable> should point to the host, <replaceable><real-name></replaceable>.
- <command>CNAME</command> records are most commonly used to point to services that use a common naming scheme, such as <command>www</command> for Web servers.</para>
+ <para>Requests for <command>example.com</command> are pointed to 10.0.1.3, while requests for <command>server1.example.com</command> are pointed to 10.0.1.5.</para>
+ </listitem>
+ <listitem>
+ <para><command>CNAME</command> — Canonical name record, maps one name to another. This type of record is also known as an alias record.</para>
+ <para>The next example tells <command>named</command> that any requests sent to the <replaceable><alias-name></replaceable> should point to the host, <replaceable><real-name></replaceable>.
+ <command>CNAME</command> records are most commonly used to point to services that use a common naming scheme, such as <command>www</command> for Web servers.</para>
<screen>
<command><replaceable><alias-name></replaceable> IN CNAME <replaceable><real-name></replaceable></command>
</screen>
- <para>In the following example, an <command>A</command> record binds a hostname to an IP address, while a <command>CNAME</command> record points the commonly used <command>www</command> hostname to it.</para>
+ <para>In the following example, an <command>A</command> record binds a hostname to an IP address, while a <command>CNAME</command> record points the commonly used <command>www</command> hostname to it.</para>
<screen>
<command>server1 IN A 10.0.1.5 www IN CNAME server1</command>
</screen>
- </listitem>
- <listitem>
- <para><command>MX</command> — Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.</para>
+ </listitem>
+ <listitem>
+ <para><command>MX</command> — Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.</para>
<screen>
<command> IN MX <replaceable><preference-value></replaceable> <replaceable><email-server-name></replaceable></command>
</screen>
- <para>In this example, the <replaceable><preference-value></replaceable> allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The <command>MX</command> resource record
- with the lowest <replaceable><preference-value></replaceable> is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.</para>
- <para>The <replaceable><email-server-name></replaceable> may be a hostname or FQDN.</para>
+ <para>In this example, the <replaceable><preference-value></replaceable> allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The <command>MX</command> resource record
+ with the lowest <replaceable><preference-value></replaceable> is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.</para>
+ <para>The <replaceable><email-server-name></replaceable> may be a hostname or FQDN.</para>
<screen>
<command> IN MX 10 mail.example.com. IN MX 20 mail2.example.com.</command>
</screen>
- <para>In this example, the first <command>mail.example.com</command> email server is preferred to the <command>mail2.example.com</command> email server when receiving email destined for the
- <command>example.com</command> domain.</para>
- </listitem>
- <listitem>
- <para><command>NS</command> — NameServer record, which announces the authoritative nameservers for a particular zone.</para>
- <para>This is an example of an <command>NS</command> record:</para>
+ <para>In this example, the first <command>mail.example.com</command> email server is preferred to the <command>mail2.example.com</command> email server when receiving email destined for the
+ <command>example.com</command> domain.</para>
+ </listitem>
+ <listitem>
+ <para><command>NS</command> — NameServer record, which announces the authoritative nameservers for a particular zone.</para>
+ <para>This is an example of an <command>NS</command> record:</para>
<screen>
<command> IN NS <replaceable><nameserver-name></replaceable></command>
</screen>
- <para>The <replaceable><nameserver-name></replaceable> should be a FQDN.</para>
- <para>Next, two nameservers are listed as authoritative for the domain. It is not important whether these nameservers are slaves or if one is a master; they are both still considered authoritative.</para>
+ <para>The <replaceable><nameserver-name></replaceable> should be a FQDN.</para>
+ <para>Next, two nameservers are listed as authoritative for the domain. It is not important whether these nameservers are slaves or if one is a master; they are both still considered authoritative.</para>
<screen>
<command> IN NS dns1.example.com. IN NS dns2.example.com.</command>
</screen>
- </listitem>
- <listitem>
- <para><command>PTR</command> — PoinTeR record, designed to point to another part of the namespace.</para>
- <para><command>PTR</command> records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to <xref linkend="s2-bind-configuration-zone-reverse"/> for more examples of
- <command>PTR</command> records in use.</para>
- </listitem>
- <listitem>
- <para><command>SOA</command> — Start Of Authority resource record, proclaims important authoritative information about a namespace to the nameserver.</para>
- <para>Located after the directives, an <command>SOA</command> resource record is the first resource record in a zone file.</para>
- <para>The following example shows the basic structure of an <command>SOA</command> resource record:</para>
+ </listitem>
+ <listitem>
+ <para><command>PTR</command> — PoinTeR record, designed to point to another part of the namespace.</para>
+ <para><command>PTR</command> records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to <xref linkend="s2-bind-configuration-zone-reverse"/> for more examples of
+ <command>PTR</command> records in use.</para>
+ </listitem>
+ <listitem>
+ <para><command>SOA</command> — Start Of Authority resource record, proclaims important authoritative information about a namespace to the nameserver.</para>
+ <para>Located after the directives, an <command>SOA</command> resource record is the first resource record in a zone file.</para>
+ <para>The following example shows the basic structure of an <command>SOA</command> resource record:</para>
<screen>
<command>@ IN SOA <replaceable><primary-name-server></replaceable> <replaceable><hostmaster-email></replaceable> ( <replaceable><serial-number></replaceable> <replaceable><time-to-refresh></replaceable> <replaceable><time-to-retry></replaceable> <replaceable><time-to-expire></replaceable> <replaceable><minimum-TTL> )</replaceable></command>
</screen>
- <para>The <command>@</command> symbol places the <command>$ORIGIN</command> directive (or the zone's name, if the <command>$ORIGIN</command> directive is not set) as the namespace being defined by this
- <command>SOA</command> resource record. The hostname of the primary nameserver that is authoritative for this domain is the <replaceable><primary-name-server></replaceable> directive, and the email of the person to contact
- about this namespace is the <replaceable><hostmaster-email></replaceable> directive.</para>
- <para>The <replaceable><serial-number></replaceable> directive is a numerical value incremented every time the zone file is altered to indicate it is time for <command>named</command> to reload the zone. The <replaceable><time-to-refresh></replaceable> directive is the numerical value slave servers use to determine how long to wait before asking the master nameserver if any changes have been made to the zone. The <replaceable><serial-number></replaceable>
- directive is a numerical value used by the slave servers to determine if it is using outdated zone data and should therefore refresh it.</para>
- <para>The <replaceable><time-to-retry></replaceable> directive is a numerical value used by slave servers to determine the length of time to wait before issuing a refresh request in the event the master nameserver is not answering. If the master
- has not replied to a refresh request before the amount of time specified in the <replaceable><time-to-expire></replaceable> directive elapses, the slave servers stop responding as an authority for requests concerning that namespace.</para>
- <para>The <replaceable><minimum-TTL></replaceable> directive is the quantity of time other nameservers cache the zone's information.</para>
- <para>When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (<command>M</command>), hours
- (<command>H</command>), days (<command>D</command>), and weeks (<command>W</command>). The table in <xref linkend="tb-bind-seconds"/> shows an amount of time in seconds and the equivalent time in
- another format.</para>
- <table id="tb-bind-seconds">
- <title>Seconds compared to other time units</title>
- <tgroup cols="2">
- <colspec colnum="1" colname="seconds" colwidth="50*"></colspec>
- <colspec colnum="2" colname="other" colwidth="50*"></colspec>
- <thead><row>
- <entry>
- Seconds
- </entry>
- <entry>
- Other Time Units
- </entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>
- <command>60</command>
- </entry>
- <entry>
- <command>1M</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>1800</command>
- </entry>
- <entry>
- <command>30M</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>3600</command>
- </entry>
- <entry>
- <command>1H</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>10800</command>
- </entry>
- <entry>
- <command>3H</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>21600</command>
- </entry>
- <entry>
- <command>6H</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>43200</command>
- </entry>
- <entry>
- <command>12H</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>86400</command>
- </entry>
- <entry>
- <command>1D</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>259200</command>
- </entry>
- <entry>
- <command>3D</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>604800</command>
- </entry>
- <entry>
- <command>1W</command>
- </entry>
- </row>
- <row>
- <entry>
- <command>31536000</command>
- </entry>
- <entry>
- <command>365D</command>
- </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- <para>The following example illustrates the form an <command>SOA</command> resource record might take when it is populated with real values.</para>
+ <para>The <command>@</command> symbol places the <command>$ORIGIN</command> directive (or the zone's name, if the <command>$ORIGIN</command> directive is not set) as the namespace being defined by this
+ <command>SOA</command> resource record. The hostname of the primary nameserver that is authoritative for this domain is the <replaceable><primary-name-server></replaceable> directive, and the email of the person to contact
+ about this namespace is the <replaceable><hostmaster-email></replaceable> directive.</para>
+ <para>The <replaceable><serial-number></replaceable> directive is a numerical value incremented every time the zone file is altered to indicate it is time for <command>named</command> to reload the zone. The <replaceable><time-to-refresh></replaceable> directive is the numerical value slave servers use to determine how long to wait before asking the master nameserver if any changes have been made to the zone. The <replaceable><serial-number></replaceable>
+ directive is a numerical value used by the slave servers to determine if it is using outdated zone data and should therefore refresh it.</para>
+ <para>The <replaceable><time-to-retry></replaceable> directive is a numerical value used by slave servers to determine the length of time to wait before issuing a refresh request in the event the master nameserver is not answering. If the master
+ has not replied to a refresh request before the amount of time specified in the <replaceable><time-to-expire></replaceable> directive elapses, the slave servers stop responding as an authority for requests concerning that namespace.</para>
+ <para>The <replaceable><minimum-TTL></replaceable> directive is the quantity of time other nameservers cache the zone's information.</para>
+ <para>When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (<command>M</command>), hours
+ (<command>H</command>), days (<command>D</command>), and weeks (<command>W</command>). The table in <xref linkend="tb-bind-seconds"/> shows an amount of time in seconds and the equivalent time in
+ another format.</para>
+ <table id="tb-bind-seconds">
+ <title>Seconds compared to other time units</title>
+ <tgroup cols="2">
+ <colspec colnum="1" colname="seconds" colwidth="50*"></colspec>
+ <colspec colnum="2" colname="other" colwidth="50*"></colspec>
+ <thead><row>
+ <entry>
+ Seconds
+ </entry>
+ <entry>
+ Other Time Units
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ <command>60</command>
+ </entry>
+ <entry>
+ <command>1M</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>1800</command>
+ </entry>
+ <entry>
+ <command>30M</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>3600</command>
+ </entry>
+ <entry>
+ <command>1H</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>10800</command>
+ </entry>
+ <entry>
+ <command>3H</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>21600</command>
+ </entry>
+ <entry>
+ <command>6H</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>43200</command>
+ </entry>
+ <entry>
+ <command>12H</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>86400</command>
+ </entry>
+ <entry>
+ <command>1D</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>259200</command>
+ </entry>
+ <entry>
+ <command>3D</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>604800</command>
+ </entry>
+ <entry>
+ <command>1W</command>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>31536000</command>
+ </entry>
+ <entry>
+ <command>365D</command>
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ <para>The following example illustrates the form an <command>SOA</command> resource record might take when it is populated with real values.</para>
<screen>
-<command> @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day</command>
+<command> @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day</command>
</screen>
- </listitem>
- </itemizedlist>
+ </listitem>
+ </itemizedlist>
-->
</section>
- <section
- id="s2-bind-zone-examples">
+ <section id="s2-bind-zone-examples">
<title>Example Zone File</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration of</secondary>
<tertiary>zone file examples</tertiary>
</indexterm>
- <para>Seen individually, directives and resource records can be difficult to grasp. However, when placed together in a single file, they become easier to understand.</para>
-
- <para>The following example shows a very basic zone file.</para>
+ <para>
+ Seen individually, directives and resource records can be difficult to grasp. However, when placed together in a single file, they become easier to understand.
+ </para>
+ <para>
+ The following example shows a very basic zone file.
+ </para>
<screen>$ORIGIN example.com.
$TTL 86400
-@ SOA dns1.example.com. hostmaster.example.com. (
- 2001062501 ; serial
- 21600 ; refresh after 6 hours
- 3600 ; retry after 1 hour
- 604800 ; expire after 1 week
- 86400 ) ; minimum TTL of 1 day
+@ SOA dns1.example.com. hostmaster.example.com. (
+ 2001062501 ; serial
+ 21600 ; refresh after 6 hours
+ 3600 ; retry after 1 hour
+ 604800 ; expire after 1 week
+ 86400 ) ; minimum TTL of 1 day
;
;
- NS dns1.example.com.
- NS dns2.example.com.
-dns1 A 10.0.1.1
- AAAA aaaa:bbbb::1
-dns2 A 10.0.1.2
- AAAA aaaa:bbbb::2
+ NS dns1.example.com.
+ NS dns2.example.com.
+dns1 A 10.0.1.1
+ AAAA aaaa:bbbb::1
+dns2 A 10.0.1.2
+ AAAA aaaa:bbbb::2
;
;
-@ MX 10 mail.example.com.
- MX 20 mail2.example.com.
-mail A 10.0.1.5
- AAAA aaaa:bbbb::5
-mail2 A 10.0.1.6
- AAAA aaaa:bbbb::6
+@ MX 10 mail.example.com.
+ MX 20 mail2.example.com.
+mail A 10.0.1.5
+ AAAA aaaa:bbbb::5
+mail2 A 10.0.1.6
+ AAAA aaaa:bbbb::6
;
;
; This sample zone file illustrates sharing the same IP addresses for multiple services:
;
-services A 10.0.1.10
- AAAA aaaa:bbbb::10
- A 10.0.1.11
- AAAA aaaa:bbbb::11
+services A 10.0.1.10
+ AAAA aaaa:bbbb::10
+ A 10.0.1.11
+ AAAA aaaa:bbbb::11
-ftp CNAME services.example.com.
-www CNAME services.example.com.
+ftp CNAME services.example.com.
+www CNAME services.example.com.
;
-;
-</screen>
- <para>In this example, standard directives and <command>SOA</command> values are used. The authoritative nameservers are set as <command>dns1.example.com</command> and <command>dns2.example.com</command>, which
- have <command>A</command> records that tie them to <command>10.0.1.1</command> and <command>10.0.1.2</command>, respectively.</para>
-
- <para>The email servers configured with the <command>MX</command> records point to <command>mail</command> and <command>mail2</command> via <command>A</command> records. Since the
- <command>mail</command> and <command>mail2</command> names do not end in a trailing period (<command>.</command>), the <command>$ORIGIN</command> domain is placed after them,
- expanding them to <command>mail.example.com</command> and <command>mail2.example.com</command>. Through the related <command>A</command> resource records, their IP addresses can be determined.</para>
-
- <!-- RHEL5: Fix BZ#455162: correct example zone file with regard to records, description
- Note: fixes also applied to certain records in the example zone config above -->
- <!--<para>FTP and Web services, available at the standard <command moreinfo="none">ftp.example.com</command> and <command moreinfo="none">www.example.com</command> names, are pointed at the appropriate servers using <command moreinfo="none">CNAME</command>
- records.</para>-->
- <para>Services available at the standard names, such as <command>www.example.com</command> (<acronym>WWW</acronym>)<!-- and ftp.example.com (FTP)-->, are pointed at the appropriate servers using a <command>CNAME</command> record.</para>
-
- <para>This zone file would be called into service with a <command>zone</command> statement in the <filename>named.conf</filename> similar to the following:</para>
-<screen>
-zone "example.com" IN {
- type master;
- file "example.com.zone";
- allow-update { none; };
-};
-</screen>
+;</screen>
+ <para>
+ In this example, standard directives and <command>SOA</command> values are used. The authoritative nameservers are set as <command>dns1.example.com</command> and <command>dns2.example.com</command>, which have <command>A</command> records that tie them to <command>10.0.1.1</command> and <command>10.0.1.2</command>, respectively.
+ </para>
+ <para>
+ The email servers configured with the <command>MX</command> records point to <command>mail</command> and <command>mail2</command> via <command>A</command> records. Since the <command>mail</command> and <command>mail2</command> names do not end in a trailing period (<command>.</command>), the <command>$ORIGIN</command> domain is placed after them, expanding them to <command>mail.example.com</command> and <command>mail2.example.com</command>. Through the related <command>A</command> resource records, their IP addresses can be determined.
+ </para>
+ <!-- RHEL5: Fix BZ#455162: correct example zone file with regard to records, description
+ Note: fixes also applied to certain records in the example zone config above -->
+ <!--<para>FTP and Web services, available at the standard <command moreinfo="none">ftp.example.com</command> and <command moreinfo="none">www.example.com</command> names, are pointed at the appropriate servers using <command moreinfo="none">CNAME</command>
+ records.</para>-->
+ <para>
+ Services available at the standard names, such as <command>www.example.com</command> (<acronym>WWW</acronym>)<!-- and ftp.example.com (FTP)-->, are pointed at the appropriate servers using a <command>CNAME</command> record.
+ </para>
+ <para>
+ This zone file would be called into service with a <command>zone</command> statement in the <filename>named.conf</filename> similar to the following:
+ </para>
+ <screen>zone "example.com" IN {
+ type master;
+ file "example.com.zone";
+ allow-update { none; };
+};</screen>
</section>
- <section
- id="s2-bind-configuration-zone-reverse">
+ <section id="s2-bind-configuration-zone-reverse">
<title>Reverse Name Resolution Zone Files</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>configuration of</secondary>
<tertiary>reverse name resolution</tertiary>
</indexterm>
- <para>A reverse name resolution zone file is used to translate an IP address in a particular namespace into an FQDN. It looks very similar to a standard zone file, except that <command>PTR</command> resource records are used to link the IP addresses to a fully qualified domain name.</para>
- <para>The following illustrates the layout of a <command>PTR</command> record:</para>
- <!-- RHEL5: ddomingo at redhat.com: above <para>replaces below
- <para>A <command>PTR</command> record looks similar to this:</para>
+ <para>
+ A reverse name resolution zone file is used to translate an IP address in a particular namespace into an FQDN. It looks very similar to a standard zone file, except that <command>PTR</command> resource records are used to link the IP addresses to a fully qualified domain name.
+ </para>
+ <para>
+ The following illustrates the layout of a <command>PTR</command> record:
+ </para>
+ <!-- RHEL5: ddomingo at redhat.com: above <para>replaces below
+ <para>A <command>PTR</command> record looks similar to this:</para>
-->
<screen>
- <replaceable><last-IP-digit></replaceable> IN PTR <replaceable><FQDN-of-system></replaceable>
- </screen>
- <para>The <replaceable><last-IP-digit></replaceable> is the last number in an IP address which points to a particular system's FQDN.</para>
- <para>In the following example, IP addresses <command>10.0.1.1</command> through <command>10.0.1.6</command> are pointed to corresponding FQDNs. It can be located in <filename>/var/named/example.com.rr.zone</filename>.</para>
+ <replaceable><last-IP-digit></replaceable> IN PTR <replaceable><FQDN-of-system></replaceable></screen>
+ <para>
+ The <replaceable><last-IP-digit></replaceable> is the last number in an IP address which points to a particular system's FQDN.
+ </para>
+ <para>
+ In the following example, IP addresses <command>10.0.1.1</command> through <command>10.0.1.6</command> are pointed to corresponding FQDNs. It can be located in <filename>/var/named/example.com.rr.zone</filename>.
+ </para>
<!--silas: Fix (BZ#404161): add NS type statement to reverse zone config-->
- <screen>
-$ORIGIN 1.0.10.in-addr.arpa.
+ <screen>$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
-@ IN SOA dns1.example.com. hostmaster.example.com. (
- 2001062501 ; serial
- 21600 ; refresh after 6 hours
- 3600 ; retry after 1 hour
- 604800 ; expire after 1 week
- 86400 ) ; minimum TTL of 1 day
+@ IN SOA dns1.example.com. hostmaster.example.com. (
+ 2001062501 ; serial
+ 21600 ; refresh after 6 hours
+ 3600 ; retry after 1 hour
+ 604800 ; expire after 1 week
+ 86400 ) ; minimum TTL of 1 day
;
@ IN NS dns1.example.com.
;
-1 IN PTR dns1.example.com.
-2 IN PTR dns2.example.com.
+1 IN PTR dns1.example.com.
+2 IN PTR dns2.example.com.
;
-5 IN PTR server1.example.com.
-6 IN PTR server2.example.com.
+5 IN PTR server1.example.com.
+6 IN PTR server2.example.com.
;
-3 IN PTR ftp.example.com.
-4 IN PTR ftp.example.com.
-</screen>
- <para>This zone file would be called into service with a <command>zone</command> statement in the <filename>named.conf</filename> file similar to the following:</para>
- <screen>
-zone "1.0.10.in-addr.arpa" IN {
- type master;
- file "example.com.rr.zone";
- allow-update { none; };
-};
-</screen>
- <para>There is very little difference between this example and a standard <command>zone</command> statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by <command>.in-addr.arpa</command>. This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.</para>
+3 IN PTR ftp.example.com.
+4 IN PTR ftp.example.com.</screen>
+ <para>
+ This zone file would be called into service with a <command>zone</command> statement in the <filename>named.conf</filename> file similar to the following:
+ </para>
+ <screen>zone "1.0.10.in-addr.arpa" IN {
+ type master;
+ file "example.com.rr.zone";
+ allow-update { none; };
+};</screen>
+ <para>
+ There is very little difference between this example and a standard <command>zone</command> statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by <command>.in-addr.arpa</command>. This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.
+ </para>
</section>
</section>
- <section
- id="s1-bind-rndc">
- <title>Using <command>rndc</command>
- </title>
- <indexterm
- significance="normal">
+ <section id="s1-bind-rndc">
+ <title>Using <command>rndc</command></title>
+ <indexterm>
<primary>BIND</primary>
- <secondary>
- <command>rndc</command> program</secondary>
+ <secondary><command>rndc</command> program</secondary>
</indexterm>
- <para>BIND includes a utility called <command>rndc</command> which allows command line administration of the <command>named</command> daemon from the localhost or <!-- RHEL5: from -->a remote host.</para>
- <para>In order to prevent unauthorized access to the <command>named</command> daemon, BIND uses a shared secret key authentication method to grant privileges to hosts. This means an identical key must be used by both <command>named</command> and the <command>rndc</command> processes. By default, both use key located in <filename>/etc/rndc.key</filename>.</para>
- <section
- id="s2-bind-rndc-configuration-namedconf">
+ <para>
+ BIND includes a utility called <command>rndc</command> which allows command line administration of the <command>named</command> daemon from the localhost or <!-- RHEL5: from -->a remote host.
+ </para>
+ <para>
+ In order to prevent unauthorized access to the <command>named</command> daemon, BIND uses a shared secret key authentication method to grant privileges to hosts. This means an identical key must be used by both <command>named</command> and the <command>rndc</command> processes. By default, both use key located in <filename>/etc/rndc.key</filename>.
+ </para>
+ <section id="s2-bind-rndc-configuration-namedconf">
<title>Configuring <command>named</command> process</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
- <secondary>
- <command>rndc</command> program</secondary>
+ <secondary><command>rndc</command> program</secondary>
<tertiary>configuring <command>named</command> to use</tertiary>
</indexterm>
- <para>In order for <command>rndc</command> to connect to a <command>named</command> service, <command>named</command> must be configured to listen on the rndc control port (953) and must use same shared key as <command>rndc</command>.</para>
- <para>The rndc control channel is configured by the <command>controls</command> statement in the <filename>/etc/named.conf</filename>. By default, when no controls statement is present, named allows connection from the loopback device and uses key located in <filename>/etc/rndc.key</filename>, which is automatically generated during installation via <command>rndc-confgen -a</command> command. Refer to the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/> and the <filename>named.conf</filename> man page for more details about the <command>controls</command> statement.</para>
+ <para>
+ In order for <command>rndc</command> to connect to a <command>named</command> service, <command>named</command> must be configured to listen on the rndc control port (953) and must use same shared key as <command>rndc</command>.
+ </para>
+ <para>
+ The rndc control channel is configured by the <command>controls</command> statement in the <filename>/etc/named.conf</filename>. By default, when no controls statement is present, named allows connection from the loopback device and uses key located in <filename>/etc/rndc.key</filename>, which is automatically generated during installation via <command>rndc-confgen -a</command> command. Refer to the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/> and the <filename>named.conf</filename> man page for more details about the <command>controls</command> statement.
+ </para>
<warning>
<title>Warning</title>
- <para>It is a good idea to keep <filename>/etc/rndc.key</filename> readable only by root, otherwise unprivileged users can send control commands to the <command>named</command> process.</para>
+ <para>
+ It is a good idea to keep <filename>/etc/rndc.key</filename> readable only by root, otherwise unprivileged users can send control commands to the <command>named</command> process.
+ </para>
</warning>
</section>
- <section
- id="s2-bind-rndc-configuration-rndcconf">
+ <section id="s2-bind-rndc-configuration-rndcconf">
<title>Configuring <command>rndc</command></title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
- <secondary>
- <command>rndc</command> program</secondary>
- <tertiary>
- <filename>/etc/rndc.conf</filename>
- </tertiary>
+ <secondary><command>rndc</command> program</secondary>
+ <tertiary><filename>/etc/rndc.conf</filename></tertiary>
</indexterm>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
- <secondary>
- <command>rndc</command> program</secondary>
+ <secondary><command>rndc</command> program</secondary>
<tertiary>configuring keys</tertiary>
</indexterm>
- <para>The <command>rndc</command> configuration is located in the <filename>/etc/rndc.conf</filename>. By default this file is not present and <command>rndc</command> uses the key located in <filename>/etc/rndc.key</filename>. Refer to the <command>rndc</command> and the <filename>rndc.conf</filename> man pages for more details.</para>
+ <para>
+ The <command>rndc</command> configuration is located in the <filename>/etc/rndc.conf</filename>. By default this file is not present and <command>rndc</command> uses the key located in <filename>/etc/rndc.key</filename>. Refer to the <command>rndc</command> and the <filename>rndc.conf</filename> man pages for more details.
+ </para>
</section>
- <section
- id="s2-bind-rndc-options">
+ <section id="s2-bind-rndc-options">
<title>Command Line Options</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
- <secondary>
- <command>rndc</command> program</secondary>
+ <secondary><command>rndc</command> program</secondary>
<tertiary>command line options</tertiary>
</indexterm>
- <para>An <command>rndc</command> command takes the following form:</para>
- <screen>rndc <replaceable><options></replaceable> <replaceable><command></replaceable> <replaceable><command-options></replaceable>
- </screen>
- <para>When executing <command>rndc</command> on a properly configured localhost, the following commands are available:</para>
+ <para>
+ An <command>rndc</command> command takes the following form:
+ </para>
+ <screen>rndc <replaceable><options></replaceable> <replaceable><command></replaceable> <replaceable><command-options></replaceable></screen>
+ <para>
+ When executing <command>rndc</command> on a properly configured localhost, the following commands are available:
+ </para>
<itemizedlist>
<listitem>
<para>
- <command>querylog</command> — Logs all queries made to this nameserver.</para>
+ <command>querylog</command> — Logs all queries made to this nameserver.
+ </para>
</listitem>
<listitem>
<para>
- <command>reload</command> — Reloads the zone files but keeps all other previously cached responses. This command also allows changes to zone files without losing all stored name resolutions.</para>
- <para>If changes made only affect<!-- RHEL5: ed --> a specific zone, reload only that specific zone by adding the name of the zone after the <command>reload</command> command.</para>
+ <command>reload</command> — Reloads the zone files but keeps all other previously cached responses. This command also allows changes to zone files without losing all stored name resolutions.
+ </para>
+ <para>
+ If changes made only affect<!-- RHEL5: ed --> a specific zone, reload only that specific zone by adding the name of the zone after the <command>reload</command> command.
+ </para>
</listitem>
<listitem>
<para>
- <command>stop</command> — Stops the server gracefully, saving any dynamic update and <firstterm>Incremental Zone Transfers</firstterm> (<firstterm>IXFR</firstterm>) data before exiting.</para>
+ <command>stop</command> — Stops the server gracefully, saving any dynamic update and <firstterm>Incremental Zone Transfers</firstterm> (<firstterm>IXFR</firstterm>) data before exiting.
+ </para>
</listitem>
<listitem>
<para>
- <command>sign <replaceable><zone></replaceable></command> - Update zone DNSSEC keys and sign it as needed.</para>
+ <command>sign <replaceable><zone></replaceable></command> - Update zone DNSSEC keys and sign it as needed.
+ </para>
</listitem>
<listitem>
<para>
- <command>validation <replaceable><on|off></replaceable></command> - Turn on/off DNSSEC validation.</para>
+ <command>validation <replaceable><on|off></replaceable></command> - Turn on/off DNSSEC validation.
+ </para>
</listitem>
</itemizedlist>
- <para>Additional information can be found in the <command>rndc</command> man page.</para>
+ <para>
+ Additional information can be found in the <command>rndc</command> man page.
+ </para>
</section>
</section>
- <section
- id="s1-bind-features">
+ <section id="s1-bind-features">
<title>Advanced Features of BIND</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>features</secondary>
</indexterm>
- <para>Most BIND implementations only use <command>named</command> to provide name resolution services or to act as an authority for a particular domain. However, BIND version 9 has a number of advanced features that allow for a more secure and efficient DNS service.</para>
+ <para>
+ Most BIND implementations only use <command>named</command> to provide name resolution services or to act as an authority for a particular domain. However, BIND version 9 has a number of advanced features that allow for a more secure and efficient DNS service.
+ </para>
<warning>
<title>Caution</title>
- <para>Some of these advanced features, such as DNSSEC, TSIG, and IXFR (which are defined in the following section), should only be used in network environments with nameservers that support the features. If the network environment includes non-BIND or older BIND nameservers, verify that each advanced feature is supported before attempting to use it.</para>
+ <para>
+ Some of these advanced features, such as DNSSEC, TSIG, and IXFR (which are defined in the following section), should only be used in network environments with nameservers that support the features. If the network environment includes non-BIND or older BIND nameservers, verify that each advanced feature is supported before attempting to use it.
+ </para>
</warning>
- <para>All of the features mentioned are discussed in greater detail in the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref
- linkend="s2-bind-installed-docs"/>.</para>
- <section
- id="s2-bind-features-protocol">
+ <para>
+ All of the features mentioned are discussed in greater detail in the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs" />.
+ </para>
+ <section id="s2-bind-features-protocol">
<title>DNS Protocol Enhancements</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>features</secondary>
<tertiary>DNS enhancements</tertiary>
</indexterm>
- <para>BIND supports Incremental Zone Transfers (IXFR), where a slave nameserver only downloads the updated portions of a zone modified on a master nameserver. The standard transfer process requires that the entire zone be transferred to each slave nameserver for even the smallest change. For very popular domains with very lengthy zone files and many slave nameservers, IXFR makes the notification and update process much less resource-intensive.</para>
- <para>Note that IXFR is only available when using <firstterm>dynamic updating</firstterm> to make changes to master zone records. If manually editing zone files to make changes, Automatic Zone Transfer (AXFR) is used. More information on dynamic updating is available in the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref
- linkend="s2-bind-installed-docs"/>.<!-- RHEL5: . See <xref linkend="s2-bind-installed-docs"/> for more information. -->
+ <para>
+ BIND supports Incremental Zone Transfers (IXFR), where a slave nameserver only downloads the updated portions of a zone modified on a master nameserver. The standard transfer process requires that the entire zone be transferred to each slave nameserver for even the smallest change. For very popular domains with very lengthy zone files and many slave nameservers, IXFR makes the notification and update process much less resource-intensive.
+ </para>
+ <para>
+ Note that IXFR is only available when using <firstterm>dynamic updating</firstterm> to make changes to master zone records. If manually editing zone files to make changes, Automatic Zone Transfer (AXFR) is used. More information on dynamic updating is available in the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs" />.<!-- RHEL5: . See <xref linkend="s2-bind-installed-docs"/> for more information. -->
</para>
</section>
- <section
- id="s2-bind-features-views">
+ <section id="s2-bind-features-views">
<title>Multiple Views</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>features</secondary>
<tertiary>multiple views</tertiary>
</indexterm>
- <para>Through the use of the <command>view</command> statement in <filename>named.conf</filename>, BIND can present different information depending on which network a request originates from.</para>
- <para>This is primarily used to deny sensitive DNS entries from clients outside of the local network, while allowing queries from clients inside the local network.</para>
- <para>The <command>view</command> statement uses the <command>match-clients</command> option to match IP addresses or entire networks and give them special options and zone data.</para>
+ <para>
+ Through the use of the <command>view</command> statement in <filename>named.conf</filename>, BIND can present different information depending on which network a request originates from.
+ </para>
+ <para>
+ This is primarily used to deny sensitive DNS entries from clients outside of the local network, while allowing queries from clients inside the local network.
+ </para>
+ <para>
+ The <command>view</command> statement uses the <command>match-clients</command> option to match IP addresses or entire networks and give them special options and zone data.
+ </para>
</section>
- <section
- id="s2-bind-features-tsig">
+ <section id="s2-bind-features-tsig">
<title>TSIG</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>features</secondary>
<tertiary>TSIG</tertiary>
</indexterm>
- <para>Short for <firstterm>Transaction SIGnatures</firstterm>, this feature allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.</para>
- <para>This feature strengthens the standard IP address-based method of transfer authorization. An attacker would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.</para>
- <para>BIND version 9 also supports <firstterm>TKEY</firstterm>, which is another shared secret key method of authorizing zone transfers.</para>
- <para>More information about TSIG is available in the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/>, in chapter called <command>Advanced DNS features</command>.</para>
+ <para>
+ Short for <firstterm>Transaction SIGnatures</firstterm>, this feature allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.
+ </para>
+ <para>
+ This feature strengthens the standard IP address-based method of transfer authorization. An attacker would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.
+ </para>
+ <para>
+ BIND version 9 also supports <firstterm>TKEY</firstterm>, which is another shared secret key method of authorizing zone transfers.
+ </para>
+ <para>
+ More information about TSIG is available in the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/>, in chapter called <command>Advanced DNS features</command>.
+ </para>
<important>
<title>Caution</title>
- <para>Master and slave nameservers which communicates over insecure network should avoid IP address-based authentication. They should use TSIG-based authentication instead.</para>
+ <para>
+ Master and slave nameservers which communicates over insecure network should avoid IP address-based authentication. They should use TSIG-based authentication instead.
+ </para>
</important>
-
- <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
- <itemizedlist>
- <listitem>
- <para><emphasis>DNSSEC</emphasis> — Short for <firstterm>DNS SECurity</firstterm>, this feature allows for zones to be cryptographically signed with a <firstterm>zone key</firstterm>.</para>
- <para>In this way, the information about a specific zone can be verified as coming from a nameserver that has signed it with a particular private key, as long as the recipient has that nameserver's public key.</para>
- <para>BIND version 9 also supports the SIG(0) public/private key method of message authentication.</para>
- </listitem>
- <listitem>
- <para><emphasis>TSIG</emphasis> — Short for <firstterm>Transaction SIGnatures</firstterm>, this feature allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.</para>
- <para>This feature strengthens the standard IP address-based method of transfer authorization. An attacker would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.</para>
- <para>BIND version 9 also supports <firstterm>TKEY</firstterm>, which is another shared secret key method of authorizing zone transfers.</para>
- </listitem>
- </itemizedlist>
+ <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>DNSSEC</emphasis> — Short for <firstterm>DNS SECurity</firstterm>, this feature allows for zones to be cryptographically signed with a <firstterm>zone key</firstterm>.</para>
+ <para>In this way, the information about a specific zone can be verified as coming from a nameserver that has signed it with a particular private key, as long as the recipient has that nameserver's public key.</para>
+ <para>BIND version 9 also supports the SIG(0) public/private key method of message authentication.</para>
+ </listitem>
+ <listitem>
+ <para><emphasis>TSIG</emphasis> — Short for <firstterm>Transaction SIGnatures</firstterm>, this feature allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.</para>
+ <para>This feature strengthens the standard IP address-based method of transfer authorization. An attacker would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.</para>
+ <para>BIND version 9 also supports <firstterm>TKEY</firstterm>, which is another shared secret key method of authorizing zone transfers.</para>
+ </listitem>
+ </itemizedlist>
-->
</section>
- <section
- id="s2-bind-features-dnssec">
+ <section id="s2-bind-features-dnssec">
<title>DNSSEC</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>features</secondary>
<tertiary>DNSSEC</tertiary>
</indexterm>
- <para>DNSSEC (DNS SECurity extensions) is an extension to DNS that provides origin authentication of DNS data, authenticated denial of existence and data integrity. DNSSEC is backward compatible with the "plain" DNS. When a particular domain is marked as secure then validating resolver returns SERFVAIL responses for all RRs which fail validating process.</para>
- <para>For detailed information how to setup DNSSEC-signed zone and DNSSEC validating resolver please refer to <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/>, sections called <command>DNSSEC</command>, <command>DNSSEC, dynamic zones, and automatic signing</command> and <command>Dynamic trust anchor management</command>.</para>
+ <para>
+ DNSSEC (DNS SECurity extensions) is an extension to DNS that provides origin authentication of DNS data, authenticated denial of existence and data integrity. DNSSEC is backward compatible with the "plain" DNS. When a particular domain is marked as secure then validating resolver returns SERFVAIL responses for all RRs which fail validating process.
+ </para>
+ <para>
+ For detailed information how to setup DNSSEC-signed zone and DNSSEC validating resolver please refer to <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/>, sections called <command>DNSSEC</command>, <command>DNSSEC, dynamic zones, and automatic signing</command> and <command>Dynamic trust anchor management</command>.
+ </para>
<note>
<title>Troubleshooting</title>
- <para>When troubleshooting issues with the DNSSEC-signed domain or the DNSSEC-aware resolver, use the <command>dig</command> utility. Useful options are:</para>
+ <para>
+ When troubleshooting issues with the DNSSEC-signed domain or the DNSSEC-aware resolver, use the <command>dig</command> utility. Useful options are:
+ </para>
<itemizedlist><!-- atkac at redhat.com: This list doesn't look so nice, does it? -->
<listitem>
- <para>+dnssec - Requests DNSSEC related RRs by setting the DNSSEC OK (DO) bit in the query.</para>
+ <para>
+ +dnssec - Requests DNSSEC related RRs by setting the DNSSEC OK (DO) bit in the query.
+ </para>
</listitem>
<listitem>
- <para>+cd - Requests the recursive server to not perform validation of the response.</para>
+ <para>
+ +cd - Requests the recursive server to not perform validation of the response.
+ </para>
</listitem>
<listitem>
- <para>+bufsize=512 - Decrease size of the DNS packet to 512B to try to go through misconfigured firewalls</para>
+ <para>
+ +bufsize=512 - Decrease size of the DNS packet to 512B to try to go through misconfigured firewalls
+ </para>
</listitem>
</itemizedlist>
</note>
</section>
- <section
- id="s2-bind-features-ipv6">
+ <section id="s2-bind-features-ipv6">
<title>IP version 6</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>features</secondary>
<tertiary>IPv6</tertiary>
</indexterm>
- <para>BIND version 9 supports name service in IP version 6 (IPv6) environments through the use of <command>AAAA</command> RRs and the <command>listen-on-v6</command> directive in <filename>/etc/named.conf</filename>.</para>
+ <para>
+ BIND version 9 supports name service in IP version 6 (IPv6) environments through the use of <command>AAAA</command> RRs and the <command>listen-on-v6</command> directive in <filename>/etc/named.conf</filename>.
+ </para>
</section>
</section>
- <section
- id="s1-bind-mistakes">
+ <section id="s1-bind-mistakes">
<title>Common Mistakes to Avoid</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>common mistakes</secondary>
</indexterm>
- <para>It is very common for beginners to make mistakes when editing BIND configuration files. Be sure to avoid the following issues:</para>
+ <para>
+ It is very common for beginners to make mistakes when editing BIND configuration files. Be sure to avoid the following issues:
+ </para>
<itemizedlist>
<listitem>
<para>
<emphasis>Take care to increment the serial number when editing a zone file.</emphasis>
</para>
- <para>If the serial number is not incremented, the master nameserver has the correct, new information, but the slave nameservers are never notified of the change and do not attempt to refresh their data of that zone.</para>
+ <para>
+ If the serial number is not incremented, the master nameserver has the correct, new information, but the slave nameservers are never notified of the change and do not attempt to refresh their data of that zone.
+ </para>
</listitem>
<listitem>
<para>
<emphasis>Be careful to use ellipses and semi-colons correctly in the <filename>/etc/named.conf</filename> file.</emphasis>
</para>
- <para>An omitted semi-colon or unclosed ellipse section can cause <command>named</command> to refuse to start.</para>
+ <para>
+ An omitted semi-colon or unclosed ellipse section can cause <command>named</command> to refuse to start.
+ </para>
</listitem>
<listitem>
<para>
<emphasis>Remember to place periods (<command>.</command>) in zone files after all FQDNs and omit them on hostnames.</emphasis>
</para>
- <para>A period at the end of a domain name denotes a fully qualified domain name. If the period is omitted, then <command>named</command> appends the name of the zone or the <command>$ORIGIN</command> value to complete it.</para>
+ <para>
+ A period at the end of a domain name denotes a fully qualified domain name. If the period is omitted, then <command>named</command> appends the name of the zone or the <command>$ORIGIN</command> value to complete it.
+ </para>
</listitem>
<listitem>
- <para>If a firewall is blocking connections from the <command>named</command> daemon to other nameservers, the recommended best practice is to change the firewall settings whenever possible.</para>
+ <para>
+ If a firewall is blocking connections from the <command>named</command> daemon to other nameservers, the recommended best practice is to change the firewall settings whenever possible.
+ </para>
<!-- RHEL5: silas: fix (BZ#455374); thoger:
Further research in DNS security showed that using fixed source UDP port for DNS queries is a security threat allowing attacker to conduct cache poisoning attacks. Because of that, bind name server was updated via RHSA-2008:0533 [1] to use new randomly selected source port for each DNS query, not only during daemon startup. Advice above can make DNS resolving work through firewalls configured in such restrictive way, but it puts your DNS resolving at risk. You should not configure named to use static source port, rather firewall configuration need to be changed to allow queries from random UDP source port.-->
- <warning
- id="warning-Warning-Avoid_Using_Fixed_UDP_Source_Ports">
+ <warning id="warning-Warning-Avoid_Using_Fixed_UDP_Source_Ports">
<title>Warning: Avoid Using Fixed UDP Source Ports</title>
- <para>Recent research in DNS security has shown that using a fixed UDP source port for DNS queries is a potential security vulnerability that could allow an attacker to more easily conduct cache-poisoning attacks</para>
- <para>DNS resolving is at risk whenever <application>named</application> is configured to use a static UDP source port. To avoid this risk, configure your firewall to allow queries from a random UDP source port.</para>
+ <para>
+ Recent research in DNS security has shown that using a fixed UDP source port for DNS queries is a potential security vulnerability that could allow an attacker to more easily conduct cache-poisoning attacks
+ </para>
+ <para>
+ DNS resolving is at risk whenever <application>named</application> is configured to use a static UDP source port. To avoid this risk, configure your firewall to allow queries from a random UDP source port.
+ </para>
</warning>
<!--<para>By default, BIND version 9 uses random ports above 1024 to query other nameservers. Some firewalls, however, expect all nameservers to communicate using only port 53. To force <command
moreinfo="none">named</command> to use port 53, add the following
- line to the <command
+ line to the <command
moreinfo="none">options</command> statement of <filename
moreinfo="none">/etc/named.conf</filename>:</para>
<screen>
@@ -1840,99 +2011,99 @@ zone "1.0.10.in-addr.arpa" IN {
</listitem>
</itemizedlist>
</section>
- <section
- id="s1-bind-additional-resources">
+ <section id="s1-bind-additional-resources">
<title>Additional Resources</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>additional resources</secondary>
</indexterm>
- <para>The following sources of information provide additional resources regarding BIND.</para>
- <section
- id="s2-bind-installed-docs">
+ <para>
+ The following sources of information provide additional resources regarding BIND.
+ </para>
+ <section id="s2-bind-installed-docs">
<title>Installed Documentation</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>additional resources</secondary>
<tertiary>installed documentation</tertiary>
</indexterm>
- <!-- RHEL5: ddomingo at redhat.com: took out main <itemizedlist> --><!-- RHEL5: <itemizedlist>
- <listitem> -->
- <para>BIND features a full range of installed documentation covering many different topics, each placed in its own subject directory. For each item below, replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system:</para>
+ <!-- RHEL5: ddomingo at redhat.com: took out main <itemizedlist> --><!-- RHEL5: <itemizedlist>
+ <listitem> -->
+ <para>
+ BIND features a full range of installed documentation covering many different topics, each placed in its own subject directory. For each item below, replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system:
+ </para>
<variablelist>
<varlistentry>
- <term>
- <filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/</filename>
- </term>
+ <term><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/</filename></term>
<listitem>
- <para>This directory lists the most recent features. <!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. --></para>
+ <para>
+ This directory lists the most recent features. <!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. -->
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/arm/</filename>
- </term>
+ <term><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/arm/</filename></term>
<listitem>
- <para>This directory contains the <citetitle>BIND 9 Administrator Reference Manual</citetitle> in HTML and SGML formats, which details BIND resource requirements, how to configure different types of nameservers, how to perform load balancing, and other advanced topics. For most new users of BIND, this is the best place to start.<!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. -->
+ <para>
+ This directory contains the <citetitle>BIND 9 Administrator Reference Manual</citetitle> in HTML and SGML formats, which details BIND resource requirements, how to configure different types of nameservers, how to perform load balancing, and other advanced topics. For most new users of BIND, this is the best place to start.<!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. -->
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/draft/</filename>
- </term>
+ <term><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/draft/</filename></term>
<listitem>
- <para>This directory contains assorted technical documents that review issues related to DNS service and propose some methods to address them.<!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. --></para>
+ <para>
+ This directory contains assorted technical documents that review issues related to DNS service and propose some methods to address them.<!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. -->
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/misc/</filename>
- </term>
+ <term><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/misc/</filename></term>
<listitem>
- <para>This directory contains documents designed to address specific advanced issues. Users of BIND version 8 should consult the <filename>migration</filename> document for specific changes they must make when moving to BIND 9. The <filename>options</filename> file lists all of the options implemented in BIND 9 that are used in <filename>/etc/named.conf</filename>.<!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. -->
+ <para>
+ This directory contains documents designed to address specific advanced issues. Users of BIND version 8 should consult the <filename>migration</filename> document for specific changes they must make when moving to BIND 9. The <filename>options</filename> file lists all of the options implemented in BIND 9 that are used in <filename>/etc/named.conf</filename>.<!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. -->
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>
- <filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/rfc/</filename>
- </term>
+ <term><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/rfc/</filename></term>
<listitem>
- <para>This directory provides every RFC document related to BIND.<!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. --></para>
+ <para>
+ This directory provides every RFC document related to BIND.<!-- RHEL5: Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system. -->
+ </para>
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces below <itemizedlist>
- <itemizedlist>
- <listitem>
- <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/</filename> — This directory lists the most recent features. Replace <replaceable><version-number></replaceable> with the version of
- <filename>bind</filename> installed on the system.</para>
- </listitem>
- <listitem>
- <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/arm/</filename> — This directory contains HTML and SGML of the <citetitle>BIND 9 Administrator Reference Manual</citetitle>, which details BIND resource requirements, how to configure different types of nameservers, how to perform load balancing, and other advanced topics. For most new users of BIND, this is the best place to start. Replace <replaceable><version-number></replaceable> with
- the version of <filename>bind</filename> installed on the system.</para>
- </listitem>
- <listitem>
- <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/draft/</filename> — This directory contains assorted technical documents that reviews issues related to DNS service and some methods proposed
- to address them. Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system.</para>
- </listitem>
- <listitem>
- <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/misc/</filename> — This directory contains documents designed to address specific advanced issues. Users of BIND version 8 should consult the
- <filename>migration</filename> document for specific changes they must make when moving to BIND 9. The <filename>options</filename> file lists all of the options implemented in BIND 9 that are used in
- <filename>/etc/named.conf</filename>. Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system.</para>
- </listitem>
- <listitem>
- <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/rfc/</filename> — This directory provides every RFC document related to BIND. Replace <replaceable><version-number></replaceable> with
- the version of <filename>bind</filename> installed on the system.</para>
- </listitem>
- </itemizedlist>
- --><!-- RHEL5: </listitem>
- <listitem>
+ <!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces below <itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/</filename> — This directory lists the most recent features. Replace <replaceable><version-number></replaceable> with the version of
+ <filename>bind</filename> installed on the system.</para>
+ </listitem>
+ <listitem>
+ <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/arm/</filename> — This directory contains HTML and SGML of the <citetitle>BIND 9 Administrator Reference Manual</citetitle>, which details BIND resource requirements, how to configure different types of nameservers, how to perform load balancing, and other advanced topics. For most new users of BIND, this is the best place to start. Replace <replaceable><version-number></replaceable> with
+ the version of <filename>bind</filename> installed on the system.</para>
+ </listitem>
+ <listitem>
+ <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/draft/</filename> — This directory contains assorted technical documents that reviews issues related to DNS service and some methods proposed
+ to address them. Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system.</para>
+ </listitem>
+ <listitem>
+ <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/misc/</filename> — This directory contains documents designed to address specific advanced issues. Users of BIND version 8 should consult the
+ <filename>migration</filename> document for specific changes they must make when moving to BIND 9. The <filename>options</filename> file lists all of the options implemented in BIND 9 that are used in
+ <filename>/etc/named.conf</filename>. Replace <replaceable><version-number></replaceable> with the version of <filename>bind</filename> installed on the system.</para>
+ </listitem>
+ <listitem>
+ <para><filename>/usr/share/doc/bind-<replaceable><version-number></replaceable>/rfc/</filename> — This directory provides every RFC document related to BIND. Replace <replaceable><version-number></replaceable> with
+ the version of <filename>bind</filename> installed on the system.</para>
+ </listitem>
+ </itemizedlist>
+ --><!-- RHEL5: </listitem>
+ <listitem>
-->
- <para><!-- RHEL5: BIND-related man pages — -->There are also a number of man pages for the various applications and configuration files involved with BIND. The following lists some of the more important man pages.</para>
+ <para>
+ <!-- RHEL5: BIND-related man pages — -->There are also a number of man pages for the various applications and configuration files involved with BIND. The following lists some of the more important man pages.
+ </para>
<variablelist>
<varlistentry>
<term>Administrative Applications</term>
@@ -1940,7 +2111,8 @@ zone "1.0.10.in-addr.arpa" IN {
<itemizedlist>
<listitem>
<para>
- <command>man rndc</command> — Explains the different options available when using the <command>rndc</command> command to control a BIND nameserver.</para>
+ <command>man rndc</command> — Explains the different options available when using the <command>rndc</command> command to control a BIND nameserver.
+ </para>
</listitem>
</itemizedlist>
</listitem>
@@ -1951,11 +2123,13 @@ zone "1.0.10.in-addr.arpa" IN {
<itemizedlist>
<listitem>
<para>
- <command>man named</command> — Explores assorted arguments that can be used to control the BIND nameserver daemon.</para>
+ <command>man named</command> — Explores assorted arguments that can be used to control the BIND nameserver daemon.
+ </para>
</listitem>
<listitem>
<para>
- <command>man lwresd</command> — Describes the purpose of and options available for the lightweight resolver daemon.</para>
+ <command>man lwresd</command> — Describes the purpose of and options available for the lightweight resolver daemon.
+ </para>
</listitem>
</itemizedlist>
</listitem>
@@ -1966,35 +2140,36 @@ zone "1.0.10.in-addr.arpa" IN {
<itemizedlist>
<listitem>
<para>
- <command>man named.conf</command> — A comprehensive list of options available within the <command>named</command> configuration file.</para>
+ <command>man named.conf</command> — A comprehensive list of options available within the <command>named</command> configuration file.
+ </para>
</listitem>
<listitem>
<para>
- <command>man rndc.conf</command> — A comprehensive list of options available within the <command>rndc</command> configuration file.</para>
+ <command>man rndc.conf</command> — A comprehensive list of options available within the <command>rndc</command> configuration file.
+ </para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: </listitem>
- </itemizedlist>
+ <!-- RHEL5: </listitem>
+ </itemizedlist>
-->
</section>
- <section
- id="s2-bind-useful-websites">
+ <section id="s2-bind-useful-websites">
<title>Useful Websites</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>BIND</primary>
<secondary>additional resources</secondary>
<tertiary>useful websites</tertiary>
</indexterm>
<itemizedlist>
<listitem>
- <para><!-- RHEL5: ddomingo: updated link, but still redirects
- <ulink url="http://www.isc.org/products/BIND/">http://www.isc.org/products/BIND/</ulink> -->
- <ulink
- url="http://www.isc.org/software/bind"/> — The home page of the BIND project containing information about current releases as well as a PDF version of the <citetitle>BIND 9 Administrator Reference Manual</citetitle>.</para>
+ <para>
+ <!-- RHEL5: ddomingo: updated link, but still redirects
+ <ulink url="http://www.isc.org/products/BIND/">http://www.isc.org/products/BIND/</ulink> -->
+ <ulink url="http://www.isc.org/software/bind" /> — The home page of the BIND project containing information about current releases as well as a PDF version of the <citetitle>BIND 9 Administrator Reference Manual</citetitle>.
+ </para>
</listitem>
<!-- atkac at redhat.com: The DNS-HOWTO document is quite outdated. I would rather to exclude it in favor of default /etc/named.conf;
<listitem>
@@ -2005,11 +2180,9 @@ zone "1.0.10.in-addr.arpa" IN {
-->
</itemizedlist>
</section>
- <section
- id="s2-bind-related-books">
+ <section id="s2-bind-related-books">
<title>Related Books</title>
- <indexterm
- significance="normal">
+ <indexterm>
<primary>bind</primary>
<secondary>additional resources</secondary>
<tertiary>related books</tertiary>
@@ -2017,11 +2190,13 @@ zone "1.0.10.in-addr.arpa" IN {
<itemizedlist>
<listitem>
<para>
- <citetitle>DNS and BIND</citetitle> by Paul Albitz and Cricket Liu; O'Reilly & Associates — A popular reference that explains both common and esoteric BIND configuration options, as well as providing strategies for securing a DNS server.</para>
+ <citetitle>DNS and BIND</citetitle> by Paul Albitz and Cricket Liu; O'Reilly & Associates — A popular reference that explains both common and esoteric BIND configuration options, as well as providing strategies for securing a DNS server.
+ </para>
</listitem>
<listitem>
<para>
- <citetitle>The Concise Guide to DNS and BIND</citetitle> by Nicolai Langfeldt; Que — Looks at the connection between multiple network services and BIND, with an emphasis on task-oriented, technical topics.</para>
+ <citetitle>The Concise Guide to DNS and BIND</citetitle> by Nicolai Langfeldt; Que — Looks at the connection between multiple network services and BIND, with an emphasis on task-oriented, technical topics.
+ </para>
</listitem>
</itemizedlist>
</section>
More information about the docs-commits
mailing list