[deployment-guide/comm-rel: 370/727] Indexed the Other Statement Types section.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 12:55:48 UTC 2010
commit 192424279ca4b20d7a8c311382a605d683a1eaf2
Author: Jaromir Hradilek <jhradile at redhat.com>
Date: Fri Aug 13 19:26:41 2010 +0200
Indexed the Other Statement Types section.
en-US/The_BIND_DNS_Server.xml | 74 ++++++++++++++++++++++++++++++++---------
1 files changed, 58 insertions(+), 16 deletions(-)
---
diff --git a/en-US/The_BIND_DNS_Server.xml b/en-US/The_BIND_DNS_Server.xml
index b716a3a..8f4a25f 100644
--- a/en-US/The_BIND_DNS_Server.xml
+++ b/en-US/The_BIND_DNS_Server.xml
@@ -846,21 +846,35 @@ options {
</para>
<variablelist>
<varlistentry>
- <term><command>controls</command></term>
+ <term>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>configuration</secondary>
+ <tertiary><option>controls</option> statement</tertiary>
+ </indexterm>
+ <option>controls</option>
+ </term>
<listitem>
<para>
- The <command>controls</command> statement allows you to configure various security requirements necessary to use the <command>rndc</command> command to administer the <systemitem class="service">named</systemitem> service.
+ The <option>controls</option> statement allows you to configure various security requirements necessary to use the <command>rndc</command> command to administer the <systemitem class="service">named</systemitem> service.
</para>
<para>
- Refer to <xref linkend="s2-bind-rndc-configuration-namedconf" /> for more information on how the <command>controls</command> statement is structured, and what options are available.
+ Refer to <xref linkend="s2-bind-rndc-configuration-namedconf" /> for more information on how the <option>controls</option> statement is structured, and what options are available.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><command>key</command></term>
+ <term>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>configuration</secondary>
+ <tertiary><option>key</option> statement</tertiary>
+ </indexterm>
+ <option>key</option>
+ </term>
<listitem>
<para>
- The <command>key</command> statement allows you to define a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the <command>rndc</command> command. Two options are used with <command>key</command>:
+ The <option>key</option> statement allows you to define a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the <command>rndc</command> command. Two options are used with <option>key</option>:
</para>
<itemizedlist>
<listitem>
@@ -875,15 +889,22 @@ options {
</listitem>
</itemizedlist>
<para>
- Refer to <xref linkend="s2-bind-rndc-configuration-rndcconf" /> for instructions on how to write a <command>key</command> statement.
+ Refer to <xref linkend="s2-bind-rndc-configuration-rndcconf" /> for instructions on how to write a <option>key</option> statement.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><command>logging</command></term>
+ <term>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>configuration</secondary>
+ <tertiary><option>logging</option> statement</tertiary>
+ </indexterm>
+ <option>logging</option>
+ </term>
<listitem>
<para>
- The <command>logging</command> statement allows you to use multiple types of logs, so called <firstterm>channels</firstterm>. By using the <option>channel</option> option within the statement, you can construct a customized type of log with its own file name (<option>file</option>), size limit (<option>size</option>), versioning (<option>version</option>), and level of importance (<option>severity</option>). Once a customized channel is defined, a <option>category</option> option is used to categorize the channel and begin logging when the <systemitem class="service">named</systemitem> service is restarted.
+ The <option>logging</option> statement allows you to use multiple types of logs, so called <firstterm>channels</firstterm>. By using the <option>channel</option> option within the statement, you can construct a customized type of log with its own file name (<option>file</option>), size limit (<option>size</option>), versioning (<option>version</option>), and level of importance (<option>severity</option>). Once a customized channel is defined, a <option>category</option> option is used to categorize the channel and begin logging when the <systemitem class="service">named</systemitem> service is restarted.
</para>
<para>
By default, <systemitem class="service">named</systemitem> sends standard messages to the <systemitem class="service">rsyslog</systemitem> daemon, which places them in <filename>/var/log/messages</filename>. Several standard channels are built into BIND with various severity levels, such as <literal>default_syslog</literal> (which handles informational logging messages) and <literal>default_debug</literal> (which specifically handles debugging messages). A default category, called <literal>default</literal>, uses the built-in channels to do normal logging without any special configuration.
@@ -894,10 +915,17 @@ options {
</listitem>
</varlistentry>
<varlistentry>
- <term><command>server</command></term>
+ <term>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>configuration</secondary>
+ <tertiary><option>server</option> statement</tertiary>
+ </indexterm>
+ <option>server</option>
+ </term>
<listitem>
<para>
- The <command>server</command> statement allows you to specify options that affect how the <systemitem class="service">named</systemitem> service should respond to remote nameservers, especially with regard to notifications and zone transfers.
+ The <option>server</option> statement allows you to specify options that affect how the <systemitem class="service">named</systemitem> service should respond to remote nameservers, especially with regard to notifications and zone transfers.
</para>
<para>
The <option>transfer-format</option> option controls the number of resource records that are sent with each message. It can be either <literal>one-answer</literal> (only one resource record), or <literal>many-answers</literal> (multiple resource records). Note that while the <literal>many-answers</literal> option is more efficient, it is not supported by older versions of BIND.
@@ -905,24 +933,38 @@ options {
</listitem>
</varlistentry>
<varlistentry>
- <term><command>trusted-keys</command></term>
+ <term>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>configuration</secondary>
+ <tertiary><option>trusted-keys</option> statement</tertiary>
+ </indexterm>
+ <option>trusted-keys</option>
+ </term>
<listitem>
<para>
- The <command>trusted-keys</command> statement allows you to specify assorted public keys used for secure DNS (DNSSEC). Refer to <xref linkend="s2-bind-features-dnssec" /> for more information on this topic.
+ The <option>trusted-keys</option> statement allows you to specify assorted public keys used for secure DNS (DNSSEC). Refer to <xref linkend="s2-bind-features-dnssec" /> for more information on this topic.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><command>view</command></term>
+ <term>
+ <indexterm>
+ <primary>BIND</primary>
+ <secondary>configuration</secondary>
+ <tertiary><option>view</option> statement</tertiary>
+ </indexterm>
+ <option>view</option>
+ </term>
<listitem>
<para>
- The <command>view</command> 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.
+ 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 <command>options</command> statement is used within a view, it overrids the already configured global options. Finally, most <command>view</command> statements contain multiple <command>zone</command> 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 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.
</para>
<para>
- Note that the order in which the <command>view</command> 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" />.
+ 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" />.
</para>
</listitem>
</varlistentry>
More information about the docs-commits
mailing list