os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Add a section about configuring Unbound in FreeBSD 10. Note that this commit avoids changing all the whitespace in favor of waiting for an automated tool to do that for us.

Browse source 
Reviewed by:	dru@, Ken Reed <kreed002 at gmail.com>
This commit is contained in:
Brad Davis 2014-05-23 14:56:38 +00:00
parent a2f9fcfcaf
commit 3d3a82d501
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44916
1 changed files with 98 additions and 23 deletions

121
en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
View file

@ -3048,7 +3048,82 @@ dhcpd_ifaces="dc0"</programlisting>
</sect2>
<sect2>
<title>How It Works</title>
<title><acronym>DNS</acronym> Server Configuration in &os; 10.0
and Later</title>
<para>In &os; 10.0, <application>BIND</application> has been
replaced with <application>Unbound</application>.
<application>Unbound</application> is a validating caching
resolver only. If an authoritative server is needed, many are
available from the Ports Collection.</para>
<para><application>Unbound</application> is provided in the &os;
base system. By default, it will provide
<acronym>DNS</acronym> resolution to the local machine only.
While the base system package can be configured to provide
resolution services beyond the local machine, it is
recommended that such requirements be addressed by installing
<application>Unbound</application> from the &os; Ports
Collection.</para>
<para>To enable <application>Unbound</application>, add the
following to <filename>/etc/rc.conf</filename>:</para>
<programlisting>local_unbound_enable="YES"</programlisting>
<para>Any existing nameservers in
<filename>/etc/resolv.conf</filename> will be configured as
forwarders in the new <application>Unbound</application>
configuration.</para>
<note>
<para>If any of the listed nameservers do not support
<acronym>DNSSEC</acronym>, local <acronym>DNS</acronym>
resolution will fail. Be sure to test each nameserver and
remove any that fail the test. The following command will
show the trust tree or a failure for a nameserver running on
<systemitem
class="ipaddress">192.168.1.1</systemitem>:</para>
</note>
<screen>&prompt.user; <userinput>drill -S FreeBSD.org @<replaceable>192.168.1.1</replaceable></userinput></screen>
<para>Once each nameserver is confirmed to support
<acronym>DNSSEC</acronym>, start
<application>Unbound</application>:</para>
<screen>&prompt.root; <userinput>service local_unbound onestart</userinput></screen>
<para>This will take care of updating
<filename>/etc/resolv.conf</filename> so that queries for
<acronym>DNSSEC</acronym> secured domains will now work. For
example, run the following to validate the FreeBSD.org
<acronym>DNSSEC</acronym> trust tree:</para>
<screen>&prompt.user; <userinput>drill -S FreeBSD.org</userinput>
;; Number of trusted keys: 1
;; Chasing: freebsd.org. A
DNSSEC Trust tree:
freebsd.org. (A)
|---freebsd.org. (DNSKEY keytag: 36786 alg: 8 flags: 256)
|---freebsd.org. (DNSKEY keytag: 32659 alg: 8 flags: 257)
|---freebsd.org. (DS keytag: 32659 digest type: 2)
|---org. (DNSKEY keytag: 49587 alg: 7 flags: 256)
|---org. (DNSKEY keytag: 9795 alg: 7 flags: 257)
|---org. (DNSKEY keytag: 21366 alg: 7 flags: 257)
|---org. (DS keytag: 21366 digest type: 1)
| |---. (DNSKEY keytag: 40926 alg: 8 flags: 256)
| |---. (DNSKEY keytag: 19036 alg: 8 flags: 257)
|---org. (DS keytag: 21366 digest type: 2)
|---. (DNSKEY keytag: 40926 alg: 8 flags: 256)
|---. (DNSKEY keytag: 19036 alg: 8 flags: 257)
;; Chase successful</screen>
</sect2>
<sect2>
<title>DNS Server Configuration in &os;
9.<replaceable>X</replaceable> and Earlier</title>
<para>In &os;, the BIND daemon is called
<application>named</application>.</para>
@ -3096,9 +3171,8 @@ dhcpd_ifaces="dc0"</programlisting>
directory. These files contain the <acronym>DNS</acronym>
information that will be given out by the name server in
response to queries.</para>
</sect2>
<sect2>
<sect3>
<title>Starting BIND</title>
<indexterm>
@ -3133,9 +3207,9 @@ dhcpd_ifaces="dc0"</programlisting>
&man.rc.conf.5;. The
<xref linkend="configtuning-rcd"/> section is also a good
read.</para>
</sect2>
</sect3>
<sect2>
<sect3>
<title>Configuration Files</title>
<indexterm>
@ -3150,7 +3224,7 @@ dhcpd_ifaces="dc0"</programlisting>
needed is a simple resolver. This is where most of the
configuration will be performed.</para>
<sect3>
<sect4>
<title><filename>/etc/namedb/named.conf</filename></title>
<programlisting>// &dollar;FreeBSD&dollar;
@ -3497,9 +3571,9 @@ zone "1.168.192.in-addr.arpa" {
dies or is unreachable, the slave name server will have the
transferred zone information and will be able to serve
it.</para>
</sect3>
</sect4>
<sect3>
<sect4>
<title>Zone Files</title>
<indexterm>
@ -3744,10 +3818,10 @@ mail IN A 192.168.1.5</programlisting>
<para>It is worth noting that all names on the right side
of a PTR record need to be fully qualified (i.e., end in
a <quote>.</quote>).</para>
</sect3>
</sect2>
</sect4>
</sect3>
<sect2>
<sect3>
<title>Caching Name Server</title>
<indexterm>
@ -3758,9 +3832,9 @@ mail IN A 192.168.1.5</programlisting>
<para>A caching name server is a name server whose primary role
is to resolve recursive queries. It simply asks queries of
its own, and remembers the answers for later use.</para>
</sect2>
</sect3>
<sect2>
<sect3>
<title><acronym role="Domain Name Security
Extensions">DNSSEC</acronym></title>
@ -3810,7 +3884,7 @@ mail IN A 192.168.1.5</programlisting>
to date. Where configurations differ between 9.6.2 and 9.7
and later, differences will be pointed out.</para>
<sect3>
<sect4>
<title>Recursive <acronym>DNS</acronym> Server
Configuration</title>
@ -3954,9 +4028,9 @@ dnssec-validation yes;</programlisting>
<para>The resolver is now capable of authenticating
<acronym>DNS</acronym> queries.</para>
</sect3>
</sect4>
<sect3 xml:id="dns-dnssec-auth">
<sect4 xml:id="dns-dnssec-auth">
<title>Authoritative <acronym>DNS</acronym> Server
Configuration</title>
@ -4085,9 +4159,9 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
xlink:href="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym>
4641: <acronym>DNSSEC</acronym> Operational
practices</link>.</para>
</sect3>
</sect4>
<sect3>
<sect4>
<title>Automation Using <acronym>BIND</acronym> 9.7 or
Later</title>
@ -4127,10 +4201,10 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
re-signing the zone with the new data added. For further
details, see <xref linkend="dns-read"/> and the
<acronym>BIND</acronym> documentation.</para>
</sect3>
</sect2>
</sect4>
</sect3>
<sect2>
<sect3>
<title>Security</title>
<para>Although BIND is the most common implementation of
@ -4155,9 +4229,9 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
having a fresh build of <application>named</application>
may help.</para>
</tip>
</sect2>
</sect3>
<sect2 xml:id="dns-read">
<sect3 xml:id="dns-read">
<title>Further Reading</title>
<para>BIND/<application>named</application> manual pages:
@ -4245,6 +4319,7 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
Trust Anchors</link></para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
</sect1>