[networking-guide] master: DNS: Updates and add "Recommended Naming Practices" (d5669c0)

stephenw at fedoraproject.org stephenw at fedoraproject.org
Sat Jul 26 12:09:28 UTC 2014 

Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git

On branch  : master

>---------------------------------------------------------------

commit d5669c03d19de2e46607635e19ac497653f84e6e
Author: Stephen Wadeley <swadeley at redhat.com>
Date:   Sat Jul 26 12:53:06 2014 +0200

    DNS: Updates and add "Recommended Naming Practices"
    
    Thanks to thozza for his review
    thanks to pspacek for "Recommended Naming Practices"


>---------------------------------------------------------------

 en-US/DNS_Servers.xml |   28 +++++++++++++---------------
 1 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/en-US/DNS_Servers.xml b/en-US/DNS_Servers.xml
index 7d88873..d304d67 100644
--- a/en-US/DNS_Servers.xml
+++ b/en-US/DNS_Servers.xml
@@ -15,7 +15,7 @@
     <see>DNS</see>
   </indexterm>
   <para>
-    <systemitem class="protocol">DNS</systemitem> (Domain Name System), is a network system that associates host names with their respective <systemitem class="protocol">IP</systemitem> 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 a <systemitem class="protocol">DNS</systemitem> server, also known as a <firstterm>nameserver</firstterm>, enables changing the <systemitem class="protocol">IP</systemitem> address for a host without ever affecting the name-based queries.
+    <systemitem class="protocol">DNS</systemitem> (Domain Name System), is a distributed database system that is used to associate host names with their respective <systemitem class="protocol">IP</systemitem> 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 a <systemitem class="protocol">DNS</systemitem> server, also known as a <firstterm>nameserver</firstterm>, enables changing the <systemitem class="protocol">IP</systemitem> address for a host without ever affecting the name-based queries. The use of the <systemitem class="protocol">DNS</systemitem> databases is not only for resolving <systemitem class="protocol">IP</systemitem> addresses to domain names and their use is becoming broader and broader as DNSSEC is deployed.
   </para>
   <section id="sec-Introduction_to_DNS">
     <title>Introduction to DNS</title>
@@ -24,7 +24,7 @@
       <see>BIND</see>
     </indexterm>
     <para>
-      <systemitem class="protocol">DNS</systemitem> 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.
+      <systemitem class="protocol">DNS</systemitem> 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 the nameserver is configured to be a recursive name servers and 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. Nameservers configured as purely authoritative, with recursion disabled, will not do lookups on behalf of clients.
     </para>
     <section id="sec-dns-introduction-zones">
       <title>Nameserver Zones</title>
@@ -36,28 +36,22 @@
         <primary>resource record</primary>
         <see>BIND</see>
       </indexterm>
-      <indexterm>
-        <primary>fully qualified domain name</primary>
-      </indexterm>
-      <indexterm>
-        <primary><acronym>FQDN</acronym></primary>
-        <see>fully qualified domain name</see>
-      </indexterm>
       <para>
-        In a <systemitem class="protocol">DNS</systemitem> server such as BIND (Berkeley Internet Name Domain), 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.
+        In a <systemitem class="protocol">DNS</systemitem> server, all information is stored in basic data elements called <firstterm>resource records</firstterm> (<acronym>RR</acronym>). Resource records are defined in <ulink url="http://www.rfc-editor.org/rfc/rfc1034.txt">RFC 1034</ulink>. The domain names are organized into a tree structure. Each level of the hierarchy is divided by a period (<literal>.</literal>). For example: The root domain, denoted by <literal>.</literal>, is the root of the <systemitem class="protocol">DNS</systemitem> tree, which is at level zero. The domain name <systemitem class="domainname">com</systemitem>, referred to as the <firstterm>top-level domain</firstterm> (<acronym>TLD</acronym>) is a child of the root domain (<literal>.</literal>) so it is the first level of the hierarchy. The domain name <systemitem class="domainname">example.com</systemitem> is at the second level of the hierarchy.
       </para>
       <example id="example-dns-introduction-zones-rr">
-        <title>A simple resource record</title>
-        <screen>bob.sales.example.com</screen>
+        <title>A Simple Resource Record</title>
+        <para>
+          An example of a simple <firstterm>resource record</firstterm> (<acronym>RR</acronym>):</para>
+        <screen>example.com.      86400    IN         A           192.0.2.1</screen>
+        <para>
+        The domain name, <systemitem class="domainname">example.com</systemitem>, is the <firstterm>owner</firstterm> for the RR. The value <literal>86400</literal> is the <firstterm>time to live</firstterm> (<acronym>TTL</acronym>). The letters <literal>IN</literal>, meaning <quote>the Internet system</quote>, indicate the <firstterm>class</firstterm> of the RR. The letter <literal>A</literal> indicates the <firstterm>type</firstterm> of RR (in this example, a host address). The host address <systemitem class="ipaddress">192.0.2.1</systemitem> is the data contained in the final section of this RR. This one line example is a RR. A set of RRs with the same type, owner, and class is called a <firstterm>resource record set</firstterm> (<acronym>RRSet</acronym>).</para>
       </example>
       <indexterm>
         <primary>BIND</primary>
         <secondary>zones</secondary>
         <tertiary>description</tertiary>
       </indexterm>
-      <para>
-        Each level of the hierarchy is divided by a period (that is, <literal>.</literal>). In <xref linkend="example-dns-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>
       <indexterm>
         <primary>BIND</primary>
         <secondary>types</secondary>
@@ -71,6 +65,10 @@
       <para>
         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>
+
+<para>
+  Note that administrators of <systemitem class="protocol">DNS</systemitem> and <systemitem class="protocol">DHCP</systemitem> servers, as well as any provisioning applications, should agree on the host name format used in an organization. See <xref linkend="sec-Recommended_Naming_Practices" /> for more information on the format of host names.
+</para>
     </section>
     <section id="sec-dns-introduction-nameservers">
       <title>Nameserver Types</title>

More information about the docs-commits mailing list