[deployment-guide/comm-rel: 143/727] Corrections in the 8.1 section.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 12:36:17 UTC 2010
commit 04b774d71c42abfe395e8b652e1eef6e1b63f86d
Author: Adam Tkac <atkac at redhat.com>
Date: Thu Jul 8 16:20:00 2010 +0200
Corrections in the 8.1 section.
en-US/The_BIND_DNS_Server.xml | 46 +++++++++++++++++++++++++++++++++-------
1 files changed, 38 insertions(+), 8 deletions(-)
---
diff --git a/en-US/The_BIND_DNS_Server.xml b/en-US/The_BIND_DNS_Server.xml
index 2d36df2..4c3e281 100644
--- a/en-US/The_BIND_DNS_Server.xml
+++ b/en-US/The_BIND_DNS_Server.xml
@@ -1,4 +1,5 @@
<?xml version='1.0'?>
+<!-- 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
@@ -73,12 +74,12 @@
<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>. A resource record 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 resource record:</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 resource record 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 resource record. 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 resource record which is part of the <computeroutput>sales.example.com</computeroutput> domain.</para>
- <para>Except for the first (leftmost) part of the resource record (<computeroutput>bob</computeroutput>), each section is called a <firstterm>zone</firstterm>. Zone defines a specific <firstterm>namespace</firstterm>. A zone contains definitions of resource records, 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 resource records 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">
@@ -132,7 +133,7 @@
<varlistentry>
<term>authoritative</term>
<listitem>
- <para>This category includes both primary (master) and secondary (slave) servers. Those servers answer only for resource records 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>
@@ -195,9 +196,38 @@
</varlistentry>
<varlistentry>
<term>
+ <filename>/etc/named/</filename> directory
+ </term>
+ <listitem>
+ <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>
<listitem>
- <para>The <command>named</command> working directory which stores zone and statistic files</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>
+ <listitem>
+ <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>
+ <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>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <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>
</listitem>
</varlistentry>
</variablelist>
@@ -213,7 +243,7 @@
-->
<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 moved there. As such, <filename>named.conf</filename> will be located in <filename>/var/named/chroot/etc/named.conf</filename>, and so on.</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>
</section>
More information about the docs-commits
mailing list