[deployment-guide/comm-rel: 396/727] Changed the structure of the sections.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 12:58:01 UTC 2010
commit d7ff2392230f513c2ceb9cc18945058ece322bf5
Author: Jaromir Hradilek <jhradile at redhat.com>
Date: Mon Aug 16 17:30:42 2010 +0200
Changed the structure of the sections.
en-US/The_BIND_DNS_Server.xml | 104 +++++++++++++++++++++-------------------
1 files changed, 55 insertions(+), 49 deletions(-)
---
diff --git a/en-US/The_BIND_DNS_Server.xml b/en-US/The_BIND_DNS_Server.xml
index 85815bc..2135076 100644
--- a/en-US/The_BIND_DNS_Server.xml
+++ b/en-US/The_BIND_DNS_Server.xml
@@ -1442,18 +1442,23 @@ IN NS dns2.example.com.</screen>
<screen> 604800 ; expire after 1 week</screen>
</section>
<section id="s2-bind-zone-examples">
- <title>Example Zone File</title>
- <indexterm>
- <primary>BIND</primary>
- <secondary>configuration of</secondary>
- <tertiary>zone file examples</tertiary>
- </indexterm>
+ <title>Example Usage</title>
<para>
- <xref linkend="example-bind-zone-examples-basic" /> demonstrates a basic usage of standard directives and <command>SOA</command> values.
+ The following examples show the basic usage of zone files.
</para>
- <example id="example-bind-zone-examples-basic">
- <title>A simple zone file</title>
- <screen>$ORIGIN example.com.
+ <section id="s3-bind-zone-examples-basic">
+ <title>A Simple Zone File</title>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>configuration of</secondary>
+ <tertiary>zone file examples</tertiary>
+ </indexterm>
+ <para>
+ <xref linkend="example-bind-zone-examples-basic" /> demonstrates the use of standard directives and <command>SOA</command> values.
+ </para>
+ <example id="example-bind-zone-examples-basic">
+ <title>A simple zone file</title>
+ <screen>$ORIGIN example.com.
$TTL 86400
@ SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
@@ -1491,38 +1496,38 @@ ftp CNAME services.example.com.
www 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.
- </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>.
- </para>
- <para>
- Services available at the standard names, such as <systemitem class="domainname">www.example.com</systemitem> (<acronym>WWW</acronym>), are pointed at the appropriate servers using the <command>CNAME</command> record.
- </para>
- <para>
- This zone file would be called into service with a <command>zone</command> statement in the <filename>/etc/named.conf</filename> similar to the following:
- </para>
- <screen>zone "example.com" IN {
+ </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.
+ </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>.
+ </para>
+ <para>
+ Services available at the standard names, such as <systemitem class="domainname">www.example.com</systemitem> (<acronym>WWW</acronym>), are pointed at the appropriate servers using the <command>CNAME</command> record.
+ </para>
+ <para>
+ This zone file would be called into service with a <command>zone</command> statement in the <filename>/etc/named.conf</filename> similar to the following:
+ </para>
+ <screen>zone "example.com" IN {
type master;
file "example.com.zone";
allow-update { none; };
};</screen>
- </section>
- <section id="s2-bind-configuration-zone-reverse">
- <title>Reverse Name Resolution Zone Files</title>
- <indexterm>
- <primary>BIND</primary>
- <secondary>configuration of</secondary>
- <tertiary>reverse name resolution</tertiary>
- </indexterm>
- <para>
- A reverse name resolution zone file is used to translate an IP address in a particular namespace into an fully qualified domain name (FQDN). It looks very similar to a standard zone file, except that the <command>PTR</command> resource records are used to link the IP addresses to a fully qualified domain name as shown in <xref linkend="example-bind-zone-examples-reverse" />.
- </para>
- <example id="example-bind-zone-examples-reverse">
- <title>A reverse name resolution zone file</title>
- <screen>$ORIGIN 1.0.10.in-addr.arpa.
+ </section>
+ <section id="s2-bind-configuration-zone-reverse">
+ <title>A Reverse Name Resolution Zone File</title>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>configuration of</secondary>
+ <tertiary>reverse name resolution</tertiary>
+ </indexterm>
+ <para>
+ A reverse name resolution zone file is used to translate an IP address in a particular namespace into an fully qualified domain name (FQDN). It looks very similar to a standard zone file, except that the <command>PTR</command> resource records are used to link the IP addresses to a fully qualified domain name as shown in <xref linkend="example-bind-zone-examples-reverse" />.
+ </para>
+ <example id="example-bind-zone-examples-reverse">
+ <title>A reverse name resolution zone file</title>
+ <screen>$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
@@ -1541,21 +1546,22 @@ $TTL 86400
;
3 IN PTR ftp.example.com.
4 IN PTR ftp.example.com.</screen>
- </example>
- <para>
- In this example, IP addresses <systemitem class="ipaddress">10.0.1.1</systemitem> through <systemitem class="ipaddress">10.0.1.6</systemitem> are pointed to the corresponding fully qualified domain name.
- </para>
- <para>
- This zone file would be called into service with a <option>zone</option> statement in the <filename>/etc/named.conf</filename> file similar to the following:
- </para>
- <screen>zone "1.0.10.in-addr.arpa" IN {
+ </example>
+ <para>
+ In this example, IP addresses <systemitem class="ipaddress">10.0.1.1</systemitem> through <systemitem class="ipaddress">10.0.1.6</systemitem> are pointed to the corresponding fully qualified domain name.
+ </para>
+ <para>
+ This zone file would be called into service with a <option>zone</option> statement in the <filename>/etc/named.conf</filename> file similar to the following:
+ </para>
+ <screen>zone "1.0.10.in-addr.arpa" IN {
type master;
file "example.com.rr.zone";
allow-update { none; };
};</screen>
- <para>
- There is very little difference between this example and a standard <command>zone</command> statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by <command>.in-addr.arpa</command>. This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.
- </para>
+ <para>
+ There is very little difference between this example and a standard <command>zone</command> statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by <command>.in-addr.arpa</command>. This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.
+ </para>
+ </section>
</section>
</section>
<section id="s1-bind-rndc">
More information about the docs-commits
mailing list