[deployment-guide/comm-rel: 147/727] Corrections in the 8.5 chapter.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 12:36:38 UTC 2010
commit 37f6ead68635ea127c52d3aa921f35f77086c9ba
Author: Adam Tkac <atkac at redhat.com>
Date: Mon Jul 12 14:03:29 2010 +0200
Corrections in the 8.5 chapter.
en-US/The_BIND_DNS_Server.xml | 72 ++++++++++++++++++++++++-----------------
1 files changed, 42 insertions(+), 30 deletions(-)
---
diff --git a/en-US/The_BIND_DNS_Server.xml b/en-US/The_BIND_DNS_Server.xml
index bf9a2af..b45aff8 100644
--- a/en-US/The_BIND_DNS_Server.xml
+++ b/en-US/The_BIND_DNS_Server.xml
@@ -867,7 +867,7 @@ masters { 192.168.0.1; };
</term>
<listitem>
<para>Contains assorted public keys used for secure DNS (DNSSEC). Refer to <xref
- linkend="s2-bind-features-security"/> for more information concerning BIND security.</para>
+ linkend="s2-bind-features-dnssec"/> for more information about DNSSEC.</para>
</listitem>
</varlistentry>
<varlistentry>
@@ -1684,7 +1684,7 @@ zone "1.0.10.in-addr.arpa" IN {
<primary>BIND</primary>
<secondary>features</secondary>
</indexterm>
- <para>Most BIND implementations only use <command>named</command> to provide name resolution services or to act as an authority for a particular domain or sub-domain. However, BIND version 9 has a number of advanced features that allow for a more secure and efficient DNS service.</para>
+ <para>Most BIND implementations only use <command>named</command> to provide name resolution services or to act as an authority for a particular domain. However, BIND version 9 has a number of advanced features that allow for a more secure and efficient DNS service.</para>
<warning>
<title>Caution</title>
<para>Some of these advanced features, such as DNSSEC, TSIG, and IXFR (which are defined in the following section), should only be used in network environments with nameservers that support the features. If the network environment includes non-BIND or older BIND nameservers, verify that each advanced feature is supported before attempting to use it.</para>
@@ -1719,37 +1719,23 @@ zone "1.0.10.in-addr.arpa" IN {
<para>The <command>view</command> statement uses the <command>match-clients</command> option to match IP addresses or entire networks and give them special options and zone data.</para>
</section>
<section
- id="s2-bind-features-security">
- <title>Security</title>
+ id="s2-bind-features-tsig">
+ <title>TSIG</title>
<indexterm
significance="normal">
<primary>BIND</primary>
<secondary>features</secondary>
- <tertiary>security</tertiary>
+ <tertiary>TSIG</tertiary>
</indexterm>
- <para>BIND supports a number of different methods to protect the updating and transfer of zones, on both master and slave nameservers:</para>
- <variablelist>
- <varlistentry>
- <term>
- <emphasis>DNSSEC</emphasis>
- </term>
- <listitem>
- <para>Short for <firstterm>DNS SECurity</firstterm>, this feature allows for zones to be cryptographically signed with a <firstterm>zone key</firstterm>.</para>
- <para>In this way, the information about a specific zone can be verified as coming from a nameserver that has signed it with a particular private key, as long as the recipient has that nameserver's public key.</para>
- <para>BIND version 9 also supports the SIG(0) public/private key method of message authentication.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <emphasis>TSIG</emphasis>
- </term>
- <listitem>
- <para>Short for <firstterm>Transaction SIGnatures</firstterm>, this feature allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.</para>
- <para>This feature strengthens the standard IP address-based method of transfer authorization. An attacker would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.</para>
- <para>BIND version 9 also supports <firstterm>TKEY</firstterm>, which is another shared secret key method of authorizing zone transfers.</para>
- </listitem>
- </varlistentry>
- </variablelist>
+ <para>Short for <firstterm>Transaction SIGnatures</firstterm>, this feature allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.</para>
+ <para>This feature strengthens the standard IP address-based method of transfer authorization. An attacker would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.</para>
+ <para>BIND version 9 also supports <firstterm>TKEY</firstterm>, which is another shared secret key method of authorizing zone transfers.</para>
+ <para>More information about TSIG is available in the <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/>, in chapter called <command>Advanced DNS features</command>.</para>
+ <important>
+ <title>Caution</title>
+ <para>Master and slave nameservers which communicates over insecure network should avoid IP address-based authentication. They should use TSIG-based authentication instead.</para>
+ </important>
+
<!-- RHEL5: ddomingo at redhat.com: above <variablelist> replaces following <itemizedlist>:
<itemizedlist>
<listitem>
@@ -1766,6 +1752,33 @@ zone "1.0.10.in-addr.arpa" IN {
-->
</section>
<section
+ id="s2-bind-features-dnssec">
+ <title>DNSSEC</title>
+ <indexterm
+ significance="normal">
+ <primary>BIND</primary>
+ <secondary>features</secondary>
+ <tertiary>DNSSEC</tertiary>
+ </indexterm>
+ <para>DNSSEC (DNS SECurity extensions) is an extension to DNS that provides origin authentication of DNS data, authenticated denial of existence and data integrity. DNSSEC is backward compatible with the "plain" DNS. When a particular domain is marked as secure then validating resolver returns SERFVAIL responses for all RRs which fail validating process.</para>
+ <para>For detailed information how to setup DNSSEC-signed zone and DNSSEC validating resolver please refer to <citetitle>BIND 9 Administrator Reference Manual</citetitle> referenced in <xref linkend="s2-bind-installed-docs"/>, sections called <command>DNSSEC</command>, <command>DNSSEC, dynamic zones, and automatic signing</command> and <command>Dynamic trust anchor management</command>.</para>
+ <note>
+ <title>Troubleshooting</title>
+ <para>When troubleshooting issues with the DNSSEC-signed domain or the DNSSEC-aware resolver, use the <command>dig</command> utility. Useful options are:</para>
+ <itemizedlist><!-- atkac at redhat.com: This list doesn't look so nice, does it? -->
+ <listitem>
+ <para>+dnssec - Requests DNSSEC related RRs by setting the DNSSEC OK (DO) bit in the query.</para>
+ </listitem>
+ <listitem>
+ <para>+cd - Requests the recursive server to not perform validation of the response.</para>
+ </listitem>
+ <listitem>
+ <para>+bufsize=512 - Decrease size of the DNS packet to 512B to try to go through misconfigured firewalls</para>
+ </listitem>
+ </itemizedlist>
+ </note>
+ </section>
+ <section
id="s2-bind-features-ipv6">
<title>IP version 6</title>
<indexterm
@@ -1774,8 +1787,7 @@ zone "1.0.10.in-addr.arpa" IN {
<secondary>features</secondary>
<tertiary>IPv6</tertiary>
</indexterm>
- <para>BIND version 9 supports name service in IP version 6 (IPv6) environments through the use of <command>A6</command> zone records.</para>
- <para>If the network environment includes both IPv4 and IPv6 hosts, use the <command>lwresd</command> lightweight resolver daemon on all network clients. This daemon is a very efficient, caching-only nameserver which understands the new <command>A6</command> and <command>DNAME</command> records used under IPv6. Refer to the <command>lwresd</command> man page for more information.</para>
+ <para>BIND version 9 supports name service in IP version 6 (IPv6) environments through the use of <command>AAAA</command> RRs and the <command>listen-on-v6</command> directive in <filename>/etc/named.conf</filename>.</para>
</section>
</section>
<section
More information about the docs-commits
mailing list