network-dns.html

FreeBSD操作系统的详细使用手册

// Also, make sure to enable it in /etc/rc.conf.

zone "." {
        type hint;
        file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
        file "localhost.rev";
};

zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
        type master;
        file "localhost.rev";
};

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example secondary config entries.  It can be convenient to become
// a secondary at least for the zone where your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// primary.
//
// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
// (This is the first bytes of the respective IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended.)
//
// Before starting to setup a primary zone, better make sure you fully
// understand how DNS and BIND works, however.  There are sometimes
// unobvious pitfalls.  Setting up a secondary is comparably simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.
//
// NOTE!!! FreeBSD runs BIND in a sandbox (see named_flags in rc.conf).
// The directory containing the secondary zones must be write accessible
// to BIND.  The following sequence is suggested:
//
//      mkdir /etc/namedb/s
//      chown bind:bind /etc/namedb/s
//      chmod 750 /etc/namedb/s
</pre>

<p>For more information on running BIND in a sandbox, see <a
href="network-dns.html#NETWORK-NAMED-SANDBOX">Running named in a sandbox</a>.</p>

<pre class="PROGRAMLISTING">
/*
zone "example.com" {
        type slave;
        file "s/example.com.bak";
        masters {
                192.168.1.1;
        };
};

zone "0.168.192.in-addr.arpa" {
        type slave;
        file "s/0.168.192.in-addr.arpa.bak";
        masters {
                192.168.1.1;
        };
};
*/
</pre>

<p>In <tt class="FILENAME">named.conf</tt>, these are examples of slave entries for a
forward and reverse zone.</p>

<p>For each new zone served, a new zone entry must be added to <tt
class="FILENAME">named.conf</tt>.</p>

<p>For example, the simplest zone entry for <tt class="HOSTID">example.org</tt> can look
like:</p>

<pre class="PROGRAMLISTING">
zone "example.org" {
    type master;
    file "example.org";
};
</pre>

<p>The zone is a master, as indicated by the <var class="OPTION">type</var> statement,
holding its zone information in <tt class="FILENAME">/etc/namedb/example.org</tt>
indicated by the <var class="OPTION">file</var> statement.</p>

<pre class="PROGRAMLISTING">
zone "example.org" {
    type slave;
    file "example.org";
};
</pre>

<p>In the slave case, the zone information is transferred from the master name server for
the particular zone, and saved in the file specified. If and when the master server dies
or is unreachable, the slave name server will have the transferred zone information and
will be able to serve it.</p>
</div>

<div class="SECT3">
<h3 class="SECT3"><a id="AEN34951" name="AEN34951">23.6.6.3 Zone Files</a></h3>

<p>An example master zone file for <tt class="HOSTID">example.org</tt> (existing within
<tt class="FILENAME">/etc/namedb/example.org</tt>) is as follows:</p>

<pre class="PROGRAMLISTING">
$TTL 3600

example.org. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        86400 )         ; Minimum TTL

; DNS Servers
@       IN NS           ns1.example.org.
@       IN NS           ns2.example.org.

; Machine Names
localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

; Aliases
www             IN CNAME        @

; MX Record
@               IN MX   10      mail.example.org.
</pre>

<p>Note that every hostname ending in a ``.'' is an exact hostname, whereas everything
without a trailing ``.'' is referenced to the origin. For example, <var
class="LITERAL">www</var> is translated into <var class="LITERAL">www.<var
class="REPLACEABLE">origin</var></var>. In our fictitious zone file, our origin is <tt
class="HOSTID">example.org.</tt>, so <var class="LITERAL">www</var> would translate to
<tt class="HOSTID">www.example.org.</tt></p>

<p>The format of a zone file follows:</p>

<pre class="PROGRAMLISTING">
recordname      IN recordtype   value
</pre>

<p>The most commonly used DNS records:</p>

<div class="VARIABLELIST">
<dl>
<dt>SOA</dt>

<dd>
<p>start of zone authority</p>
</dd>

<dt>NS</dt>

<dd>
<p>an authoritative name server</p>
</dd>

<dt>A</dt>

<dd>
<p>a host address</p>
</dd>

<dt>CNAME</dt>

<dd>
<p>the canonical name for an alias</p>
</dd>

<dt>MX</dt>

<dd>
<p>mail exchanger</p>
</dd>

<dt>PTR</dt>

<dd>
<p>a domain name pointer (used in reverse DNS)</p>
</dd>
</dl>
</div>

<pre class="PROGRAMLISTING">
example.org. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum TTL of 1 day
</pre>

<div class="VARIABLELIST">
<dl>
<dt><tt class="HOSTID">example.org.</tt></dt>

<dd>
<p>the domain name, also the origin for this zone file.</p>
</dd>

<dt><tt class="HOSTID">ns1.example.org.</tt></dt>

<dd>
<p>the primary/authoritative name server for this zone.</p>
</dd>

<dt><var class="LITERAL">admin.example.org.</var></dt>

<dd>
<p>the responsible person for this zone, email address with ``@'' replaced. (<code
class="EMAIL">&#60;<a href="mailto:[e-mail]">[e-mail]</a>&#62;</code>
becomes <var class="LITERAL">admin.example.org</var>)</p>
</dd>

<dt><var class="LITERAL">5</var></dt>

<dd>
<p>the serial number of the file. This must be incremented each time the zone file is
modified. Nowadays, many admins prefer a <var class="LITERAL">yyyymmddrr</var> format for
the serial number. <var class="LITERAL">2001041002</var> would mean last modified
04/10/2001, the latter <var class="LITERAL">02</var> being the second time the zone file
has been modified this day. The serial number is important as it alerts slave name
servers for a zone when it is updated.</p>
</dd>
</dl>
</div>

<pre class="PROGRAMLISTING">
@       IN NS           ns1.example.org.
</pre>

<p>This is an NS entry. Every name server that is going to reply authoritatively for the
zone must have one of these entries. The <var class="LITERAL">@</var> as seen here could
have been <tt class="HOSTID">example.org.</tt> The <var class="LITERAL">@</var>
translates to the origin.</p>

<pre class="PROGRAMLISTING">
localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30
</pre>

<p>The A record indicates machine names. As seen above, <tt
class="HOSTID">ns1.example.org</tt> would resolve to <tt class="HOSTID">3.2.1.2</tt>.
Again, the origin symbol, <var class="LITERAL">@</var>, is used here, thus meaning <tt
class="HOSTID">example.org</tt> would resolve to <tt class="HOSTID">3.2.1.30</tt>.</p>

<pre class="PROGRAMLISTING">
www             IN CNAME        @
</pre>

<p>The canonical name record is usually used for giving aliases to a machine. In the
example, <tt class="HOSTID">www</tt> is aliased to the machine addressed to the origin,
or <tt class="HOSTID">example.org</tt> (<tt class="HOSTID">3.2.1.30</tt>). CNAMEs can be
used to provide alias hostnames, or round robin one hostname among multiple machines.</p>

<pre class="PROGRAMLISTING">
@               IN MX   10      mail.example.org.
</pre>

<p>The MX record indicates which mail servers are responsible for handling incoming mail
for the zone. <tt class="HOSTID">mail.example.org</tt> is the hostname of the mail
server, and 10 being the priority of that mail server.</p>

<p>One can have several mail servers, with priorities of 3, 2, 1. A mail server
attempting to deliver to <tt class="HOSTID">example.org</tt> would first try the highest
priority MX, then the second highest, etc, until the mail can be properly delivered.</p>

<p>For in-addr.arpa zone files (reverse DNS), the same format is used, except with PTR
entries instead of A or CNAME.</p>

<pre class="PROGRAMLISTING">
$TTL 3600

1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        3600 )          ; Minimum

@       IN NS   ns1.example.org.
@       IN NS   ns2.example.org.

2       IN PTR  ns1.example.org.
3       IN PTR  ns2.example.org.
10      IN PTR  mail.example.org.
30      IN PTR  example.org.
</pre>

<p>This file gives the proper IP address to hostname mappings of our above fictitious
domain.</p>
</div>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN35052" name="AEN35052">23.6.7 Caching Name Server</a></h2>

<p>A caching name server is a name server that is not authoritative for any zones. It
simply asks queries of its own, and remembers them for later use. To set one up, just
configure the name server as usual, omitting any inclusions of zones.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="NETWORK-NAMED-SANDBOX" name="NETWORK-NAMED-SANDBOX">23.6.8
Running <b class="APPLICATION">named</b> in a Sandbox</a></h2>

<p>For added security you may want to run <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=named&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">named</span>(8)</span></a> as an
unprivileged user, and configure it to <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=chroot&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">chroot</span>(8)</span></a> into a
sandbox directory. This makes everything outside of the sandbox inaccessible to the <b
class="APPLICATION">named</b> daemon. Should <b class="APPLICATION">named</b> be
compromised, this will help to reduce the damage that can be caused. By default, FreeBSD
has a user and a group called <tt class="GROUPNAME">bind</tt>, intended for this use.</p>

<div class="NOTE">
<blockquote class="NOTE">
<p><b>Note:</b> Various people would recommend that instead of configuring <b
class="APPLICATION">named</b> to <tt class="COMMAND">chroot</tt>, you should run <b
class="APPLICATION">named</b> inside a <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=jail&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">jail</span>(8)</span></a>. This section
does not attempt to cover this situation.</p>
</blockquote>
</div>

<p>Since <b class="APPLICATION">named</b> will not be able to access anything outside of
the sandbox (such as shared libraries, log sockets, and so on), there are a number of
steps that need to be followed in order to allow <b class="APPLICATION">named</b> to
function correctly. In the following checklist, it is assumed that the path to the
sandbox is <tt class="FILENAME">/etc/namedb</tt> and that you have made no prior
modifications to the contents of this directory. Perform the following steps as <tt
class="USERNAME">root</tt>:</p>

<ul>
<li>
<p>Create all directories that <b class="APPLICATION">named</b> expects to see:</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">cd /etc/namedb</kbd>
<samp class="PROMPT">#</samp> <kbd
class="USERINPUT">mkdir -p bin dev etc var/tmp var/run master slave</kbd>
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">chown bind:bind slave var/*</kbd><a
id="CHOWN-SLAVE" name="CHOWN-SLAVE"><img src="./imagelib/callouts/1.png" hspace="0"
vspace="0" border="0" alt="(1)" /></a>
</pre>

<div class="CALLOUTLIST">
<dl compact="COMPACT">
<dt><a href="network-dns.html#CHOWN-SLAVE"><img src="./imagelib/callouts/1.png"
hspace="0" vspace="0" border="0" alt="(1)" /></a></dt>

<dd><b class="APPLICATION">named</b> only needs write access to these directories, so
that is all we give it.</dd>
</dl>
</div>
</li>

<li>
<p>Rearrange and create basic zone and configuration files:</p>