[deployment-guide/comm-rel: 145/727] Corrections in the 8.3 section.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 12:36:27 UTC 2010
commit 1d29a7d61102fc4bcaa5d239462cc89d3a3aaa46
Author: Adam Tkac <atkac at redhat.com>
Date: Mon Jul 12 11:59:40 2010 +0200
Corrections in the 8.3 section.
en-US/The_BIND_DNS_Server.xml | 31 ++++++++++++++++++++-----------
1 files changed, 20 insertions(+), 11 deletions(-)
---
diff --git a/en-US/The_BIND_DNS_Server.xml b/en-US/The_BIND_DNS_Server.xml
index a30bdcd..dfa23b8 100644
--- a/en-US/The_BIND_DNS_Server.xml
+++ b/en-US/The_BIND_DNS_Server.xml
@@ -963,10 +963,6 @@ masters { 192.168.0.1; };
</indexterm>
<para>
<firstterm>Zone files</firstterm> contain information about a namespace and are stored in the <command>named</command> working directory (<filename>/var/named/</filename>) by default. Each zone file is named according to the <command>file</command> option data in the <command>zone</command> statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as <filename>example.com.zone</filename>.</para>
- <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, you can find the zone files in <filename>/var/named/chroot/var/named</filename>.</para>
- </note>
<para>Each zone file may contain <firstterm>directives</firstterm> and <firstterm>resource records</firstterm>. Directives tell the nameserver to perform tasks or apply special settings to the zone. Resource records define the parameters of the zone and assign identities to individual hosts. Directives are optional, but resource records are required to provide name service to a zone.</para>
<para>All directives and resource records should be entered on individual lines.</para>
<para>Comments can be placed after semicolon characters (<command>;</command>) in zone files.</para>
@@ -1064,13 +1060,13 @@ masters { 192.168.0.1; };
<screen>
<replaceable><host></replaceable> IN A <replaceable><IP-address></replaceable>
</screen>
- <para>If the <replaceable><host></replaceable> value is omitted, then an <command>A</command> record points to a default IP address for the top of the namespace. This system is the target for all non-FQDN requests.</para>
+ <para>If the <replaceable><host></replaceable> value is omitted, then an <command>A</command> record points to the last specified <replaceable><host></replaceable>.</para>
<para>Consider the following <command>A</command> record examples for the <command>example.com</command> zone file:</para>
<screen>
server1 IN A 10.0.1.3
- IN A 10.0.1.5
+ IN A 10.0.1.5
</screen>
- <para>Requests for <command>example.com</command> are pointed to 10.0.1.3 or 10.0.1.5.</para>
+ <para>Requests for <command>server1.example.com</command> are pointed to 10.0.1.3 or 10.0.1.5.</para>
</listitem>
</varlistentry>
<varlistentry>
@@ -1086,6 +1082,18 @@ server1 IN A 10.0.1.3
<para>In the following example, an <command>A</command> record binds a hostname to an IP address, while a <command>CNAME</command> record points the commonly used <command>www</command> hostname to it.</para>
<screen>server1 IN A 10.0.1.5
www IN CNAME server1</screen>
+ <para>There are multiple restrictions for CNAME usage:</para>
+ <itemizedlist>
+ <listitem>
+ <para>CNAME RRs should not point to other CNAME RRs. Particularly, it is possible to create infinite loops when CNAME points to another CNAME and vice-versa.</para>
+ </listitem>
+ <listitem>
+ <para>CNAME RR mustn't contain other RR types (like A, NS, MX, etc.). The exception are DNSSEC related RRs (RRSIG, NSEC, etc.), when zone is signed.</para>
+ </listitem>
+ <listitem>
+ <para>Other RRs which points to FQDN (like NS, MX, PTR) must not point to a CNAME.</para>
+ </listitem>
+ </itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
@@ -1093,14 +1101,15 @@ www IN CNAME server1</screen>
<command>MX</command>
</term>
<listitem>
- <para>This refers to the Mhail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.</para>
+ <para>This refers to the Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.</para>
<screen>IN MX <replaceable><preference-value></replaceable>
<replaceable><email-server-name></replaceable>
</screen>
<para><!-- RHEL5: In this example, -->Here, the <replaceable><preference-value></replaceable> allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The <command>MX</command> resource record with the lowest <replaceable><preference-value></replaceable> is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.</para>
- <para>The <replaceable><email-server-name></replaceable> may be a hostname or FQDN.</para>
- <screen>IN MX 10 mail.example.com.
-IN MX 20 mail2.example.com.</screen>
+ <para>The <replaceable><email-server-name></replaceable> is FQDN.</para>
+ <screen>
+example.com. IN MX 10 mail.example.com.
+ IN MX 20 mail2.example.com.</screen>
<para>In this example, the first <command>mail.example.com</command> email server is preferred to the <command>mail2.example.com</command> email server when receiving email destined for the <command>example.com</command> domain.</para>
</listitem>
</varlistentry>
More information about the docs-commits
mailing list