3432 lines
198 KiB
HTML
3432 lines
198 KiB
HTML
<!--
|
||
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
|
||
- Copyright (C) 2000-2003 Internet Software Consortium.
|
||
-
|
||
- Permission to use, copy, modify, and distribute this software for any
|
||
- purpose with or without fee is hereby granted, provided that the above
|
||
- copyright notice and this permission notice appear in all copies.
|
||
-
|
||
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
|
||
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
|
||
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
|
||
- INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
|
||
- LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
|
||
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
|
||
- PERFORMANCE OF THIS SOFTWARE.
|
||
-->
|
||
<!-- $Id: Bv9ARM.ch06.html,v 1.56.2.29 2005/10/13 02:23:42 marka Exp $ -->
|
||
<html>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||
<title>Chapter 6. BIND 9 Configuration Reference</title>
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
|
||
<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
|
||
<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
|
||
<link rel="prev" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
|
||
<link rel="next" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
|
||
</head>
|
||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
|
||
<div class="navheader">
|
||
<table width="100%" summary="Navigation header">
|
||
<tr><th colspan="3" align="center">Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</th></tr>
|
||
<tr>
|
||
<td width="20%" align="left">
|
||
<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
|
||
<th width="60%" align="center"> </th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
|
||
</td>
|
||
</tr>
|
||
</table>
|
||
<hr>
|
||
</div>
|
||
<div class="chapter" lang="en">
|
||
<div class="titlepage"><div><div><h2 class="title">
|
||
<a name="Bv9ARM.ch06"></a>Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</h2></div></div></div>
|
||
<div class="toc">
|
||
<p><b>Table of Contents</b></p>
|
||
<dl>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
|
||
<dd><dl>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553409">Comment Syntax</a></span></dt>
|
||
</dl></dd>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
|
||
<dd><dl>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553847"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
|
||
Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554026"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554477"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554492"><span><strong class="command">include</strong></span> Statement Definition and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554515"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554536"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554667"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554861"><span><strong class="command">logging</strong></span> Statement Definition and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2556019"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2556091"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2556154"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2557009"><span><strong class="command">options</strong></span> Statement Definition and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2560541"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2560726"><span><strong class="command">trusted-keys</strong></span> Statement Definition
|
||
and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2560749"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2560797"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
|
||
Statement Grammar</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2561404"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
|
||
</dl></dd>
|
||
<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2562711">Zone File</a></span></dt>
|
||
<dd><dl>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2564235">Discussion of MX Records</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2564801">Inverse Mapping in IPv4</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2564906">Other Zone File Directives</a></span></dt>
|
||
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2565075"><span class="acronym">BIND</span> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
|
||
</dl></dd>
|
||
</dl>
|
||
</div>
|
||
<p><span class="acronym">BIND</span> 9 configuration is broadly similar to <span class="acronym">BIND</span> 8.x; however,
|
||
there are a few new areas of configuration, such as views. <span class="acronym">BIND</span>
|
||
8.x configuration files should work with few alterations in <span class="acronym">BIND</span>
|
||
9, although more complex configurations should be reviewed to check
|
||
if they can be more efficiently implemented using the new features
|
||
found in <span class="acronym">BIND</span> 9.</p>
|
||
<p><span class="acronym">BIND</span> 4 configuration files can be converted to the new format
|
||
using the shell script
|
||
<code class="filename">contrib/named-bootconf/named-bootconf.sh</code>.</p>
|
||
<div class="sect1" lang="en">
|
||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||
<a name="configuration_file_elements"></a>Configuration File Elements</h2></div></div></div>
|
||
<p>Following is a list of elements used throughout the <span class="acronym">BIND</span> configuration
|
||
file documentation:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><code class="varname">acl_name</code></p></td>
|
||
<td><p>The name of an <code class="varname">address_match_list</code> as
|
||
defined by the <span><strong class="command">acl</strong></span> statement.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">address_match_list</code></p></td>
|
||
<td><p>A list of one or more <code class="varname">ip_addr</code>, <code class="varname">ip_prefix</code>, <code class="varname">key_id</code>, or <code class="varname">acl_name</code> elements, see
|
||
<a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called “Address Match Lists”</a>.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">domain_name</code></p></td>
|
||
<td><p>A quoted string which will be used as
|
||
a DNS name, for example "<code class="literal">my.test.domain</code>".</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">dotted_decimal</code></p></td>
|
||
<td><p>One or more integers valued 0 through
|
||
255 separated only by dots (`.'), such as <span><strong class="command">123</strong></span>, <span><strong class="command">45.67</strong></span> or <span><strong class="command">89.123.45.67</strong></span>.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">ip4_addr</code></p></td>
|
||
<td><p>An IPv4 address with exactly four elements
|
||
in <code class="varname">dotted_decimal</code> notation.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">ip6_addr</code></p></td>
|
||
<td><p>An IPv6 address, such as <span><strong class="command">2001:db8::1234</strong></span>.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">ip_addr</code></p></td>
|
||
<td><p>An <code class="varname">ip4_addr</code> or <code class="varname">ip6_addr</code>.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">ip_port</code></p></td>
|
||
<td><p>An IP port <code class="varname">number</code>.
|
||
<code class="varname">number</code> is limited to 0 through 65535, with values
|
||
below 1024 typically restricted to root-owned processes. In some
|
||
cases an asterisk (`*') character can be used as a placeholder to
|
||
select a random high-numbered port.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">ip_prefix</code></p></td>
|
||
<td><p>An IP network specified as an <code class="varname">ip_addr</code>,
|
||
followed by a slash (`/') and then the number of bits in the netmask.
|
||
Trailing zeros in a <code class="varname">ip_addr</code> may omitted.
|
||
For example, <span><strong class="command">127/8</strong></span> is the network <span><strong class="command">127.0.0.0</strong></span> with
|
||
netmask <span><strong class="command">255.0.0.0</strong></span> and <span><strong class="command">1.2.3.0/28</strong></span> is
|
||
network <span><strong class="command">1.2.3.0</strong></span> with netmask <span><strong class="command">255.255.255.240</strong></span>.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">key_id</code></p></td>
|
||
<td><p>A <code class="varname">domain_name</code> representing
|
||
the name of a shared key, to be used for transaction security.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">key_list</code></p></td>
|
||
<td><p>A list of one or more <code class="varname">key_id</code>s,
|
||
separated by semicolons and ending with a semicolon.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">number</code></p></td>
|
||
<td><p>A non-negative 32 bit unsigned integer
|
||
(i.e., a number between 0 and 4294967295, inclusive).
|
||
Its acceptable value might further
|
||
be limited by the context in which it is used.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">path_name</code></p></td>
|
||
<td><p>A quoted string which will be used as
|
||
a pathname, such as <code class="filename">zones/master/my.test.domain</code>.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">size_spec</code></p></td>
|
||
<td>
|
||
<p>A number, the word <strong class="userinput"><code>unlimited</code></strong>,
|
||
or the word <strong class="userinput"><code>default</code></strong>.</p>
|
||
<p>
|
||
An <code class="varname">unlimited</code> <code class="varname">size_spec</code> requests unlimited
|
||
use, or the maximum available amount. A <code class="varname">default size_spec</code> uses
|
||
the limit that was in force when the server was started.</p>
|
||
<p>A <code class="varname">number</code> can
|
||
optionally be followed by a scaling factor: <strong class="userinput"><code>K</code></strong> or <strong class="userinput"><code>k</code></strong> for
|
||
kilobytes, <strong class="userinput"><code>M</code></strong> or <strong class="userinput"><code>m</code></strong> for
|
||
megabytes, and <strong class="userinput"><code>G</code></strong> or <strong class="userinput"><code>g</code></strong> for gigabytes,
|
||
which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.</p>
|
||
<p>The value must be representable as a 64-bit unsigned integer
|
||
(0 to 18446744073709551615, inclusive).
|
||
Using <code class="varname">unlimited</code> is the best way
|
||
to safely set a really large number.</p>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">yes_or_no</code></p></td>
|
||
<td><p>Either <strong class="userinput"><code>yes</code></strong> or <strong class="userinput"><code>no</code></strong>.
|
||
The words <strong class="userinput"><code>true</code></strong> and <strong class="userinput"><code>false</code></strong> are
|
||
also accepted, as are the numbers <strong class="userinput"><code>1</code></strong> and <strong class="userinput"><code>0</code></strong>.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">dialup_option</code></p></td>
|
||
<td><p>One of <strong class="userinput"><code>yes</code></strong>,
|
||
<strong class="userinput"><code>no</code></strong>, <strong class="userinput"><code>notify</code></strong>,
|
||
<strong class="userinput"><code>notify-passive</code></strong>, <strong class="userinput"><code>refresh</code></strong> or
|
||
<strong class="userinput"><code>passive</code></strong>.
|
||
When used in a zone, <strong class="userinput"><code>notify-passive</code></strong>,
|
||
<strong class="userinput"><code>refresh</code></strong>, and <strong class="userinput"><code>passive</code></strong>
|
||
are restricted to slave and stub zones.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="address_match_lists"></a>Address Match Lists</h3></div></div></div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2553294"></a>Syntax</h4></div></div></div>
|
||
<pre class="programlisting"><code class="varname">address_match_list</code> = address_match_list_element ;
|
||
[<span class="optional"> address_match_list_element; ... </span>]
|
||
<code class="varname">address_match_list_element</code> = [<span class="optional"> ! </span>] (ip_address [<span class="optional">/length</span>] |
|
||
key key_id | acl_name | { address_match_list } )
|
||
</pre>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2553321"></a>Definition and Usage</h4></div></div></div>
|
||
<p>Address match lists are primarily used to determine access
|
||
control for various server operations. They are also used to define
|
||
priorities for querying other nameservers and to set the addresses
|
||
on which <span><strong class="command">named</strong></span> will listen for queries. The elements
|
||
which constitute an address match list can be any of the following:</p>
|
||
<div class="itemizedlist"><ul type="disc">
|
||
<li>an IP address (IPv4 or IPv6)</li>
|
||
<li>an IP prefix (in the `/'-notation)</li>
|
||
<li>a key ID, as defined by the key statement</li>
|
||
<li>the name of an address match list defined with
|
||
the <span><strong class="command">acl</strong></span> statement</li>
|
||
<li>a nested address match list enclosed in braces</li>
|
||
</ul></div>
|
||
<p>Elements can be negated with a leading exclamation mark (`!')
|
||
and the match list names "any," "none," "localhost" and "localnets"
|
||
are predefined. More information on those names can be found in
|
||
the description of the acl statement.</p>
|
||
<p>The addition of the key clause made the name of this syntactic
|
||
element something of a misnomer, since security keys can be used
|
||
to validate access without regard to a host or network address. Nonetheless,
|
||
the term "address match list" is still used throughout the documentation.</p>
|
||
<p>When a given IP address or prefix is compared to an address
|
||
match list, the list is traversed in order until an element matches.
|
||
The interpretation of a match depends on whether the list is being used
|
||
for access control, defining listen-on ports, or as a topology,
|
||
and whether the element was negated.</p>
|
||
<p>When used as an access control list, a non-negated match allows
|
||
access and a negated match denies access. If there is no match,
|
||
access is denied. The clauses <span><strong class="command">allow-notify</strong></span>,
|
||
<span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
|
||
<span><strong class="command">allow-update</strong></span> and <span><strong class="command">blackhole</strong></span> all
|
||
use address match lists this. Similarly, the listen-on option will cause
|
||
the server to not accept queries on any of the machine's addresses
|
||
which do not match the list.</p>
|
||
<p>When used with the topology clause, a non-negated match returns
|
||
a distance based on its position on the list (the closer the match
|
||
is to the start of the list, the shorter the distance is between
|
||
it and the server). A negated match will be assigned the maximum
|
||
distance from the server. If there is no match, the address will
|
||
get a distance which is further than any non-negated list element,
|
||
and closer than any negated element.</p>
|
||
<p>Because of the first-match aspect of the algorithm, an element
|
||
that defines a subset of another element in the list should come
|
||
before the broader element, regardless of whether either is negated. For
|
||
example, in
|
||
<span><strong class="command">1.2.3/24; ! 1.2.3.13;</strong></span> the 1.2.3.13 element is
|
||
completely useless because the algorithm will match any lookup for
|
||
1.2.3.13 to the 1.2.3/24 element. Using <span><strong class="command">! 1.2.3.13; 1.2.3/24</strong></span> fixes
|
||
that problem by having 1.2.3.13 blocked by the negation but all
|
||
other 1.2.3.* hosts fall through.</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2553409"></a>Comment Syntax</h3></div></div></div>
|
||
<p>The <span class="acronym">BIND</span> 9 comment syntax allows for comments to appear
|
||
anywhere that white space may appear in a <span class="acronym">BIND</span> configuration
|
||
file. To appeal to programmers of all kinds, they can be written
|
||
in C, C++, or shell/perl constructs.</p>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2553424"></a>Syntax</h4></div></div></div>
|
||
<pre class="programlisting">/* This is a <span class="acronym">BIND</span> comment as in C */</pre>
|
||
<p>
|
||
</p>
|
||
<pre class="programlisting">// This is a <span class="acronym">BIND</span> comment as in C++</pre>
|
||
<p>
|
||
</p>
|
||
<pre class="programlisting"># This is a <span class="acronym">BIND</span> comment as in common UNIX shells and perl</pre>
|
||
<p>
|
||
</p>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2553521"></a>Definition and Usage</h4></div></div></div>
|
||
<p>Comments may appear anywhere that whitespace may appear in
|
||
a <span class="acronym">BIND</span> configuration file.</p>
|
||
<p>C-style comments start with the two characters /* (slash,
|
||
star) and end with */ (star, slash). Because they are completely
|
||
delimited with these characters, they can be used to comment only
|
||
a portion of a line or to span multiple lines.</p>
|
||
<p>C-style comments cannot be nested. For example, the following
|
||
is not valid because the entire comment ends with the first */:</p>
|
||
<pre class="programlisting">/* This is the start of a comment.
|
||
This is still part of the comment.
|
||
/* This is an incorrect attempt at nesting a comment. */
|
||
This is no longer in any comment. */
|
||
</pre>
|
||
<p>C++-style comments start with the two characters // (slash,
|
||
slash) and continue to the end of the physical line. They cannot
|
||
be continued across multiple physical lines; to have one logical
|
||
comment span multiple lines, each line must use the // pair.</p>
|
||
<p>For example:</p>
|
||
<pre class="programlisting">// This is the start of a comment. The next line
|
||
// is a new comment, even though it is logically
|
||
// part of the previous comment.
|
||
</pre>
|
||
<p>Shell-style (or perl-style, if you prefer) comments start
|
||
with the character <code class="literal">#</code> (number sign) and continue to the end of the
|
||
physical line, as in C++ comments.</p>
|
||
<p>For example:</p>
|
||
<pre class="programlisting"># This is the start of a comment. The next line
|
||
# is a new comment, even though it is logically
|
||
# part of the previous comment.
|
||
</pre>
|
||
<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Warning</h3>
|
||
<p>WARNING: you cannot use the semicolon (`;') character
|
||
to start a comment such as you would in a zone file. The
|
||
semicolon indicates the end of a configuration
|
||
statement.</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="sect1" lang="en">
|
||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||
<a name="Configuration_File_Grammar"></a>Configuration File Grammar</h2></div></div></div>
|
||
<p>A <span class="acronym">BIND</span> 9 configuration consists of statements and comments.
|
||
Statements end with a semicolon. Statements and comments are the
|
||
only elements that can appear without enclosing braces. Many
|
||
statements contain a block of substatements, which are also
|
||
terminated with a semicolon.</p>
|
||
<p>The following statements are supported:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><span><strong class="command">acl</strong></span></p></td>
|
||
<td><p>defines a named IP address
|
||
matching list, for access control and other uses.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">controls</strong></span></p></td>
|
||
<td><p>declares control channels to be used
|
||
by the <span><strong class="command">rndc</strong></span> utility.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">include</strong></span></p></td>
|
||
<td><p>includes a file.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">key</strong></span></p></td>
|
||
<td><p>specifies key information for use in
|
||
authentication and authorization using TSIG.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">logging</strong></span></p></td>
|
||
<td><p>specifies what the server logs, and where
|
||
the log messages are sent.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">options</strong></span></p></td>
|
||
<td><p>controls global server configuration
|
||
options and sets defaults for other statements.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">server</strong></span></p></td>
|
||
<td><p>sets certain configuration options on
|
||
a per-server basis.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">trusted-keys</strong></span></p></td>
|
||
<td><p>defines trusted DNSSEC keys.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">view</strong></span></p></td>
|
||
<td><p>defines a view.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">zone</strong></span></p></td>
|
||
<td><p>defines a zone.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>The <span><strong class="command">logging</strong></span> and
|
||
<span><strong class="command">options</strong></span> statements may only occur once per
|
||
configuration.</p>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2553847"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting"><span><strong class="command">acl</strong></span> acl-name {
|
||
address_match_list
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="acl"></a><span><strong class="command">acl</strong></span> Statement Definition and
|
||
Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">acl</strong></span> statement assigns a symbolic
|
||
name to an address match list. It gets its name from a primary
|
||
use of address match lists: Access Control Lists (ACLs).</p>
|
||
<p>Note that an address match list's name must be defined
|
||
with <span><strong class="command">acl</strong></span> before it can be used elsewhere; no
|
||
forward references are allowed.</p>
|
||
<p>The following ACLs are built-in:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><span><strong class="command">any</strong></span></p></td>
|
||
<td><p>Matches all hosts.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">none</strong></span></p></td>
|
||
<td><p>Matches no hosts.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">localhost</strong></span></p></td>
|
||
<td><p>Matches the IPv4 addresses of all network
|
||
interfaces on the system.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">localnets</strong></span></p></td>
|
||
<td><p>Matches any host on an IPv4 network for which
|
||
the system has an interface.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>The <span><strong class="command">localhost</strong></span> and <span><strong class="command">localnets</strong></span>
|
||
ACLs do not currently support IPv6 (that is,
|
||
<span><strong class="command">localhost</strong></span> does not match the host's IPv6 addresses,
|
||
and <span><strong class="command">localnets</strong></span> does not match the host's attached
|
||
IPv6 networks) due to the lack of a standard method of determining the
|
||
complete set of local IPv6 addresses for a host.
|
||
</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2554026"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting"><span><strong class="command">controls</strong></span> {
|
||
inet ( ip_addr | * ) [<span class="optional"> port ip_port </span>] allow { <em class="replaceable"><code> address_match_list </code></em> }
|
||
keys { <em class="replaceable"><code> key_list </code></em> };
|
||
[<span class="optional"> inet ...; </span>]
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="controls_statement_definition_and_usage"></a><span><strong class="command">controls</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">controls</strong></span> statement declares control
|
||
channels to be used by system administrators to affect the
|
||
operation of the local nameserver. These control channels are
|
||
used by the <span><strong class="command">rndc</strong></span> utility to send commands to
|
||
and retrieve non-DNS results from a nameserver.</p>
|
||
<p>An <span><strong class="command">inet</strong></span> control channel is a TCP
|
||
socket listening at the specified
|
||
<span><strong class="command">ip_port</strong></span> on the specified
|
||
<span><strong class="command">ip_addr</strong></span>, which can be an IPv4 or IPv6
|
||
address. An <span><strong class="command">ip_addr</strong></span>
|
||
of <code class="literal">*</code> is interpreted as the IPv4 wildcard
|
||
address; connections will be accepted on any of the system's
|
||
IPv4 addresses. To listen on the IPv6 wildcard address,
|
||
use an <span><strong class="command">ip_addr</strong></span> of <code class="literal">::</code>.
|
||
If you will only use <span><strong class="command">rndc</strong></span> on the local host,
|
||
using the loopback address (<code class="literal">127.0.0.1</code>
|
||
or <code class="literal">::1</code>) is recommended for maximum
|
||
security.
|
||
</p>
|
||
<p>The ability to issue commands over the control channel is
|
||
restricted by the <span><strong class="command">allow</strong></span> and
|
||
<span><strong class="command">keys</strong></span> clauses. Connections to the control
|
||
channel are permitted based on the address permissions in
|
||
<span><strong class="command">address_match_list</strong></span>. <span><strong class="command">key_id</strong></span>
|
||
members of the <span><strong class="command">address_match_list</strong></span> are
|
||
ignored, and instead are interpreted independently based the
|
||
<span><strong class="command">key_list</strong></span>. Each <span><strong class="command">key_id</strong></span> in
|
||
the <span><strong class="command">key_list</strong></span> is allowed to be used to
|
||
authenticate commands and responses given over the control
|
||
channel by digitally signing each message between the server and
|
||
a command client (See <a href="Bv9ARM.ch03.html#rndc">Remote Name Daemon Control application</a> in
|
||
<a href="Bv9ARM.ch03.html#admin_tools" title="Administrative Tools">the section called “Administrative Tools”</a>). All commands to the control channel
|
||
must be signed by one of its specified keys to
|
||
be honored.</p>
|
||
<p>
|
||
If no <span><strong class="command">controls</strong></span> statement is present,
|
||
<span><strong class="command">named</strong></span> will set up a default
|
||
control channel listening on the loopback address 127.0.0.1
|
||
and its IPv6 counterpart ::1.
|
||
|
||
In this case, and also when the <span><strong class="command">controls</strong></span> statement
|
||
is present but does not have a <span><strong class="command">keys</strong></span> clause,
|
||
<span><strong class="command">named</strong></span> will attempt to load the command channel key
|
||
from the file <code class="filename">rndc.key</code> in
|
||
<code class="filename">/etc</code> (or whatever <code class="varname">sysconfdir</code>
|
||
was specified as when <span class="acronym">BIND</span> was built).
|
||
To create a <code class="filename">rndc.key</code> file, run
|
||
<strong class="userinput"><code>rndc-confgen -a</code></strong>.
|
||
</p>
|
||
<p>The <code class="filename">rndc.key</code> feature was created to
|
||
ease the transition of systems from <span class="acronym">BIND</span> 8,
|
||
which did not have digital signatures on its command channel messages
|
||
and thus did not have a <span><strong class="command">keys</strong></span> clause.
|
||
|
||
It makes it possible to use an existing <span class="acronym">BIND</span> 8
|
||
configuration file in <span class="acronym">BIND</span> 9 unchanged,
|
||
and still have <span><strong class="command">rndc</strong></span> work the same way
|
||
<span><strong class="command">ndc</strong></span> worked in BIND 8, simply by executing the
|
||
command <strong class="userinput"><code>rndc-confgen -a</code></strong> after BIND 9 is
|
||
installed.
|
||
</p>
|
||
<p>
|
||
Since the <code class="filename">rndc.key</code> feature
|
||
is only intended to allow the backward-compatible usage of
|
||
<span class="acronym">BIND</span> 8 configuration files, this feature does not
|
||
have a high degree of configurability. You cannot easily change
|
||
the key name or the size of the secret, so you should make a
|
||
<code class="filename">rndc.conf</code> with your own key if you wish to change
|
||
those things. The <code class="filename">rndc.key</code> file also has its
|
||
permissions set such that only the owner of the file (the user that
|
||
<span><strong class="command">named</strong></span> is running as) can access it. If you
|
||
desire greater flexibility in allowing other users to access
|
||
<span><strong class="command">rndc</strong></span> commands then you need to create an
|
||
<code class="filename">rndc.conf</code> and make it group readable by a group
|
||
that contains the users who should have access.</p>
|
||
<p>The UNIX control channel type of <span class="acronym">BIND</span> 8 is not supported
|
||
in <span class="acronym">BIND</span> 9, and is not expected to be added in future
|
||
releases. If it is present in the controls statement from a
|
||
<span class="acronym">BIND</span> 8 configuration file, it is ignored
|
||
and a warning is logged.</p>
|
||
<p>
|
||
To disable the command channel, use an empty <span><strong class="command">controls</strong></span>
|
||
statement: <span><strong class="command">controls { };</strong></span>.
|
||
</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2554477"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting">include <em class="replaceable"><code>filename</code></em>;</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2554492"></a><span><strong class="command">include</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">include</strong></span> statement inserts the
|
||
specified file at the point that the <span><strong class="command">include</strong></span>
|
||
statement is encountered. The <span><strong class="command">include</strong></span>
|
||
statement facilitates the administration of configuration files
|
||
by permitting the reading or writing of some things but not
|
||
others. For example, the statement could include private keys
|
||
that are readable only by a nameserver.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2554515"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting">key <em class="replaceable"><code>key_id</code></em> {
|
||
algorithm <em class="replaceable"><code>string</code></em>;
|
||
secret <em class="replaceable"><code>string</code></em>;
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2554536"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">key</strong></span> statement defines a shared
|
||
secret key for use with TSIG, see <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called “TSIG”</a>.</p>
|
||
<p>
|
||
The <span><strong class="command">key</strong></span> statement can occur at the top level
|
||
of the configuration file or inside a <span><strong class="command">view</strong></span>
|
||
statement. Keys defined in top-level <span><strong class="command">key</strong></span>
|
||
statements can be used in all views. Keys intended for use in
|
||
a <span><strong class="command">controls</strong></span> statement
|
||
(see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and Usage">the section called “<span><strong class="command">controls</strong></span> Statement Definition and Usage”</a>)
|
||
must be defined at the top level.
|
||
</p>
|
||
<p>The <em class="replaceable"><code>key_id</code></em>, also known as the
|
||
key name, is a domain name uniquely identifying the key. It can
|
||
be used in a "server" statement to cause requests sent to that
|
||
server to be signed with this key, or in address match lists to
|
||
verify that incoming requests have been signed with a key
|
||
matching this name, algorithm, and secret.</p>
|
||
<p>The <em class="replaceable"><code>algorithm_id</code></em> is a string
|
||
that specifies a security/authentication algorithm. The only
|
||
algorithm currently supported with TSIG authentication is
|
||
<code class="literal">hmac-md5</code>. The
|
||
<em class="replaceable"><code>secret_string</code></em> is the secret to be
|
||
used by the algorithm, and is treated as a base-64 encoded
|
||
string.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2554667"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting"><span><strong class="command">logging</strong></span> {
|
||
[ <span><strong class="command">channel</strong></span> <em class="replaceable"><code>channel_name</code></em> {
|
||
( <span><strong class="command">file</strong></span> <em class="replaceable"><code>path name</code></em>
|
||
[ <span><strong class="command">versions</strong></span> ( <em class="replaceable"><code>number</code></em> | <span><strong class="command">unlimited</strong></span> ) ]
|
||
[ <span><strong class="command">size</strong></span> <em class="replaceable"><code>size spec</code></em> ]
|
||
| <span><strong class="command">syslog</strong></span> <em class="replaceable"><code>syslog_facility</code></em>
|
||
| <span><strong class="command">stderr</strong></span>
|
||
| <span><strong class="command">null</strong></span> );
|
||
[ <span><strong class="command">severity</strong></span> (<code class="option">critical</code> | <code class="option">error</code> | <code class="option">warning</code> | <code class="option">notice</code> |
|
||
<code class="option">info</code> | <code class="option">debug</code> [ <em class="replaceable"><code>level</code></em> ] | <code class="option">dynamic</code> ); ]
|
||
[ <span><strong class="command">print-category</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
|
||
[ <span><strong class="command">print-severity</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
|
||
[ <span><strong class="command">print-time</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
|
||
}; ]
|
||
[ <span><strong class="command">category</strong></span> <em class="replaceable"><code>category_name</code></em> {
|
||
<em class="replaceable"><code>channel_name</code></em> ; [ <em class="replaceable"><code>channel_nam</code></em>e ; ... ]
|
||
}; ]
|
||
...
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2554861"></a><span><strong class="command">logging</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">logging</strong></span> statement configures a wide
|
||
variety of logging options for the nameserver. Its <span><strong class="command">channel</strong></span> phrase
|
||
associates output methods, format options and severity levels with
|
||
a name that can then be used with the <span><strong class="command">category</strong></span> phrase
|
||
to select how various classes of messages are logged.</p>
|
||
<p>Only one <span><strong class="command">logging</strong></span> statement is used to define
|
||
as many channels and categories as are wanted. If there is no <span><strong class="command">logging</strong></span> statement,
|
||
the logging configuration will be:</p>
|
||
<pre class="programlisting">logging {
|
||
category "unmatched" { "null"; };
|
||
category "default" { "default_syslog"; "default_debug"; };
|
||
};
|
||
</pre>
|
||
<p>In <span class="acronym">BIND</span> 9, the logging configuration is only established when
|
||
the entire configuration file has been parsed. In <span class="acronym">BIND</span> 8, it was
|
||
established as soon as the <span><strong class="command">logging</strong></span> statement
|
||
was parsed. When the server is starting up, all logging messages
|
||
regarding syntax errors in the configuration file go to the default
|
||
channels, or to standard error if the "<code class="option">-g</code>" option
|
||
was specified.</p>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2554914"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
|
||
<p>All log output goes to one or more <span class="emphasis"><em>channels</em></span>;
|
||
you can make as many of them as you want.</p>
|
||
<p>Every channel definition must include a destination clause that
|
||
says whether messages selected for the channel go to a file, to a
|
||
particular syslog facility, to the standard error stream, or are
|
||
discarded. It can optionally also limit the message severity level
|
||
that will be accepted by the channel (the default is
|
||
<span><strong class="command">info</strong></span>), and whether to include a
|
||
<span><strong class="command">named</strong></span>-generated time stamp, the category name
|
||
and/or severity level (the default is not to include any).</p>
|
||
<p>The <span><strong class="command">null</strong></span> destination clause
|
||
causes all messages sent to the channel to be discarded;
|
||
in that case, other options for the channel are meaningless.</p>
|
||
<p>The <span><strong class="command">file</strong></span> destination clause directs the channel
|
||
to a disk file. It can include limitations
|
||
both on how large the file is allowed to become, and how many versions
|
||
of the file will be saved each time the file is opened.</p>
|
||
<p>If you use the <span><strong class="command">versions</strong></span> log file option, then
|
||
<span><strong class="command">named</strong></span> will retain that many backup versions of the file by
|
||
renaming them when opening. For example, if you choose to keep 3 old versions
|
||
of the file <code class="filename">lamers.log</code> then just before it is opened
|
||
<code class="filename">lamers.log.1</code> is renamed to
|
||
<code class="filename">lamers.log.2</code>, <code class="filename">lamers.log.0</code> is renamed
|
||
to <code class="filename">lamers.log.1</code>, and <code class="filename">lamers.log</code> is
|
||
renamed to <code class="filename">lamers.log.0</code>.
|
||
You can say <span><strong class="command">versions unlimited;</strong></span> to not limit
|
||
the number of versions.
|
||
If a <span><strong class="command">size</strong></span> option is associated with the log file,
|
||
then renaming is only done when the file being opened exceeds the
|
||
indicated size. No backup versions are kept by default; any existing
|
||
log file is simply appended.</p>
|
||
<p>The <span><strong class="command">size</strong></span> option for files is used to limit log
|
||
growth. If the file ever exceeds the size, then <span><strong class="command">named</strong></span> will
|
||
stop writing to the file unless it has a <span><strong class="command">versions</strong></span> option
|
||
associated with it. If backup versions are kept, the files are rolled as
|
||
described above and a new one begun. If there is no
|
||
<span><strong class="command">versions</strong></span> option, no more data will be written to the log
|
||
until some out-of-band mechanism removes or truncates the log to less than the
|
||
maximum size. The default behavior is not to limit the size of the
|
||
file.</p>
|
||
<p>Example usage of the <span><strong class="command">size</strong></span> and
|
||
<span><strong class="command">versions</strong></span> options:</p>
|
||
<pre class="programlisting">channel "an_example_channel" {
|
||
file "example.log" versions 3 size 20m;
|
||
print-time yes;
|
||
print-category yes;
|
||
};
|
||
</pre>
|
||
<p>The <span><strong class="command">syslog</strong></span> destination clause directs the
|
||
channel to the system log. Its argument is a
|
||
syslog facility as described in the <span><strong class="command">syslog</strong></span> man
|
||
page. Known facilities are <span><strong class="command">kern</strong></span>, <span><strong class="command">user</strong></span>,
|
||
<span><strong class="command">mail</strong></span>, <span><strong class="command">daemon</strong></span>, <span><strong class="command">auth</strong></span>,
|
||
<span><strong class="command">syslog</strong></span>, <span><strong class="command">lpr</strong></span>, <span><strong class="command">news</strong></span>,
|
||
<span><strong class="command">uucp</strong></span>, <span><strong class="command">cron</strong></span>, <span><strong class="command">authpriv</strong></span>,
|
||
<span><strong class="command">ftp</strong></span>, <span><strong class="command">local0</strong></span>, <span><strong class="command">local1</strong></span>,
|
||
<span><strong class="command">local2</strong></span>, <span><strong class="command">local3</strong></span>, <span><strong class="command">local4</strong></span>,
|
||
<span><strong class="command">local5</strong></span>, <span><strong class="command">local6</strong></span> and
|
||
<span><strong class="command">local7</strong></span>, however not all facilities are supported on
|
||
all operating systems.
|
||
How <span><strong class="command">syslog</strong></span> will handle messages sent to
|
||
this facility is described in the <span><strong class="command">syslog.conf</strong></span> man
|
||
page. If you have a system which uses a very old version of <span><strong class="command">syslog</strong></span> that
|
||
only uses two arguments to the <span><strong class="command">openlog()</strong></span> function,
|
||
then this clause is silently ignored.</p>
|
||
<p>The <span><strong class="command">severity</strong></span> clause works like <span><strong class="command">syslog</strong></span>'s
|
||
"priorities," except that they can also be used if you are writing
|
||
straight to a file rather than using <span><strong class="command">syslog</strong></span>.
|
||
Messages which are not at least of the severity level given will
|
||
not be selected for the channel; messages of higher severity levels
|
||
will be accepted.</p>
|
||
<p>If you are using <span><strong class="command">syslog</strong></span>, then the <span><strong class="command">syslog.conf</strong></span> priorities
|
||
will also determine what eventually passes through. For example,
|
||
defining a channel facility and severity as <span><strong class="command">daemon</strong></span> and <span><strong class="command">debug</strong></span> but
|
||
only logging <span><strong class="command">daemon.warning</strong></span> via <span><strong class="command">syslog.conf</strong></span> will
|
||
cause messages of severity <span><strong class="command">info</strong></span> and <span><strong class="command">notice</strong></span> to
|
||
be dropped. If the situation were reversed, with <span><strong class="command">named</strong></span> writing
|
||
messages of only <span><strong class="command">warning</strong></span> or higher, then <span><strong class="command">syslogd</strong></span> would
|
||
print all messages it received from the channel.</p>
|
||
<p>The <span><strong class="command">stderr</strong></span> destination clause directs the
|
||
channel to the server's standard error stream. This is intended for
|
||
use when the server is running as a foreground process, for example
|
||
when debugging a configuration.</p>
|
||
<p>The server can supply extensive debugging information when
|
||
it is in debugging mode. If the server's global debug level is greater
|
||
than zero, then debugging mode will be active. The global debug
|
||
level is set either by starting the <span><strong class="command">named</strong></span> server
|
||
with the <code class="option">-d</code> flag followed by a positive integer,
|
||
or by running <span><strong class="command">rndc trace</strong></span>.
|
||
The global debug level
|
||
can be set to zero, and debugging mode turned off, by running <span><strong class="command">ndc
|
||
notrace</strong></span>. All debugging messages in the server have a debug
|
||
level, and higher debug levels give more detailed output. Channels
|
||
that specify a specific debug severity, for example:</p>
|
||
<pre class="programlisting">channel "specific_debug_level" {
|
||
file "foo";
|
||
severity debug 3;
|
||
};
|
||
</pre>
|
||
<p>will get debugging output of level 3 or less any time the
|
||
server is in debugging mode, regardless of the global debugging
|
||
level. Channels with <span><strong class="command">dynamic</strong></span> severity use the
|
||
server's global level to determine what messages to print.</p>
|
||
<p>If <span><strong class="command">print-time</strong></span> has been turned on, then
|
||
the date and time will be logged. <span><strong class="command">print-time</strong></span> may
|
||
be specified for a <span><strong class="command">syslog</strong></span> channel, but is usually
|
||
pointless since <span><strong class="command">syslog</strong></span> also prints the date and
|
||
time. If <span><strong class="command">print-category</strong></span> is requested, then the
|
||
category of the message will be logged as well. Finally, if <span><strong class="command">print-severity</strong></span> is
|
||
on, then the severity level of the message will be logged. The <span><strong class="command">print-</strong></span> options may
|
||
be used in any combination, and will always be printed in the following
|
||
order: time, category, severity. Here is an example where all three <span><strong class="command">print-</strong></span> options
|
||
are on:</p>
|
||
<p><code class="computeroutput">28-Feb-2000 15:05:32.863 general: notice: running</code></p>
|
||
<p>There are four predefined channels that are used for
|
||
<span><strong class="command">named</strong></span>'s default logging as follows. How they are
|
||
used is described in <a href="Bv9ARM.ch06.html#the_category_phrase" title="The category Phrase">the section called “The <span><strong class="command">category</strong></span> Phrase”</a>.
|
||
</p>
|
||
<pre class="programlisting">channel "default_syslog" {
|
||
syslog daemon; // send to syslog's daemon
|
||
// facility
|
||
severity info; // only send priority info
|
||
// and higher
|
||
};
|
||
|
||
channel "default_debug" {
|
||
file "named.run"; // write to named.run in
|
||
// the working directory
|
||
// Note: stderr is used instead
|
||
// of "named.run"
|
||
// if the server is started
|
||
// with the '-f' option.
|
||
severity dynamic; // log at the server's
|
||
// current debug level
|
||
};
|
||
|
||
channel "default_stderr" { // writes to stderr
|
||
stderr;
|
||
severity info; // only send priority info
|
||
// and higher
|
||
};
|
||
|
||
channel "null" {
|
||
null; // toss anything sent to
|
||
// this channel
|
||
};
|
||
</pre>
|
||
<p>The <span><strong class="command">default_debug</strong></span> channel has the special
|
||
property that it only produces output when the server's debug level is
|
||
nonzero. It normally writes to a file <code class="filename">named.run</code>
|
||
in the server's working directory.</p>
|
||
<p>For security reasons, when the "<code class="option">-u</code>"
|
||
command line option is used, the <code class="filename">named.run</code> file
|
||
is created only after <span><strong class="command">named</strong></span> has changed to the
|
||
new UID, and any debug output generated while <span><strong class="command">named</strong></span> is
|
||
starting up and still running as root is discarded. If you need
|
||
to capture this output, you must run the server with the "<code class="option">-g</code>"
|
||
option and redirect standard error to a file.</p>
|
||
<p>Once a channel is defined, it cannot be redefined. Thus you
|
||
cannot alter the built-in channels directly, but you can modify
|
||
the default logging by pointing categories at channels you have defined.</p>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="the_category_phrase"></a>The <span><strong class="command">category</strong></span> Phrase</h4></div></div></div>
|
||
<p>There are many categories, so you can send the logs you want
|
||
to see wherever you want, without seeing logs you don't want. If
|
||
you don't specify a list of channels for a category, then log messages
|
||
in that category will be sent to the <span><strong class="command">default</strong></span> category
|
||
instead. If you don't specify a default category, the following
|
||
"default default" is used:</p>
|
||
<pre class="programlisting">category "default" { "default_syslog"; "default_debug"; };
|
||
</pre>
|
||
<p>As an example, let's say you want to log security events to
|
||
a file, but you also want keep the default logging behavior. You'd
|
||
specify the following:</p>
|
||
<pre class="programlisting">channel "my_security_channel" {
|
||
file "my_security_file";
|
||
severity info;
|
||
};
|
||
category "security" {
|
||
"my_security_channel";
|
||
"default_syslog";
|
||
"default_debug";
|
||
};</pre>
|
||
<p>To discard all messages in a category, specify the <span><strong class="command">null</strong></span> channel:</p>
|
||
<pre class="programlisting">category "xfer-out" { "null"; };
|
||
category "notify" { "null"; };
|
||
</pre>
|
||
<p>Following are the available categories and brief descriptions
|
||
of the types of log information they contain. More
|
||
categories may be added in future <span class="acronym">BIND</span> releases.</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><span><strong class="command">default</strong></span></p></td>
|
||
<td><p>The default category defines the logging
|
||
options for those categories where no specific configuration has been
|
||
defined.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">general</strong></span></p></td>
|
||
<td><p>The catch-all. Many things still aren't
|
||
classified into categories, and they all end up here.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">database</strong></span></p></td>
|
||
<td><p>Messages relating to the databases used
|
||
internally by the name server to store zone and cache data.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">security</strong></span></p></td>
|
||
<td><p>Approval and denial of requests.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">config</strong></span></p></td>
|
||
<td><p>Configuration file parsing and processing.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">resolver</strong></span></p></td>
|
||
<td><p>DNS resolution, such as the recursive
|
||
lookups performed on behalf of clients by a caching name server.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">xfer-in</strong></span></p></td>
|
||
<td><p>Zone transfers the server is receiving.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">xfer-out</strong></span></p></td>
|
||
<td><p>Zone transfers the server is sending.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">notify</strong></span></p></td>
|
||
<td><p>The NOTIFY protocol.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">client</strong></span></p></td>
|
||
<td><p>Processing of client requests.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">unmatched</strong></span></p></td>
|
||
<td><p>Messages that named was unable to determine the
|
||
class of or for which there was no matching <span><strong class="command">view</strong></span>.
|
||
A one line summary is also logged to the <span><strong class="command">client</strong></span> category.
|
||
This category is best sent to a file or stderr, by default it is sent to
|
||
the <span><strong class="command">null</strong></span> channel.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">network</strong></span></p></td>
|
||
<td><p>Network operations.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">update</strong></span></p></td>
|
||
<td><p>Dynamic updates.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">queries</strong></span></p></td>
|
||
<td><p>Queries. Using the category <span><strong class="command">queries</strong></span> will enable query logging.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">dispatch</strong></span></p></td>
|
||
<td><p>Dispatching of incoming packets to the
|
||
server modules where they are to be processed.
|
||
</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">dnssec</strong></span></p></td>
|
||
<td><p>DNSSEC and TSIG protocol processing.
|
||
</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">lame-servers</strong></span></p></td>
|
||
<td><p>Lame servers. These are misconfigurations
|
||
in remote servers, discovered by BIND 9 when trying to query
|
||
those servers during resolution.
|
||
</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">delegation-only</strong></span></p></td>
|
||
<td><p>Delegation only. Logs queries that have have
|
||
been forced to NXDOMAIN as the result of a delegation-only zone or
|
||
a <span><strong class="command">delegation-only</strong></span> in a hint or stub zone declartation.
|
||
</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
</div>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2556019"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
|
||
<p> This is the grammar of the <span><strong class="command">lwres</strong></span>
|
||
statement in the <code class="filename">named.conf</code> file:</p>
|
||
<pre class="programlisting"><span><strong class="command">lwres</strong></span> {
|
||
[<span class="optional"> listen-on { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
|
||
[<span class="optional"> view <em class="replaceable"><code>view_name</code></em>; </span>]
|
||
[<span class="optional"> search { <em class="replaceable"><code>domain_name</code></em> ; [<span class="optional"> <em class="replaceable"><code>domain_name</code></em> ; ... </span>] }; </span>]
|
||
[<span class="optional"> ndots <em class="replaceable"><code>number</code></em>; </span>]
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2556091"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">lwres</strong></span> statement configures the name
|
||
server to also act as a lightweight resolver server, see
|
||
<a href="Bv9ARM.ch05.html#lwresd" title="Running a Resolver Daemon">the section called “Running a Resolver Daemon”</a>. There may be be multiple
|
||
<span><strong class="command">lwres</strong></span> statements configuring
|
||
lightweight resolver servers with different properties.</p>
|
||
<p>The <span><strong class="command">listen-on</strong></span> statement specifies a list of
|
||
addresses (and ports) that this instance of a lightweight resolver daemon
|
||
should accept requests on. If no port is specified, port 921 is used.
|
||
If this statement is omitted, requests will be accepted on 127.0.0.1,
|
||
port 921.</p>
|
||
<p>The <span><strong class="command">view</strong></span> statement binds this instance of a
|
||
lightweight resolver daemon to a view in the DNS namespace, so that the
|
||
response will be constructed in the same manner as a normal DNS query
|
||
matching this view. If this statement is omitted, the default view is
|
||
used, and if there is no default view, an error is triggered.</p>
|
||
<p>The <span><strong class="command">search</strong></span> statement is equivalent to the
|
||
<span><strong class="command">search</strong></span> statement in
|
||
<code class="filename">/etc/resolv.conf</code>. It provides a list of domains
|
||
which are appended to relative names in queries.</p>
|
||
<p>The <span><strong class="command">ndots</strong></span> statement is equivalent to the
|
||
<span><strong class="command">ndots</strong></span> statement in
|
||
<code class="filename">/etc/resolv.conf</code>. It indicates the minimum
|
||
number of dots in a relative domain name that should result in an
|
||
exact match lookup before search path elements are appended.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2556154"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
|
||
<p>This is the grammar of the <span><strong class="command">options</strong></span>
|
||
statement in the <code class="filename">named.conf</code> file:</p>
|
||
<pre class="programlisting">options {
|
||
[<span class="optional"> version <em class="replaceable"><code>version_string</code></em>; </span>]
|
||
[<span class="optional"> directory <em class="replaceable"><code>path_name</code></em>; </span>]
|
||
[<span class="optional"> named-xfer <em class="replaceable"><code>path_name</code></em>; </span>]
|
||
[<span class="optional"> tkey-domain <em class="replaceable"><code>domainname</code></em>; </span>]
|
||
[<span class="optional"> tkey-dhkey <em class="replaceable"><code>key_name</code></em> <em class="replaceable"><code>key_tag</code></em>; </span>]
|
||
[<span class="optional"> dump-file <em class="replaceable"><code>path_name</code></em>; </span>]
|
||
[<span class="optional"> memstatistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
|
||
[<span class="optional"> pid-file <em class="replaceable"><code>path_name</code></em>; </span>]
|
||
[<span class="optional"> statistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
|
||
[<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> auth-nxdomain <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> deallocate-on-exit <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em>; </span>]
|
||
[<span class="optional"> fake-iquery <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> fetch-glue <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> has-old-clients <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> host-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> host-statistics-max <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> minimal-responses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> multiple-cnames <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em>; </span>]
|
||
[<span class="optional"> recursion <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> rfc2308-type1 <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> use-id-pool <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> forward ( <em class="replaceable"><code>only</code></em> | <em class="replaceable"><code>first</code></em> ); </span>]
|
||
[<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
|
||
[<span class="optional"> check-names ( <em class="replaceable"><code>master</code></em> | <em class="replaceable"><code>slave</code></em> | <em class="replaceable"><code> response</code></em> )( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
|
||
[<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
|
||
[<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
|
||
[<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
|
||
[<span class="optional"> allow-recursion { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
|
||
[<span class="optional"> allow-v6-synthesis { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
|
||
[<span class="optional"> blackhole { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
|
||
[<span class="optional"> listen-on [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
|
||
[<span class="optional"> listen-on-v6 [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
|
||
[<span class="optional"> query-source [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
|
||
[<span class="optional"> query-source-v6 [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
|
||
[<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> tcp-clients <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> recursive-clients <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> serial-query-rate <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> serial-queries <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em>; </span>]
|
||
[<span class="optional"> transfers-in <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> transfers-out <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> transfers-per-ns <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
|
||
[<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
|
||
[<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
|
||
[<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
|
||
[<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
|
||
[<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> coresize <em class="replaceable"><code>size_spec</code></em> ; </span>]
|
||
[<span class="optional"> datasize <em class="replaceable"><code>size_spec</code></em> ; </span>]
|
||
[<span class="optional"> files <em class="replaceable"><code>size_spec</code></em> ; </span>]
|
||
[<span class="optional"> stacksize <em class="replaceable"><code>size_spec</code></em> ; </span>]
|
||
[<span class="optional"> cleaning-interval <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> heartbeat-interval <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> interface-interval <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> statistics-interval <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> topology { <em class="replaceable"><code>address_match_list</code></em> }</span>];
|
||
[<span class="optional"> sortlist { <em class="replaceable"><code>address_match_list</code></em> }</span>];
|
||
[<span class="optional"> rrset-order { <em class="replaceable"><code>order_spec</code></em> ; [<span class="optional"> <em class="replaceable"><code>order_spec</code></em> ; ... </span>] </span>] };
|
||
[<span class="optional"> lame-ttl <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> max-ncache-ttl <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> max-cache-ttl <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> min-roots <em class="replaceable"><code>number</code></em>; </span>]
|
||
[<span class="optional"> use-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> treat-cr-as-space <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> port <em class="replaceable"><code>ip_port</code></em>; </span>]
|
||
[<span class="optional"> additional-from-auth <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> additional-from-cache <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> random-device <em class="replaceable"><code>path_name</code></em> ; </span>]
|
||
[<span class="optional"> max-cache-size <em class="replaceable"><code>size_spec</code></em> ; </span>]
|
||
[<span class="optional"> match-mapped-addresses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
|
||
[<span class="optional"> root-delegation-only [<span class="optional"> exclude { <em class="replaceable"><code>namelist
|
||
</code></em> } </span>] ; </span>]
|
||
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2557009"></a><span><strong class="command">options</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">options</strong></span> statement sets up global options
|
||
to be used by <span class="acronym">BIND</span>. This statement may appear only
|
||
once in a configuration file. If more than one occurrence is found,
|
||
the first occurrence determines the actual options used, and a warning
|
||
will be generated. If there is no <span><strong class="command">options</strong></span>
|
||
statement, an options block with each option set to its default will
|
||
be used.</p>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">version</strong></span></span></dt>
|
||
<dd><p>The version the server should report
|
||
via a query of name <code class="filename">version.bind</code> in
|
||
class <span><strong class="command">CHAOS</strong></span>.
|
||
The default is the real version number of this server.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">directory</strong></span></span></dt>
|
||
<dd><p>The working directory of the server.
|
||
Any non-absolute pathnames in the configuration file will be taken
|
||
as relative to this directory. The default location for most server
|
||
output files (e.g. <code class="filename">named.run</code>) is this directory.
|
||
If a directory is not specified, the working directory defaults
|
||
to `<code class="filename">.</code>', the directory from which the server
|
||
was started. The directory specified should be an absolute path.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">named-xfer</strong></span></span></dt>
|
||
<dd><p><span class="emphasis"><em>This option is obsolete.</em></span>
|
||
It was used in <span class="acronym">BIND</span> 8 to
|
||
specify the pathname to the <span><strong class="command">named-xfer</strong></span> program.
|
||
In <span class="acronym">BIND</span> 9, no separate <span><strong class="command">named-xfer</strong></span> program is
|
||
needed; its functionality is built into the name server.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">tkey-domain</strong></span></span></dt>
|
||
<dd><p>The domain appended to the names of all
|
||
shared keys generated with <span><strong class="command">TKEY</strong></span>. When a client
|
||
requests a <span><strong class="command">TKEY</strong></span> exchange, it may or may not specify
|
||
the desired name for the key. If present, the name of the shared
|
||
key will be "<code class="varname">client specified part</code>" +
|
||
"<code class="varname">tkey-domain</code>".
|
||
Otherwise, the name of the shared key will be "<code class="varname">random hex
|
||
digits</code>" + "<code class="varname">tkey-domain</code>". In most cases,
|
||
the <span><strong class="command">domainname</strong></span> should be the server's domain
|
||
name.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">tkey-dhkey</strong></span></span></dt>
|
||
<dd><p>The Diffie-Hellman key used by the server
|
||
to generate shared keys with clients using the Diffie-Hellman mode
|
||
of <span><strong class="command">TKEY</strong></span>. The server must be able to load the
|
||
public and private keys from files in the working directory. In
|
||
most cases, the keyname should be the server's host name.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">dump-file</strong></span></span></dt>
|
||
<dd><p>The pathname of the file the server dumps
|
||
the database to when instructed to do so with
|
||
<span><strong class="command">rndc dumpdb</strong></span>.
|
||
If not specified, the default is <code class="filename">named_dump.db</code>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">memstatistics-file</strong></span></span></dt>
|
||
<dd>
|
||
<p>The pathname of the file the server writes memory
|
||
usage statistics to on exit. If not specified,
|
||
the default is <code class="filename">named.memstats</code>.</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>Not yet implemented in <span class="acronym">BIND</span> 9.</p>
|
||
</div>
|
||
</dd>
|
||
<dt><span class="term"><span><strong class="command">pid-file</strong></span></span></dt>
|
||
<dd><p>The pathname of the file the server writes its process ID
|
||
in. If not specified, the default is <code class="filename">/var/run/named.pid</code>.
|
||
The pid-file is used by programs that want to send signals to the running
|
||
nameserver.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">statistics-file</strong></span></span></dt>
|
||
<dd><p>The pathname of the file the server appends statistics
|
||
to when instructed to do so using <span><strong class="command">rndc stats</strong></span>.
|
||
If not specified, the default is <code class="filename">named.stats</code> in the
|
||
server's current directory. The format of the file is described
|
||
in <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called “The Statistics File”</a></p></dd>
|
||
<dt><span class="term"><span><strong class="command">port</strong></span></span></dt>
|
||
<dd><p>
|
||
The UDP/TCP port number the server uses for
|
||
receiving and sending DNS protocol traffic.
|
||
The default is 53. This option is mainly intended for server testing;
|
||
a server using a port other than 53 will not be able to communicate with
|
||
the global DNS.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">random-device</strong></span></span></dt>
|
||
<dd><p>
|
||
The source of entropy to be used by the server. Entropy is primarily needed
|
||
for DNSSEC operations, such as TKEY transactions and dynamic update of signed
|
||
zones. This options specifies the device (or file) from which to read
|
||
entropy. If this is a file, operations requiring entropy will fail when the
|
||
file has been exhausted. If not specified, the default value is
|
||
<code class="filename">/dev/random</code>
|
||
(or equivalent) when present, and none otherwise. The
|
||
<span><strong class="command">random-device</strong></span> option takes effect during
|
||
the initial configuration load at server startup time and
|
||
is ignored on subsequent reloads.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">root-delegation-only</strong></span></span></dt>
|
||
<dd>
|
||
<p>
|
||
Turn on enforcment of delegation-only in TLDs and root zones with an optional
|
||
exclude list.
|
||
</p>
|
||
<p>
|
||
Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM").
|
||
</p>
|
||
<pre class="programlisting">
|
||
options {
|
||
root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
|
||
};
|
||
</pre>
|
||
</dd>
|
||
</dl></div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="boolean_options"></a>Boolean Options</h4></div></div></div>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">auth-nxdomain</strong></span></span></dt>
|
||
<dd><p>If <strong class="userinput"><code>yes</code></strong>, then the <span><strong class="command">AA</strong></span> bit
|
||
is always set on NXDOMAIN responses, even if the server is not actually
|
||
authoritative. The default is <strong class="userinput"><code>no</code></strong>; this is
|
||
a change from <span class="acronym">BIND</span> 8. If you are using very old DNS software, you
|
||
may need to set it to <strong class="userinput"><code>yes</code></strong>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">deallocate-on-exit</strong></span></span></dt>
|
||
<dd><p>This option was used in <span class="acronym">BIND</span> 8 to enable checking
|
||
for memory leaks on exit. <span class="acronym">BIND</span> 9 ignores the option and always performs
|
||
the checks.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
|
||
<dd>
|
||
<p>If <strong class="userinput"><code>yes</code></strong>, then the
|
||
server treats all zones as if they are doing zone transfers across
|
||
a dial on demand dialup link, which can be brought up by traffic
|
||
originating from this server. This has different effects according
|
||
to zone type and concentrates the zone maintenance so that it all
|
||
happens in a short interval, once every <span><strong class="command">heartbeat-interval</strong></span> and
|
||
hopefully during the one call. It also suppresses some of the normal
|
||
zone maintenance traffic. The default is <strong class="userinput"><code>no</code></strong>.</p>
|
||
<p>The <span><strong class="command">dialup</strong></span> option
|
||
may also be specified in the <span><strong class="command">view</strong></span> and
|
||
<span><strong class="command">zone</strong></span> statements,
|
||
in which case it overrides the global <span><strong class="command">dialup</strong></span>
|
||
option.</p>
|
||
<p>If the zone is a master zone then the server will send out a NOTIFY
|
||
request to all the slaves. This will trigger the zone serial number check
|
||
in the slave (providing it supports NOTIFY) allowing the slave to
|
||
verify the zone while the connection is active.</p>
|
||
<p>If the
|
||
zone is a slave or stub zone, then the server will suppress the regular
|
||
"zone up to date" (refresh) queries and only perform them when the
|
||
<span><strong class="command">heartbeat-interval</strong></span> expires in addition to sending
|
||
NOTIFY requests.</p>
|
||
<p>Finer control can be achieved by using
|
||
<strong class="userinput"><code>notify</code></strong> which only sends NOTIFY messages,
|
||
<strong class="userinput"><code>notify-passive</code></strong> which sends NOTIFY messages and
|
||
suppresses the normal refresh queries, <strong class="userinput"><code>refresh</code></strong>
|
||
which suppresses normal refresh processing and send refresh queries
|
||
when the <span><strong class="command">heartbeat-interval</strong></span> expires and
|
||
<strong class="userinput"><code>passive</code></strong> which just disables normal refresh
|
||
processing.</p>
|
||
</dd>
|
||
<dt><span class="term"><span><strong class="command">fake-iquery</strong></span></span></dt>
|
||
<dd><p>In <span class="acronym">BIND</span> 8, this option was used to
|
||
enable simulating the obsolete DNS query type
|
||
IQUERY. <span class="acronym">BIND</span> 9 never does IQUERY simulation.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">fetch-glue</strong></span></span></dt>
|
||
<dd><p>This option is obsolete.
|
||
In BIND 8, <strong class="userinput"><code>fetch-glue yes</code></strong>
|
||
caused the server to attempt to fetch glue resource records it
|
||
didn't have when constructing the additional
|
||
data section of a response. This is now considered a bad idea
|
||
and BIND 9 never does it.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">has-old-clients</strong></span></span></dt>
|
||
<dd><p>This option was incorrectly implemented
|
||
in <span class="acronym">BIND</span> 8, and is ignored by <span class="acronym">BIND</span> 9.
|
||
To achieve the intended effect
|
||
of
|
||
<span><strong class="command">has-old-clients</strong></span> <strong class="userinput"><code>yes</code></strong>, specify
|
||
the two separate options <span><strong class="command">auth-nxdomain</strong></span> <strong class="userinput"><code>yes</code></strong>
|
||
and <span><strong class="command">rfc2308-type1</strong></span> <strong class="userinput"><code>no</code></strong> instead.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">host-statistics</strong></span></span></dt>
|
||
<dd><p>In BIND 8, this enables keeping of
|
||
statistics for every host that the nameserver interacts with.
|
||
Not implemented in BIND 9.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">maintain-ixfr-base</strong></span></span></dt>
|
||
<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
|
||
It was used in <span class="acronym">BIND</span> 8 to determine whether a transaction log was
|
||
kept for Incremental Zone Transfer. <span class="acronym">BIND</span> 9 maintains a transaction
|
||
log whenever possible. If you need to disable outgoing incremental zone
|
||
transfers, use <span><strong class="command">provide-ixfr</strong></span> <strong class="userinput"><code>no</code></strong>.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">minimal-responses</strong></span></span></dt>
|
||
<dd><p>If <strong class="userinput"><code>yes</code></strong>, then when generating
|
||
responses the server will only add records to the authority and
|
||
additional data sections when they are required (e.g. delegations,
|
||
negative responses). This may improve the performance of the server.
|
||
The default is <strong class="userinput"><code>no</code></strong>.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">multiple-cnames</strong></span></span></dt>
|
||
<dd><p>This option was used in <span class="acronym">BIND</span> 8 to allow
|
||
a domain name to allow multiple CNAME records in violation of the
|
||
DNS standards. <span class="acronym">BIND</span> 9.2 always strictly
|
||
enforces the CNAME rules both in master files and dynamic updates.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
|
||
<dd>
|
||
<p>If <strong class="userinput"><code>yes</code></strong> (the default),
|
||
DNS NOTIFY messages are sent when a zone the server is authoritative for
|
||
changes, see <a href="Bv9ARM.ch03.html#notify" title="Notify">the section called “Notify”</a>. The messages are sent to the
|
||
servers listed in the zone's NS records (except the master server identified
|
||
in the SOA MNAME field), and to any servers listed in the
|
||
<span><strong class="command">also-notify</strong></span> option.
|
||
</p>
|
||
<p>
|
||
If <strong class="userinput"><code>explicit</code></strong>, notifies are sent only to
|
||
servers explicitly listed using <span><strong class="command">also-notify</strong></span>.
|
||
If <strong class="userinput"><code>no</code></strong>, no notifies are sent.
|
||
</p>
|
||
<p>
|
||
The <span><strong class="command">notify</strong></span> option may also be
|
||
specified in the <span><strong class="command">zone</strong></span> statement,
|
||
in which case it overrides the <span><strong class="command">options notify</strong></span> statement.
|
||
It would only be necessary to turn off this option if it caused slaves
|
||
to crash.</p>
|
||
</dd>
|
||
<dt><span class="term"><span><strong class="command">recursion</strong></span></span></dt>
|
||
<dd><p>If <strong class="userinput"><code>yes</code></strong>, and a
|
||
DNS query requests recursion, then the server will attempt to do
|
||
all the work required to answer the query. If recursion is off
|
||
and the server does not already know the answer, it will return a
|
||
referral response. The default is <strong class="userinput"><code>yes</code></strong>.
|
||
Note that setting <span><strong class="command">recursion no;</strong></span> does not prevent
|
||
clients from getting data from the server's cache; it only
|
||
prevents new data from being cached as an effect of client queries.
|
||
Caching may still occur as an effect the server's internal
|
||
operation, such as NOTIFY address lookups.
|
||
See also <span><strong class="command">fetch-glue</strong></span> above.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">rfc2308-type1</strong></span></span></dt>
|
||
<dd>
|
||
<p>Setting this to <strong class="userinput"><code>yes</code></strong> will
|
||
cause the server to send NS records along with the SOA record for negative
|
||
answers. The default is <strong class="userinput"><code>no</code></strong>.</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>Not yet implemented in <span class="acronym">BIND</span> 9.</p>
|
||
</div>
|
||
</dd>
|
||
<dt><span class="term"><span><strong class="command">use-id-pool</strong></span></span></dt>
|
||
<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
|
||
<span class="acronym">BIND</span> 9 always allocates query IDs from a pool.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
|
||
<dd><p>If <strong class="userinput"><code>yes</code></strong>, the server will, by default, collect
|
||
statistical data on all zones in the server. These statistics may be accessed
|
||
using <span><strong class="command">rndc stats</strong></span>, which will dump them to the file listed
|
||
in the <span><strong class="command">statistics-file</strong></span>. See also <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called “The Statistics File”</a>.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">use-ixfr</strong></span></span></dt>
|
||
<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
|
||
If you need to disable IXFR to a particular server or servers see
|
||
the information on the <span><strong class="command">provide-ixfr</strong></span> option
|
||
in <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called “<span><strong class="command">server</strong></span> Statement Definition and Usage”</a>. See also
|
||
<a href="Bv9ARM.ch04.html#incremental_zone_transfers" title="Incremental Zone Transfers (IXFR)">the section called “Incremental Zone Transfers (IXFR)”</a>.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">provide-ixfr</strong></span></span></dt>
|
||
<dd><p>
|
||
See the description of
|
||
<span><strong class="command">provide-ixfr</strong></span> in
|
||
<a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called “<span><strong class="command">server</strong></span> Statement Definition and Usage”</a>
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">request-ixfr</strong></span></span></dt>
|
||
<dd><p>
|
||
See the description of
|
||
<span><strong class="command">request-ixfr</strong></span> in
|
||
<a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called “<span><strong class="command">server</strong></span> Statement Definition and Usage”</a>
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">treat-cr-as-space</strong></span></span></dt>
|
||
<dd><p>This option was used in <span class="acronym">BIND</span> 8 to make
|
||
the server treat carriage return ("<span><strong class="command">\r</strong></span>") characters the same way
|
||
as a space or tab character,
|
||
to facilitate loading of zone files on a UNIX system that were generated
|
||
on an NT or DOS machine. In <span class="acronym">BIND</span> 9, both UNIX "<span><strong class="command">\n</strong></span>"
|
||
and NT/DOS "<span><strong class="command">\r\n</strong></span>" newlines are always accepted,
|
||
and the option is ignored.</p></dd>
|
||
<dt>
|
||
<span class="term"><span><strong class="command">additional-from-auth</strong></span>, </span><span class="term"><span><strong class="command">additional-from-cache</strong></span></span>
|
||
</dt>
|
||
<dd>
|
||
<p>
|
||
These options control the behavior of an authoritative server when
|
||
answering queries which have additional data, or when following CNAME
|
||
and DNAME chains.
|
||
</p>
|
||
<p>
|
||
When both of these options are set to <strong class="userinput"><code>yes</code></strong>
|
||
(the default) and a
|
||
query is being answered from authoritative data (a zone
|
||
configured into the server), the additional data section of the
|
||
reply will be filled in using data from other authoritative zones
|
||
and from the cache. In some situations this is undesirable, such
|
||
as when there is concern over the correctness of the cache, or
|
||
in servers where slave zones may be added and modified by
|
||
untrusted third parties. Also, avoiding
|
||
the search for this additional data will speed up server operations
|
||
at the possible expense of additional queries to resolve what would
|
||
otherwise be provided in the additional section.
|
||
</p>
|
||
<p>
|
||
For example, if a query asks for an MX record for host <code class="literal">foo.example.com</code>,
|
||
and the record found is "<code class="literal">MX 10 mail.example.net</code>", normally the address
|
||
records (A, A6, and AAAA) for <code class="literal">mail.example.net</code> will be provided as well,
|
||
if known. Setting these options to <span><strong class="command">no</strong></span> disables this behavior.
|
||
</p>
|
||
<p>
|
||
These options are intended for use in authoritative-only
|
||
servers, or in authoritative-only views. Attempts to set
|
||
them to <span><strong class="command">no</strong></span> without also specifying
|
||
<span><strong class="command">recursion no;</strong></span> will cause the server to
|
||
ignore the options and log a warning message.
|
||
</p>
|
||
<p>
|
||
Specifying <span><strong class="command">additional-from-cache no</strong></span> actually
|
||
disables the use of the cache not only for additional data lookups
|
||
but also when looking up the answer. This is usually the desired
|
||
behavior in an authoritative-only server where the correctness of
|
||
the cached data is an issue.
|
||
</p>
|
||
<p>
|
||
When a name server is non-recursively queried for a name that is not
|
||
below the apex of any served zone, it normally answers with an
|
||
"upwards referral" to the root servers or the servers of some other
|
||
known parent of the query name. Since the data in an upwards referral
|
||
comes from the cache, the server will not be able to provide upwards
|
||
referrals when <span><strong class="command">additional-from-cache no</strong></span>
|
||
has been specified. Instead, it will respond to such queries
|
||
with REFUSED. This should not cause any problems since
|
||
upwards referrals are not required for the resolution process.
|
||
</p>
|
||
</dd>
|
||
<dt><span class="term"><span><strong class="command">match-mapped-addresses</strong></span></span></dt>
|
||
<dd><p>If <strong class="userinput"><code>yes</code></strong>, then an
|
||
IPv4-mapped IPv6 address will match any address match
|
||
list entries that match the corresponding IPv4 address.
|
||
Enabling this option is sometimes useful on IPv6-enabled Linux
|
||
systems, to work around a kernel quirk that causes IPv4
|
||
TCP connections such as zone transfers to be accepted
|
||
on an IPv6 socket using mapped addresses, causing
|
||
address match lists designed for IPv4 to fail to match.
|
||
The use of this option for any other purpose is discouraged.
|
||
</p></dd>
|
||
</dl></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2557963"></a>Forwarding</h4></div></div></div>
|
||
<p>The forwarding facility can be used to create a large site-wide
|
||
cache on a few servers, reducing traffic over links to external
|
||
nameservers. It can also be used to allow queries by servers that
|
||
do not have direct access to the Internet, but wish to look up exterior
|
||
names anyway. Forwarding occurs only on those queries for which
|
||
the server is not authoritative and does not have the answer in
|
||
its cache.</p>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
|
||
<dd><p>This option is only meaningful if the
|
||
forwarders list is not empty. A value of <code class="varname">first</code>,
|
||
the default, causes the server to query the forwarders first, and
|
||
if that doesn't answer the question the server will then look for
|
||
the answer itself. If <code class="varname">only</code> is specified, the
|
||
server will only query the forwarders.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
|
||
<dd><p>Specifies the IP addresses to be used
|
||
for forwarding. The default is the empty list (no forwarding).
|
||
</p></dd>
|
||
</dl></div>
|
||
<p>Forwarding can also be configured on a per-domain basis, allowing
|
||
for the global forwarding options to be overridden in a variety
|
||
of ways. You can set particular domains to use different forwarders,
|
||
or have a different <span><strong class="command">forward only/first</strong></span> behavior,
|
||
or not forward at all, see <a href="Bv9ARM.ch06.html#zone_statement_grammar" title="zone
|
||
Statement Grammar">the section called “<span><strong class="command">zone</strong></span>
|
||
Statement Grammar”</a>.</p>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="access_control"></a>Access Control</h4></div></div></div>
|
||
<p>Access to the server can be restricted based on the IP address
|
||
of the requesting system. See <a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called “Address Match Lists”</a> for
|
||
details on how to specify IP address lists.</p>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
|
||
<dd><p>Specifies which hosts are allowed to
|
||
notify slaves of a zone change in addition to the zone masters.
|
||
<span><strong class="command">allow-notify</strong></span> may also be specified in the
|
||
<span><strong class="command">zone</strong></span> statement, in which case it overrides the
|
||
<span><strong class="command">options allow-notify</strong></span> statement. It is only meaningful
|
||
for a slave zone. If not specified, the default is to process notify messages
|
||
only from a zone's master.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
|
||
<dd><p>Specifies which hosts are allowed to
|
||
ask ordinary questions. <span><strong class="command">allow-query</strong></span> may also
|
||
be specified in the <span><strong class="command">zone</strong></span> statement, in which
|
||
case it overrides the <span><strong class="command">options allow-query</strong></span> statement. If
|
||
not specified, the default is to allow queries from all hosts.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">allow-recursion</strong></span></span></dt>
|
||
<dd><p>Specifies which hosts are allowed to
|
||
make recursive queries through this server. If not specified, the
|
||
default is to allow recursive queries from all hosts.
|
||
Note that disallowing recursive queries for a host does not prevent the
|
||
host from retrieving data that is already in the server's cache.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">allow-v6-synthesis</strong></span></span></dt>
|
||
<dd><p>Specifies which hosts are to receive
|
||
synthetic responses to IPv6 queries as described in
|
||
<a href="Bv9ARM.ch06.html#synthesis" title="Synthetic IPv6 responses">the section called “Synthetic IPv6 responses”</a>.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
|
||
<dd><p>Specifies which hosts are allowed to
|
||
receive zone transfers from the server. <span><strong class="command">allow-transfer</strong></span> may
|
||
also be specified in the <span><strong class="command">zone</strong></span> statement, in which
|
||
case it overrides the <span><strong class="command">options allow-transfer</strong></span> statement.
|
||
If not specified, the default is to allow transfers to all hosts.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">blackhole</strong></span></span></dt>
|
||
<dd><p>Specifies a list of addresses that the
|
||
server will not accept queries from or use to resolve a query. Queries
|
||
from these addresses will not be responded to. The default is <strong class="userinput"><code>none</code></strong>.</p></dd>
|
||
</dl></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2558205"></a>Interfaces</h4></div></div></div>
|
||
<p>The interfaces and ports that the server will answer queries
|
||
from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes
|
||
an optional port, and an <code class="varname">address_match_list</code>.
|
||
The server will listen on all interfaces allowed by the address
|
||
match list. If a port is not specified, port 53 will be used.</p>
|
||
<p>Multiple <span><strong class="command">listen-on</strong></span> statements are allowed.
|
||
For example,</p>
|
||
<pre class="programlisting">listen-on { 5.6.7.8; };
|
||
listen-on port 1234 { !1.2.3.4; 1.2/16; };
|
||
</pre>
|
||
<p>will enable the nameserver on port 53 for the IP address
|
||
5.6.7.8, and on port 1234 of an address on the machine in net
|
||
1.2 that is not 1.2.3.4.</p>
|
||
<p>If no <span><strong class="command">listen-on</strong></span> is specified, the
|
||
server will listen on port 53 on all interfaces.</p>
|
||
<p>The <span><strong class="command">listen-on-v6</strong></span> option is used to
|
||
specify the ports on which the server will listen for incoming
|
||
queries sent using IPv6.</p>
|
||
<p>The server does not bind a separate socket to each IPv6
|
||
interface address as it does for IPv4. Instead, it always
|
||
listens on the IPv6 wildcard address. Therefore, the only
|
||
values allowed for the <code class="varname">address_match_list</code>
|
||
argument to the <span><strong class="command">listen-on-v6</strong></span> statement are
|
||
</p>
|
||
<pre class="programlisting">{ any; }</pre>
|
||
<p> and
|
||
</p>
|
||
<pre class="programlisting">{ none;}</pre>
|
||
<p>Multiple <span><strong class="command">listen-on-v6</strong></span> options can be
|
||
used to listen on multiple ports:</p>
|
||
<pre class="programlisting">listen-on-v6 port 53 { any; };
|
||
listen-on-v6 port 1234 { any; };
|
||
</pre>
|
||
<p>To make the server not listen on any IPv6 address, use</p>
|
||
<pre class="programlisting">listen-on-v6 { none; };
|
||
</pre>
|
||
<p>If no <span><strong class="command">listen-on-v6</strong></span> statement is specified,
|
||
the server will not listen on any IPv6 address.</p>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2558290"></a>Query Address</h4></div></div></div>
|
||
<p>If the server doesn't know the answer to a question, it will
|
||
query other nameservers. <span><strong class="command">query-source</strong></span> specifies
|
||
the address and port used for such queries. For queries sent over
|
||
IPv6, there is a separate <span><strong class="command">query-source-v6</strong></span> option.
|
||
If <span><strong class="command">address</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
|
||
a wildcard IP address (<span><strong class="command">INADDR_ANY</strong></span>) will be used.
|
||
If <span><strong class="command">port</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
|
||
a random unprivileged port will be used. The defaults are</p>
|
||
<pre class="programlisting">query-source address * port *;
|
||
query-source-v6 address * port *;
|
||
</pre>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>The address specified in the <span><strong class="command">query-source</strong></span> option
|
||
is used for both UDP and TCP queries, but the port applies only to
|
||
UDP queries. TCP queries always use a random
|
||
unprivileged port.</p>
|
||
</div>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>See also <span><strong class="command">transfer-source</strong></span> and
|
||
<span><strong class="command">notify-source</strong></span>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="zone_transfers"></a>Zone Transfers</h4></div></div></div>
|
||
<p><span class="acronym">BIND</span> has mechanisms in place to facilitate zone transfers
|
||
and set limits on the amount of load that transfers place on the
|
||
system. The following options apply to zone transfers.</p>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
|
||
<dd><p>Defines a global list of IP addresses of name servers
|
||
that are also sent NOTIFY messages whenever a fresh copy of the
|
||
zone is loaded, in addition to the servers listed in the zone's NS records.
|
||
This helps to ensure that copies of the zones will
|
||
quickly converge on stealth servers. If an <span><strong class="command">also-notify</strong></span> list
|
||
is given in a <span><strong class="command">zone</strong></span> statement, it will override
|
||
the <span><strong class="command">options also-notify</strong></span> statement. When a <span><strong class="command">zone notify</strong></span> statement
|
||
is set to <span><strong class="command">no</strong></span>, the IP addresses in the global <span><strong class="command">also-notify</strong></span> list will
|
||
not be sent NOTIFY messages for that zone. The default is the empty
|
||
list (no global notification list).</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
|
||
<dd><p>Inbound zone transfers running longer than
|
||
this many minutes will be terminated. The default is 120 minutes
|
||
(2 hours).</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
|
||
<dd><p>Inbound zone transfers making no progress
|
||
in this many minutes will be terminated. The default is 60 minutes
|
||
(1 hour).</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
|
||
<dd><p>Outbound zone transfers running longer than
|
||
this many minutes will be terminated. The default is 120 minutes
|
||
(2 hours).</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
|
||
<dd><p>Outbound zone transfers making no progress
|
||
in this many minutes will be terminated. The default is 60 minutes (1
|
||
hour).</p></dd>
|
||
<dt><span class="term"><span><strong class="command">serial-query-rate</strong></span></span></dt>
|
||
<dd><p>Slave servers will periodically query master servers
|
||
to find out if zone serial numbers have changed. Each such query uses
|
||
a minute amount of the slave server's network bandwidth. To limit the
|
||
amount of bandwidth used, BIND 9 limits the rate at which queries are
|
||
sent. The value of the <span><strong class="command">serial-query-rate</strong></span> option,
|
||
an integer, is the maximum number of queries sent per second.
|
||
The default is 20.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">serial-queries</strong></span></span></dt>
|
||
<dd><p>In BIND 8, the <span><strong class="command">serial-queries</strong></span> option
|
||
set the maximum number of concurrent serial number queries
|
||
allowed to be outstanding at any given time.
|
||
BIND 9 does not limit the number of outstanding
|
||
serial queries and ignores the <span><strong class="command">serial-queries</strong></span> option.
|
||
Instead, it limits the rate at which the queries are sent
|
||
as defined using the <span><strong class="command">serial-query-rate</strong></span> option.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">transfer-format</strong></span></span></dt>
|
||
<dd><p>
|
||
Zone transfers can be sent using two different formats,
|
||
<span><strong class="command">one-answer</strong></span> and <span><strong class="command">many-answers</strong></span>.
|
||
The <span><strong class="command">transfer-format</strong></span> option is used
|
||
on the master server to determine which format it sends.
|
||
<span><strong class="command">one-answer</strong></span> uses one DNS message per
|
||
resource record transferred.
|
||
<span><strong class="command">many-answers</strong></span> packs as many resource records as
|
||
possible into a message. <span><strong class="command">many-answers</strong></span> is more
|
||
efficient, but is only supported by relatively new slave servers,
|
||
such as <span class="acronym">BIND</span> 9, <span class="acronym">BIND</span> 8.x and patched
|
||
versions of <span class="acronym">BIND</span> 4.9.5. The default is
|
||
<span><strong class="command">many-answers</strong></span>. <span><strong class="command">transfer-format</strong></span>
|
||
may be overridden on a per-server basis by using the
|
||
<span><strong class="command">server</strong></span> statement.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">transfers-in</strong></span></span></dt>
|
||
<dd><p>The maximum number of inbound zone transfers
|
||
that can be running concurrently. The default value is <code class="literal">10</code>.
|
||
Increasing <span><strong class="command">transfers-in</strong></span> may speed up the convergence
|
||
of slave zones, but it also may increase the load on the local system.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">transfers-out</strong></span></span></dt>
|
||
<dd><p>The maximum number of outbound zone transfers
|
||
that can be running concurrently. Zone transfer requests in excess
|
||
of the limit will be refused. The default value is <code class="literal">10</code>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">transfers-per-ns</strong></span></span></dt>
|
||
<dd><p>The maximum number of inbound zone transfers
|
||
that can be concurrently transferring from a given remote nameserver.
|
||
The default value is <code class="literal">2</code>. Increasing <span><strong class="command">transfers-per-ns</strong></span> may
|
||
speed up the convergence of slave zones, but it also may increase
|
||
the load on the remote nameserver. <span><strong class="command">transfers-per-ns</strong></span> may
|
||
be overridden on a per-server basis by using the <span><strong class="command">transfers</strong></span> phrase
|
||
of the <span><strong class="command">server</strong></span> statement.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
|
||
<dd><p><span><strong class="command">transfer-source</strong></span> determines
|
||
which local address will be bound to IPv4 TCP connections used to
|
||
fetch zones transferred inbound by the server. It also determines
|
||
the source IPv4 address, and optionally the UDP port, used for the
|
||
refresh queries and forwarded dynamic updates. If not set, it defaults
|
||
to a system controlled value which will usually be the address of
|
||
the interface "closest to" the remote end. This address must appear
|
||
in the remote end's <span><strong class="command">allow-transfer</strong></span> option for
|
||
the zone being transferred, if one is specified. This statement
|
||
sets the <span><strong class="command">transfer-source</strong></span> for all zones, but can
|
||
be overridden on a per-view or per-zone basis by including a
|
||
<span><strong class="command">transfer-source</strong></span> statement within the
|
||
<span><strong class="command">view</strong></span> or <span><strong class="command">zone</strong></span> block
|
||
in the configuration file.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
|
||
<dd><p>The same as <span><strong class="command">transfer-source</strong></span>,
|
||
except zone transfers are performed using IPv6.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
|
||
<dd><p><span><strong class="command">notify-source</strong></span> determines
|
||
which local source address, and optionally UDP port, will be used to
|
||
send NOTIFY messages.
|
||
This address must appear in the slave server's <span><strong class="command">masters</strong></span>
|
||
zone clause or in an <span><strong class="command">allow-notify</strong></span> clause.
|
||
This statement sets the <span><strong class="command">notify-source</strong></span> for all zones,
|
||
but can be overridden on a per-zone / per-view basis by including a
|
||
<span><strong class="command">notify-source</strong></span> statement within the <span><strong class="command">zone</strong></span>
|
||
or <span><strong class="command">view</strong></span> block in the configuration file.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
|
||
<dd><p>Like <span><strong class="command">notify-source</strong></span>,
|
||
but applies to notify messages sent to IPv6 addresses.</p></dd>
|
||
</dl></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2545228"></a>Operating System Resource Limits</h4></div></div></div>
|
||
<p>The server's usage of many system resources can be limited.
|
||
Scaled values are allowed when specifying resource limits. For
|
||
example, <span><strong class="command">1G</strong></span> can be used instead of
|
||
<span><strong class="command">1073741824</strong></span> to specify a limit of one
|
||
gigabyte. <span><strong class="command">unlimited</strong></span> requests unlimited use, or the
|
||
maximum available amount. <span><strong class="command">default</strong></span> uses the limit
|
||
that was in force when the server was started. See the description of
|
||
<span><strong class="command">size_spec</strong></span> in <a href="Bv9ARM.ch06.html#configuration_file_elements" title="Configuration File Elements">the section called “Configuration File Elements”</a>.</p>
|
||
<p>The following options set operating system resource limits for
|
||
the name server process. Some operating systems don't support some or
|
||
any of the limits. On such systems, a warning will be issued if the
|
||
unsupported limit is used.</p>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">coresize</strong></span></span></dt>
|
||
<dd><p>The maximum size of a core dump. The default
|
||
is <code class="literal">default</code>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">datasize</strong></span></span></dt>
|
||
<dd><p>The maximum amount of data memory the server
|
||
may use. The default is <code class="literal">default</code>.
|
||
This is a hard limit on server memory usage.
|
||
If the server attempts to allocate memory in excess of this
|
||
limit, the allocation will fail, which may in turn leave
|
||
the server unable to perform DNS service. Therefore,
|
||
this option is rarely useful as a way of limiting the
|
||
amount of memory used by the server, but it can be used
|
||
to raise an operating system data size limit that is
|
||
too small by default. If you wish to limit the amount
|
||
of memory used by the server, use the
|
||
<span><strong class="command">max-cache-size</strong></span> and
|
||
<span><strong class="command">recursive-clients</strong></span>
|
||
options instead.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">files</strong></span></span></dt>
|
||
<dd><p>The maximum number of files the server
|
||
may have open concurrently. The default is <code class="literal">unlimited</code>.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">stacksize</strong></span></span></dt>
|
||
<dd><p>The maximum amount of stack memory the server
|
||
may use. The default is <code class="literal">default</code>.</p></dd>
|
||
</dl></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2545330"></a>Server Resource Limits</h4></div></div></div>
|
||
<p>The following options set limits on the server's
|
||
resource consumption that are enforced internally by the
|
||
server rather than the operating system.</p>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">max-ixfr-log-size</strong></span></span></dt>
|
||
<dd><p>This option is obsolete; it is accepted
|
||
and ignored for BIND 8 compatibility.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">recursive-clients</strong></span></span></dt>
|
||
<dd><p>The maximum number of simultaneous recursive lookups
|
||
the server will perform on behalf of clients. The default is
|
||
<code class="literal">1000</code>. Because each recursing client uses a fair
|
||
bit of memory, on the order of 20 kilobytes, the value of the
|
||
<span><strong class="command">recursive-clients</strong></span> option may have to be decreased
|
||
on hosts with limited memory.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">tcp-clients</strong></span></span></dt>
|
||
<dd><p>The maximum number of simultaneous client TCP
|
||
connections that the server will accept.
|
||
The default is <code class="literal">100</code>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-cache-size</strong></span></span></dt>
|
||
<dd><p>The maximum amount of memory to use for the
|
||
server's cache, in bytes. When the amount of data in the cache
|
||
reaches this limit, the server will cause records to expire
|
||
prematurely so that the limit is not exceeded. In a server with
|
||
multiple views, the limit applies separately to the cache of each
|
||
view. The default is <code class="literal">unlimited</code>, meaning that
|
||
records are purged from the cache only when their TTLs expire.
|
||
</p></dd>
|
||
</dl></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2559257"></a>Periodic Task Intervals</h4></div></div></div>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt>
|
||
<dd><p>The server will remove expired resource records
|
||
from the cache every <span><strong class="command">cleaning-interval</strong></span> minutes.
|
||
The default is 60 minutes.
|
||
If set to 0, no periodic cleaning will occur.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">heartbeat-interval</strong></span></span></dt>
|
||
<dd><p>The server will perform zone maintenance tasks
|
||
for all zones marked as <span><strong class="command">dialup</strong></span> whenever this
|
||
interval expires. The default is 60 minutes. Reasonable values are up
|
||
to 1 day (1440 minutes). If set to 0, no zone maintenance for these zones will occur.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">interface-interval</strong></span></span></dt>
|
||
<dd><p>The server will scan the network interface list
|
||
every <span><strong class="command">interface-interval</strong></span> minutes. The default
|
||
is 60 minutes. If set to 0, interface scanning will only occur when
|
||
the configuration file is loaded. After the scan, listeners will be
|
||
started on any new interfaces (provided they are allowed by the
|
||
<span><strong class="command">listen-on</strong></span> configuration). Listeners on interfaces
|
||
that have gone away will be cleaned up.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">statistics-interval</strong></span></span></dt>
|
||
<dd>
|
||
<p>Nameserver statistics will be logged
|
||
every <span><strong class="command">statistics-interval</strong></span> minutes. The default is
|
||
60. If set to 0, no statistics will be logged.</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>Not yet implemented in <span class="acronym">BIND</span>9.</p>
|
||
</div>
|
||
</dd>
|
||
</dl></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="topology"></a>Topology</h4></div></div></div>
|
||
<p>All other things being equal, when the server chooses a nameserver
|
||
to query from a list of nameservers, it prefers the one that is
|
||
topologically closest to itself. The <span><strong class="command">topology</strong></span> statement
|
||
takes an <span><strong class="command">address_match_list</strong></span> and interprets it
|
||
in a special way. Each top-level list element is assigned a distance.
|
||
Non-negated elements get a distance based on their position in the
|
||
list, where the closer the match is to the start of the list, the
|
||
shorter the distance is between it and the server. A negated match
|
||
will be assigned the maximum distance from the server. If there
|
||
is no match, the address will get a distance which is further than
|
||
any non-negated list element, and closer than any negated element.
|
||
For example,</p>
|
||
<pre class="programlisting">topology {
|
||
10/8;
|
||
!1.2.3/24;
|
||
{ 1.2/16; 3/8; };
|
||
};</pre>
|
||
<p>will prefer servers on network 10 the most, followed by hosts
|
||
on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the
|
||
exception of hosts on network 1.2.3 (netmask 255.255.255.0), which
|
||
is preferred least of all.</p>
|
||
<p>The default topology is</p>
|
||
<pre class="programlisting"> topology { localhost; localnets; };
|
||
</pre>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>The <span><strong class="command">topology</strong></span> option
|
||
is not implemented in <span class="acronym">BIND</span> 9.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="the_sortlist_statement"></a>The <span><strong class="command">sortlist</strong></span> Statement</h4></div></div></div>
|
||
<p>The response to a DNS query may consist of multiple resource
|
||
records (RRs) forming a resource records set (RRset).
|
||
The name server will normally return the
|
||
RRs within the RRset in an indeterminate order
|
||
(but see the <span><strong class="command">rrset-order</strong></span>
|
||
statement in <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called “RRset Ordering”</a>).
|
||
The client resolver code should rearrange the RRs as appropriate,
|
||
that is, using any addresses on the local net in preference to other addresses.
|
||
However, not all resolvers can do this or are correctly configured.
|
||
When a client is using a local server the sorting can be performed
|
||
in the server, based on the client's address. This only requires
|
||
configuring the nameservers, not all the clients.</p>
|
||
<p>The <span><strong class="command">sortlist</strong></span> statement (see below) takes
|
||
an <span><strong class="command">address_match_list</strong></span> and interprets it even
|
||
more specifically than the <span><strong class="command">topology</strong></span> statement
|
||
does (<a href="Bv9ARM.ch06.html#topology" title="Topology">the section called “Topology”</a>).
|
||
Each top level statement in the <span><strong class="command">sortlist</strong></span> must
|
||
itself be an explicit <span><strong class="command">address_match_list</strong></span> with
|
||
one or two elements. The first element (which may be an IP address,
|
||
an IP prefix, an ACL name or a nested <span><strong class="command">address_match_list</strong></span>)
|
||
of each top level list is checked against the source address of
|
||
the query until a match is found.</p>
|
||
<p>Once the source address of the query has been matched, if
|
||
the top level statement contains only one element, the actual primitive
|
||
element that matched the source address is used to select the address
|
||
in the response to move to the beginning of the response. If the
|
||
statement is a list of two elements, then the second element is
|
||
treated the same as the <span><strong class="command">address_match_list</strong></span> in
|
||
a <span><strong class="command">topology</strong></span> statement. Each top level element
|
||
is assigned a distance and the address in the response with the minimum
|
||
distance is moved to the beginning of the response.</p>
|
||
<p>In the following example, any queries received from any of
|
||
the addresses of the host itself will get responses preferring addresses
|
||
on any of the locally connected networks. Next most preferred are addresses
|
||
on the 192.168.1/24 network, and after that either the 192.168.2/24
|
||
or
|
||
192.168.3/24 network with no preference shown between these two
|
||
networks. Queries received from a host on the 192.168.1/24 network
|
||
will prefer other addresses on that network to the 192.168.2/24
|
||
and
|
||
192.168.3/24 networks. Queries received from a host on the 192.168.4/24
|
||
or the 192.168.5/24 network will only prefer other addresses on
|
||
their directly connected networks.</p>
|
||
<pre class="programlisting">sortlist {
|
||
{ localhost; // IF the local host
|
||
{ localnets; // THEN first fit on the
|
||
192.168.1/24; // following nets
|
||
{ 192.168.2/24; 192.168.3/24; }; }; };
|
||
{ 192.168.1/24; // IF on class C 192.168.1
|
||
{ 192.168.1/24; // THEN use .1, or .2 or .3
|
||
{ 192.168.2/24; 192.168.3/24; }; }; };
|
||
{ 192.168.2/24; // IF on class C 192.168.2
|
||
{ 192.168.2/24; // THEN use .2, or .1 or .3
|
||
{ 192.168.1/24; 192.168.3/24; }; }; };
|
||
{ 192.168.3/24; // IF on class C 192.168.3
|
||
{ 192.168.3/24; // THEN use .3, or .1 or .2
|
||
{ 192.168.1/24; 192.168.2/24; }; }; };
|
||
{ { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net
|
||
};
|
||
};</pre>
|
||
<p>The following example will give reasonable behavior for the
|
||
local host and hosts on directly connected networks. It is similar
|
||
to the behavior of the address sort in <span class="acronym">BIND</span> 4.9.x. Responses sent
|
||
to queries from the local host will favor any of the directly connected
|
||
networks. Responses sent to queries from any other hosts on a directly
|
||
connected network will prefer addresses on that same network. Responses
|
||
to other queries will not be sorted.</p>
|
||
<pre class="programlisting">sortlist {
|
||
{ localhost; localnets; };
|
||
{ localnets; };
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="rrset_ordering"></a>RRset Ordering</h4></div></div></div>
|
||
<p>When multiple records are returned in an answer it may be
|
||
useful to configure the order of the records placed into the response.
|
||
The <span><strong class="command">rrset-order</strong></span> statement permits configuration
|
||
of the ordering of the records in a multiple record response.
|
||
See also the <span><strong class="command">sortlist</strong></span> statement,
|
||
<a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called “The <span><strong class="command">sortlist</strong></span> Statement”</a>.
|
||
</p>
|
||
<p>An <span><strong class="command">order_spec</strong></span> is defined as follows:</p>
|
||
<pre class="programlisting">[<span class="optional"> class <em class="replaceable"><code>class_name</code></em> </span>][<span class="optional"> type <em class="replaceable"><code>type_name</code></em> </span>][<span class="optional"> name <em class="replaceable"><code>"domain_name"</code></em></span>]
|
||
order <em class="replaceable"><code>ordering</code></em>
|
||
</pre>
|
||
<p>If no class is specified, the default is <span><strong class="command">ANY</strong></span>.
|
||
If no type is specified, the default is <span><strong class="command">ANY</strong></span>.
|
||
If no name is specified, the default is "<span><strong class="command">*</strong></span>".</p>
|
||
<p>The legal values for <span><strong class="command">ordering</strong></span> are:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><span><strong class="command">fixed</strong></span></p></td>
|
||
<td><p>Records are returned in the order they
|
||
are defined in the zone file.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">random</strong></span></p></td>
|
||
<td><p>Records are returned in some random order.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">cyclic</strong></span></p></td>
|
||
<td><p>Records are returned in a round-robin
|
||
order.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>For example:</p>
|
||
<pre class="programlisting">rrset-order {
|
||
class IN type A name "host.example.com" order random;
|
||
order cyclic;
|
||
};
|
||
</pre>
|
||
<p>will cause any responses for type A records in class IN that
|
||
have "<code class="literal">host.example.com</code>" as a suffix, to always be returned
|
||
in random order. All other records are returned in cyclic order.</p>
|
||
<p>If multiple <span><strong class="command">rrset-order</strong></span> statements appear,
|
||
they are not combined — the last one applies.</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>The <span><strong class="command">rrset-order</strong></span> statement
|
||
is not yet implemented in <span class="acronym">BIND</span> 9.
|
||
BIND 9 currently supports only a "random-cyclic" ordering,
|
||
where the server randomly chooses a starting point within
|
||
the RRset and returns the records in order starting at
|
||
that point, wrapping around the end of the RRset if
|
||
necessary.</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="synthesis"></a>Synthetic IPv6 responses</h4></div></div></div>
|
||
<p>Many existing stub resolvers support IPv6 DNS lookups as defined in
|
||
RFC1886, using AAAA records for forward lookups and "nibble labels" in
|
||
the <code class="literal">IP6.INT</code> domain for reverse lookups, but do not support
|
||
RFC2874-style lookups (using A6 records and binary labels in the
|
||
<code class="literal">IP6.ARPA</code> domain).</p>
|
||
<p>For those who wish to continue to use such stub resolvers rather than
|
||
switching to the BIND 9 lightweight resolver, BIND 9 provides a way
|
||
to automatically convert RFC1886-style lookups into
|
||
RFC2874-style lookups and return the results as "synthetic" AAAA and
|
||
PTR records.</p>
|
||
<p>This feature is disabled by default and can be enabled on a per-client
|
||
basis by adding a
|
||
<span><strong class="command">allow-v6-synthesis { <em class="replaceable"><code>address_match_list</code></em> };</strong></span>
|
||
clause to the <span><strong class="command">options</strong></span> or <span><strong class="command">view</strong></span> statement.
|
||
When it is enabled, recursive
|
||
AAAA queries cause the server to first try an A6 lookup and if that
|
||
fails, an AAAA lookups. No matter which one succeeds, the results are
|
||
returned as a set of synthetic AAAA records. Similarly, recursive PTR
|
||
queries in <code class="literal">IP6.INT</code> will cause a
|
||
lookup in <code class="literal">IP6.ARPA</code> using binary
|
||
labels, and if that fails, another lookup in <code class="literal">IP6.INT</code>.
|
||
The results are returned as a synthetic PTR record in
|
||
<code class="literal">ip6.int</code>.</p>
|
||
<p>The synthetic records have a TTL of zero. DNSSEC validation of
|
||
synthetic responses is not currently supported; therefore responses
|
||
containing synthetic RRs will not have the AD flag set.</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p><span><strong class="command">allow-v6-synthesis</strong></span> is only performed for
|
||
clients that are supplied recursive service.</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="tuning"></a>Tuning</h4></div></div></div>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">lame-ttl</strong></span></span></dt>
|
||
<dd><p>Sets the number of seconds to cache a
|
||
lame server indication. 0 disables caching. (This is
|
||
<span class="bold"><strong>NOT</strong></span> recommended.)
|
||
Default is <code class="literal">600</code> (10 minutes). Maximum value is
|
||
<code class="literal">1800</code> (30 minutes).</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-ncache-ttl</strong></span></span></dt>
|
||
<dd><p>To reduce network traffic and increase performance
|
||
the server stores negative answers. <span><strong class="command">max-ncache-ttl</strong></span> is
|
||
used to set a maximum retention time for these answers in the server
|
||
in seconds. The default
|
||
<span><strong class="command">max-ncache-ttl</strong></span> is <code class="literal">10800</code> seconds (3 hours).
|
||
<span><strong class="command">max-ncache-ttl</strong></span> cannot exceed 7 days and will
|
||
be silently truncated to 7 days if set to a greater value.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">host-statistics-max</strong></span></span></dt>
|
||
<dd><p>In BIND 8, specifies the maximum number of host statistic
|
||
entries to be kept.
|
||
Not implemented in BIND 9.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-cache-ttl</strong></span></span></dt>
|
||
<dd><p><span><strong class="command">max-cache-ttl</strong></span> sets
|
||
the maximum time for which the server will cache ordinary (positive)
|
||
answers. The default is one week (7 days).</p></dd>
|
||
<dt><span class="term"><span><strong class="command">min-roots</strong></span></span></dt>
|
||
<dd>
|
||
<p>The minimum number of root servers that
|
||
is required for a request for the root servers to be accepted. Default
|
||
is <strong class="userinput"><code>2</code></strong>.</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>Not yet implemented in <span class="acronym">BIND</span>9.</p>
|
||
</div>
|
||
</dd>
|
||
<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
|
||
<dd><p>Specifies the number of days into the
|
||
future when DNSSEC signatures automatically generated as a result
|
||
of dynamic updates (<a href="Bv9ARM.ch04.html#dynamic_update" title="Dynamic Update">the section called “Dynamic Update”</a>)
|
||
will expire. The default is <code class="literal">30</code> days. The signature
|
||
inception time is unconditionally set to one hour before the current time
|
||
to allow for a limited amount of clock skew.</p></dd>
|
||
<dt>
|
||
<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
|
||
</dt>
|
||
<dd>
|
||
<p>
|
||
These options control the server's behavior on refreshing a zone
|
||
(querying for SOA changes) or retrying failed transfers.
|
||
Usually the SOA values for the zone are used, but these values
|
||
are set by the master, giving slave server administrators little
|
||
control over their contents.
|
||
</p>
|
||
<p>
|
||
These options allow the administrator to set a minimum and maximum
|
||
refresh and retry time either per-zone, per-view or globally.
|
||
These options are valid for slave and stub zones,
|
||
and clamp the SOA refresh and retry times to the specified values.
|
||
</p>
|
||
</dd>
|
||
</dl></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="statsfile"></a>The Statistics File</h4></div></div></div>
|
||
<p>The statistics file generated by <span class="acronym">BIND</span> 9
|
||
is similar, but not identical, to that
|
||
generated by <span class="acronym">BIND</span> 8.
|
||
</p>
|
||
<p>The statistics dump begins with the line <span><strong class="command">+++ Statistics Dump
|
||
+++ (973798949)</strong></span>, where the number in parentheses is a standard
|
||
Unix-style timestamp, measured as seconds since January 1, 1970. Following
|
||
that line are a series of lines containing a counter type, the value of the
|
||
counter, optionally a zone name, and optionally a view name.
|
||
The lines without view and zone listed are global statistics for the entire server.
|
||
Lines with a zone and view name for the given view and zone (the view name is
|
||
omitted for the default view). The statistics dump ends
|
||
with the line <span><strong class="command">--- Statistics Dump --- (973798949)</strong></span>, where the
|
||
number is identical to the number in the beginning line.</p>
|
||
<p>The following statistics counters are maintained:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><span><strong class="command">success</strong></span></p></td>
|
||
<td><p>The number of
|
||
successful queries made to the server or zone. A successful query
|
||
is defined as query which returns a NOERROR response other than
|
||
a referral response.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">referral</strong></span></p></td>
|
||
<td><p>The number of queries which resulted
|
||
in referral responses.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">nxrrset</strong></span></p></td>
|
||
<td><p>The number of queries which resulted in
|
||
NOERROR responses with no data.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">nxdomain</strong></span></p></td>
|
||
<td><p>The number
|
||
of queries which resulted in NXDOMAIN responses.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">recursion</strong></span></p></td>
|
||
<td><p>The number of queries which caused the server
|
||
to perform recursion in order to find the final answer.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">failure</strong></span></p></td>
|
||
<td><p>The number of queries which resulted in a
|
||
failure response other than those above.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>
|
||
Each query received by the server will cause exactly one of
|
||
<span><strong class="command">success</strong></span>,
|
||
<span><strong class="command">referral</strong></span>,
|
||
<span><strong class="command">nxrrset</strong></span>,
|
||
<span><strong class="command">nxdomain</strong></span>, or
|
||
<span><strong class="command">failure</strong></span>
|
||
to be incremented, and may additionally cause the
|
||
<span><strong class="command">recursion</strong></span> counter to be incremented.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="server_statement_grammar"></a><span><strong class="command">server</strong></span> Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting">server <em class="replaceable"><code>ip_addr</code></em> {
|
||
[<span class="optional"> bogus <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> edns <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> transfers <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em> ; ]</span>]
|
||
[<span class="optional"> keys <em class="replaceable"><code>{ string ; [<span class="optional"> string ; [<span class="optional">...</span>]</span>] }</code></em> ; </span>]
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="server_statement_definition_and_usage"></a><span><strong class="command">server</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">server</strong></span> statement defines characteristics
|
||
to be associated with a remote nameserver.</p>
|
||
<p>
|
||
The <span><strong class="command">server</strong></span> statement can occur at the top level of the
|
||
configuration file or inside a <span><strong class="command">view</strong></span> statement.
|
||
If a <span><strong class="command">view</strong></span> statement contains
|
||
one or more <span><strong class="command">server</strong></span> statements, only those
|
||
apply to the view and any top-level ones are ignored.
|
||
If a view contains no <span><strong class="command">server</strong></span> statements,
|
||
any top-level <span><strong class="command">server</strong></span> statements are used as
|
||
defaults.
|
||
</p>
|
||
<p>If you discover that a remote server is giving out bad data,
|
||
marking it as bogus will prevent further queries to it. The default
|
||
value of <span><strong class="command">bogus</strong></span> is <span><strong class="command">no</strong></span>.</p>
|
||
<p>The <span><strong class="command">provide-ixfr</strong></span> clause determines whether
|
||
the local server, acting as master, will respond with an incremental
|
||
zone transfer when the given remote server, a slave, requests it.
|
||
If set to <span><strong class="command">yes</strong></span>, incremental transfer will be provided
|
||
whenever possible. If set to <span><strong class="command">no</strong></span>, all transfers
|
||
to the remote server will be nonincremental. If not set, the value
|
||
of the <span><strong class="command">provide-ixfr</strong></span> option in the view or
|
||
global options block is used as a default.</p>
|
||
<p>The <span><strong class="command">request-ixfr</strong></span> clause determines whether
|
||
the local server, acting as a slave, will request incremental zone
|
||
transfers from the given remote server, a master. If not set, the
|
||
value of the <span><strong class="command">request-ixfr</strong></span> option in the view or
|
||
global options block is used as a default.</p>
|
||
<p>IXFR requests to servers that do not support IXFR will automatically
|
||
fall back to AXFR. Therefore, there is no need to manually list
|
||
which servers support IXFR and which ones do not; the global default
|
||
of <span><strong class="command">yes</strong></span> should always work.
|
||
The purpose of the <span><strong class="command">provide-ixfr</strong></span> and
|
||
<span><strong class="command">request-ixfr</strong></span> clauses is
|
||
to make it possible to disable the use of IXFR even when both master
|
||
and slave claim to support it, for example if one of the servers
|
||
is buggy and crashes or corrupts data when IXFR is used.</p>
|
||
<p>The <span><strong class="command">edns</strong></span> clause determines whether the local server
|
||
will attempt to use EDNS when communicating with the remote server. The
|
||
default is <span><strong class="command">yes</strong></span>.</p>
|
||
<p>The server supports two zone transfer methods. The first, <span><strong class="command">one-answer</strong></span>,
|
||
uses one DNS message per resource record transferred. <span><strong class="command">many-answers</strong></span> packs
|
||
as many resource records as possible into a message. <span><strong class="command">many-answers</strong></span> is
|
||
more efficient, but is only known to be understood by <span class="acronym">BIND</span> 9, <span class="acronym">BIND</span>
|
||
8.x, and patched versions of <span class="acronym">BIND</span> 4.9.5. You can specify which method
|
||
to use for a server with the <span><strong class="command">transfer-format</strong></span> option.
|
||
If <span><strong class="command">transfer-format</strong></span> is not specified, the <span><strong class="command">transfer-format</strong></span> specified
|
||
by the <span><strong class="command">options</strong></span> statement will be used.</p>
|
||
<p><span><strong class="command">transfers</strong></span> is used to limit the number of
|
||
concurrent inbound zone transfers from the specified server. If
|
||
no <span><strong class="command">transfers</strong></span> clause is specified, the limit is
|
||
set according to the <span><strong class="command">transfers-per-ns</strong></span> option.</p>
|
||
<p>The <span><strong class="command">keys</strong></span> clause is used to identify a <span><strong class="command">key_id</strong></span> defined
|
||
by the <span><strong class="command">key</strong></span> statement, to be used for transaction
|
||
security when talking to the remote server. The <span><strong class="command">key</strong></span> statement
|
||
must come before the <span><strong class="command">server</strong></span> statement that references
|
||
it. When a request is sent to the remote server, a request signature
|
||
will be generated using the key specified here and appended to the
|
||
message. A request originating from the remote server is not required
|
||
to be signed by this key.</p>
|
||
<p>Although the grammar of the <span><strong class="command">keys</strong></span> clause
|
||
allows for multiple keys, only a single key per server is currently
|
||
supported.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2560541"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting">trusted-keys {
|
||
<em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ;
|
||
[<span class="optional"> <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>]
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2560726"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
|
||
and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">trusted-keys</strong></span> statement defines DNSSEC
|
||
security roots. DNSSEC is described in <a href="Bv9ARM.ch04.html#DNSSEC" title="DNSSEC">the section called “DNSSEC”</a>. A security root is defined when the public key for a non-authoritative
|
||
zone is known, but cannot be securely obtained through DNS, either
|
||
because it is the DNS root zone or its parent zone is unsigned.
|
||
Once a key has been configured as a trusted key, it is treated as
|
||
if it had been validated and proven secure. The resolver attempts
|
||
DNSSEC validation on all DNS data in subdomains of a security root.</p>
|
||
<p>The <span><strong class="command">trusted-keys</strong></span> statement can contain
|
||
multiple key entries, each consisting of the key's domain name,
|
||
flags, protocol, algorithm, and the base-64 representation of the
|
||
key data.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2560749"></a><span><strong class="command">view</strong></span> Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting">view <em class="replaceable"><code>view_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
|
||
match-clients { <em class="replaceable"><code>address_match_list</code></em> } ;
|
||
match-destinations { <em class="replaceable"><code>address_match_list</code></em> } ;
|
||
match-recursive-only <em class="replaceable"><code>yes_or_no</code></em> ;
|
||
[<span class="optional"> <em class="replaceable"><code>view_option</code></em>; ...</span>]
|
||
[<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> <em class="replaceable"><code>zone_statement</code></em>; ...</span>]
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2560797"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<p>The <span><strong class="command">view</strong></span> statement is a powerful new feature
|
||
of <span class="acronym">BIND</span> 9 that lets a name server answer a DNS query differently
|
||
depending on who is asking. It is particularly useful for implementing
|
||
split DNS setups without having to run multiple servers.</p>
|
||
<p>Each <span><strong class="command">view</strong></span> statement defines a view of the
|
||
DNS namespace that will be seen by a subset of clients. A client matches
|
||
a view if its source IP address matches the
|
||
<code class="varname">address_match_list</code> of the view's
|
||
<span><strong class="command">match-clients</strong></span> clause and its destination IP address matches
|
||
the <code class="varname">address_match_list</code> of the view's
|
||
<span><strong class="command">match-destinations</strong></span> clause. If not specified, both
|
||
<span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
|
||
default to matching all addresses. A view can also be specified
|
||
as <span><strong class="command">match-recursive-only</strong></span>, which means that only recursive
|
||
requests from matching clients will match that view.
|
||
The order of the <span><strong class="command">view</strong></span> statements is significant —
|
||
a client request will be resolved in the context of the first
|
||
<span><strong class="command">view</strong></span> that it matches.</p>
|
||
<p>Zones defined within a <span><strong class="command">view</strong></span> statement will
|
||
be only be accessible to clients that match the <span><strong class="command">view</strong></span>.
|
||
By defining a zone of the same name in multiple views, different
|
||
zone data can be given to different clients, for example, "internal"
|
||
and "external" clients in a split DNS setup.</p>
|
||
<p>Many of the options given in the <span><strong class="command">options</strong></span> statement
|
||
can also be used within a <span><strong class="command">view</strong></span> statement, and then
|
||
apply only when resolving queries with that view. When no view-specific
|
||
value is given, the value in the <span><strong class="command">options</strong></span> statement
|
||
is used as a default. Also, zone options can have default values specified
|
||
in the <span><strong class="command">view</strong></span> statement; these view-specific defaults
|
||
take precedence over those in the <span><strong class="command">options</strong></span> statement.</p>
|
||
<p>Views are class specific. If no class is given, class IN
|
||
is assumed. Note that all non-IN views must contain a hint zone,
|
||
since only the IN class has compiled-in default hints.</p>
|
||
<p>If there are no <span><strong class="command">view</strong></span> statements in the config
|
||
file, a default view that matches any client is automatically created
|
||
in class IN, and any <span><strong class="command">zone</strong></span> statements specified on
|
||
the top level of the configuration file are considered to be part of
|
||
this default view. If any explicit <span><strong class="command">view</strong></span> statements
|
||
are present, all <span><strong class="command">zone</strong></span> statements must occur inside
|
||
<span><strong class="command">view</strong></span> statements.</p>
|
||
<p>Here is an example of a typical split DNS setup implemented
|
||
using <span><strong class="command">view</strong></span> statements.</p>
|
||
<pre class="programlisting">view "internal" {
|
||
// This should match our internal networks.
|
||
match-clients { 10.0.0.0/8; };
|
||
// Provide recursive service to internal clients only.
|
||
recursion yes;
|
||
// Provide a complete view of the example.com zone
|
||
// including addresses of internal hosts.
|
||
zone "example.com" {
|
||
type master;
|
||
file "example-internal.db";
|
||
};
|
||
};
|
||
view "external" {
|
||
match-clients { any; };
|
||
// Refuse recursive service to external clients.
|
||
recursion no;
|
||
// Provide a restricted view of the example.com zone
|
||
// containing only publicly accessible hosts.
|
||
zone "example.com" {
|
||
type master;
|
||
file "example-external.db";
|
||
};
|
||
};
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="zone_statement_grammar"></a><span><strong class="command">zone</strong></span>
|
||
Statement Grammar</h3></div></div></div>
|
||
<pre class="programlisting">zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] [<span class="optional">{
|
||
type ( master | slave | hint | stub | forward | delegation-only ) ;
|
||
[<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
|
||
[<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
|
||
[<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
|
||
[<span class="optional"> allow-update { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
|
||
[<span class="optional"> update-policy { <em class="replaceable"><code>update_policy_rule</code></em> [<span class="optional">...</span>] } ; </span>]
|
||
[<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
|
||
[<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
|
||
[<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
|
||
[<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
|
||
[<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
|
||
[<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
|
||
[<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
|
||
[<span class="optional"> ixfr-base <em class="replaceable"><code>string</code></em> ; </span>]
|
||
[<span class="optional"> ixfr-tmp-file <em class="replaceable"><code>string</code></em> ; </span>]
|
||
[<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> masters [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>]; [<span class="optional">...</span>] } ; </span>]
|
||
[<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> ; </span>]
|
||
[<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
|
||
[<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
|
||
[<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
|
||
[<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
|
||
[<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
|
||
[<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
|
||
[<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
|
||
[<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
|
||
[<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
|
||
|
||
}</span>];
|
||
</pre>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2561404"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2561411"></a>Zone Types</h4></div></div></div>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><code class="varname">master</code></p></td>
|
||
<td><p>The server has a master copy of the data
|
||
for the zone and will be able to provide authoritative answers for
|
||
it.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">slave</code></p></td>
|
||
<td><p>A slave zone is a replica of a master
|
||
zone. The <span><strong class="command">masters</strong></span> list specifies one or more IP addresses
|
||
of master servers that the slave contacts to update its copy of the zone.
|
||
By default, transfers are made from port 53 on the servers; this can
|
||
be changed for all servers by specifying a port number before the
|
||
list of IP addresses, or on a per-server basis after the IP address.
|
||
Authentication to the master can also be done with per-server TSIG keys.
|
||
If a file is specified, then the
|
||
replica will be written to this file whenever the zone is changed,
|
||
and reloaded from this file on a server restart. Use of a file is
|
||
recommended, since it often speeds server start-up and eliminates
|
||
a needless waste of bandwidth. Note that for large numbers (in the
|
||
tens or hundreds of thousands) of zones per server, it is best to
|
||
use a two level naming scheme for zone file names. For example,
|
||
a slave server for the zone <code class="literal">example.com</code> might place
|
||
the zone contents into a file called
|
||
<code class="filename">ex/example.com</code> where <code class="filename">ex/</code> is
|
||
just the first two letters of the zone name. (Most operating systems
|
||
behave very slowly if you put 100K files into a single directory.)</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">stub</code></p></td>
|
||
<td>
|
||
<p>A stub zone is similar to a slave zone,
|
||
except that it replicates only the NS records of a master zone instead
|
||
of the entire zone. Stub zones are not a standard part of the DNS;
|
||
they are a feature specific to the <span class="acronym">BIND</span> implementation.
|
||
</p>
|
||
|
||
<p>Stub zones can be used to eliminate the need for glue NS record
|
||
in a parent zone at the expense of maintaining a stub zone entry and
|
||
a set of name server addresses in <code class="filename">named.conf</code>.
|
||
This usage is not recommended for new configurations, and BIND 9
|
||
supports it only in a limited way.
|
||
In <span class="acronym">BIND</span> 4/8, zone transfers of a parent zone
|
||
included the NS records from stub children of that zone. This meant
|
||
that, in some cases, users could get away with configuring child stubs
|
||
only in the master server for the parent zone. <span class="acronym">BIND</span>
|
||
9 never mixes together zone data from different zones in this
|
||
way. Therefore, if a <span class="acronym">BIND</span> 9 master serving a parent
|
||
zone has child stub zones configured, all the slave servers for the
|
||
parent zone also need to have the same child stub zones
|
||
configured.</p>
|
||
|
||
<p>Stub zones can also be used as a way of forcing the resolution
|
||
of a given domain to use a particular set of authoritative servers.
|
||
For example, the caching name servers on a private network using
|
||
RFC1981 addressing may be configured with stub zones for
|
||
<code class="literal">10.in-addr.arpa</code>
|
||
to use a set of internal name servers as the authoritative
|
||
servers for that domain.</p>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">forward</code></p></td>
|
||
<td>
|
||
<p>A "forward zone" is a way to configure
|
||
forwarding on a per-domain basis. A <span><strong class="command">zone</strong></span> statement
|
||
of type <span><strong class="command">forward</strong></span> can contain a <span><strong class="command">forward</strong></span> and/or <span><strong class="command">forwarders</strong></span> statement,
|
||
which will apply to queries within the domain given by the zone
|
||
name. If no <span><strong class="command">forwarders</strong></span> statement is present or
|
||
an empty list for <span><strong class="command">forwarders</strong></span> is given, then no
|
||
forwarding will be done for the domain, canceling the effects of
|
||
any forwarders in the <span><strong class="command">options</strong></span> statement. Thus
|
||
if you want to use this type of zone to change the behavior of the
|
||
global <span><strong class="command">forward</strong></span> option (that is, "forward first
|
||
to", then "forward only", or vice versa, but want to use the same
|
||
servers as set globally) you need to respecify the global forwarders.</p>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">hint</code></p></td>
|
||
<td><p>The initial set of root nameservers is
|
||
specified using a "hint zone". When the server starts up, it uses
|
||
the root hints to find a root nameserver and get the most recent
|
||
list of root nameservers. If no hint zone is specified for class
|
||
IN, the server uses a compiled-in default set of root servers hints.
|
||
Classes other than IN have no built-in defaults hints.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">delegation-only</code></p></td>
|
||
<td>
|
||
<p>This is used to enforce the delegation only
|
||
status of infrastructure zones (e.g. COM, NET, ORG). Any answer that
|
||
is received without a explicit or implict delegation in the authority
|
||
section will be treated as NXDOMAIN. This does not apply to the zone
|
||
apex. This SHOULD NOT be applied to leaf zones.</p>
|
||
<p><code class="varname">delegation-only</code> has no effect on answers received
|
||
from forwarders.</p>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2561785"></a>Class</h4></div></div></div>
|
||
<p>The zone's name may optionally be followed by a class. If
|
||
a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>),
|
||
is assumed. This is correct for the vast majority of cases.</p>
|
||
<p>The <code class="literal">hesiod</code> class is
|
||
named for an information service from MIT's Project Athena. It is
|
||
used to share information about various systems databases, such
|
||
as users, groups, printers and so on. The keyword
|
||
<code class="literal">HS</code> is
|
||
a synonym for hesiod.</p>
|
||
<p>Another MIT development is CHAOSnet, a LAN protocol created
|
||
in the mid-1970s. Zone data for it can be specified with the <code class="literal">CHAOS</code> class.</p>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2561816"></a>Zone Options</h4></div></div></div>
|
||
<div class="variablelist"><dl>
|
||
<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">allow-notify</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called “Access Control”</a></p></dd>
|
||
<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">allow-query</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called “Access Control”</a></p></dd>
|
||
<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
|
||
<dd><p>See the description of <span><strong class="command">allow-transfer</strong></span>
|
||
in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called “Access Control”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">allow-update</strong></span></span></dt>
|
||
<dd><p>Specifies which hosts are allowed to
|
||
submit Dynamic DNS updates for master zones. The default is to deny
|
||
updates from all hosts.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">update-policy</strong></span></span></dt>
|
||
<dd><p>Specifies a "Simple Secure Update" policy. See
|
||
<a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called “Dynamic Update Policies”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
|
||
<dd>
|
||
<p>Specifies which hosts are allowed to
|
||
submit Dynamic DNS updates to slave zones to be forwarded to the
|
||
master. The default is <strong class="userinput"><code>{ none; }</code></strong>, which
|
||
means that no update forwarding will be performed. To enable
|
||
update forwarding, specify
|
||
<strong class="userinput"><code>allow-update-forwarding { any; };</code></strong>.
|
||
Specifying values other than <strong class="userinput"><code>{ none; }</code></strong> or
|
||
<strong class="userinput"><code>{ any; }</code></strong> is usually counterproductive, since
|
||
the responsibility for update access control should rest with the
|
||
master server, not the slaves.</p>
|
||
<p>Note that enabling the update forwarding feature on a slave server
|
||
may expose master servers relying on insecure IP address based
|
||
access control to attacks; see <a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called “Dynamic Update Security”</a>
|
||
for more details.</p>
|
||
</dd>
|
||
<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
|
||
<dd><p>Only meaningful if <span><strong class="command">notify</strong></span> is
|
||
active for this zone. The set of machines that will receive a
|
||
<code class="literal">DNS NOTIFY</code> message
|
||
for this zone is made up of all the listed nameservers (other than
|
||
the primary master) for the zone plus any IP addresses specified
|
||
with <span><strong class="command">also-notify</strong></span>. A port may be specified
|
||
with each <span><strong class="command">also-notify</strong></span> address to send the notify
|
||
messages to a port other than the default of 53.
|
||
<span><strong class="command">also-notify</strong></span> is not meaningful for stub zones.
|
||
The default is the empty list.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
|
||
<dd><p>
|
||
This option was used in BIND 8 to restrict the character set of
|
||
domain names in master files and/or DNS responses received from the
|
||
network. BIND 9 does not restrict the character set of domain names
|
||
and does not implement the <span><strong class="command">check-names</strong></span> option.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">database</strong></span></span></dt>
|
||
<dd>
|
||
<p>Specify the type of database to be used for storing the
|
||
zone data. The string following the <span><strong class="command">database</strong></span> keyword
|
||
is interpreted as a list of whitespace-delimited words. The first word
|
||
identifies the database type, and any subsequent words are passed
|
||
as arguments to the database to be interpreted in a way specific
|
||
to the database type.</p>
|
||
<p>The default is <strong class="userinput"><code>"rbt"</code></strong>, BIND 9's native in-memory
|
||
red-black-tree database. This database does not take arguments.</p>
|
||
<p>Other values are possible if additional database drivers
|
||
have been linked into the server. Some sample drivers are included
|
||
with the distribution but none are linked in by default.</p>
|
||
</dd>
|
||
<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">dialup</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">delegation-only</strong></span></span></dt>
|
||
<dd><p>The flag only applies to hint and stub zones. If set
|
||
to <strong class="userinput"><code>yes</code></strong> then the zone will also be treated as if it
|
||
is also a delegation-only type zone.
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
|
||
<dd><p>Only meaningful if the zone has a forwarders
|
||
list. The <span><strong class="command">only</strong></span> value causes the lookup to fail
|
||
after trying the forwarders and getting no answer, while <span><strong class="command">first</strong></span> would
|
||
allow a normal lookup to be tried.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
|
||
<dd><p>Used to override the list of global forwarders.
|
||
If it is not specified in a zone of type <span><strong class="command">forward</strong></span>,
|
||
no forwarding is done for the zone; the global options are not used.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">ixfr-base</strong></span></span></dt>
|
||
<dd><p>Was used in <span class="acronym">BIND</span> 8 to specify the name
|
||
of the transaction log (journal) file for dynamic update and IXFR.
|
||
<span class="acronym">BIND</span> 9 ignores the option and constructs the name of the journal
|
||
file by appending "<code class="filename">.jnl</code>" to the name of the
|
||
zone file.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">ixfr-tmp-file</strong></span></span></dt>
|
||
<dd><p>Was an undocumented option in <span class="acronym">BIND</span> 8.
|
||
Ignored in <span class="acronym">BIND</span> 9.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">max-transfer-time-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">max-transfer-idle-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">max-transfer-time-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">max-transfer-idle-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">notify</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called “Boolean Options”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">pubkey</strong></span></span></dt>
|
||
<dd><p>In <span class="acronym">BIND</span> 8, this option was intended for specifying
|
||
a public zone key for verification of signatures in DNSSEC signed
|
||
zones when they are loaded from disk. <span class="acronym">BIND</span> 9 does not verify signatures
|
||
on loading and ignores the option.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
|
||
<dd><p>If <strong class="userinput"><code>yes</code></strong>, the server will keep statistical
|
||
information for this zone, which can be dumped to the
|
||
<span><strong class="command">statistics-file</strong></span> defined in the server options.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">sig-validity-interval</strong></span> in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called “Tuning”</a>.</p></dd>
|
||
<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">notify-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>
|
||
</p></dd>
|
||
<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
|
||
<dd><p>See the description of
|
||
<span><strong class="command">notify-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called “Zone Transfers”</a>.
|
||
</p></dd>
|
||
<dt>
|
||
<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
|
||
</dt>
|
||
<dd><p>
|
||
See the description in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called “Tuning”</a>.
|
||
</p></dd>
|
||
</dl></div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="dynamic_update_policies"></a>Dynamic Update Policies</h4></div></div></div>
|
||
<p><span class="acronym">BIND</span> 9 supports two alternative methods of granting clients
|
||
the right to perform dynamic updates to a zone,
|
||
configured by the <span><strong class="command">allow-update</strong></span> and
|
||
<span><strong class="command">update-policy</strong></span> option, respectively.</p>
|
||
<p>The <span><strong class="command">allow-update</strong></span> clause works the same
|
||
way as in previous versions of <span class="acronym">BIND</span>. It grants given clients the
|
||
permission to update any record of any name in the zone.</p>
|
||
<p>The <span><strong class="command">update-policy</strong></span> clause is new in <span class="acronym">BIND</span>
|
||
9 and allows more fine-grained control over what updates are allowed.
|
||
A set of rules is specified, where each rule either grants or denies
|
||
permissions for one or more names to be updated by one or more identities.
|
||
If the dynamic update request message is signed (that is, it includes
|
||
either a TSIG or SIG(0) record), the identity of the signer can
|
||
be determined.</p>
|
||
<p>Rules are specified in the <span><strong class="command">update-policy</strong></span> zone
|
||
option, and are only meaningful for master zones. When the <span><strong class="command">update-policy</strong></span> statement
|
||
is present, it is a configuration error for the <span><strong class="command">allow-update</strong></span> statement
|
||
to be present. The <span><strong class="command">update-policy</strong></span> statement only
|
||
examines the signer of a message; the source address is not relevant.</p>
|
||
<p>This is how a rule definition looks:</p>
|
||
<pre class="programlisting">
|
||
( <span><strong class="command">grant</strong></span> | <span><strong class="command">deny</strong></span> ) <em class="replaceable"><code>identity</code></em> <em class="replaceable"><code>nametype</code></em> <em class="replaceable"><code>name</code></em> [<span class="optional"> <em class="replaceable"><code>types</code></em> </span>]
|
||
</pre>
|
||
<p>Each rule grants or denies privileges. Once a message has
|
||
successfully matched a rule, the operation is immediately granted
|
||
or denied and no further rules are examined. A rule is matched
|
||
when the signer matches the identity field, the name matches the
|
||
name field, and the type is specified in the type field.</p>
|
||
<p>The identity field specifies a name or a wildcard name. The
|
||
nametype field has 4 values: <code class="varname">name</code>, <code class="varname">subdomain</code>, <code class="varname">wildcard</code>,
|
||
and <code class="varname">self</code>
|
||
</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><code class="varname">name</code></p></td>
|
||
<td><p>Matches when the updated name is the
|
||
same as the name in the name field.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">subdomain</code></p></td>
|
||
<td><p>Matches when the updated name is a subdomain
|
||
of the name in the name field (which includes the name itself).</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">wildcard</code></p></td>
|
||
<td><p>Matches when the updated name is a valid
|
||
expansion of the wildcard name in the name field.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="varname">self</code></p></td>
|
||
<td><p>Matches when the updated name is the
|
||
same as the message signer. The name field is ignored.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>If no types are specified, the rule matches all types except
|
||
SIG, NS, SOA, and NXT. Types may be specified by name, including
|
||
"ANY" (ANY matches all types except NXT, which can never be updated).
|
||
</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="sect1" lang="en">
|
||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||
<a name="id2562711"></a>Zone File</h2></div></div></div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div>
|
||
<p>This section, largely borrowed from RFC 1034, describes the
|
||
concept of a Resource Record (RR) and explains when each is used.
|
||
Since the publication of RFC 1034, several new RRs have been identified
|
||
and implemented in the DNS. These are also included.</p>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2562729"></a>Resource Records</h4></div></div></div>
|
||
<p>A domain name identifies a node. Each node has a set of
|
||
resource information, which may be empty. The set of resource
|
||
information associated with a particular name is composed of
|
||
separate RRs. The order of RRs in a set is not significant and
|
||
need not be preserved by nameservers, resolvers, or other
|
||
parts of the DNS. However, sorting of multiple RRs is
|
||
permitted for optimization purposes, for example, to specify
|
||
that a particular nearby server be tried first. See <a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called “The <span><strong class="command">sortlist</strong></span> Statement”</a> and <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called “RRset Ordering”</a>.</p>
|
||
<p>The components of a Resource Record are:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p>owner name</p></td>
|
||
<td><p>the domain name where the RR is found.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>type</p></td>
|
||
<td><p>an encoded 16 bit value that specifies
|
||
the type of the resource in this resource record. Types refer to
|
||
abstract resources.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>TTL</p></td>
|
||
<td><p>the time to live of the RR. This field
|
||
is a 32 bit integer in units of seconds, and is primarily used by
|
||
resolvers when they cache RRs. The TTL describes how long a RR can
|
||
be cached before it should be discarded.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>class</p></td>
|
||
<td><p>an encoded 16 bit value that identifies
|
||
a protocol family or instance of a protocol.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>RDATA</p></td>
|
||
<td><p>the type and sometimes class-dependent
|
||
data that describes the resource.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>The following are <span class="emphasis"><em>types</em></span> of valid RRs
|
||
(some of these listed, although not obsolete, are experimental (x)
|
||
or historical (h) and no longer in general use):</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p>A</p></td>
|
||
<td><p>a host address.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>A6</p></td>
|
||
<td><p>an IPv6 address.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>AAAA</p></td>
|
||
<td><p>Obsolete format of IPv6 address</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>AFSDB</p></td>
|
||
<td><p>(x) location of AFS database servers.
|
||
Experimental.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>CERT</p></td>
|
||
<td><p>holds a digital certificate.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>CNAME</p></td>
|
||
<td><p>identifies the canonical name of an alias.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>DNAME</p></td>
|
||
<td><p>for delegation of reverse addresses.
|
||
Replaces the domain name specified with another name to be looked
|
||
up. Described in RFC 2672.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>GPOS</p></td>
|
||
<td><p>Specifies the global position. Superseded by LOC.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>HINFO</p></td>
|
||
<td><p>identifies the CPU and OS used by a host.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>ISDN</p></td>
|
||
<td><p>(x) representation of ISDN addresses.
|
||
Experimental.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>KEY</p></td>
|
||
<td><p>stores a public key associated with a
|
||
DNS name.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>KX</p></td>
|
||
<td><p>identifies a key exchanger for this
|
||
DNS name.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>LOC</p></td>
|
||
<td><p>(x) for storing GPS info. See RFC 1876.
|
||
Experimental.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>MX</p></td>
|
||
<td><p>identifies a mail exchange for the domain.
|
||
See RFC 974 for details.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>NAPTR</p></td>
|
||
<td><p>name authority pointer.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>NSAP</p></td>
|
||
<td><p>a network service access point.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>NS</p></td>
|
||
<td><p>the authoritative nameserver for the
|
||
domain.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>NXT</p></td>
|
||
<td><p>used in DNSSEC to securely indicate that
|
||
RRs with an owner name in a certain name interval do not exist in
|
||
a zone and indicate what RR types are present for an existing name.
|
||
See RFC 2535 for details.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>PTR</p></td>
|
||
<td><p>a pointer to another part of the domain
|
||
name space.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>PX</p></td>
|
||
<td><p>provides mappings between RFC 822 and X.400
|
||
addresses.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>RP</p></td>
|
||
<td><p>(x) information on persons responsible
|
||
for the domain. Experimental.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>RT</p></td>
|
||
<td><p>(x) route-through binding for hosts that
|
||
do not have their own direct wide area network addresses. Experimental.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>SIG</p></td>
|
||
<td><p>("signature") contains data authenticated
|
||
in the secure DNS. See RFC 2535 for details.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>SOA</p></td>
|
||
<td><p>identifies the start of a zone of authority.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>SRV</p></td>
|
||
<td><p>information about well known network
|
||
services (replaces WKS).</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>TXT</p></td>
|
||
<td><p>text records.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>WKS</p></td>
|
||
<td><p>(h) information about which well known
|
||
network services, such as SMTP, that a domain supports. Historical,
|
||
replaced by newer RR SRV.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>X25</p></td>
|
||
<td><p>(x) representation of X.25 network addresses. Experimental.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>The following <span class="emphasis"><em>classes</em></span> of resource records
|
||
are currently valid in the DNS:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p>IN</p></td>
|
||
<td><p>the Internet system.</p></td>
|
||
</tr>
|
||
<tr><td colspan="2"><p>For information about other,
|
||
older classes of RRs, see <a href="Bv9ARM.ch09.html#classes_of_resource_records" title="Classes of Resource Records">the section called “Classes of Resource Records”</a>.</p></td></tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p><span class="emphasis"><em>RDATA</em></span> is the type-dependent or class-dependent
|
||
data that describes the resource:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p>A</p></td>
|
||
<td><p>for the IN class, a 32 bit IP address.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>A6</p></td>
|
||
<td><p>maps a domain name to an IPv6 address,
|
||
with a provision for indirection for leading "prefix" bits.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>CNAME</p></td>
|
||
<td><p>a domain name.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>DNAME</p></td>
|
||
<td><p>provides alternate naming to an entire
|
||
subtree of the domain name space, rather than to a single node.
|
||
It causes some suffix of a queried name to be substituted with
|
||
a name from the DNAME record's RDATA.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>MX</p></td>
|
||
<td><p>a 16 bit preference value (lower is better)
|
||
followed by a host name willing to act as a mail exchange for the
|
||
owner domain.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>NS</p></td>
|
||
<td><p>a fully qualified domain name.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>PTR</p></td>
|
||
<td><p>a fully qualified domain name.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>SOA</p></td>
|
||
<td><p>several fields.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>The owner name is often implicit, rather than forming an integral
|
||
part of the RR. For example, many nameservers internally form tree
|
||
or hash structures for the name space, and chain RRs off nodes.
|
||
The remaining RR parts are the fixed header (type, class, TTL)
|
||
which is consistent for all RRs, and a variable part (RDATA) that
|
||
fits the needs of the resource being described.</p>
|
||
<p>The meaning of the TTL field is a time limit on how long an
|
||
RR can be kept in a cache. This limit does not apply to authoritative
|
||
data in zones; it is also timed out, but by the refreshing policies
|
||
for the zone. The TTL is assigned by the administrator for the
|
||
zone where the data originates. While short TTLs can be used to
|
||
minimize caching, and a zero TTL prohibits caching, the realities
|
||
of Internet performance suggest that these times should be on the
|
||
order of days for the typical host. If a change can be anticipated,
|
||
the TTL can be reduced prior to the change to minimize inconsistency
|
||
during the change, and then increased back to its former value following
|
||
the change.</p>
|
||
<p>The data in the RDATA section of RRs is carried as a combination
|
||
of binary strings and domain names. The domain names are frequently
|
||
used as "pointers" to other data in the DNS.</p>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2563878"></a>Textual expression of RRs</h4></div></div></div>
|
||
<p>RRs are represented in binary form in the packets of the DNS
|
||
protocol, and are usually represented in highly encoded form when
|
||
stored in a nameserver or resolver. In the examples provided in
|
||
RFC 1034, a style similar to that used in master files was employed
|
||
in order to show the contents of RRs. In this format, most RRs
|
||
are shown on a single line, although continuation lines are possible
|
||
using parentheses.</p>
|
||
<p>The start of the line gives the owner of the RR. If a line
|
||
begins with a blank, then the owner is assumed to be the same as
|
||
that of the previous RR. Blank lines are often included for readability.</p>
|
||
<p>Following the owner, we list the TTL, type, and class of the
|
||
RR. Class and type use the mnemonics defined above, and TTL is
|
||
an integer before the type field. In order to avoid ambiguity in
|
||
parsing, type and class mnemonics are disjoint, TTLs are integers,
|
||
and the type mnemonic is always last. The IN class and TTL values
|
||
are often omitted from examples in the interests of clarity.</p>
|
||
<p>The resource data or RDATA section of the RR are given using
|
||
knowledge of the typical representation for the data.</p>
|
||
<p>For example, we might show the RRs carried in a message as:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><code class="literal">ISI.EDU.</code></p></td>
|
||
<td><p><code class="literal">MX</code></p></td>
|
||
<td><p><code class="literal">10 VENERA.ISI.EDU.</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p></p></td>
|
||
<td><p><code class="literal">MX</code></p></td>
|
||
<td><p><code class="literal">10 VAXA.ISI.EDU</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="literal">VENERA.ISI.EDU</code></p></td>
|
||
<td><p><code class="literal">A</code></p></td>
|
||
<td><p><code class="literal">128.9.0.32</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p></p></td>
|
||
<td><p><code class="literal">A</code></p></td>
|
||
<td><p><code class="literal">10.1.0.52</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="literal">VAXA.ISI.EDU</code></p></td>
|
||
<td><p><code class="literal">A</code></p></td>
|
||
<td><p><code class="literal">10.2.0.27</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p></p></td>
|
||
<td><p><code class="literal">A</code></p></td>
|
||
<td><p><code class="literal">128.9.0.33</code></p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>The MX RRs have an RDATA section which consists of a 16 bit
|
||
number followed by a domain name. The address RRs use a standard
|
||
IP address format to contain a 32 bit internet address.</p>
|
||
<p>This example shows six RRs, with two RRs at each of three
|
||
domain names.</p>
|
||
<p>Similarly we might see:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><code class="literal">XX.LCS.MIT.EDU. IN</code></p></td>
|
||
<td><p><code class="literal">A</code></p></td>
|
||
<td><p><code class="literal">10.0.0.44</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="literal">CH</code></p></td>
|
||
<td><p><code class="literal">A</code></p></td>
|
||
<td><p><code class="literal">MIT.EDU. 2420</code></p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>This example shows two addresses for <code class="literal">XX.LCS.MIT.EDU</code>,
|
||
each of a different class.</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2564235"></a>Discussion of MX Records</h3></div></div></div>
|
||
<p>As described above, domain servers store information as a
|
||
series of resource records, each of which contains a particular
|
||
piece of information about a given domain name (which is usually,
|
||
but not always, a host). The simplest way to think of a RR is as
|
||
a typed pair of data, a domain name matched with a relevant datum,
|
||
and stored with some additional type information to help systems
|
||
determine when the RR is relevant.</p>
|
||
<p>MX records are used to control delivery of email. The data
|
||
specified in the record is a priority and a domain name. The priority
|
||
controls the order in which email delivery is attempted, with the
|
||
lowest number first. If two priorities are the same, a server is
|
||
chosen randomly. If no servers at a given priority are responding,
|
||
the mail transport agent will fall back to the next largest priority.
|
||
Priority numbers do not have any absolute meaning — they are relevant
|
||
only respective to other MX records for that domain name. The domain
|
||
name given is the machine to which the mail will be delivered. It <span class="emphasis"><em>must</em></span> have
|
||
an associated A record — CNAME is not sufficient.</p>
|
||
<p>For a given domain, if there is both a CNAME record and an
|
||
MX record, the MX record is in error, and will be ignored. Instead,
|
||
the mail will be delivered to the server specified in the MX record
|
||
pointed to by the CNAME.</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
<col>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><code class="literal">example.com.</code></p></td>
|
||
<td><p><code class="literal">IN</code></p></td>
|
||
<td><p><code class="literal">MX</code></p></td>
|
||
<td><p><code class="literal">10</code></p></td>
|
||
<td><p><code class="literal">mail.example.com.</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p></p></td>
|
||
<td><p><code class="literal">IN</code></p></td>
|
||
<td><p><code class="literal">MX</code></p></td>
|
||
<td><p><code class="literal">10</code></p></td>
|
||
<td><p><code class="literal">mail2.example.com.</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p></p></td>
|
||
<td><p><code class="literal">IN</code></p></td>
|
||
<td><p><code class="literal">MX</code></p></td>
|
||
<td><p><code class="literal">20</code></p></td>
|
||
<td><p><code class="literal">mail.backup.org.</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="literal">mail.example.com.</code></p></td>
|
||
<td><p><code class="literal">IN</code></p></td>
|
||
<td><p><code class="literal">A</code></p></td>
|
||
<td><p><code class="literal">10.0.0.1</code></p></td>
|
||
<td><p></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="literal">mail2.example.com.</code></p></td>
|
||
<td><p><code class="literal">IN</code></p></td>
|
||
<td><p><code class="literal">A</code></p></td>
|
||
<td><p><code class="literal">10.0.0.2</code></p></td>
|
||
<td><p></p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>For example:</p>
|
||
<p>Mail delivery will be attempted to <code class="literal">mail.example.com</code> and
|
||
<code class="literal">mail2.example.com</code> (in
|
||
any order), and if neither of those succeed, delivery to <code class="literal">mail.backup.org</code> will
|
||
be attempted.</p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="Setting_TTLs"></a>Setting TTLs</h3></div></div></div>
|
||
<p>The time to live of the RR field is a 32 bit integer represented
|
||
in units of seconds, and is primarily used by resolvers when they
|
||
cache RRs. The TTL describes how long a RR can be cached before it
|
||
should be discarded. The following three types of TTL are currently
|
||
used in a zone file.</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p>SOA</p></td>
|
||
<td>
|
||
<p>The last field in the SOA is the negative
|
||
caching TTL. This controls how long other servers will cache no-such-domain
|
||
(NXDOMAIN) responses from you.</p>
|
||
<p>The maximum time for
|
||
negative caching is 3 hours (3h).</p>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>$TTL</p></td>
|
||
<td><p>The $TTL directive at the top of the
|
||
zone file (before the SOA) gives a default TTL for every RR without
|
||
a specific TTL set.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p>RR TTLs</p></td>
|
||
<td><p>Each RR can have a TTL as the second
|
||
field in the RR, which will control how long other servers can cache
|
||
the it.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>All of these TTLs default to units of seconds, though units
|
||
can be explicitly specified, for example, <code class="literal">1h30m</code>. </p>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2564801"></a>Inverse Mapping in IPv4</h3></div></div></div>
|
||
<p>Reverse name resolution (that is, translation from IP address
|
||
to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> domain
|
||
and PTR records. Entries in the in-addr.arpa domain are made in
|
||
least-to-most significant order, read left to right. This is the
|
||
opposite order to the way IP addresses are usually written. Thus,
|
||
a machine with an IP address of 10.1.2.3 would have a corresponding
|
||
in-addr.arpa name of
|
||
3.2.1.10.in-addr.arpa. This name should have a PTR resource record
|
||
whose data field is the name of the machine or, optionally, multiple
|
||
PTR records if the machine has more than one name. For example,
|
||
in the [<span class="optional">example.com</span>] domain:</p>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><code class="literal">$ORIGIN</code></p></td>
|
||
<td><p><code class="literal">2.1.10.in-addr.arpa</code></p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><code class="literal">3</code></p></td>
|
||
<td><p><code class="literal">IN PTR foo.example.com.</code></p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>The <span><strong class="command">$ORIGIN</strong></span> lines in the examples
|
||
are for providing context to the examples only-they do not necessarily
|
||
appear in the actual usage. They are only used here to indicate
|
||
that the example is relative to the listed origin.</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2564906"></a>Other Zone File Directives</h3></div></div></div>
|
||
<p>The Master File Format was initially defined in RFC 1035 and
|
||
has subsequently been extended. While the Master File Format itself
|
||
is class independent all records in a Master File must be of the same
|
||
class.</p>
|
||
<p>Master File Directives include <span><strong class="command">$ORIGIN</strong></span>, <span><strong class="command">$INCLUDE</strong></span>,
|
||
and <span><strong class="command">$TTL.</strong></span></p>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2564925"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
|
||
<p>Syntax: <span><strong class="command">$ORIGIN
|
||
</strong></span><em class="replaceable"><code>domain-name</code></em> [<span class="optional"> <em class="replaceable"><code>comment</code></em></span>]</p>
|
||
<p><span><strong class="command">$ORIGIN</strong></span> sets the domain name that will
|
||
be appended to any unqualified records. When a zone is first read
|
||
in there is an implicit <span><strong class="command">$ORIGIN</strong></span> <<code class="varname">zone-name</code>><span><strong class="command">.</strong></span> The
|
||
current <span><strong class="command">$ORIGIN</strong></span> is appended to the domain specified
|
||
in the <span><strong class="command">$ORIGIN</strong></span> argument if it is not absolute.</p>
|
||
<pre class="programlisting">$ORIGIN example.com.
|
||
WWW CNAME MAIN-SERVER</pre>
|
||
<p>is equivalent to</p>
|
||
<pre class="programlisting">WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</pre>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2564981"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
|
||
<p>Syntax: <span><strong class="command">$INCLUDE</strong></span>
|
||
<em class="replaceable"><code>filename</code></em> [<span class="optional">
|
||
<em class="replaceable"><code>origin</code></em> </span>] [<span class="optional"> <em class="replaceable"><code>comment</code></em> </span>]</p>
|
||
<p>Read and process the file <code class="filename">filename</code> as
|
||
if it were included into the file at this point. If <span><strong class="command">origin</strong></span> is
|
||
specified the file is processed with <span><strong class="command">$ORIGIN</strong></span> set
|
||
to that value, otherwise the current <span><strong class="command">$ORIGIN</strong></span> is
|
||
used.</p>
|
||
<p>The origin and the current domain name
|
||
revert to the values they had prior to the <span><strong class="command">$INCLUDE</strong></span> once
|
||
the file has been read.</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>
|
||
RFC 1035 specifies that the current origin should be restored after
|
||
an <span><strong class="command">$INCLUDE</strong></span>, but it is silent on whether the current
|
||
domain name should also be restored. BIND 9 restores both of them.
|
||
This could be construed as a deviation from RFC 1035, a feature, or both.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect3" lang="en">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="id2565044"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
|
||
<p>Syntax: <span><strong class="command">$TTL</strong></span>
|
||
<em class="replaceable"><code>default-ttl</code></em> [<span class="optional">
|
||
<em class="replaceable"><code>comment</code></em> </span>]</p>
|
||
<p>Set the default Time To Live (TTL) for subsequent records
|
||
with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.</p>
|
||
<p><span><strong class="command">$TTL</strong></span> is defined in RFC 2308.</p>
|
||
</div>
|
||
</div>
|
||
<div class="sect2" lang="en">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="id2565075"></a><span class="acronym">BIND</span> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
|
||
<p>Syntax: <span><strong class="command">$GENERATE</strong></span> <em class="replaceable"><code>range</code></em> <em class="replaceable"><code>lhs</code></em> <em class="replaceable"><code>type</code></em> <em class="replaceable"><code>rhs</code></em> [<span class="optional"> <em class="replaceable"><code>comment</code></em> </span>]</p>
|
||
<p><span><strong class="command">$GENERATE</strong></span> is used to create a series of
|
||
resource records that only differ from each other by an iterator. <span><strong class="command">$GENERATE</strong></span> can
|
||
be used to easily generate the sets of records required to support
|
||
sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA
|
||
delegation.</p>
|
||
<pre class="programlisting">$ORIGIN 0.0.192.IN-ADDR.ARPA.
|
||
$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
|
||
$GENERATE 1-127 $ CNAME $.0</pre>
|
||
<p>is equivalent to</p>
|
||
<pre class="programlisting">0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
|
||
0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
|
||
1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
|
||
2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
|
||
...
|
||
127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
|
||
</pre>
|
||
<div class="informaltable"><table border="1">
|
||
<colgroup>
|
||
<col>
|
||
<col>
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td><p><span><strong class="command">range</strong></span></p></td>
|
||
<td><p>This can be one of two forms: start-stop
|
||
or start-stop/step. If the first form is used then step is set to
|
||
1. All of start, stop and step must be positive.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">lhs</strong></span></p></td>
|
||
<td>
|
||
<p><span><strong class="command">lhs</strong></span> describes the
|
||
owner name of the resource records to be created. Any single <span><strong class="command">$</strong></span> symbols
|
||
within the <span><strong class="command">lhs</strong></span> side are replaced by the iterator
|
||
value.
|
||
To get a $ in the output you need to escape the <span><strong class="command">$</strong></span>
|
||
using a backslash <span><strong class="command">\</strong></span>,
|
||
e.g. <span><strong class="command">\$</strong></span>. The <span><strong class="command">$</strong></span> may optionally be followed
|
||
by modifiers which change the offset from the interator, field width and base.
|
||
Modifiers are introduced by a <span><strong class="command">{</strong></span> immediately following the
|
||
<span><strong class="command">$</strong></span> as <span><strong class="command">${offset[,width[,base]]}</strong></span>.
|
||
e.g. <span><strong class="command">${-20,3,d}</strong></span> which subtracts 20 from the current value,
|
||
prints the result as a decimal in a zero padded field of with 3. Available
|
||
output forms are decimal (<span><strong class="command">d</strong></span>), octal (<span><strong class="command">o</strong></span>)
|
||
and hexadecimal (<span><strong class="command">x</strong></span> or <span><strong class="command">X</strong></span> for uppercase).
|
||
The default modifier is <span><strong class="command">${0,0,d}</strong></span>.
|
||
If the <span><strong class="command">lhs</strong></span> is not
|
||
absolute, the current <span><strong class="command">$ORIGIN</strong></span> is appended to
|
||
the name.</p>
|
||
<p>For compatibility with earlier versions <span><strong class="command">$$</strong></span> is still
|
||
recognised a indicating a literal $ in the output.</p>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">type</strong></span></p></td>
|
||
<td><p>At present the only supported types are
|
||
PTR, CNAME, DNAME, A, AAAA and NS.</p></td>
|
||
</tr>
|
||
<tr>
|
||
<td><p><span><strong class="command">rhs</strong></span></p></td>
|
||
<td><p>rhs is a domain name. It is processed
|
||
similarly to lhs.</p></td>
|
||
</tr>
|
||
</tbody>
|
||
</table></div>
|
||
<p>The <span><strong class="command">$GENERATE</strong></span> directive is a <span class="acronym">BIND</span> extension
|
||
and not part of the standard zone file format.</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr>
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left">
|
||
<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
|
||
<td width="20%" align="center"> </td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver </td>
|
||
<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
|
||
<td width="40%" align="right" valign="top"> Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|