Repository :
http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
---------------------------------------------------------------
commit d5669c03d19de2e46607635e19ac497653f84e6e
Author: Stephen Wadeley <swadeley(a)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>