[deployment-guide/comm-rel: 404/727] Updated the Nameserver Zones section.

[Jaromir Hradilek]

commit bcb8b157e10aad15cde472ad27020f8934fb3918
Author: Jaromir Hradilek <jhradile at redhat.com>
Date:   Tue Aug 17 15:36:58 2010 +0200

    Updated the Nameserver Zones section.

 en-US/The_BIND_DNS_Server.xml |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)
---
diff --git a/en-US/The_BIND_DNS_Server.xml b/en-US/The_BIND_DNS_Server.xml
index 6ecfb7d..fcb9b70 100644
--- a/en-US/The_BIND_DNS_Server.xml
+++ b/en-US/The_BIND_DNS_Server.xml
@@ -46,17 +46,17 @@
         <tertiary>description</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:
+        In a DNS server such as BIND, all information is stored in basic data elements called <firstterm>resource records</firstterm> (RR). The resource record is usually a <firstterm>fully qualified domain name</firstterm> (FQDN) of a host, and is broken down into multiple sections organized into a tree-like hierarchy. This hierarchy consists of a main trunk, primary branches, secondary branches, and so on.
       </para>
-      <screen>bob.sales.example.com</screen>
+      <example id="example-bind-introduction-zones-rr">
+        <title>A simple resource record</title>
+        <screen>bob.sales.example.com</screen>
+      </example>
       <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.
+        Each level of the hierarchy is divided by a period (that is, <literal>.</literal>). In <xref linkend="example-bind-introduction-zones-rr" />, <literal>com</literal> defines the <firstterm>top-level domain</firstterm>, <literal>example</literal> its subdomain, and <literal>sales</literal> the subdomain of <literal>example</literal>. In this case, <literal>bob</literal> identifies a resource record that is part of the <systemitem class="domainname">sales.example.com</systemitem> domain. With the exception of the part furthest to the left (that is, <literal>bob</literal>), each of these sections is called a <firstterm>zone</firstterm> and defines a specific <firstterm>namespace</firstterm>.
       </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.
+        Zones are defined on authoritative nameservers through the use of <firstterm>zone files</firstterm>, which contain definitions of the resource records in each 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. Depending on the configuration, any nameserver can also serve as a primary or secondary server for multiple zones at the same time.
       </para>
     </section>
     <section id="s2-bind-introduction-nameservers">