[deployment-guide/comm-rel: 440/727] Corrected a handful of typing errors.

Jaromir Hradilek jhradile at fedoraproject.org
Tue Oct 19 13:01:50 UTC 2010


commit 354ee474f64e8db6b21a8f828d6801ca0145ebb1
Author: Jaromir Hradilek <jhradile at redhat.com>
Date:   Fri Aug 20 10:31:43 2010 +0200

    Corrected a handful of typing errors.

 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 b864264..8faf4d8 100644
--- a/en-US/The_BIND_DNS_Server.xml
+++ b/en-US/The_BIND_DNS_Server.xml
@@ -13,7 +13,7 @@
     <see>DNS</see>
   </indexterm>
   <para>
-    <systemitem class="protocol">DNS</systemitem> (Domain Name System), also known as a <firstterm>nameserver</firstterm>, is a network system that associates hostnames with their respective IP adresses. For users, this has the advantage that they can refer to machines on the network by names that are usually easier to remember than the numerical network adresses. For system administrators, using the nameserver allows them to change the IP adress for a host without ever affecting the name-based queries, or to decide which machines handle these queries.
+    <systemitem class="protocol">DNS</systemitem> (Domain Name System), also known as a <firstterm>nameserver</firstterm>, is a network system that associates hostnames with their respective IP addresses. For users, this has the advantage that they can refer to machines on the network by names that are usually easier to remember than the numerical network addresses. For system administrators, using the nameserver allows them to change the IP address for a host without ever affecting the name-based queries, or to decide which machines handle these queries.
   </para>
   <indexterm>
     <primary>Berkeley Internet Name Domain</primary>
@@ -29,7 +29,7 @@
       <see>BIND</see>
     </indexterm>
     <para>
-      DNS is usually implemented using one or more cenralized servers that are authoritative for certain domains. 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 it does not have an authoritative answer, 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, and then queries them to get the requested name.
+      DNS is usually implemented using one or more centralized servers that are authoritative for certain domains. 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 it does not have an authoritative answer, 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, and then queries them to get the requested name.
     </para>
     <section id="s2-bind-introduction-zones">
       <title>Nameserver Zones</title>
@@ -918,7 +918,7 @@ options {
               The <option>view</option> statement allows you to create 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 can be used as long as their names are unique. The <option>match-clients</option> option allows you to specify the IP addresses that apply to a particular view. If the <option>options</option> statement is used within a view, it overrids the already configured global options. Finally, most <option>view</option> statements contain multiple <option>zone</option> statements that apply to the <option>match-clients</option> list.
+              Multiple views can be used as long as their names are unique. The <option>match-clients</option> option allows you to specify the IP addresses that apply to a particular view. If the <option>options</option> statement is used within a view, it overrides the already configured global options. Finally, most <option>view</option> statements contain multiple <option>zone</option> statements that apply to the <option>match-clients</option> list.
             </para>
             <para>
              Note that the order in which the <option>view</option> statements are listed is important, as the first statement that matches a particular client's IP address is used. For more information on this topic, refer to <xref linkend="s2-bind-features-views" />.
@@ -1037,7 +1037,7 @@ options {
               <filename class="directory">/var/named/data/</filename>
             </entry>
             <entry>
-              The directory for various stytistics and debugging files. This directory is writable by the <systemitem class="service">named</systemitem> service.
+              The directory for various statistics and debugging files. This directory is writable by the <systemitem class="service">named</systemitem> service.
             </entry>
           </row>
         </tbody>
@@ -1066,7 +1066,7 @@ options {
           </term>
           <listitem>
             <para>
-              The <command>$INCLUDE</command> directive allows you to include another file at the the place where it appears, so that other zone settings can be stored in a separate zone file.
+              The <command>$INCLUDE</command> directive allows you to include another file at the place where it appears, so that other zone settings can be stored in a separate zone file.
             </para>
             <example id="example-bind-zone-directive-include">
               <title>Using the <command>$INCLUDE</command> directive</title>
@@ -1137,7 +1137,7 @@ options {
           </term>
           <listitem>
             <para>
-              The <firstterm>Address</firstterm> record specifies an IP addres to be assigned to a name. It takes the following form:
+              The <firstterm>Address</firstterm> record specifies an IP address to be assigned to a name. It takes the following form:
             </para>
             <screen><replaceable>hostname</replaceable> IN A <replaceable>IP-address</replaceable></screen>
             <para>
@@ -1519,7 +1519,7 @@ www       IN  CNAME  services.example.com.
 ;</screen>
         </example>
         <para>
-          In this example, the authoritative nameservers are set as <systemitem class="domainname">dns1.example.com</systemitem> and <systemitem class="domainname">dns2.example.com</systemitem>, and are tied to the <systemitem class="ipaddress">10.0.1.1</systemitem> and <systemitem class="ipaddress">10.0.1.2</systemitem> IP adresses respectively using the <command>A</command> record.
+          In this example, the authoritative nameservers are set as <systemitem class="domainname">dns1.example.com</systemitem> and <systemitem class="domainname">dns2.example.com</systemitem>, and are tied to the <systemitem class="ipaddress">10.0.1.1</systemitem> and <systemitem class="ipaddress">10.0.1.2</systemitem> IP addresses respectively using the <command>A</command> record.
         </para>
         <para>
           The email servers configured with the <command>MX</command> records point to <systemitem class="domainname">mail</systemitem> and <systemitem class="domainname">mail2</systemitem> via <command>A</command> records. Since these names do not end in a trailing period (that is, the <literal>.</literal> character), the <command>$ORIGIN</command> domain is placed after them, expanding them to <systemitem class="domainname">mail.example.com</systemitem> and <systemitem class="domainname">mail2.example.com</systemitem>.


More information about the docs-commits mailing list