17122 lines
581 KiB
XML
17122 lines
581 KiB
XML
<!--
|
|
- Copyright (C) Internet Systems Consortium, Inc. ("ISC")
|
|
-
|
|
- This Source Code Form is subject to the terms of the Mozilla Public
|
|
- License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
- file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
-
|
|
- See the COPYRIGHT file distributed with this work for additional
|
|
- information regarding copyright ownership.
|
|
-->
|
|
|
|
<!-- Converted by db4-upgrade version 1.0 -->
|
|
<book xmlns:db="http://docbook.org/ns/docbook" version="5.0">
|
|
<info>
|
|
<title>BIND 9 Administrator Reference Manual</title>
|
|
<!-- insert copyright start -->
|
|
<copyright>
|
|
<year>2000</year>
|
|
<year>2001</year>
|
|
<year>2002</year>
|
|
<year>2003</year>
|
|
<year>2004</year>
|
|
<year>2005</year>
|
|
<year>2006</year>
|
|
<year>2007</year>
|
|
<year>2008</year>
|
|
<year>2009</year>
|
|
<year>2010</year>
|
|
<year>2011</year>
|
|
<year>2012</year>
|
|
<year>2013</year>
|
|
<year>2014</year>
|
|
<year>2015</year>
|
|
<year>2016</year>
|
|
<year>2017</year>
|
|
<year>2018</year>
|
|
<year>2019</year>
|
|
<year>2020</year>
|
|
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
|
|
</copyright>
|
|
<!-- insert copyright end -->
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="releaseinfo.xml"/>
|
|
</info>
|
|
|
|
<chapter xml:id="Bv9ARM.ch01"><info><title>Introduction</title></info>
|
|
|
|
<para>
|
|
The Internet Domain Name System (<acronym>DNS</acronym>)
|
|
consists of the syntax
|
|
to specify the names of entities in the Internet in a hierarchical
|
|
manner, the rules used for delegating authority over names, and the
|
|
system implementation that actually maps names to Internet
|
|
addresses. <acronym>DNS</acronym> data is maintained in a
|
|
group of distributed
|
|
hierarchical databases.
|
|
</para>
|
|
|
|
<section xml:id="doc_scope"><info><title>Scope of Document</title></info>
|
|
|
|
<para>
|
|
The Berkeley Internet Name Domain
|
|
(<acronym>BIND</acronym>) implements a
|
|
domain name server for a number of operating systems. This
|
|
document provides basic information about the installation and
|
|
care of the Internet Systems Consortium (<acronym>ISC</acronym>)
|
|
<acronym>BIND</acronym> version 9 software package for
|
|
system administrators.
|
|
</para>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="pkgversion.xml"/>
|
|
</section>
|
|
|
|
<section xml:id="organization"><info><title>Organization of This Document</title></info>
|
|
|
|
<para>
|
|
In this document, <emphasis>Chapter 1</emphasis> introduces
|
|
the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Chapter 2</emphasis>
|
|
describes resource requirements for running <acronym>BIND</acronym> in various
|
|
environments. Information in <emphasis>Chapter 3</emphasis> is
|
|
<emphasis>task-oriented</emphasis> in its presentation and is
|
|
organized functionally, to aid in the process of installing the
|
|
<acronym>BIND</acronym> 9 software. The task-oriented
|
|
section is followed by
|
|
<emphasis>Chapter 4</emphasis>, which contains more advanced
|
|
concepts that the system administrator may need for implementing
|
|
certain options. <emphasis>Chapter 5</emphasis>
|
|
describes the <acronym>BIND</acronym> 9 lightweight
|
|
resolver. The contents of <emphasis>Chapter 6</emphasis> are
|
|
organized as in a reference manual to aid in the ongoing
|
|
maintenance of the software. <emphasis>Chapter 7</emphasis> addresses
|
|
security considerations, and
|
|
<emphasis>Chapter 8</emphasis> contains troubleshooting help. The
|
|
main body of the document is followed by several
|
|
<emphasis>appendices</emphasis> which contain useful reference
|
|
information, such as a <emphasis>bibliography</emphasis> and
|
|
historic information related to <acronym>BIND</acronym>
|
|
and the Domain Name
|
|
System.
|
|
</para>
|
|
</section>
|
|
<section xml:id="conventions"><info><title>Conventions Used in This Document</title></info>
|
|
|
|
<para>
|
|
In this document, we use the following general typographic
|
|
conventions:
|
|
</para>
|
|
|
|
<informaltable>
|
|
<tgroup cols="2">
|
|
<colspec colname="1" colnum="1" colwidth="3.000in"/>
|
|
<colspec colname="2" colnum="2" colwidth="2.625in"/>
|
|
<tbody>
|
|
<row>
|
|
<entry colname="1">
|
|
<para>
|
|
<emphasis>To describe:</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<emphasis>We use the style:</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry colname="1">
|
|
<para>
|
|
a pathname, filename, URL, hostname,
|
|
mailing list name, or new term or concept
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<filename>Fixed width</filename>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry colname="1">
|
|
<para>
|
|
literal user
|
|
input
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<userinput>Fixed Width Bold</userinput>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry colname="1">
|
|
<para>
|
|
program output
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<computeroutput>Fixed Width</computeroutput>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>
|
|
The following conventions are used in descriptions of the
|
|
<acronym>BIND</acronym> configuration file:<informaltable colsep="0" frame="all" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="3.000in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="2.625in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1" colsep="1" rowsep="1">
|
|
<para>
|
|
<emphasis>To describe:</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2" rowsep="1">
|
|
<para>
|
|
<emphasis>We use the style:</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1" colsep="1" rowsep="1">
|
|
<para>
|
|
keywords
|
|
</para>
|
|
</entry>
|
|
<entry colname="2" rowsep="1">
|
|
<para>
|
|
<literal>Fixed Width</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1" colsep="1" rowsep="1">
|
|
<para>
|
|
variables
|
|
</para>
|
|
</entry>
|
|
<entry colname="2" rowsep="1">
|
|
<para>
|
|
<varname>Fixed Width</varname>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1" colsep="1">
|
|
<para>
|
|
Optional input
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<optional>Text is enclosed in square brackets</optional>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</para>
|
|
</section>
|
|
<section xml:id="dns_overview"><info><title>The Domain Name System (<acronym>DNS</acronym>)</title></info>
|
|
|
|
<para>
|
|
This document explains the installation
|
|
and upkeep of the <acronym>BIND</acronym> (Berkeley Internet
|
|
Name Domain) software package. We
|
|
begin by reviewing the fundamentals of the Domain Name System
|
|
(<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>.
|
|
</para>
|
|
|
|
<section xml:id="dns_fundamentals"><info><title>DNS Fundamentals</title></info>
|
|
|
|
<para>
|
|
The Domain Name System (DNS) is a hierarchical, distributed
|
|
database. It stores information for mapping Internet host names to
|
|
IP
|
|
addresses and vice versa, mail routing information, and other data
|
|
used by Internet applications.
|
|
</para>
|
|
|
|
<para>
|
|
Clients look up information in the DNS by calling a
|
|
<emphasis>resolver</emphasis> library, which sends queries to one or
|
|
more <emphasis>name servers</emphasis> and interprets the responses.
|
|
The <acronym>BIND</acronym> 9 software distribution
|
|
contains a name server, <command>named</command>, and a
|
|
resolver library, <command>liblwres</command>.
|
|
</para>
|
|
|
|
</section>
|
|
<section xml:id="domain_names"><info><title>Domains and Domain Names</title></info>
|
|
|
|
<para>
|
|
The data stored in the DNS is identified by <emphasis>domain names</emphasis> that are organized as a tree according to
|
|
organizational or administrative boundaries. Each node of the tree,
|
|
called a <emphasis>domain</emphasis>, is given a label. The domain
|
|
name of the
|
|
node is the concatenation of all the labels on the path from the
|
|
node to the <emphasis>root</emphasis> node. This is represented
|
|
in written form as a string of labels listed from right to left and
|
|
separated by dots. A label need only be unique within its parent
|
|
domain.
|
|
</para>
|
|
|
|
<para>
|
|
For example, a domain name for a host at the
|
|
company <emphasis>Example, Inc.</emphasis> could be
|
|
<literal>ourhost.example.com</literal>,
|
|
where <literal>com</literal> is the
|
|
top level domain to which
|
|
<literal>ourhost.example.com</literal> belongs,
|
|
<literal>example</literal> is
|
|
a subdomain of <literal>com</literal>, and
|
|
<literal>ourhost</literal> is the
|
|
name of the host.
|
|
</para>
|
|
|
|
<para>
|
|
For administrative purposes, the name space is partitioned into
|
|
areas called <emphasis>zones</emphasis>, each starting at a node and
|
|
extending down to the "leaf" nodes or to nodes where other zones
|
|
start.
|
|
The data for each zone is stored in a <emphasis>name server</emphasis>, which answers queries about the zone using the
|
|
<emphasis>DNS protocol</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
The data associated with each domain name is stored in the
|
|
form of <emphasis>resource records</emphasis> (<acronym>RR</acronym>s).
|
|
Some of the supported resource record types are described in
|
|
<xref linkend="types_of_resource_records_and_when_to_use_them"/>.
|
|
</para>
|
|
|
|
<para>
|
|
For more detailed information about the design of the DNS and
|
|
the DNS protocol, please refer to the standards documents listed in
|
|
<xref linkend="rfcs"/>.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="zones"><info><title>Zones</title></info>
|
|
|
|
<para>
|
|
To properly operate a name server, it is important to understand
|
|
the difference between a <emphasis>zone</emphasis>
|
|
and a <emphasis>domain</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
As stated previously, a zone is a point of delegation in
|
|
the <acronym>DNS</acronym> tree. A zone consists of
|
|
those contiguous parts of the domain
|
|
tree for which a name server has complete information and over which
|
|
it has authority. It contains all domain names from a certain point
|
|
downward in the domain tree except those which are delegated to
|
|
other zones. A delegation point is marked by one or more
|
|
<emphasis>NS records</emphasis> in the
|
|
parent zone, which should be matched by equivalent NS records at
|
|
the root of the delegated zone.
|
|
</para>
|
|
|
|
<para>
|
|
For instance, consider the <literal>example.com</literal>
|
|
domain which includes names
|
|
such as <literal>host.aaa.example.com</literal> and
|
|
<literal>host.bbb.example.com</literal> even though
|
|
the <literal>example.com</literal> zone includes
|
|
only delegations for the <literal>aaa.example.com</literal> and
|
|
<literal>bbb.example.com</literal> zones. A zone can
|
|
map
|
|
exactly to a single domain, but could also include only part of a
|
|
domain, the rest of which could be delegated to other
|
|
name servers. Every name in the <acronym>DNS</acronym>
|
|
tree is a
|
|
<emphasis>domain</emphasis>, even if it is
|
|
<emphasis>terminal</emphasis>, that is, has no
|
|
<emphasis>subdomains</emphasis>. Every subdomain is a domain and
|
|
every domain except the root is also a subdomain. The terminology is
|
|
not intuitive and we suggest reading RFCs 1033, 1034, and 1035
|
|
to
|
|
gain a complete understanding of this difficult and subtle
|
|
topic.
|
|
</para>
|
|
|
|
<para>
|
|
Though <acronym>BIND</acronym> is called a "domain name
|
|
server",
|
|
it deals primarily in terms of zones. The "primary" and "secondary"
|
|
declarations in the <filename>named.conf</filename> file
|
|
specify
|
|
zones, not domains. When BIND asks some other site if it is willing to
|
|
be a secondary server for a <emphasis>domain</emphasis>, it is
|
|
actually asking for secondary service for some collection of <emphasis>zones</emphasis>.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="auth_servers"><info><title>Authoritative Name Servers</title></info>
|
|
|
|
<para>
|
|
Each zone is served by at least
|
|
one <emphasis>authoritative name server</emphasis>,
|
|
which contains the complete data for the zone.
|
|
To make the DNS tolerant of server and network failures,
|
|
most zones have two or more authoritative servers, on
|
|
different networks.
|
|
</para>
|
|
|
|
<para>
|
|
Responses from authoritative servers have the "authoritative
|
|
answer" (AA) bit set in the response packets. This makes them
|
|
easy to identify when debugging DNS configurations using tools like
|
|
<command>dig</command> (<xref linkend="diagnostic_tools"/>).
|
|
</para>
|
|
|
|
<section xml:id="primary_master"><info><title>The Primary Server</title></info>
|
|
|
|
<para>
|
|
The authoritative server where the main copy of the zone
|
|
data is maintained is called the
|
|
<emphasis>primary</emphasis> (or
|
|
<command>master</command>) server, or simply the
|
|
<emphasis>primary</emphasis>. Typically it loads the zone
|
|
contents from some local file edited by humans or perhaps
|
|
generated mechanically from some other local file which is
|
|
edited by humans. This file is called the
|
|
<emphasis>zone file</emphasis> or
|
|
<emphasis>master file</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
In some cases, however, the zone file may not be edited
|
|
by humans at all, but may instead be the result of
|
|
<emphasis>dynamic update</emphasis> operations.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="slave_server"><info><title>Secondary Servers</title></info>
|
|
|
|
<para>
|
|
The other authoritative servers, called the
|
|
<emphasis>secondary</emphasis>
|
|
(or <command>slave</command>) servers, load the zone
|
|
contents from another server using a replication
|
|
process known as a <emphasis>zone transfer</emphasis>.
|
|
Typically the data is transferred directly from the primary
|
|
master, but it is also possible to transfer it from another
|
|
secondary. In other words, a secondary server may itself act as a
|
|
primary to a subordinate secondary server.
|
|
</para>
|
|
<para>
|
|
Periodically, the secondary server must send a refresh query to
|
|
determine whether the zone contents have been updated. This
|
|
is done by sending a query for the zone's Start of Authority (SOA) record and
|
|
checking whether the SERIAL field has been updated; if so,
|
|
a new transfer request is initiated. The timing of these
|
|
refresh queries is controlled by the SOA REFRESH and RETRY
|
|
fields, but can be overridden with the
|
|
<command>max-refresh-time</command>,
|
|
<command>min-refresh-time</command>,
|
|
<command>max-retry-time</command>, and
|
|
<command>min-retry-time</command> options.
|
|
</para>
|
|
<para>
|
|
If the zone data cannot be updated within the time specified
|
|
by the SOA EXPIRE option (up to a hard-coded maximum of
|
|
24 weeks), the secondary zone expires and no longer
|
|
responds to queries.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="stealth_server"><info><title>Stealth Servers</title></info>
|
|
|
|
<para>
|
|
Usually, all of the zone's authoritative servers are listed in
|
|
NS records in the parent zone. These NS records constitute
|
|
a <emphasis>delegation</emphasis> of the zone from the parent.
|
|
The authoritative servers are also listed in the zone file itself,
|
|
at the <emphasis>top level</emphasis> or <emphasis>apex</emphasis>
|
|
of the zone. Servers that are not in the parent's NS delegation can be listed in the zone's top-level NS
|
|
records, but servers that are not present at
|
|
the zone's top level cannot be listed in the parent's delegation.
|
|
</para>
|
|
|
|
<para>
|
|
A <emphasis>stealth server</emphasis> is a server that is
|
|
authoritative for a zone but is not listed in that zone's NS
|
|
records. Stealth servers can be used for keeping a local copy of
|
|
a
|
|
zone, to speed up access to the zone's records, or to make sure that
|
|
the
|
|
zone is available even if all the "official" servers for the zone
|
|
are
|
|
inaccessible.
|
|
</para>
|
|
|
|
<para>
|
|
A configuration where the primary server itself is a
|
|
stealth server is often referred to as a "hidden primary"
|
|
configuration. One use for this configuration is when the primary
|
|
is behind a firewall and is therefore unable to communicate directly
|
|
with the outside world.
|
|
</para>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
<section xml:id="cache_servers"><info><title>Caching Name Servers</title></info>
|
|
|
|
<!--
|
|
- Terminology here is inconsistent. Probably ought to
|
|
- convert to using "recursive name server" everywhere
|
|
- with just a note about "caching" terminology.
|
|
-->
|
|
|
|
<para>
|
|
The resolver libraries provided by most operating systems are
|
|
<emphasis>stub resolvers</emphasis>, meaning that they are not
|
|
capable of
|
|
performing the full DNS resolution process by themselves by talking
|
|
directly to the authoritative servers. Instead, they rely on a
|
|
local
|
|
name server to perform the resolution on their behalf. Such a
|
|
server
|
|
is called a <emphasis>recursive</emphasis> name server; it performs
|
|
<emphasis>recursive lookups</emphasis> for local clients.
|
|
</para>
|
|
|
|
<para>
|
|
To improve performance, recursive servers cache the results of
|
|
the lookups they perform. Since the processes of recursion and
|
|
caching are intimately connected, the terms
|
|
<emphasis>recursive server</emphasis> and
|
|
<emphasis>caching server</emphasis> are often used synonymously.
|
|
</para>
|
|
|
|
<para>
|
|
The length of time for which a record may be retained in
|
|
the cache of a caching name server is controlled by the
|
|
Time-To-Live (TTL) field associated with each resource record.
|
|
</para>
|
|
|
|
<section xml:id="forwarder"><info><title>Forwarding</title></info>
|
|
|
|
<para>
|
|
Even a caching name server does not necessarily perform
|
|
the complete recursive lookup itself. Instead, it can
|
|
<emphasis>forward</emphasis> some or all of the queries
|
|
that it cannot satisfy from its cache to another caching name
|
|
server,
|
|
commonly referred to as a <emphasis>forwarder</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
Forwarders are typically used when an administrator does not
|
|
wish for all the servers at a given site to interact
|
|
directly with the rest of the Internet. For example, a
|
|
common scenario is when multiple internal DNS servers are
|
|
behind an Internet firewall. Servers behind the firewall
|
|
forward their requests to the server with external access,
|
|
which queries Internet DNS servers on the internal servers'
|
|
behalf.
|
|
</para>
|
|
|
|
<para>
|
|
Another scenario (largely now superseded by Response Policy
|
|
Zones) is to send queries first to a custom server for RBL
|
|
processing before forwarding them to the wider Internet.
|
|
</para>
|
|
|
|
<para>
|
|
There may be one or more forwarders in a given setup. The
|
|
order in which the forwarders are listed in
|
|
<filename>named.conf</filename> does not determine the
|
|
sequence in which they are queried; rather,
|
|
<command>named</command> uses the response times from
|
|
previous queries to select the server that is likely to
|
|
respond the most quickly. A server that has not yet been
|
|
queried is given an initial small random response time to
|
|
ensure that it is tried at least once. Dynamic adjustment of
|
|
the recorded response times ensures that all forwarders are
|
|
queried, even those with slower response times. This
|
|
permits changes in behavior based on server responsiveness.
|
|
</para>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section xml:id="multi_role"><info><title>Name Servers in Multiple Roles</title></info>
|
|
|
|
<para>
|
|
The <acronym>BIND</acronym> name server can
|
|
simultaneously act as
|
|
a primary for some zones, a secondary for other zones, and a caching
|
|
(recursive) server for a set of local clients.
|
|
</para>
|
|
|
|
<para>
|
|
However, since the functions of authoritative name service
|
|
and caching/recursive name service are logically separate, it is
|
|
often advantageous to run them on separate server machines.
|
|
|
|
A server that only provides authoritative name service
|
|
(an <emphasis>authoritative-only</emphasis> server) can run with
|
|
recursion disabled, improving reliability and security.
|
|
|
|
A server that is not authoritative for any zones and only provides
|
|
recursive service to local
|
|
clients (a <emphasis>caching-only</emphasis> server)
|
|
does not need to be reachable from the Internet at large and can
|
|
be placed inside a firewall.
|
|
</para>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
</chapter>
|
|
|
|
<chapter xml:id="Bv9ARM.ch02"><info><title><acronym>BIND</acronym> Resource Requirements</title></info>
|
|
|
|
<section xml:id="hw_req"><info><title>Hardware requirements</title></info>
|
|
<para>
|
|
<acronym>DNS</acronym> hardware requirements have
|
|
traditionally been quite modest.
|
|
For many installations, servers that have been retired from
|
|
active duty have performed admirably as <acronym>DNS</acronym> servers.
|
|
</para>
|
|
<para>
|
|
However, the DNSSEC features of <acronym>BIND</acronym> 9
|
|
may be quite
|
|
CPU-intensive, so organizations that make heavy use of these
|
|
features may wish to consider larger systems for these applications.
|
|
<acronym>BIND</acronym> 9 is fully multithreaded, allowing
|
|
full utilization of
|
|
multiprocessor systems for installations that need it.
|
|
</para>
|
|
</section>
|
|
<section xml:id="cpu_req"><info><title>CPU Requirements</title></info>
|
|
<para>
|
|
CPU requirements for <acronym>BIND</acronym> 9 range from
|
|
i386-class machines,
|
|
for serving static zones without caching, to enterprise-class
|
|
machines to process many dynamic updates and DNSSEC-signed zones,
|
|
serving many thousands of queries per second.
|
|
</para>
|
|
</section>
|
|
<section xml:id="mem_req"><info><title>Memory Requirements</title></info>
|
|
<para>
|
|
Server memory must be sufficient to hold both the
|
|
cache and the zones loaded from disk. The <command>max-cache-size</command>
|
|
option can limit the amount of memory used by the cache,
|
|
at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
|
|
traffic.
|
|
If additional section caching
|
|
(<xref linkend="acache"/>) is enabled,
|
|
the <command>max-acache-size</command> option can be used to
|
|
limit the amount
|
|
of memory used by the mechanism.
|
|
It is still good practice to have enough memory to load
|
|
all zone and cache data into memory; unfortunately, the best
|
|
way
|
|
to determine this for a given installation is to watch the name server
|
|
in operation. After a few weeks, the server process should reach
|
|
a relatively stable size where entries are expiring from the cache as
|
|
fast as they are being inserted.
|
|
</para>
|
|
<!--
|
|
- Add something here about leaving overhead for attacks?
|
|
- How much overhead? Percentage?
|
|
-->
|
|
</section>
|
|
|
|
<section xml:id="intensive_env"><info><title>Name Server-Intensive Environment Issues</title></info>
|
|
|
|
<para>
|
|
For name server-intensive environments, there are two
|
|
configurations that may be used. The first is one where clients and
|
|
any second-level internal name servers query a main name server, which
|
|
has enough memory to build a large cache; this approach minimizes
|
|
the bandwidth used by external name lookups. The second alternative
|
|
is to set up second-level internal name servers to make queries
|
|
independently.
|
|
In this configuration, none of the individual machines need to
|
|
have as much memory or CPU power as in the first alternative, but
|
|
this has the disadvantage of making many more external queries,
|
|
as none of the name servers share their cached data.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="supported_os"><info><title>Supported Operating Systems</title></info>
|
|
|
|
<para>
|
|
ISC <acronym>BIND</acronym> 9 compiles and runs on many
|
|
Unix-like operating systems and on
|
|
Microsoft Windows Server 2012 R2, 2016 and Windows 10.
|
|
For an up-to-date
|
|
list of supported systems, see the PLATFORMS.md file in the top-level
|
|
directory
|
|
of the BIND 9 source distribution.
|
|
</para>
|
|
</section>
|
|
</chapter>
|
|
|
|
<chapter xml:id="Bv9ARM.ch03"><info><title>Name Server Configuration</title></info>
|
|
|
|
<para>
|
|
In this chapter we provide some suggested configurations, along
|
|
with guidelines for their use. We suggest reasonable values for
|
|
certain option settings.
|
|
</para>
|
|
|
|
<section xml:id="sample_configuration"><info><title>Sample Configurations</title></info>
|
|
|
|
<section xml:id="cache_only_sample"><info><title>A Caching-only Name Server</title></info>
|
|
|
|
<para>
|
|
The following sample configuration is appropriate for a caching-only
|
|
name server for use by clients internal to a corporation. All
|
|
queries
|
|
from outside clients are refused using the <command>allow-query</command>
|
|
option. The same effect can be achieved using
|
|
suitable
|
|
firewall rules.
|
|
</para>
|
|
|
|
<programlisting>
|
|
// Two corporate subnets we wish to allow queries from.
|
|
acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
|
|
options {
|
|
// Working directory
|
|
directory "/etc/namedb";
|
|
|
|
allow-query { corpnets; };
|
|
};
|
|
// Provide a reverse mapping for the loopback
|
|
// address 127.0.0.1
|
|
zone "0.0.127.in-addr.arpa" {
|
|
type master;
|
|
file "localhost.rev";
|
|
notify no;
|
|
};
|
|
</programlisting>
|
|
|
|
</section>
|
|
|
|
<section xml:id="auth_only_sample"><info><title>An Authoritative-only Name Server</title></info>
|
|
|
|
<para>
|
|
This sample configuration is for an authoritative-only server
|
|
that is the primary server for "<filename>example.com</filename>"
|
|
and a secondary server for the subdomain "<filename>eng.example.com</filename>".
|
|
</para>
|
|
|
|
<programlisting>
|
|
options {
|
|
// Working directory
|
|
directory "/etc/namedb";
|
|
// Do not allow access to cache
|
|
allow-query-cache { none; };
|
|
// This is the default
|
|
allow-query { any; };
|
|
// Do not provide recursive service
|
|
recursion no;
|
|
};
|
|
|
|
// Provide a reverse mapping for the loopback
|
|
// address 127.0.0.1
|
|
zone "0.0.127.in-addr.arpa" {
|
|
type master;
|
|
file "localhost.rev";
|
|
notify no;
|
|
};
|
|
// We are the primary server for example.com
|
|
zone "example.com" {
|
|
type master;
|
|
file "example.com.db";
|
|
// IP addresses of secondary servers allowed to
|
|
// transfer example.com
|
|
allow-transfer {
|
|
192.168.4.14;
|
|
192.168.5.53;
|
|
};
|
|
};
|
|
// We are a secondary server for eng.example.com
|
|
zone "eng.example.com" {
|
|
type slave;
|
|
file "eng.example.com.bk";
|
|
// IP address of eng.example.com primary server
|
|
masters { 192.168.4.12; };
|
|
};
|
|
</programlisting>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="load_balancing"><info><title>Load Balancing</title></info>
|
|
|
|
<!--
|
|
- Add explanation of why load balancing is fragile at best
|
|
- and completely pointless in the general case.
|
|
-->
|
|
|
|
<para>
|
|
A primitive form of load balancing can be achieved in
|
|
the <acronym>DNS</acronym> by using multiple records
|
|
(such as multiple A records) for one name.
|
|
</para>
|
|
|
|
<para>
|
|
For example, assuming three HTTP servers with network addresses
|
|
of 10.0.0.1, 10.0.0.2, and 10.0.0.3, a set of records such as the
|
|
following means that clients will connect to each machine one-third
|
|
of the time:
|
|
</para>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="2Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="0.500in"/>
|
|
<colspec colname="3" colnum="3" colsep="0" colwidth="0.750in"/>
|
|
<colspec colname="4" colnum="4" colsep="0" colwidth="0.750in"/>
|
|
<colspec colname="5" colnum="5" colsep="0" colwidth="2.028in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
Name
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
TTL
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
CLASS
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
TYPE
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para>
|
|
Resource Record (RR) Data
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>www</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>600</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>IN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para>
|
|
<literal>10.0.0.1</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para/>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>600</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>IN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para>
|
|
<literal>10.0.0.2</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para/>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>600</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>IN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para>
|
|
<literal>10.0.0.3</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<para>
|
|
When a resolver queries for these records, <acronym>BIND</acronym> rotates
|
|
them and responds to the query with the records in a different
|
|
order. In the example above, clients randomly receive
|
|
records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
|
|
use the first record returned and discard the rest.
|
|
</para>
|
|
<para>
|
|
For more detail on ordering responses, check the
|
|
<command>rrset-order</command> sub-statement in the
|
|
<command>options</command> statement, see
|
|
<xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
|
|
</para>
|
|
|
|
</section>
|
|
|
|
<section xml:id="ns_operations"><info><title>Name Server Operations</title></info>
|
|
|
|
<section xml:id="tools"><info><title>Tools for Use With the Name Server Daemon</title></info>
|
|
<para>
|
|
This section describes several indispensable diagnostic,
|
|
administrative, and monitoring tools available to the system
|
|
administrator for controlling and debugging the name server
|
|
daemon.
|
|
</para>
|
|
<section xml:id="diagnostic_tools"><info><title>Diagnostic Tools</title></info>
|
|
<para>
|
|
The <command>dig</command>, <command>host</command>, and
|
|
<command>nslookup</command> programs are all command-line tools
|
|
for manually querying name servers. They differ in style and
|
|
output format.
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term xml:id="dig"><command>dig</command></term>
|
|
<listitem>
|
|
<para>
|
|
<command>dig</command>
|
|
is the most versatile and complete of these lookup tools.
|
|
It has two modes: simple interactive
|
|
mode for a single query, and batch mode, which executes a
|
|
query for
|
|
each in a list of several query lines. All query options are
|
|
accessible
|
|
from the command line.
|
|
</para>
|
|
<cmdsynopsis label="Usage" sepchar=" ">
|
|
<command>dig</command>
|
|
<arg choice="opt" rep="norepeat">@<replaceable>server</replaceable></arg>
|
|
<arg choice="plain" rep="norepeat"><replaceable>domain</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat"><replaceable>query-type</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat"><replaceable>query-class</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">+<replaceable>query-option</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-<replaceable>dig-option</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">%<replaceable>comment</replaceable></arg>
|
|
</cmdsynopsis>
|
|
<para>
|
|
The usual simple use of <command>dig</command> takes the form
|
|
</para>
|
|
<simpara>
|
|
<command>dig @server domain query-type query-class</command>
|
|
</simpara>
|
|
<para>
|
|
For more information and a list of available commands and
|
|
options, see the <command>dig</command> man
|
|
page.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>host</command></term>
|
|
<listitem>
|
|
<para>
|
|
The <command>host</command> utility emphasizes
|
|
simplicity
|
|
and ease of use. By default, it converts
|
|
between host names and Internet addresses, but its
|
|
functionality
|
|
can be extended with the use of options.
|
|
</para>
|
|
<cmdsynopsis label="Usage" sepchar=" ">
|
|
<command>host</command>
|
|
<arg choice="opt" rep="norepeat">-aCdlnrsTwv</arg>
|
|
<arg choice="opt" rep="norepeat">-c <replaceable>class</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-N <replaceable>ndots</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-t <replaceable>type</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-W <replaceable>timeout</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-R <replaceable>retries</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-m <replaceable>flag</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-4</arg>
|
|
<arg choice="opt" rep="norepeat">-6</arg>
|
|
<arg choice="plain" rep="norepeat"><replaceable>hostname</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat"><replaceable>server</replaceable></arg>
|
|
</cmdsynopsis>
|
|
<para>
|
|
For more information and a list of available commands and
|
|
options, see the <command>host</command> man
|
|
page.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>nslookup</command></term>
|
|
<listitem>
|
|
<para><command>nslookup</command>
|
|
has two modes: interactive and
|
|
non-interactive. Interactive mode allows the user to
|
|
query name servers for information about various
|
|
hosts and domains, or to print a list of hosts in a
|
|
domain. Non-interactive mode is used to print just
|
|
the name and requested information for a host or
|
|
domain.
|
|
</para>
|
|
<cmdsynopsis label="Usage" sepchar=" ">
|
|
<command>nslookup</command>
|
|
<arg rep="repeat" choice="opt">-option</arg>
|
|
<group choice="opt" rep="norepeat">
|
|
<arg choice="opt" rep="norepeat"><replaceable>host-to-find</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">- <arg choice="opt" rep="norepeat">server</arg></arg>
|
|
</group>
|
|
</cmdsynopsis>
|
|
<para>
|
|
Interactive mode is entered when no arguments are given (the
|
|
default name server is used) or when the first argument
|
|
is a
|
|
hyphen ("-") and the second argument is the host name or
|
|
Internet address
|
|
of a name server.
|
|
</para>
|
|
<para>
|
|
Non-interactive mode is used when the name or Internet
|
|
address
|
|
of the host to be looked up is given as the first argument.
|
|
The
|
|
optional second argument specifies the host name or address
|
|
of a name server.
|
|
</para>
|
|
<para>
|
|
Due to its arcane user interface and frequently inconsistent
|
|
behavior, we do not recommend the use of <command>nslookup</command>.
|
|
Use <command>dig</command> instead.
|
|
</para>
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
|
|
<section xml:id="admin_tools"><info><title>Administrative Tools</title></info>
|
|
<para>
|
|
Administrative tools play an integral part in the management
|
|
of a server.
|
|
</para>
|
|
<variablelist>
|
|
<varlistentry xml:id="named-checkconf" xreflabel="Named Configuration Checking application">
|
|
|
|
<term><command>named-checkconf</command></term>
|
|
<listitem>
|
|
<para>
|
|
The <command>named-checkconf</command> program
|
|
checks the syntax of a <filename>named.conf</filename> file.
|
|
</para>
|
|
<cmdsynopsis label="Usage" sepchar=" ">
|
|
<command>named-checkconf</command>
|
|
<arg choice="opt" rep="norepeat">-jvz</arg>
|
|
<arg choice="opt" rep="norepeat">-t <replaceable>directory</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat"><replaceable>filename</replaceable></arg>
|
|
</cmdsynopsis>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry xml:id="named-checkzone" xreflabel="Zone Checking application">
|
|
|
|
<term><command>named-checkzone</command></term>
|
|
<listitem>
|
|
<para>
|
|
The <command>named-checkzone</command> program
|
|
checks a zone file for
|
|
syntax and consistency.
|
|
</para>
|
|
<cmdsynopsis label="Usage" sepchar=" ">
|
|
<command>named-checkzone</command>
|
|
<arg choice="opt" rep="norepeat">-djqvD</arg>
|
|
<arg choice="opt" rep="norepeat">-c <replaceable>class</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-o <replaceable>output</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-t <replaceable>directory</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-w <replaceable>directory</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-k <replaceable>(ignore|warn|fail)</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-n <replaceable>(ignore|warn|fail)</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-W <replaceable>(ignore|warn)</replaceable></arg>
|
|
<arg choice="plain" rep="norepeat"><replaceable>zone</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat"><replaceable>filename</replaceable></arg>
|
|
</cmdsynopsis>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry xml:id="named-compilezone" xreflabel="Zone Compilation application">
|
|
<term><command>named-compilezone</command></term>
|
|
<listitem>
|
|
<para>
|
|
This tool is similar to <command>named-checkzone,</command> but
|
|
it always dumps the zone content to a specified file
|
|
(typically in a different format).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry xml:id="rndc" xreflabel="Remote Name Daemon Control application">
|
|
|
|
<term><command>rndc</command></term>
|
|
<listitem>
|
|
<para>
|
|
The remote name daemon control
|
|
(<command>rndc</command>) program allows the
|
|
system
|
|
administrator to control the operation of a name server.
|
|
If <command>rndc</command> is run without any
|
|
options,
|
|
it displays a usage message as follows:
|
|
</para>
|
|
<cmdsynopsis label="Usage" sepchar=" ">
|
|
<command>rndc</command>
|
|
<arg choice="opt" rep="norepeat">-c <replaceable>config</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-s <replaceable>server</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-p <replaceable>port</replaceable></arg>
|
|
<arg choice="opt" rep="norepeat">-y <replaceable>key</replaceable></arg>
|
|
<arg choice="plain" rep="norepeat"><replaceable>command</replaceable></arg>
|
|
<arg rep="repeat" choice="opt"><replaceable>command</replaceable></arg>
|
|
</cmdsynopsis>
|
|
|
|
<para>See <xref linkend="man.rndc"/> for details of
|
|
the available <command>rndc</command> commands.
|
|
</para>
|
|
|
|
<para>
|
|
<command>rndc</command> requires a configuration file,
|
|
since all
|
|
communication with the server is authenticated with
|
|
digital signatures that rely on a shared secret, and
|
|
there is no way to provide that secret other than with a
|
|
configuration file. The default location for the
|
|
<command>rndc</command> configuration file is
|
|
<filename>/etc/rndc.conf</filename>, but an
|
|
alternate
|
|
location can be specified with the <option>-c</option>
|
|
option. If the configuration file is not found,
|
|
<command>rndc</command> also looks in
|
|
<filename>/etc/rndc.key</filename> (or whatever
|
|
<varname>sysconfdir</varname> was defined when
|
|
the <acronym>BIND</acronym> build was
|
|
configured).
|
|
The <filename>rndc.key</filename> file is
|
|
generated by
|
|
running <command>rndc-confgen -a</command> as
|
|
described in
|
|
<xref linkend="controls_statement_definition_and_usage"/>.
|
|
</para>
|
|
|
|
<para>
|
|
The format of the configuration file is similar to
|
|
that of <filename>named.conf</filename>, but is
|
|
limited to
|
|
only four statements: the <command>options</command>,
|
|
<command>key</command>, <command>server</command>, and
|
|
<command>include</command>
|
|
statements. These statements are what associate the
|
|
secret keys to the servers with which they are meant to
|
|
be shared. The order of statements is not
|
|
significant.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>options</command> statement has
|
|
three clauses:
|
|
<command>default-server</command>, <command>default-key</command>,
|
|
and <command>default-port</command>.
|
|
<command>default-server</command> takes a
|
|
host name or address argument and represents the server
|
|
that
|
|
is contacted if no <option>-s</option>
|
|
option is provided on the command line.
|
|
<command>default-key</command> takes
|
|
the name of a key as its argument, as defined by a <command>key</command> statement.
|
|
<command>default-port</command> specifies the
|
|
port to which
|
|
<command>rndc</command> should connect if no
|
|
port is given on the command line or in a
|
|
<command>server</command> statement.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>key</command> statement defines a
|
|
key to be used
|
|
by <command>rndc</command> when authenticating
|
|
with
|
|
<command>named</command>. Its syntax is
|
|
identical to the
|
|
<command>key</command> statement in <filename>named.conf</filename>.
|
|
The keyword <userinput>key</userinput> is
|
|
followed by a key name, which must be a valid
|
|
domain name, though it need not actually be hierarchical;
|
|
thus,
|
|
a string like "<userinput>rndc_key</userinput>" is a valid
|
|
name.
|
|
The <command>key</command> statement has two
|
|
clauses:
|
|
<command>algorithm</command> and <command>secret</command>.
|
|
While the configuration parser accepts any string as the
|
|
argument
|
|
to <command>algorithm</command>, currently only the strings
|
|
"<userinput>hmac-md5</userinput>",
|
|
"<userinput>hmac-sha1</userinput>",
|
|
"<userinput>hmac-sha224</userinput>",
|
|
"<userinput>hmac-sha256</userinput>",
|
|
"<userinput>hmac-sha384</userinput>",
|
|
and "<userinput>hmac-sha512</userinput>"
|
|
have any meaning. The secret is a Base64-encoded string
|
|
as specified in RFC 3548.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>server</command> statement
|
|
associates a key
|
|
defined using the <command>key</command>
|
|
statement with a server.
|
|
The keyword <userinput>server</userinput> is followed by a
|
|
host name or address. The <command>server</command> statement
|
|
has two clauses: <command>key</command> and <command>port</command>.
|
|
The <command>key</command> clause specifies the
|
|
name of the key
|
|
to be used when communicating with this server, and the
|
|
<command>port</command> clause can be used to
|
|
specify the port <command>rndc</command> should
|
|
connect
|
|
to on the server.
|
|
</para>
|
|
|
|
<para>
|
|
A sample minimal configuration file is as follows:
|
|
</para>
|
|
|
|
<programlisting>
|
|
key rndc_key {
|
|
algorithm "hmac-sha256";
|
|
secret
|
|
"c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
|
|
};
|
|
options {
|
|
default-server 127.0.0.1;
|
|
default-key rndc_key;
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
This file, if installed as <filename>/etc/rndc.conf</filename>,
|
|
allows the command:
|
|
</para>
|
|
|
|
<para>
|
|
<prompt>$ </prompt><userinput>rndc reload</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
to connect to 127.0.0.1 port 953 and causes the name server
|
|
to reload, if a name server on the local machine is
|
|
running with
|
|
following controls statements:
|
|
</para>
|
|
|
|
<programlisting>
|
|
controls {
|
|
inet 127.0.0.1
|
|
allow { localhost; } keys { rndc_key; };
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
and it has an identical key statement for
|
|
<literal>rndc_key</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
Running the <command>rndc-confgen</command>
|
|
program
|
|
conveniently creates an <filename>rndc.conf</filename>
|
|
file, and also displays the
|
|
corresponding <command>controls</command>
|
|
statement needed to
|
|
add to <filename>named.conf</filename>.
|
|
Alternatively,
|
|
it is possible to run <command>rndc-confgen -a</command>
|
|
to set up
|
|
an <filename>rndc.key</filename> file and not
|
|
modify
|
|
<filename>named.conf</filename> at all.
|
|
</para>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="signals"><info><title>Signals</title></info>
|
|
<para>
|
|
Certain Unix signals cause the name server to take specific
|
|
actions, as described in the following table. These signals can
|
|
be sent using the <command>kill</command> command.
|
|
</para>
|
|
<informaltable frame="all">
|
|
<tgroup cols="2">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>SIGHUP</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Causes the server to read <filename>named.conf</filename> and
|
|
reload the database.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>SIGTERM</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Causes the server to clean up and exit.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>SIGINT</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Causes the server to clean up and exit.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
</section>
|
|
</chapter>
|
|
|
|
<chapter xml:id="Bv9ARM.ch04"><info><title>Advanced DNS Features</title></info>
|
|
|
|
<section xml:id="notify"><info><title>Notify</title></info>
|
|
<para>
|
|
<acronym>DNS</acronym> NOTIFY is a mechanism that allows primary
|
|
servers to notify their secondary servers of changes to a zone's data. In
|
|
response to a <command>NOTIFY</command> from a primary server, the
|
|
secondary checks to see that its version of the zone is the
|
|
current version and, if not, initiates a zone transfer.
|
|
</para>
|
|
|
|
<para>
|
|
For more information about <acronym>DNS</acronym>
|
|
<command>NOTIFY</command>, see the description of the
|
|
<command>notify</command> option in <xref linkend="boolean_options"/> and
|
|
the description of the zone option <command>also-notify</command> in
|
|
<xref linkend="zone_transfers"/>. The <command>NOTIFY</command>
|
|
protocol is specified in RFC 1996.
|
|
</para>
|
|
|
|
<note><simpara>
|
|
As a secondary zone can also be a primary to other secondaries, <command>named</command>,
|
|
by default, sends <command>NOTIFY</command> messages for every zone
|
|
it loads. Specifying <command>notify primary-only;</command>
|
|
causes <command>named</command> to only send <command>NOTIFY</command> for primary
|
|
zones that it loads.
|
|
</simpara></note>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dynamic_update"><info><title>Dynamic Update</title></info>
|
|
|
|
<para>
|
|
Dynamic Update is a method for adding, replacing, or deleting
|
|
records in a primary server by sending it a special form of DNS
|
|
messages. The format and meaning of these messages is specified
|
|
in RFC 2136.
|
|
</para>
|
|
|
|
<para>
|
|
Dynamic update is enabled by including an
|
|
<command>allow-update</command> or an <command>update-policy</command>
|
|
clause in the <command>zone</command> statement.
|
|
</para>
|
|
|
|
<para>
|
|
If the zone's <command>update-policy</command> is set to
|
|
<userinput>local</userinput>, updates to the zone
|
|
are permitted for the key <varname>local-ddns</varname>,
|
|
which is generated by <command>named</command> at startup.
|
|
See <xref linkend="dynamic_update_policies"/> for more details.
|
|
</para>
|
|
|
|
<para>
|
|
Dynamic updates using Kerberos-signed requests can be made
|
|
using the TKEY/GSS protocol, either by setting the
|
|
<command>tkey-gssapi-keytab</command> option, or
|
|
by setting both the <command>tkey-gssapi-credential</command>
|
|
and <command>tkey-domain</command> options. Once enabled,
|
|
Kerberos-signed requests are matched against the update
|
|
policies for the zone, using the Kerberos principal as the
|
|
signer for the request.
|
|
</para>
|
|
|
|
<para>
|
|
Updating of secure zones (zones using DNSSEC) follows RFC
|
|
3007: RRSIG, NSEC, and NSEC3 records affected by updates are
|
|
automatically regenerated by the server using an online
|
|
zone key. Update authorization is based on transaction
|
|
signatures and an explicit server policy.
|
|
</para>
|
|
|
|
<section xml:id="journal"><info><title>The Journal File</title></info>
|
|
|
|
<para>
|
|
All changes made to a zone using dynamic update are stored
|
|
in the zone's journal file. This file is automatically created
|
|
by the server when the first dynamic update takes place.
|
|
The name of the journal file is formed by appending the extension
|
|
<filename>.jnl</filename> to the name of the
|
|
corresponding zone
|
|
file, unless specifically overridden. The journal file is in a
|
|
binary format and should not be edited manually.
|
|
</para>
|
|
|
|
<para>
|
|
The server also occasionally writes ("dumps")
|
|
the complete contents of the updated zone to its zone file.
|
|
This is not done immediately after
|
|
each dynamic update, because that would be too slow when a large
|
|
zone is updated frequently. Instead, the dump is delayed by
|
|
up to 15 minutes, allowing additional updates to take place.
|
|
During the dump process, transient files are created
|
|
with the extensions <filename>.jnw</filename> and
|
|
<filename>.jbk</filename>; under ordinary circumstances, these
|
|
are removed when the dump is complete, and can be safely
|
|
ignored.
|
|
</para>
|
|
|
|
<para>
|
|
When a server is restarted after a shutdown or crash, it replays
|
|
the journal file to incorporate into the zone any updates that
|
|
took
|
|
place after the last zone dump.
|
|
</para>
|
|
|
|
<para>
|
|
Changes that result from incoming incremental zone transfers are
|
|
also
|
|
journaled in a similar way.
|
|
</para>
|
|
|
|
<para>
|
|
The zone files of dynamic zones cannot normally be edited by
|
|
hand because they are not guaranteed to contain the most recent
|
|
dynamic changes; those are only in the journal file.
|
|
The only way to ensure that the zone file of a dynamic zone
|
|
is up-to-date is to run <command>rndc stop</command>.
|
|
</para>
|
|
|
|
<para>
|
|
To make changes to a dynamic zone
|
|
manually, follow these steps:
|
|
first, disable dynamic updates to the zone using
|
|
<command>rndc freeze <replaceable>zone</replaceable></command>.
|
|
This updates the zone file with the changes
|
|
stored in its <filename>.jnl</filename> file.
|
|
Then, edit the zone file. Finally, run
|
|
<command>rndc thaw <replaceable>zone</replaceable></command>
|
|
to reload the changed zone and re-enable dynamic updates.
|
|
</para>
|
|
|
|
<para>
|
|
<command>rndc sync <replaceable>zone</replaceable></command>
|
|
updates the zone file with changes from the journal file
|
|
without stopping dynamic updates; this may be useful for viewing
|
|
the current zone state. To remove the <filename>.jnl</filename>
|
|
file after updating the zone file, use
|
|
<command>rndc sync -clean</command>.
|
|
</para>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section xml:id="incremental_zone_transfers"><info><title>Incremental Zone Transfers (IXFR)</title></info>
|
|
|
|
<para>
|
|
The incremental zone transfer (IXFR) protocol is a way for
|
|
secondary servers to transfer only changed data, instead of having to
|
|
transfer an entire zone. The IXFR protocol is specified in RFC
|
|
1995. See <xref linkend="proposed_standards"/>.
|
|
</para>
|
|
|
|
<para>
|
|
When acting as a primary server, <acronym>BIND</acronym> 9
|
|
supports IXFR for those zones
|
|
where the necessary change history information is available. These
|
|
include primary zones maintained by dynamic update and secondary zones
|
|
whose data was obtained by IXFR. For manually maintained primary
|
|
zones, and for secondary zones obtained by performing a full zone
|
|
transfer (AXFR), IXFR is supported only if the option
|
|
<command>ixfr-from-differences</command> is set
|
|
to <userinput>yes</userinput>.
|
|
</para>
|
|
|
|
<para>
|
|
When acting as a secondary server, <acronym>BIND</acronym> 9
|
|
attempts to use IXFR unless
|
|
it is explicitly disabled. For more information about disabling
|
|
IXFR, see the description of the <command>request-ixfr</command> clause
|
|
of the <command>server</command> statement.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="split_dns"><info><title>Split DNS</title></info>
|
|
|
|
<para>
|
|
Setting up different views of the DNS space to
|
|
internal and external resolvers is usually referred to as a
|
|
<emphasis>split DNS</emphasis> setup. There are several
|
|
reasons an organization might want to set up its DNS this way.
|
|
</para>
|
|
<para>
|
|
One common reason to use split DNS is
|
|
to hide "internal" DNS information from "external" clients on the
|
|
Internet. There is some debate as to whether this is actually
|
|
useful.
|
|
Internal DNS information leaks out in many ways (via email headers,
|
|
for example) and most savvy "attackers" can find the information
|
|
they need using other means.
|
|
However, since listing addresses of internal servers that
|
|
external clients cannot possibly reach can result in
|
|
connection delays and other annoyances, an organization may
|
|
choose to use split DNS to present a consistent view of itself
|
|
to the outside world.
|
|
</para>
|
|
<para>
|
|
Another common reason for setting up a split DNS system is
|
|
to allow internal networks that are behind filters or in RFC 1918
|
|
space (reserved IP space, as documented in RFC 1918) to resolve DNS
|
|
on the Internet. Split DNS can also be used to allow mail from outside
|
|
back into the internal network.
|
|
</para>
|
|
<section xml:id="split_dns_sample"><info><title>Example Split DNS Setup</title></info>
|
|
<para>
|
|
Let's say a company named <emphasis>Example, Inc.</emphasis>
|
|
(<literal>example.com</literal>)
|
|
has several corporate sites that have an internal network with
|
|
reserved
|
|
Internet Protocol (IP) space and an external demilitarized zone (DMZ),
|
|
or "outside" section of a network, that is available to the public.
|
|
</para>
|
|
<para>
|
|
<emphasis>Example, Inc.</emphasis> wants its internal clients
|
|
to be able to resolve external hostnames and to exchange mail with
|
|
people on the outside. The company also wants its internal resolvers
|
|
to have access to certain internal-only zones that are not available
|
|
at all outside of the internal network.
|
|
</para>
|
|
<para>
|
|
In order to accomplish this, the company sets up two sets
|
|
of name servers. One set is on the inside network (in the
|
|
reserved
|
|
IP space) and the other set is on bastion hosts, which are
|
|
"proxy"
|
|
hosts in the DMZ that can talk to both sides of its network.
|
|
</para>
|
|
<para>
|
|
The internal servers are configured to forward all queries,
|
|
except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>,
|
|
and <filename>site2.example.com</filename>, to the servers
|
|
in the
|
|
DMZ. These internal servers will have complete sets of information
|
|
for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>, <filename>site1.internal</filename>,
|
|
and <filename>site2.internal</filename>.
|
|
</para>
|
|
<para>
|
|
To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
|
|
the internal name servers must be configured to disallow all queries
|
|
to these domains from any external hosts, including the bastion
|
|
hosts.
|
|
</para>
|
|
<para>
|
|
The external servers, which are on the bastion hosts, are
|
|
configured to serve the "public" version of the <filename>site1.example.com</filename> and <filename>site2.example.com</filename> zones.
|
|
This could include things such as the host records for public servers
|
|
(<filename>www.example.com</filename> and <filename>ftp.example.com</filename>)
|
|
and mail exchange (MX) records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).
|
|
</para>
|
|
<para>
|
|
In addition, the public <filename>site1.example.com</filename> and <filename>site2.example.com</filename> zones
|
|
should have special MX records that contain wildcard ("*") records
|
|
pointing to the bastion hosts. This is needed because external mail
|
|
servers do not have any other way of looking up how to deliver mail
|
|
to those internal hosts. With the wildcard records, the mail is
|
|
delivered to the bastion host, which can then forward it on to
|
|
internal hosts.
|
|
</para>
|
|
<para>
|
|
Here's an example of a wildcard MX record:
|
|
</para>
|
|
<programlisting>* IN MX 10 external1.example.com.</programlisting>
|
|
<para>
|
|
Now that they accept mail on behalf of anything in the internal
|
|
network, the bastion hosts need to know how to deliver mail
|
|
to internal hosts. The resolvers
|
|
on
|
|
the bastion hosts need to be configured to point to the internal
|
|
name servers for DNS resolution.
|
|
</para>
|
|
<para>
|
|
Queries for internal hostnames are answered by the internal
|
|
servers, and queries for external hostnames are forwarded back
|
|
out to the DNS servers on the bastion hosts.
|
|
</para>
|
|
<para>
|
|
For all of this to work properly, internal clients
|
|
need to be configured to query <emphasis>only</emphasis> the internal
|
|
name servers for DNS queries. This could also be enforced via
|
|
selective
|
|
filtering on the network.
|
|
</para>
|
|
<para>
|
|
If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s
|
|
internal clients are now able to:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<simpara>
|
|
Look up any hostnames in the <literal>site1.example.com</literal>
|
|
and
|
|
<literal>site2.example.com</literal> zones.
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
Look up any hostnames in the <literal>site1.internal</literal> and
|
|
<literal>site2.internal</literal> domains.
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>Look up any hostnames on the Internet.</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>Exchange mail with both internal and external users.</simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
Hosts on the Internet are able to:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<simpara>
|
|
Look up any hostnames in the <literal>site1.example.com</literal>
|
|
and
|
|
<literal>site2.example.com</literal> zones.
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
Exchange mail with anyone in the <literal>site1.example.com</literal> and
|
|
<literal>site2.example.com</literal> zones.
|
|
</simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
Here is an example configuration for the setup just
|
|
described above. Note that this is only configuration information;
|
|
for information on how to configure the zone files, see <xref linkend="sample_configuration"/>.
|
|
</para>
|
|
|
|
<para>
|
|
Internal DNS server config:
|
|
</para>
|
|
|
|
<programlisting>
|
|
|
|
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
|
|
|
|
acl externals { <varname>bastion-ips-go-here</varname>; };
|
|
|
|
options {
|
|
...
|
|
...
|
|
forward only;
|
|
// forward to external servers
|
|
forwarders {
|
|
<varname>bastion-ips-go-here</varname>;
|
|
};
|
|
// sample allow-transfer (no one)
|
|
allow-transfer { none; };
|
|
// restrict query access
|
|
allow-query { internals; externals; };
|
|
// restrict recursion
|
|
allow-recursion { internals; };
|
|
...
|
|
...
|
|
};
|
|
|
|
// sample primary zone
|
|
zone "site1.example.com" {
|
|
type master;
|
|
file "m/site1.example.com";
|
|
// do normal iterative resolution (do not forward)
|
|
forwarders { };
|
|
allow-query { internals; externals; };
|
|
allow-transfer { internals; };
|
|
};
|
|
|
|
// sample secondary zone
|
|
zone "site2.example.com" {
|
|
type slave;
|
|
file "s/site2.example.com";
|
|
masters { 172.16.72.3; };
|
|
forwarders { };
|
|
allow-query { internals; externals; };
|
|
allow-transfer { internals; };
|
|
};
|
|
|
|
zone "site1.internal" {
|
|
type master;
|
|
file "m/site1.internal";
|
|
forwarders { };
|
|
allow-query { internals; };
|
|
allow-transfer { internals; }
|
|
};
|
|
|
|
zone "site2.internal" {
|
|
type slave;
|
|
file "s/site2.internal";
|
|
masters { 172.16.72.3; };
|
|
forwarders { };
|
|
allow-query { internals };
|
|
allow-transfer { internals; }
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
External (bastion host) DNS server config:
|
|
</para>
|
|
|
|
<programlisting>
|
|
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
|
|
|
|
acl externals { bastion-ips-go-here; };
|
|
|
|
options {
|
|
...
|
|
...
|
|
// sample allow-transfer (no one)
|
|
allow-transfer { none; };
|
|
// default query access
|
|
allow-query { any; };
|
|
// restrict cache access
|
|
allow-query-cache { internals; externals; };
|
|
// restrict recursion
|
|
allow-recursion { internals; externals; };
|
|
...
|
|
...
|
|
};
|
|
|
|
// sample secondary zone
|
|
zone "site1.example.com" {
|
|
type master;
|
|
file "m/site1.foo.com";
|
|
allow-transfer { internals; externals; };
|
|
};
|
|
|
|
zone "site2.example.com" {
|
|
type slave;
|
|
file "s/site2.foo.com";
|
|
masters { another_bastion_host_maybe; };
|
|
allow-transfer { internals; externals; }
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
In the <filename>resolv.conf</filename> (or equivalent) on
|
|
the bastion host(s):
|
|
</para>
|
|
|
|
<programlisting>
|
|
search ...
|
|
nameserver 172.16.72.2
|
|
nameserver 172.16.72.3
|
|
nameserver 172.16.72.4
|
|
</programlisting>
|
|
|
|
</section>
|
|
</section>
|
|
<section xml:id="tsig"><info><title>TSIG</title></info>
|
|
|
|
<para>
|
|
TSIG (Transaction SIGnatures) is a mechanism for authenticating DNS
|
|
messages, originally specified in RFC 2845. It allows DNS messages
|
|
to be cryptographically signed using a shared secret. TSIG can
|
|
be used in any DNS transaction, as a way to restrict access to
|
|
certain server functions (e.g., recursive queries) to authorized
|
|
clients when IP-based access control is insufficient or needs to
|
|
be overridden, or as a way to ensure message authenticity when it
|
|
is critical to the integrity of the server, such as with dynamic
|
|
UPDATE messages or zone transfers from a primary to a secondary server.
|
|
</para>
|
|
<para>
|
|
This section is a guide to setting up TSIG in <acronym>BIND</acronym>.
|
|
It describes the configuration syntax and the process of creating
|
|
TSIG keys.
|
|
</para>
|
|
<para>
|
|
<command>named</command> supports TSIG for server-to-server
|
|
communication, and some of the tools included with
|
|
<acronym>BIND</acronym> support it for sending messages to
|
|
<command>named</command>:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<xref linkend="man.nsupdate"/> supports TSIG via the
|
|
<option>-k</option>, <option>-l</option>, and
|
|
<option>-y</option> command-line options, or via
|
|
the <command>key</command> command when running
|
|
interactively.
|
|
</listitem>
|
|
<listitem>
|
|
<xref linkend="man.dig"/> supports TSIG via the
|
|
<option>-k</option> and <option>-y</option>
|
|
command-line options.
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<section><info><title>Generating a Shared Key</title></info>
|
|
<para>
|
|
TSIG keys can be generated using the <command>tsig-keygen</command>
|
|
command; the output of the command is a <command>key</command> directive
|
|
suitable for inclusion in <filename>named.conf</filename>. The
|
|
key name, algorithm, and size can be specified by command-line parameters;
|
|
the defaults are "tsig-key", HMAC-SHA256, and 256 bits, respectively.
|
|
</para>
|
|
<para>
|
|
Any string which is a valid DNS name can be used as a key name.
|
|
For example, a key to be shared between servers called
|
|
<emphasis>host1</emphasis> and <emphasis>host2</emphasis> could
|
|
be called "host1-host2.", and this key can be generated using:
|
|
</para>
|
|
<programlisting>
|
|
$ tsig-keygen host1-host2. > host1-host2.key
|
|
</programlisting>
|
|
<para>
|
|
This key may then be copied to both hosts. The key name and secret
|
|
must be identical on both hosts.
|
|
(Note: copying a shared secret from one server to another is beyond
|
|
the scope of the DNS. A secure transport mechanism should be used:
|
|
secure FTP, SSL, ssh, telephone, encrypted email, etc.)
|
|
</para>
|
|
<para>
|
|
<command>tsig-keygen</command> can also be run as
|
|
<command>ddns-confgen</command>, in which case its output includes
|
|
additional configuration text for setting up dynamic DNS in
|
|
<command>named</command>. See <xref linkend="man.ddns-confgen"/>
|
|
for details.
|
|
</para>
|
|
</section>
|
|
|
|
<section><info><title>Loading a New Key</title></info>
|
|
<para>
|
|
For a key shared between servers called
|
|
<emphasis>host1</emphasis> and <emphasis>host2</emphasis>,
|
|
the following could be added to each server's
|
|
<filename>named.conf</filename> file:
|
|
</para>
|
|
<programlisting>
|
|
key "host1-host2." {
|
|
algorithm hmac-sha256;
|
|
secret "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=";
|
|
};
|
|
</programlisting>
|
|
<para>
|
|
(This is the same key generated above using
|
|
<command>tsig-keygen</command>.)
|
|
</para>
|
|
<para>
|
|
Since this text contains a secret, it
|
|
is recommended that either <filename>named.conf</filename> not be
|
|
world-readable, or that the <command>key</command> directive
|
|
be stored in a file which is not world-readable and which is
|
|
included in <filename>named.conf</filename> via the
|
|
<command>include</command> directive.
|
|
</para>
|
|
<para>
|
|
Once a key has been added to <filename>named.conf</filename> and the
|
|
server has been restarted or reconfigured, the server can recognize
|
|
the key. If the server receives a message signed by the
|
|
key, it is able to verify the signature. If the signature
|
|
is valid, the response is signed using the same key.
|
|
</para>
|
|
<para>
|
|
TSIG keys that are known to a server can be listed using the
|
|
command <command>rndc tsig-list</command>.
|
|
</para>
|
|
</section>
|
|
|
|
<section><info><title>Instructing the Server to Use a Key</title></info>
|
|
<para>
|
|
A server sending a request to another server must be told whether
|
|
to use a key, and if so, which key to use.
|
|
</para>
|
|
<para>
|
|
For example, a key may be specified for each server in the
|
|
<command>masters</command> statement in the definition of a
|
|
secondary zone; in this case, all SOA QUERY messages, NOTIFY
|
|
messages, and zone transfer requests (AXFR or IXFR) are
|
|
signed using the specified key. Keys may also be specified
|
|
in the <command>also-notify</command> statement of a primary
|
|
or secondary zone, causing NOTIFY messages to be signed using
|
|
the specified key.
|
|
</para>
|
|
<para>
|
|
Keys can also be specified in a <command>server</command>
|
|
directive. Adding the following on <emphasis>host1</emphasis>,
|
|
if the IP address of <emphasis>host2</emphasis> is 10.1.2.3, would
|
|
cause <emphasis>all</emphasis> requests from <emphasis>host1</emphasis>
|
|
to <emphasis>host2</emphasis>, including normal DNS queries, to be
|
|
signed using the <command>host1-host2.</command> key:
|
|
</para>
|
|
<programlisting>
|
|
server 10.1.2.3 {
|
|
keys { host1-host2. ;};
|
|
};
|
|
</programlisting>
|
|
<para>
|
|
Multiple keys may be present in the <command>keys</command>
|
|
statement, but only the first one is used. As this directive does
|
|
not contain secrets, it can be used in a world-readable file.
|
|
</para>
|
|
<para>
|
|
Requests sent by <emphasis>host2</emphasis> to <emphasis>host1</emphasis>
|
|
would <emphasis>not</emphasis> be signed, unless a similar
|
|
<command>server</command> directive were in <emphasis>host2</emphasis>'s
|
|
configuration file.
|
|
</para>
|
|
<para>
|
|
Whenever any server sends a TSIG-signed DNS request, it expects
|
|
the response to be signed with the same key. If a response is not
|
|
signed, or if the signature is not valid, the response is
|
|
rejected.
|
|
</para>
|
|
</section>
|
|
|
|
<section><info><title>TSIG-Based Access Control</title></info>
|
|
<para>
|
|
TSIG keys may be specified in ACL definitions and ACL directives
|
|
such as <command>allow-query</command>, <command>allow-transfer</command>,
|
|
and <command>allow-update</command>.
|
|
The above key would be denoted in an ACL element as
|
|
<command>key host1-host2.</command>
|
|
</para>
|
|
<para>
|
|
Here is an example of an <command>allow-update</command> directive using
|
|
a TSIG key:
|
|
</para>
|
|
<programlisting>
|
|
allow-update { !{ !localnets; any; }; key host1-host2. ;};
|
|
</programlisting>
|
|
<para>
|
|
This allows dynamic updates to succeed only if the UPDATE
|
|
request comes from an address in <command>localnets</command>,
|
|
<emphasis>and</emphasis> if it is signed using the
|
|
<command>host1-host2.</command> key.
|
|
</para>
|
|
<para>
|
|
See <xref linkend="dynamic_update_policies"/> for a discussion of
|
|
the more flexible <command>update-policy</command> statement.
|
|
</para>
|
|
</section>
|
|
|
|
<section><info><title>Errors</title></info>
|
|
<para>
|
|
Processing of TSIG-signed messages can result in several errors:
|
|
<itemizedlist>
|
|
<listitem>
|
|
If a TSIG-aware server receives a message signed by an
|
|
unknown key, the response will be unsigned, with the TSIG
|
|
extended error code set to BADKEY.
|
|
</listitem>
|
|
<listitem>
|
|
If a TSIG-aware server receives a message from a known key
|
|
but with an invalid signature, the response will be unsigned,
|
|
with the TSIG extended error code set to BADSIG.
|
|
</listitem>
|
|
<listitem>
|
|
If a TSIG-aware server receives a message with a time
|
|
outside of the allowed range, the response will be signed but
|
|
the TSIG extended error code set to BADTIME, and the time values
|
|
will be adjusted so that the response can be successfully
|
|
verified.
|
|
</listitem>
|
|
</itemizedlist>
|
|
In all of the above cases, the server returns a response code
|
|
of NOTAUTH (not authenticated).
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="tkey"><info><title>TKEY</title></info>
|
|
|
|
<para>
|
|
TKEY (Transaction KEY) is a mechanism for automatically negotiating
|
|
a shared secret between two hosts, originally specified in RFC 2930.
|
|
</para>
|
|
<para>
|
|
There are several TKEY "modes" that specify how a key is to be
|
|
generated or assigned. <acronym>BIND</acronym> 9 implements only
|
|
one of these modes: Diffie-Hellman key exchange. Both hosts are
|
|
required to have a KEY record with algorithm DH (though this
|
|
record is not required to be present in a zone).
|
|
</para>
|
|
<para>
|
|
The TKEY process is initiated by a client or server by sending
|
|
a query of type TKEY to a TKEY-aware server. The query must include
|
|
an appropriate KEY record in the additional section, and
|
|
must be signed using either TSIG or SIG(0) with a previously
|
|
established key. The server's response, if successful,
|
|
contains a TKEY record in its answer section. After this transaction,
|
|
both participants have enough information to calculate a
|
|
shared secret using Diffie-Hellman key exchange. The shared secret
|
|
can then be used by to sign subsequent transactions between the
|
|
two servers.
|
|
</para>
|
|
<para>
|
|
TSIG keys known by the server, including TKEY-negotiated keys, can
|
|
be listed using <command>rndc tsig-list</command>.
|
|
</para>
|
|
<para>
|
|
TKEY-negotiated keys can be deleted from a server using
|
|
<command>rndc tsig-delete</command>. This can also be done via
|
|
the TKEY protocol itself, by sending an authenticated TKEY query
|
|
specifying the "key deletion" mode.
|
|
</para>
|
|
|
|
</section>
|
|
<section xml:id="sig0"><info><title>SIG(0)</title></info>
|
|
|
|
<para>
|
|
<acronym>BIND</acronym> partially supports DNSSEC SIG(0)
|
|
transaction signatures as specified in RFC 2535 and RFC 2931.
|
|
SIG(0) uses public/private keys to authenticate messages. Access control
|
|
is performed in the same manner as with TSIG keys; privileges can be
|
|
granted or denied in ACL directives based on the key name.
|
|
</para>
|
|
<para>
|
|
When a SIG(0) signed message is received, it is only
|
|
verified if the key is known and trusted by the server. The
|
|
server does not attempt to recursively fetch or validate the
|
|
key.
|
|
</para>
|
|
<para>
|
|
SIG(0) signing of multiple-message TCP streams is not supported.
|
|
</para>
|
|
<para>
|
|
The only tool shipped with <acronym>BIND</acronym> 9 that
|
|
generates SIG(0) signed messages is <command>nsupdate</command>.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="DNSSEC"><info><title>DNSSEC</title></info>
|
|
<para>
|
|
Cryptographic authentication of DNS information is possible
|
|
through the DNS Security (<emphasis>DNSSEC-bis</emphasis>) extensions,
|
|
defined in RFC 4033, RFC 4034, and RFC 4035.
|
|
This section describes the creation and use of DNSSEC signed zones.
|
|
</para>
|
|
|
|
<para>
|
|
In order to set up a DNSSEC secure zone, there are a series
|
|
of steps which must be followed. <acronym>BIND</acronym>
|
|
9 ships
|
|
with several tools
|
|
that are used in this process, which are explained in more detail
|
|
below. In all cases, the <option>-h</option> option prints a
|
|
full list of parameters. Note that the DNSSEC tools require the
|
|
keyset files to be in the working directory or the
|
|
directory specified by the <option>-d</option> option.
|
|
</para>
|
|
|
|
<para>
|
|
There must also be communication with the administrators of
|
|
the parent and/or child zone to transmit keys. A zone's security
|
|
status must be indicated by the parent zone for a DNSSEC-capable
|
|
resolver to trust its data. This is done through the presence
|
|
or absence of a <literal>DS</literal> record at the
|
|
delegation
|
|
point.
|
|
</para>
|
|
|
|
<para>
|
|
For other servers to trust data in this zone, they must
|
|
be statically configured with either this zone's zone key or the
|
|
zone key of another zone above this one in the DNS tree.
|
|
</para>
|
|
|
|
<section xml:id="dnssec_keys"><info><title>Generating Keys</title></info>
|
|
|
|
<para>
|
|
The <command>dnssec-keygen</command> program is used to
|
|
generate keys.
|
|
</para>
|
|
|
|
<para>
|
|
A secure zone must contain one or more zone keys. The
|
|
zone keys will sign all other records in the zone, as well as
|
|
the zone keys of any secure delegated zones. Zone keys must
|
|
have the same name as the zone, have a name type of
|
|
<command>ZONE</command>, and be usable for
|
|
authentication.
|
|
It is recommended that zone keys use a cryptographic algorithm
|
|
designated as "mandatory to implement" by the IETF; currently
|
|
the only one is RSASHA1.
|
|
</para>
|
|
|
|
<para>
|
|
The following command generates a 768-bit RSASHA1 key for
|
|
the <filename>child.example</filename> zone:
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
Two output files are produced:
|
|
<filename>Kchild.example.+005+12345.key</filename> and
|
|
<filename>Kchild.example.+005+12345.private</filename>
|
|
(where
|
|
12345 is an example of a key tag). The key filenames contain
|
|
the key name (<filename>child.example.</filename>), the
|
|
algorithm (3
|
|
is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
|
|
this case).
|
|
The private key (in the <filename>.private</filename>
|
|
file) is
|
|
used to generate signatures, and the public key (in the
|
|
<filename>.key</filename> file) is used for signature
|
|
verification.
|
|
</para>
|
|
|
|
<para>
|
|
To generate another key with the same properties but with
|
|
a different key tag, repeat the above command.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>dnssec-keyfromlabel</command> program is used
|
|
to get a key pair from a crypto hardware device and build the key
|
|
files. Its usage is similar to <command>dnssec-keygen</command>.
|
|
</para>
|
|
|
|
<para>
|
|
The public keys should be inserted into the zone file by
|
|
including the <filename>.key</filename> files using
|
|
<command>$INCLUDE</command> statements.
|
|
</para>
|
|
|
|
</section>
|
|
<section xml:id="dnssec_signing"><info><title>Signing the Zone</title></info>
|
|
|
|
<para>
|
|
The <command>dnssec-signzone</command> program is used
|
|
to sign a zone.
|
|
</para>
|
|
|
|
<para>
|
|
Any <filename>keyset</filename> files corresponding to
|
|
secure sub-zones should be present. The zone signer
|
|
generates <literal>NSEC</literal>, <literal>NSEC3</literal>,
|
|
and <literal>RRSIG</literal> records for the zone, as
|
|
well as <literal>DS</literal> for the child zones if
|
|
<literal>-g</literal> is specified. If <literal>-g</literal>
|
|
is not specified, then DS RRsets for the secure child
|
|
zones need to be added manually.
|
|
</para>
|
|
|
|
<para>
|
|
By default, all zone keys which have an available private key are
|
|
used to generate signatures. The following command signs the zone, assuming it is in a
|
|
file called <filename>zone.child.example</filename>:
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>dnssec-signzone -o child.example zone.child.example</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
One output file is produced:
|
|
<filename>zone.child.example.signed</filename>. This
|
|
file
|
|
should be referenced by <filename>named.conf</filename>
|
|
as the
|
|
input file for the zone.
|
|
</para>
|
|
|
|
<para><command>dnssec-signzone</command>
|
|
also produces keyset and dsset files.
|
|
These are used to provide the parent zone
|
|
administrators with the <literal>DNSKEYs</literal> (or their
|
|
corresponding <literal>DS</literal> records) that are the
|
|
secure entry point to the zone.
|
|
</para>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dnssec_config"><info><title>Configuring Servers for DNSSEC</title></info>
|
|
|
|
<para>
|
|
To enable <command>named</command> to respond appropriately
|
|
to DNS requests from DNSSEC-aware clients,
|
|
<command>dnssec-enable</command> must be set to yes.
|
|
(This is the default setting.)
|
|
</para>
|
|
|
|
<para>
|
|
To enable <command>named</command> to validate answers from
|
|
other servers, the <command>dnssec-enable</command> option
|
|
must be set to <userinput>yes</userinput>, and the
|
|
<command>dnssec-validation</command> option must be set to
|
|
<userinput>yes</userinput> or <userinput>auto</userinput>.
|
|
</para>
|
|
|
|
<para>
|
|
If <command>dnssec-validation</command> is set to
|
|
<userinput>auto</userinput>, then a default
|
|
trust anchor for the DNS root zone is used.
|
|
If it is set to <userinput>yes</userinput>, however,
|
|
then at least one trust anchor must be configured
|
|
with a <command>trusted-keys</command> or
|
|
<command>managed-keys</command> statement in
|
|
<filename>named.conf</filename>, or DNSSEC validation
|
|
will not occur. The default setting is
|
|
<userinput>yes</userinput>.
|
|
</para>
|
|
|
|
<para>
|
|
<command>trusted-keys</command> are copies of DNSKEY RRs
|
|
for zones that are used to form the first link in the
|
|
cryptographic chain of trust. All keys listed in
|
|
<command>trusted-keys</command> (and corresponding zones)
|
|
are deemed to exist and only the listed keys are used
|
|
to validate the DNSKEY RRset that they are from.
|
|
</para>
|
|
|
|
<para>
|
|
<command>managed-keys</command> are trusted keys which are
|
|
automatically kept up-to-date via RFC 5011 trust anchor
|
|
maintenance.
|
|
</para>
|
|
|
|
<para>
|
|
<command>trusted-keys</command> and
|
|
<command>managed-keys</command> are described in more detail
|
|
later in this document.
|
|
</para>
|
|
|
|
<para>
|
|
<acronym>BIND</acronym>
|
|
9 does not verify signatures on load, so zone keys for
|
|
authoritative zones do not need to be specified in the
|
|
configuration file.
|
|
</para>
|
|
|
|
<para>
|
|
After DNSSEC is established, a typical DNSSEC configuration
|
|
looks something like the following. It has one or
|
|
more public keys for the root, which allows answers from
|
|
outside the organization to be validated. It also
|
|
has several keys for parts of the namespace that the organization
|
|
controls. These are here to ensure that <command>named</command>
|
|
is immune to compromised security in the DNSSEC components
|
|
of parent zones.
|
|
</para>
|
|
|
|
<programlisting>
|
|
managed-keys {
|
|
/* Root Key */
|
|
"." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
|
|
JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
|
|
aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
|
|
4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
|
|
hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
|
|
5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
|
|
g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
|
|
66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
|
|
97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
|
|
dgxbcDTClU0CRBdiieyLMNzXG3";
|
|
};
|
|
|
|
trusted-keys {
|
|
/* Key for our organization's forward zone */
|
|
example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
|
|
5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
|
|
GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
|
|
4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
|
|
kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O
|
|
g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
|
|
TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
|
|
FxmAVZP20igTixin/1LcrgX/KMEGd/biuv
|
|
F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
|
|
/oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o
|
|
1OTQ09A0=";
|
|
|
|
/* Key for our reverse zone. */
|
|
2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc
|
|
xOdNax071L18QqZnQQQAVVr+i
|
|
LhGTnNGp3HoWQLUIzKrJVZ3zg
|
|
gy3WwNT6kZo6c0tszYqbtvchm
|
|
gQC8CzKojM/W16i6MG/eafGU3
|
|
siaOdS0yOI6BgPsw+YZdzlYMa
|
|
IJGf4M4dyoKIhzdZyQ2bYQrjy
|
|
Q4LB0lC7aOnsMyYKHHYeRvPxj
|
|
IQXmdqgOJGq+vsevG06zW+1xg
|
|
YJh9rCIfnm1GX/KMgxLPG2vXT
|
|
D/RnLX+D3T3UL7HJYHJhAZD5L
|
|
59VvjSPsZJHeDCUyWYrvPZesZ
|
|
DIRvhDD52SKvbheeTJUm6Ehkz
|
|
ytNN2SN96QRk8j/iI8ib";
|
|
};
|
|
|
|
options {
|
|
...
|
|
dnssec-enable yes;
|
|
dnssec-validation yes;
|
|
};
|
|
</programlisting>
|
|
|
|
<note><simpara>
|
|
None of the keys listed in this example are valid. In particular,
|
|
the root key is not valid.
|
|
</simpara></note>
|
|
|
|
<para>
|
|
When DNSSEC validation is enabled and properly configured,
|
|
the resolver rejects any answers from signed, secure zones
|
|
which fail to validate, and returns SERVFAIL to the client.
|
|
</para>
|
|
|
|
<para>
|
|
Responses may fail to validate for any of several reasons,
|
|
including missing, expired, or invalid signatures, a key which
|
|
does not match the DS RRset in the parent zone, or an insecure
|
|
response from a zone which, according to its parent, should have
|
|
been secure.
|
|
</para>
|
|
|
|
<note>
|
|
<para>
|
|
When the validator receives a response from an unsigned zone
|
|
that has a signed parent, it must confirm with the parent
|
|
that the zone was intentionally left unsigned. It does
|
|
this by verifying, via signed and validated NSEC/NSEC3 records,
|
|
that the parent zone contains no DS records for the child.
|
|
</para>
|
|
<para>
|
|
If the validator <emphasis>can</emphasis> prove that the zone
|
|
is insecure, then the response is accepted. However, if it
|
|
cannot, the validator must assume an insecure response to be a
|
|
forgery; it rejects the response and logs an error.
|
|
</para>
|
|
<para>
|
|
The logged error reads "insecurity proof failed" and
|
|
"got insecure response; parent indicates it should be secure".
|
|
</para>
|
|
</note>
|
|
</section>
|
|
</section>
|
|
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dnssec.xml"/>
|
|
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="managed-keys.xml"/>
|
|
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="pkcs11.xml"/>
|
|
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dlz.xml"/>
|
|
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dyndb.xml"/>
|
|
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="catz.xml"/>
|
|
|
|
<section xml:id="ipv6"><info><title>IPv6 Support in <acronym>BIND</acronym> 9</title></info>
|
|
<para>
|
|
<acronym>BIND</acronym> 9 fully supports all currently
|
|
defined forms of IPv6 name-to-address and address-to-name
|
|
lookups. It also uses IPv6 addresses to make queries when
|
|
running on an IPv6-capable system.
|
|
</para>
|
|
|
|
<para>
|
|
For forward lookups, <acronym>BIND</acronym> 9 supports
|
|
only AAAA records. RFC 3363 deprecated the use of A6 records,
|
|
and client-side support for A6 records was accordingly removed
|
|
from <acronym>BIND</acronym> 9.
|
|
However, authoritative <acronym>BIND</acronym> 9 name servers still
|
|
load zone files containing A6 records correctly, answer queries
|
|
for A6 records, and accept zone transfer for a zone containing A6
|
|
records.
|
|
</para>
|
|
|
|
<para>
|
|
For IPv6 reverse lookups, <acronym>BIND</acronym> 9 supports
|
|
the traditional "nibble" format used in the
|
|
<emphasis>ip6.arpa</emphasis> domain, as well as the older, deprecated
|
|
<emphasis>ip6.int</emphasis> domain.
|
|
Older versions of <acronym>BIND</acronym> 9
|
|
supported the "binary label" (also known as "bitstring") format,
|
|
but support of binary labels has been completely removed per
|
|
RFC 3363.
|
|
Many applications in <acronym>BIND</acronym> 9 do not understand
|
|
the binary label format at all anymore, and return an
|
|
error if one is given.
|
|
In particular, an authoritative <acronym>BIND</acronym> 9
|
|
name server will not load a zone file containing binary labels.
|
|
</para>
|
|
|
|
<para>
|
|
For an overview of the format and structure of IPv6 addresses,
|
|
see <xref linkend="ipv6addresses"/>.
|
|
</para>
|
|
|
|
<section><info><title>Address Lookups Using AAAA Records</title></info>
|
|
|
|
<para>
|
|
The IPv6 AAAA record is a parallel to the IPv4 A record,
|
|
and, unlike the deprecated A6 record, specifies the entire
|
|
IPv6 address in a single record. For example:
|
|
</para>
|
|
|
|
<programlisting>
|
|
$ORIGIN example.com.
|
|
host 3600 IN AAAA 2001:db8::1
|
|
</programlisting>
|
|
|
|
<para>
|
|
Use of IPv4-in-IPv6 mapped addresses is not recommended.
|
|
If a host has an IPv4 address, use an A record, not
|
|
a AAAA, with <literal>::ffff:192.168.42.1</literal> as
|
|
the address.
|
|
</para>
|
|
</section>
|
|
<section><info><title>Address-to-Name Lookups Using Nibble Format</title></info>
|
|
|
|
<para>
|
|
When looking up an address in nibble format, the address
|
|
components are simply reversed, just as in IPv4, and
|
|
<literal>ip6.arpa.</literal> is appended to the
|
|
resulting name.
|
|
For example, the following would provide reverse name lookup for
|
|
a host with address
|
|
<literal>2001:db8::1</literal>:
|
|
</para>
|
|
|
|
<programlisting>
|
|
$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
|
|
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR (
|
|
host.example.com. )
|
|
</programlisting>
|
|
|
|
</section>
|
|
</section>
|
|
</chapter>
|
|
|
|
<chapter xml:id="Bv9ARM.ch05"><info><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title></info>
|
|
|
|
<section xml:id="lightweight_resolver"><info><title>The Lightweight Resolver Library</title></info>
|
|
|
|
<para>
|
|
Traditionally, applications have been linked with a stub resolver
|
|
library that sends recursive DNS queries to a local caching name
|
|
server.
|
|
</para>
|
|
<para>
|
|
At first, IPv6 introduced new complexity into the resolution process,
|
|
such as following A6 chains and DNAME records, and simultaneous
|
|
lookup of IPv4 and IPv6 addresses. Though most of the complexity was
|
|
then removed, these are hard or impossible
|
|
to implement in a traditional stub resolver.
|
|
</para>
|
|
<para>
|
|
<acronym>BIND</acronym> 9 therefore can also provide resolution
|
|
services to local clients
|
|
using a combination of a lightweight resolver library and a resolver
|
|
daemon process running on the local host. These communicate using
|
|
a simple UDP-based protocol, the "lightweight resolver protocol,"
|
|
that is distinct from and simpler than the full DNS protocol.
|
|
</para>
|
|
</section>
|
|
<section xml:id="lwresd"><info><title>Running a Resolver Daemon</title></info>
|
|
|
|
<para>
|
|
To use the lightweight resolver interface, the system must
|
|
run the resolver daemon <command>lwresd</command> or a
|
|
local
|
|
name server configured with a <command>lwres</command>
|
|
statement.
|
|
</para>
|
|
|
|
<para>
|
|
By default, applications using the lightweight resolver library
|
|
make
|
|
UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
|
|
The
|
|
address can be overridden by <command>lwserver</command>
|
|
lines in
|
|
<filename>/etc/resolv.conf</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>lwresd</command> daemon is essentially a
|
|
caching-only name server that responds to requests using the
|
|
lightweight
|
|
resolver protocol rather than the DNS protocol. Because it needs
|
|
to run on each host, it is designed to require no or minimal
|
|
configuration.
|
|
Unless otherwise instructed, it uses the name servers listed on
|
|
<command>nameserver</command> lines in <filename>/etc/resolv.conf</filename>
|
|
as forwarders, but is also capable of doing the resolution
|
|
autonomously if
|
|
none are specified.
|
|
</para>
|
|
<para>
|
|
The <command>lwresd</command> daemon may also be
|
|
configured with a
|
|
<filename>named.conf</filename>-style configuration file,
|
|
in
|
|
<filename>/etc/lwresd.conf</filename> by default. A name
|
|
server may also
|
|
be configured to act as a lightweight resolver daemon using the
|
|
<command>lwres</command> statement in <filename>named.conf</filename>.
|
|
</para>
|
|
<para>
|
|
The number of client queries that the <command>lwresd</command>
|
|
daemon serves can be set using the
|
|
<option>lwres-tasks</option> and <option>lwres-clients</option>
|
|
statements in the configuration.
|
|
</para>
|
|
</section>
|
|
</chapter>
|
|
|
|
<chapter xml:id="Bv9ARM.ch06"><info><title><acronym>BIND</acronym> 9 Configuration Reference</title></info>
|
|
|
|
<section xml:id="configuration_file_elements"><info><title>Configuration File Elements</title></info>
|
|
|
|
<para>
|
|
Following is a list of elements used throughout the <acronym>BIND</acronym> configuration
|
|
file documentation:
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.855in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.770in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>acl_name</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The name of an <varname>address_match_list</varname> as
|
|
defined by the <command>acl</command> statement.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>address_match_list</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A list of one or more
|
|
<varname>ip_addr</varname>,
|
|
<varname>ip_prefix</varname>, <varname>key_id</varname>,
|
|
or <varname>acl_name</varname> elements; see
|
|
<xref linkend="address_match_lists"/>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>masters_list</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A named list of one or more <varname>ip_addr</varname>
|
|
with optional <varname>key_id</varname> and/or
|
|
<varname>ip_port</varname>.
|
|
A <varname>masters_list</varname> may include other
|
|
<varname>masters_list</varname>s.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>domain_name</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A quoted string which is used as
|
|
a DNS name; for example, <literal>my.test.domain</literal>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>namelist</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A list of one or more <varname>domain_name</varname>
|
|
elements.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>dotted_decimal</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
One to four integers valued 0 through
|
|
255 separated by dots ("."), such as <command>123.45.67</command> or <command>89.123.45.67</command>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ip4_addr</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
An IPv4 address with exactly four elements
|
|
in <varname>dotted_decimal</varname> notation.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ip6_addr</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
An IPv6 address, such as <command>2001:db8::1234</command>.
|
|
IPv6-scoped addresses that have ambiguity on their
|
|
scope zones must be disambiguated by an appropriate
|
|
zone ID with the percent character ("%") as a
|
|
delimiter. It is strongly recommended to use
|
|
string zone names rather than numeric identifiers,
|
|
to be robust against system configuration
|
|
changes. However, since there is no standard
|
|
mapping for such names and identifier values,
|
|
only interface names as link identifiers
|
|
are supported, assuming one-to-one mapping between
|
|
interfaces and links. For example, a link-local
|
|
address <command>fe80::1</command> on the link
|
|
attached to the interface <command>ne0</command>
|
|
can be specified as <command>fe80::1%ne0</command>.
|
|
Note that on most systems link-local addresses
|
|
always have ambiguity and need to be
|
|
disambiguated.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ip_addr</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
An <varname>ip4_addr</varname> or <varname>ip6_addr</varname>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ip_dscp</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A <varname>number</varname> between 0 and 63, used
|
|
to select a differentiated services code point (DSCP)
|
|
value for use with outgoing traffic on operating systems
|
|
that support DSCP.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ip_port</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
An IP port <varname>number</varname>.
|
|
The <varname>number</varname> is limited to 0
|
|
through 65535, with values
|
|
below 1024 typically restricted to use by processes running
|
|
as root.
|
|
In some cases, an asterisk ("*") character can be used as a
|
|
placeholder to
|
|
select a random high-numbered port.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ip_prefix</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
An IP network specified as an <varname>ip_addr</varname>,
|
|
followed by a slash ("/") and then the number of bits in the
|
|
netmask.
|
|
Trailing zeros in an <varname>ip_addr</varname>
|
|
may be omitted.
|
|
For example, <command>127/8</command> is the
|
|
network <command>127.0.0.0</command> with
|
|
netmask <command>255.0.0.0</command> and <command>1.2.3.0/28</command> is
|
|
network <command>1.2.3.0</command> with netmask <command>255.255.255.240</command>.
|
|
</para>
|
|
<para>
|
|
When specifying a prefix involving a IPv6-scoped address,
|
|
the scope may be omitted. In that case, the prefix
|
|
matches packets from any scope.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>key_id</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A <varname>domain_name</varname> representing
|
|
the name of a shared key, to be used for transaction
|
|
security.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>key_list</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A list of one or more
|
|
<varname>key_id</varname>s,
|
|
separated by semicolons and ending with a semicolon.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>number</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A non-negative 32-bit integer
|
|
(i.e., a number between 0 and 4294967295, inclusive).
|
|
Its acceptable value might be further
|
|
limited by the context in which it is used.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>fixedpoint</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A non-negative real number that can be specified to
|
|
the nearest one-hundredth. Up to five digits can be
|
|
specified before a decimal point, and up to two
|
|
digits after, so the maximum value is 99999.99.
|
|
Acceptable values might be further limited by the
|
|
contexts in which they are used.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>path_name</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A quoted string which is used as
|
|
a pathname, such as <filename>zones/master/my.test.domain</filename>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>port_list</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A list of an <varname>ip_port</varname> or a port
|
|
range.
|
|
A port range is specified in the form of
|
|
<userinput>range</userinput> followed by
|
|
two <varname>ip_port</varname>s,
|
|
<varname>port_low</varname> and
|
|
<varname>port_high</varname>, which represents
|
|
port numbers from <varname>port_low</varname> through
|
|
<varname>port_high</varname>, inclusive.
|
|
<varname>port_low</varname> must not be larger than
|
|
<varname>port_high</varname>.
|
|
For example,
|
|
<userinput>range 1024 65535</userinput> represents
|
|
ports from 1024 through 65535.
|
|
In either case an asterisk ("*") character is not
|
|
allowed as a valid <varname>ip_port</varname>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>size_spec</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A 64-bit unsigned integer, or the keywords
|
|
<userinput>unlimited</userinput> or
|
|
<userinput>default</userinput>.
|
|
</para>
|
|
<para>
|
|
Integers may take values
|
|
0 <= value <= 18446744073709551615, though
|
|
certain parameters
|
|
(such as <command>max-journal-size</command>) may
|
|
use a more limited range within these extremes.
|
|
In most cases, setting a value to 0 does not
|
|
literally mean zero; it means "undefined" or
|
|
"as big as possible," depending on the context.
|
|
See the explanations of particular parameters
|
|
that use <varname>size_spec</varname>
|
|
for details on how they interpret its use.
|
|
</para>
|
|
<para>
|
|
Numeric values can optionally be followed by a
|
|
scaling factor:
|
|
<userinput>K</userinput> or <userinput>k</userinput>
|
|
for kilobytes,
|
|
<userinput>M</userinput> or <userinput>m</userinput>
|
|
for megabytes, and
|
|
<userinput>G</userinput> or <userinput>g</userinput>
|
|
for gigabytes, which scale by 1024, 1024*1024, and
|
|
1024*1024*1024 respectively.
|
|
</para>
|
|
<para>
|
|
<varname>unlimited</varname> generally means
|
|
"as big as possible," and is usually the best
|
|
way to safely set a very large number.
|
|
</para>
|
|
<para>
|
|
<varname>default</varname>
|
|
uses the limit that was in force when the server was started.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>size_or_percent</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A <varname>size_spec</varname> or integer value
|
|
followed by "%" to represent percent.
|
|
</para>
|
|
<para>
|
|
The behavior is exactly the same as
|
|
<varname>size_spec</varname>, but
|
|
<varname>size_or_percent</varname> also allows
|
|
specifying a positive integer value followed by the
|
|
"%"" sign to represent percent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>yes_or_no</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Either <userinput>yes</userinput> or <userinput>no</userinput>.
|
|
The words <userinput>true</userinput> and <userinput>false</userinput> are
|
|
also accepted, as are the numbers <userinput>1</userinput>
|
|
and <userinput>0</userinput>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>dialup_option</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
One of <userinput>yes</userinput>,
|
|
<userinput>no</userinput>, <userinput>notify</userinput>,
|
|
<userinput>notify-passive</userinput>, <userinput>refresh</userinput>, or
|
|
<userinput>passive</userinput>.
|
|
When used in a zone, <userinput>notify-passive</userinput>,
|
|
<userinput>refresh</userinput>, and <userinput>passive</userinput>
|
|
are restricted to secondary and stub zones.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<section xml:id="address_match_lists"><info><title>Address Match Lists</title></info>
|
|
|
|
<section><info><title>Syntax</title></info>
|
|
|
|
<programlisting><replaceable>address_match_list</replaceable> = <replaceable>address_match_list_element</replaceable> <command>;</command> ...
|
|
|
|
<replaceable>address_match_list_element</replaceable> = [ <command>!</command> ] ( <replaceable>ip_address</replaceable> | <replaceable>ip_prefix</replaceable> |
|
|
<command>key</command> <replaceable>key_id</replaceable> | <replaceable>acl_name</replaceable> | <command>{</command> <replaceable>address_match_list</replaceable> <command>}</command> )
|
|
</programlisting>
|
|
|
|
</section>
|
|
<section><info><title>Definition and Usage</title></info>
|
|
|
|
<para>
|
|
Address match lists are primarily used to determine access
|
|
control for various server operations. They are also used in
|
|
the <command>listen-on</command> and <command>sortlist</command>
|
|
statements. The elements which constitute an address match
|
|
list can be any of the following:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<simpara>an IP address (IPv4 or IPv6)</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>an IP prefix (in "/" notation)</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
a key ID, as defined by the <command>key</command>
|
|
statement
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>the name of an address match list defined with
|
|
the <command>acl</command> statement
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>a nested address match list enclosed in braces</simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
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 <command>acl</command>
|
|
statement.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
When a given IP address or prefix is compared to an address
|
|
match list, the comparison takes place in approximately O(1)
|
|
time. However, key comparisons require that the list of keys
|
|
be traversed until a matching key is found, and therefore may
|
|
be somewhat slower.
|
|
</para>
|
|
|
|
<para>
|
|
The interpretation of a match depends on whether the list is being
|
|
used for access control, defining <command>listen-on</command> ports, or in a
|
|
<command>sortlist</command>, and whether the element was negated.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<command>allow-notify</command>,
|
|
<command>allow-recursion</command>,
|
|
<command>allow-recursion-on</command>,
|
|
<command>allow-query</command>,
|
|
<command>allow-query-on</command>,
|
|
<command>allow-query-cache</command>,
|
|
<command>allow-query-cache-on</command>,
|
|
<command>allow-transfer</command>,
|
|
<command>allow-update</command>,
|
|
<command>allow-update-forwarding</command>,
|
|
<command>blackhole</command>, and
|
|
<command>keep-response-order</command> all use address match
|
|
lists. Similarly, the <command>listen-on</command> option causes the
|
|
server to refuse queries on any of the machine's
|
|
addresses which do not match the list.
|
|
</para>
|
|
|
|
<para>
|
|
Order of insertion is significant. If more than one element
|
|
in an ACL is found to match a given IP address or prefix,
|
|
preference is given to the one that came
|
|
<emphasis>first</emphasis> in the ACL definition.
|
|
Because of this first-match behavior, 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
|
|
<command>1.2.3/24; ! 1.2.3.13;</command>
|
|
the 1.2.3.13 element is completely useless because the
|
|
algorithm matches any lookup for 1.2.3.13 to the 1.2.3/24
|
|
element. Using <command>! 1.2.3.13; 1.2.3/24</command> fixes
|
|
that problem by blocking 1.2.3.13 via the negation, but
|
|
all other 1.2.3.* hosts pass through.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="comment_syntax"><info><title>Comment Syntax</title></info>
|
|
|
|
<para>
|
|
The <acronym>BIND</acronym> 9 comment syntax allows
|
|
comments to appear
|
|
anywhere that whitespace may appear in a <acronym>BIND</acronym> configuration
|
|
file. To appeal to programmers of all kinds, they can be written
|
|
in the C, C++, or shell/perl style.
|
|
</para>
|
|
|
|
<section><info><title>Syntax</title></info>
|
|
|
|
<para>
|
|
<programlisting>/* This is a <acronym>BIND</acronym> comment as in C */</programlisting>
|
|
<programlisting>// This is a <acronym>BIND</acronym> comment as in C++</programlisting>
|
|
<programlisting># This is a <acronym>BIND</acronym> comment as in common Unix shells
|
|
# and perl</programlisting>
|
|
</para>
|
|
</section>
|
|
<section><info><title>Definition and Usage</title></info>
|
|
|
|
<para>
|
|
Comments may appear anywhere that whitespace may appear in
|
|
a <acronym>BIND</acronym> configuration file.
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
C-style comments cannot be nested. For example, the following
|
|
is not valid because the entire comment ends with the first */:
|
|
</para>
|
|
<para>
|
|
|
|
<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. */
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
For example:
|
|
</para>
|
|
<para>
|
|
|
|
<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.
|
|
</programlisting>
|
|
|
|
</para>
|
|
<para>
|
|
Shell-style (or perl-style) comments start
|
|
with the character <literal>#</literal> (number sign)
|
|
and continue to the end of the
|
|
physical line, as in C++ comments.
|
|
For example:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<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.
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<warning>
|
|
<para>
|
|
The semicolon (";") character
|
|
cannot start a comment, unlike in a zone file. The
|
|
semicolon indicates the end of a configuration
|
|
statement.
|
|
</para>
|
|
</warning>
|
|
</section>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="Configuration_File_Grammar"><info><title>Configuration File Grammar</title></info>
|
|
|
|
<para>
|
|
A <acronym>BIND</acronym> 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 sub-statements, which are also
|
|
terminated with a semicolon.
|
|
</para>
|
|
|
|
<para>
|
|
The following statements are supported:
|
|
</para>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.336in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.778in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>acl</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Defines a named IP address
|
|
matching list, for access control and other uses.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>controls</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Declares control channels to be used
|
|
by the <command>rndc</command> utility.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>include</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Includes a file.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>key</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Specifies key information for use in
|
|
authentication and authorization using TSIG.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>logging</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Specifies what information the server logs and where
|
|
the log messages are sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>lwres</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Configures <command>named</command> to
|
|
also act as a lightweight resolver daemon (<command>lwresd</command>).
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>masters</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Defines a named list of primary servers for
|
|
inclusion in stub and secondary zones'
|
|
<command>masters</command> or
|
|
<command>also-notify</command> lists.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>options</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Controls global server configuration
|
|
options and sets defaults for other statements.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>server</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Sets certain configuration options on
|
|
a per-server basis.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>statistics-channels</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Declares communication channels to get access to
|
|
<command>named</command> statistics.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>trusted-keys</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Defines trusted DNSSEC keys.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>managed-keys</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Lists DNSSEC keys to be kept up-to-date
|
|
using RFC 5011 trust anchor maintenance.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>view</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Defines a view.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>zone</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Defines a zone.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>
|
|
The <command>logging</command> and
|
|
<command>options</command> statements may only occur once
|
|
per
|
|
configuration.
|
|
</para>
|
|
|
|
<section xml:id="acl_grammar"><info><title><command>acl</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="acl.grammar.xml"/>
|
|
</section>
|
|
<section xml:id="acl"><info><title><command>acl</command> Statement Definition and
|
|
Usage</title></info>
|
|
|
|
<para>
|
|
The <command>acl</command> statement assigns a symbolic
|
|
name to an address match list. It gets its name from one of the primary
|
|
uses of address match lists: Access Control Lists (ACLs).
|
|
</para>
|
|
|
|
<para>
|
|
The following ACLs are built-in:
|
|
</para>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.130in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>any</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Matches all hosts.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>none</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Matches no hosts.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>localhost</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Matches the IPv4 and IPv6 addresses of all network
|
|
interfaces on the system. When addresses are
|
|
added or removed, the <command>localhost</command>
|
|
ACL element is updated to reflect the changes.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>localnets</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Matches any host on an IPv4 or IPv6 network
|
|
for which the system has an interface.
|
|
When addresses are added or removed,
|
|
the <command>localnets</command>
|
|
ACL element is updated to reflect the changes.
|
|
Some systems do not provide a way to determine the prefix
|
|
lengths of
|
|
local IPv6 addresses;
|
|
in such cases, <command>localnets</command>
|
|
only matches the local
|
|
IPv6 addresses, just like <command>localhost</command>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
<section xml:id="controls_grammar"><info><title><command>controls</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="controls.grammar.xml"/>
|
|
</section>
|
|
|
|
<section xml:id="controls_statement_definition_and_usage"><info><title><command>controls</command> Statement Definition and
|
|
Usage</title></info>
|
|
|
|
<para>
|
|
The <command>controls</command> statement declares control
|
|
channels to be used by system administrators to manage the
|
|
operation of the name server. These control channels are
|
|
used by the <command>rndc</command> utility to send
|
|
commands to and retrieve non-DNS results from a name server.
|
|
</para>
|
|
|
|
<para>
|
|
An <command>inet</command> control channel is a TCP socket
|
|
listening at the specified <command>ip_port</command> on the
|
|
specified <command>ip_addr</command>, which can be an IPv4 or IPv6
|
|
address. An <command>ip_addr</command> of <literal>*</literal> (asterisk) is
|
|
interpreted as the IPv4 wildcard address; connections are
|
|
accepted on any of the system's IPv4 addresses.
|
|
To listen on the IPv6 wildcard address,
|
|
use an <command>ip_addr</command> of <literal>::</literal>.
|
|
If <command>rndc</command> is only used on the local host,
|
|
using the loopback address (<literal>127.0.0.1</literal>
|
|
or <literal>::1</literal>) is recommended for maximum security.
|
|
</para>
|
|
|
|
<para>
|
|
If no port is specified, port 953 is used. The asterisk
|
|
"<literal>*</literal>" cannot be used for <command>ip_port</command>.
|
|
</para>
|
|
|
|
<para>
|
|
The ability to issue commands over the control channel is
|
|
restricted by the <command>allow</command> and
|
|
<command>keys</command> clauses.
|
|
Connections to the control channel are permitted based on the
|
|
<command>address_match_list</command>. This is for simple
|
|
IP address-based filtering only; any <command>key_id</command>
|
|
elements of the <command>address_match_list</command>
|
|
are ignored.
|
|
</para>
|
|
|
|
<para>
|
|
A <command>unix</command> control channel is a Unix domain
|
|
socket listening at the specified path in the file system.
|
|
Access to the socket is specified by the <command>perm</command>,
|
|
<command>owner</command>, and <command>group</command> clauses.
|
|
Note on some platforms (SunOS and Solaris), the permissions
|
|
(<command>perm</command>) are applied to the parent directory
|
|
as the permissions on the socket itself are ignored.
|
|
</para>
|
|
|
|
<para>
|
|
The primary authorization mechanism of the command
|
|
channel is the <command>key_list</command>, which
|
|
contains a list of <command>key_id</command>s.
|
|
Each <command>key_id</command> in the <command>key_list</command>
|
|
is authorized to execute commands over the control channel.
|
|
See <xref linkend="rndc"/> in <xref linkend="admin_tools"/>)
|
|
for information about configuring keys in <command>rndc</command>.
|
|
</para>
|
|
|
|
<para>
|
|
If the <command>read-only</command> clause is enabled, the
|
|
control channel is limited to the following set of read-only
|
|
commands: <command>nta -dump</command>,
|
|
<command>null</command>, <command>status</command>,
|
|
<command>showzone</command>, <command>testgen</command>, and
|
|
<command>zonestatus</command>. By default,
|
|
<command>read-only</command> is not enabled and the control
|
|
channel allows read-write access.
|
|
</para>
|
|
|
|
<para>
|
|
If no <command>controls</command> statement is present,
|
|
<command>named</command> sets 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 <command>controls</command> statement
|
|
is present but does not have a <command>keys</command> clause,
|
|
<command>named</command> attempts to load the command channel key
|
|
from the file <filename>rndc.key</filename> in
|
|
<filename>/etc</filename> (or whatever <varname>sysconfdir</varname>
|
|
was specified when <acronym>BIND</acronym> was built).
|
|
To create an <filename>rndc.key</filename> file, run
|
|
<userinput>rndc-confgen -a</userinput>.
|
|
</para>
|
|
|
|
<para>
|
|
The key name and the size of the secret cannot be easily changed; if it
|
|
is desirable to change those things, make a
|
|
<filename>rndc.conf</filename> with a custom key. The <filename>rndc.key</filename> file
|
|
also has its
|
|
permissions set such that only the owner of the file (the user that
|
|
<command>named</command> is running as) can access it.
|
|
For greater flexibility in allowing other users to access
|
|
<command>rndc</command> commands, create
|
|
a
|
|
<filename>rndc.conf</filename> file and make it group-readable by a group
|
|
that contains the users who should have access.
|
|
</para>
|
|
|
|
<para>
|
|
To disable the command channel, use an empty
|
|
<command>controls</command> statement:
|
|
<command>controls { };</command>.
|
|
</para>
|
|
|
|
</section>
|
|
<section xml:id="include_grammar"><info><title><command>include</command> Statement Grammar</title></info>
|
|
|
|
<programlisting><command>include</command> <replaceable>filename</replaceable><command>;</command></programlisting>
|
|
</section>
|
|
<section xml:id="include_statement"><info><title><command>include</command> Statement Definition and Usage</title></info>
|
|
|
|
<para>
|
|
The <command>include</command> statement inserts the
|
|
specified file at the point where the <command>include</command>
|
|
statement is encountered. The <command>include</command>
|
|
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 the name server.
|
|
</para>
|
|
|
|
</section>
|
|
<section xml:id="key_grammar"><info><title><command>key</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="key.grammar.xml"/>
|
|
</section>
|
|
|
|
<section xml:id="key_statement"><info><title><command>key</command> Statement Definition and Usage</title></info>
|
|
|
|
<para>
|
|
The <command>key</command> statement defines a shared
|
|
secret key for use with TSIG (see <xref linkend="tsig"/>)
|
|
or the command channel
|
|
(see <xref linkend="controls_statement_definition_and_usage"/>).
|
|
</para>
|
|
|
|
<para>
|
|
The <command>key</command> statement can occur at the
|
|
top level
|
|
of the configuration file or inside a <command>view</command>
|
|
statement. Keys defined in top-level <command>key</command>
|
|
statements can be used in all views. Keys intended for use in
|
|
a <command>controls</command> statement
|
|
(see <xref linkend="controls_statement_definition_and_usage"/>)
|
|
must be defined at the top level.
|
|
</para>
|
|
|
|
<para>
|
|
The <replaceable>key_id</replaceable>, also known as the
|
|
key name, is a domain name that uniquely identifies the key. It can
|
|
be used in a <command>server</command>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
The <replaceable>algorithm_id</replaceable> is a string
|
|
that specifies a security/authentication algorithm. The
|
|
<command>named</command> server supports <literal>hmac-md5</literal>,
|
|
<literal>hmac-sha1</literal>, <literal>hmac-sha224</literal>,
|
|
<literal>hmac-sha256</literal>, <literal>hmac-sha384</literal>,
|
|
and <literal>hmac-sha512</literal> TSIG authentication.
|
|
Truncated hashes are supported by appending the minimum
|
|
number of required bits preceded by a dash, e.g.,
|
|
<literal>hmac-sha1-80</literal>. The
|
|
<replaceable>secret_string</replaceable> is the secret
|
|
to be used by the algorithm, and is treated as a Base64-encoded string.
|
|
</para>
|
|
|
|
</section>
|
|
<section xml:id="logging_grammar"><info><title><command>logging</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="logging.grammar.xml"/>
|
|
</section>
|
|
|
|
<section xml:id="logging_statement"><info><title><command>logging</command> Statement Definition and Usage</title></info>
|
|
|
|
<para>
|
|
The <command>logging</command> statement configures a
|
|
wide
|
|
variety of logging options for the name server. Its <command>channel</command> phrase
|
|
associates output methods, format options, and severity levels with
|
|
a name that can then be used with the <command>category</command> phrase
|
|
to select how various classes of messages are logged.
|
|
</para>
|
|
<para>
|
|
Only one <command>logging</command> statement is used to
|
|
define
|
|
as many channels and categories as desired. If there is no <command>logging</command> statement,
|
|
the logging configuration is:
|
|
</para>
|
|
|
|
<programlisting>logging {
|
|
category default { default_syslog; default_debug; };
|
|
category unmatched { null; };
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
If <command>named</command> is started with the
|
|
<option>-L</option> option, it logs to the specified file
|
|
at startup, instead of using syslog. In this case the logging
|
|
configuration is:
|
|
</para>
|
|
|
|
<programlisting>logging {
|
|
category default { default_logfile; default_debug; };
|
|
category unmatched { null; };
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
The logging configuration
|
|
is only established when
|
|
the entire configuration file has been parsed. When the server starts up, all logging messages
|
|
regarding syntax errors in the configuration file go to the default
|
|
channels, or to standard error if the <option>-g</option> option
|
|
was specified.
|
|
</para>
|
|
|
|
<section xml:id="channel"><info><title>The <command>channel</command> Phrase</title></info>
|
|
|
|
<para>
|
|
All log output goes to one or more <emphasis>channels</emphasis>;
|
|
there is no limit to the number of channels that can be created.
|
|
</para>
|
|
|
|
<para>
|
|
Every channel definition must include a destination clause that
|
|
says whether messages selected for the channel go to a file, go to a
|
|
particular syslog facility, go to the standard error stream, or are
|
|
discarded. The definition can optionally also limit the message severity level
|
|
that is accepted by the channel (the default is
|
|
<command>info</command>), and whether to include a
|
|
<command>named</command>-generated time stamp, the
|
|
category name,
|
|
and/or the severity level (the default is not to include any).
|
|
</para>
|
|
|
|
<para>
|
|
The <command>null</command> destination clause
|
|
causes all messages sent to the channel to be discarded;
|
|
in that case, other options for the channel are meaningless.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>file</command> destination clause directs
|
|
the channel
|
|
to a disk file. It can include limitations
|
|
both on how large the file is allowed to become, and on how many
|
|
versions
|
|
of the file are saved each time the file is opened.
|
|
</para>
|
|
|
|
<para>
|
|
If the <command>versions</command> log file
|
|
option is used, then
|
|
<command>named</command> retains that many backup
|
|
versions of the file by
|
|
renaming them when opening. For example, to keep
|
|
three old versions
|
|
of the file <filename>lamers.log</filename>, just
|
|
before it is opened
|
|
<filename>lamers.log.1</filename> is renamed to
|
|
<filename>lamers.log.2</filename>, <filename>lamers.log.0</filename> is renamed
|
|
to <filename>lamers.log.1</filename>, and <filename>lamers.log</filename> is
|
|
renamed to <filename>lamers.log.0</filename>.
|
|
The <command>versions unlimited</command> option can be set to
|
|
not limit
|
|
the number of versions.
|
|
If a <command>size</command> 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.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>size</command> option for files is used
|
|
to limit log
|
|
growth. If the file ever exceeds the size, then <command>named</command>
|
|
stops writing to the file unless it also has a <command>versions</command> 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
|
|
<command>versions</command> option, no more data is
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Here is an example using the <command>size</command> and
|
|
<command>versions</command> options:
|
|
</para>
|
|
|
|
<programlisting>channel an_example_channel {
|
|
file "example.log" versions 3 size 20m;
|
|
print-time yes;
|
|
print-category yes;
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
The <command>syslog</command> destination clause
|
|
directs the
|
|
channel to the system log. Its argument is a
|
|
syslog facility as described in the <command>syslog</command> man
|
|
page. Known facilities are <command>kern</command>, <command>user</command>,
|
|
<command>mail</command>, <command>daemon</command>, <command>auth</command>,
|
|
<command>syslog</command>, <command>lpr</command>, <command>news</command>,
|
|
<command>uucp</command>, <command>cron</command>, <command>authpriv</command>,
|
|
<command>ftp</command>, <command>local0</command>, <command>local1</command>,
|
|
<command>local2</command>, <command>local3</command>, <command>local4</command>,
|
|
<command>local5</command>, <command>local6</command>, and
|
|
<command>local7</command>; however, not all facilities
|
|
are supported on
|
|
all operating systems.
|
|
How <command>syslog</command> handles messages
|
|
sent to
|
|
this facility is described in the <command>syslog.conf</command> man
|
|
page. On a system which uses a very old version of <command>syslog</command>, which
|
|
only uses two arguments to the <command>openlog()</command> function,
|
|
then this clause is silently ignored.
|
|
</para>
|
|
<para>
|
|
On Windows machines, syslog messages are directed to the EventViewer.
|
|
</para>
|
|
<para>
|
|
The <command>severity</command> clause works like <command>syslog</command>'s
|
|
"priorities," except that they can also be used when writing
|
|
straight to a file rather than using <command>syslog</command>.
|
|
Messages which are not at least of the severity level given are
|
|
not selected for the channel; messages of higher severity
|
|
levels
|
|
are accepted.
|
|
</para>
|
|
<para>
|
|
When using <command>syslog</command>, the <command>syslog.conf</command> priorities
|
|
also determine what eventually passes through. For example,
|
|
defining a channel facility and severity as <command>daemon</command> and <command>debug</command>, but
|
|
only logging <command>daemon.warning</command> via <command>syslog.conf</command>,
|
|
causes messages of severity <command>info</command> and
|
|
<command>notice</command> to
|
|
be dropped. If the situation were reversed, with <command>named</command> writing
|
|
messages of only <command>warning</command> or higher,
|
|
then <command>syslogd</command> would
|
|
print all messages it received from the channel.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>stderr</command> 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, as
|
|
when debugging a configuration, for example.
|
|
</para>
|
|
|
|
<para>
|
|
The server can supply extensive debugging information when
|
|
it is in debugging mode. If the server's global debug level is
|
|
greater
|
|
than zero, debugging mode is active. The global debug
|
|
level is set either by starting the <command>named</command> server
|
|
with the <option>-d</option> flag followed by a positive integer,
|
|
or by running <command>rndc trace</command>.
|
|
The global debug level
|
|
can be set to zero, and debugging mode turned off, by running <command>rndc
|
|
notrace</command>. All debugging messages in the server have a debug
|
|
level; higher debug levels give more detailed output. Channels
|
|
that specify a specific debug severity, for example:
|
|
</para>
|
|
|
|
<programlisting>channel specific_debug_level {
|
|
file "foo";
|
|
severity debug 3;
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
get debugging output of level 3 or less any time the
|
|
server is in debugging mode, regardless of the global debugging
|
|
level. Channels with <command>dynamic</command>
|
|
severity use the
|
|
server's global debug level to determine what messages to print.
|
|
</para>
|
|
<para>
|
|
If <command>print-time</command> is set to
|
|
<userinput>yes</userinput>, then the date and time are logged.
|
|
<command>print-time</command> may be specified for a
|
|
<command>syslog</command> channel, but is usually
|
|
unnecessary since <command>syslog</command> also logs
|
|
the date and time. If <command>print-category</command> is
|
|
set to <userinput>yes</userinput>, then the
|
|
category of the message is logged as well. Finally, if
|
|
<command>print-severity</command> is set, then the severity
|
|
level of the message is logged.
|
|
The <command>print-</command> options may
|
|
be used in any combination, and are always printed in the
|
|
following
|
|
order: time, category, severity. Here is an example where all
|
|
three <command>print-</command> options
|
|
are on:
|
|
</para>
|
|
|
|
<para>
|
|
<computeroutput>28-Feb-2000 15:05:32.863 general: notice: running</computeroutput>
|
|
</para>
|
|
|
|
<para>
|
|
If <command>buffered</command> has been turned on, the output
|
|
to files is not flushed after each log entry. By default
|
|
all log messages are flushed.
|
|
</para>
|
|
|
|
<para>
|
|
There are four predefined channels that are used for
|
|
<command>named</command>'s default logging, as follows.
|
|
If <command>named</command> is started with the
|
|
<option>-L</option>, then a
|
|
fifth channel, <command>default_logfile</command>, is added.
|
|
How they are
|
|
used is described in <xref linkend="the_category_phrase"/>.
|
|
</para>
|
|
|
|
<programlisting>channel default_syslog {
|
|
// send to syslog's daemon facility
|
|
syslog daemon;
|
|
// only send priority info and higher
|
|
severity info;
|
|
};
|
|
|
|
channel default_debug {
|
|
// write to named.run in the working directory
|
|
// Note: stderr is used instead of "named.run" if
|
|
// the server is started with the '-g' option.
|
|
file "named.run";
|
|
// log at the server's current debug level
|
|
severity dynamic;
|
|
};
|
|
|
|
channel default_stderr {
|
|
// writes to stderr
|
|
stderr;
|
|
// only send priority info and higher
|
|
severity info;
|
|
};
|
|
|
|
channel null {
|
|
// toss anything sent to this channel
|
|
null;
|
|
};
|
|
|
|
channel default_logfile {
|
|
// this channel is only present if named is
|
|
// started with the -L option, whose argument
|
|
// provides the file name
|
|
file "...";
|
|
// log at the server's current debug level
|
|
severity dynamic;
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
The <command>default_debug</command> channel has the
|
|
special
|
|
property that it only produces output when the server's debug
|
|
level is
|
|
non-zero. It normally writes to a file called <filename>named.run</filename>
|
|
in the server's working directory.
|
|
</para>
|
|
|
|
<para>
|
|
For security reasons, when the <option>-u</option>
|
|
command-line option is used, the <filename>named.run</filename> file
|
|
is created only after <command>named</command> has
|
|
changed to the
|
|
new UID, and any debug output generated while <command>named</command> is
|
|
starting - and still running as root - is discarded.
|
|
To capture this output, run the server with the <option>-L</option>
|
|
option to specify a default logfile, or the <option>-g</option>
|
|
option to log to standard error which can be redirected to a file.
|
|
</para>
|
|
|
|
<para>
|
|
Once a channel is defined, it cannot be redefined.
|
|
The built-in channels cannot be altered directly, but
|
|
the default logging can be modified by pointing categories at defined channels.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="the_category_phrase"><info><title>The <command>category</command> Phrase</title></info>
|
|
|
|
<para>
|
|
There are many categories, so desired logs
|
|
can be sent anywhere while unwanted logs are ignored. If
|
|
a list of channels is not specified for a category, log
|
|
messages
|
|
in that category are sent to the <command>default</command> category
|
|
instead. If no default category is specified, the following
|
|
"default default" is used:
|
|
</para>
|
|
|
|
<programlisting>category default { default_syslog; default_debug; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
If <command>named</command> is started with the
|
|
<option>-L</option> option, the default category is:
|
|
</para>
|
|
|
|
<programlisting>category default { default_logfile; default_debug; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
As an example, let's say a user wants to log security events to
|
|
a file, but also wants to keep the default logging behavior. They would
|
|
specify the following:
|
|
</para>
|
|
|
|
<programlisting>channel my_security_channel {
|
|
file "my_security_file";
|
|
severity info;
|
|
};
|
|
category security {
|
|
my_security_channel;
|
|
default_syslog;
|
|
default_debug;
|
|
};</programlisting>
|
|
|
|
<para>
|
|
To discard all messages in a category, specify the <command>null</command> channel:
|
|
</para>
|
|
|
|
<programlisting>category xfer-out { null; };
|
|
category notify { null; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
The following are the available categories and brief descriptions
|
|
of the types of log information they contain. More
|
|
categories may be added in future <acronym>BIND</acronym> releases.
|
|
</para>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="logging-categories.xml"/>
|
|
</section>
|
|
<section xml:id="query_errors"><info><title>The <command>query-errors</command> Category</title></info>
|
|
<para>
|
|
The <command>query-errors</command> category is
|
|
used to indicate why and how specific queries resulted in
|
|
responses which indicate an error. Normally, these messages
|
|
will be logged at <command>debug</command> logging levels;
|
|
note, however, that if query logging is active, some are
|
|
logged at <command>info</command>. The logging levels are
|
|
described below:
|
|
</para>
|
|
|
|
<para>
|
|
At <command>debug</command> level 1 or higher - or at
|
|
<command>info</command>, when query logging is active - each
|
|
response with response code SERVFAIL is logged as follows:
|
|
</para>
|
|
<para>
|
|
<computeroutput>client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880</computeroutput>
|
|
</para>
|
|
<para>
|
|
This means an error resulting in SERVFAIL was detected at line
|
|
3880 of source file <filename>query.c</filename>. Log messages
|
|
of this level are particularly helpful in identifying the cause of
|
|
SERVFAIL for an authoritative server.
|
|
</para>
|
|
<para>
|
|
At <command>debug</command> level 2 or higher, detailed
|
|
context information about recursive resolutions that resulted in
|
|
SERVFAIL is logged. The log message looks like this:
|
|
</para>
|
|
<para>
|
|
<!-- NOTE: newlines and some spaces added so this would fit on page -->
|
|
<programlisting>
|
|
fetch completed at resolver.c:2970 for www.example.com/A
|
|
in 10.000183: timed out/success [domain:example.com,
|
|
referral:2,restart:7,qrysent:8,timeout:5,lame:0,quota:0,neterr:0,
|
|
badresp:1,adberr:0,findfail:0,valfail:0]
|
|
</programlisting>
|
|
</para>
|
|
<para>
|
|
The first part before the colon shows that a recursive
|
|
resolution for AAAA records of www.example.com completed
|
|
in 10.000183 seconds, and the final result that led to the
|
|
SERVFAIL was determined at line 2970 of source file
|
|
<filename>resolver.c</filename>.
|
|
</para>
|
|
<para>
|
|
The next part shows the detected final result and the
|
|
latest result of DNSSEC validation. The latter is always
|
|
"success" when no validation attempt was made. In this example,
|
|
this query probably resulted in SERVFAIL because all name
|
|
servers are down or unreachable, leading to a timeout in 10
|
|
seconds. DNSSEC validation was probably not attempted.
|
|
</para>
|
|
<para>
|
|
The last part, enclosed in square brackets, shows statistics
|
|
collected for this particular resolution attempt.
|
|
The <varname>domain</varname> field shows the deepest zone that
|
|
the resolver reached; it is the zone where the error was
|
|
finally detected. The meaning of the other fields is
|
|
summarized in the following table.
|
|
</para>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>referral</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of referrals the resolver received
|
|
throughout the resolution process.
|
|
In the above example there are two, which are most
|
|
likely com and example.com.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>restart</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of cycles that the resolver tried
|
|
remote servers at the <varname>domain</varname>
|
|
zone.
|
|
In each cycle, the resolver sends one query
|
|
(possibly resending it, depending on the response)
|
|
to each known name server of
|
|
the <varname>domain</varname> zone.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>qrysent</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of queries the resolver sent at the
|
|
<varname>domain</varname> zone.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>timeout</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of timeouts since the resolver
|
|
received the last response.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>lame</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of lame servers the resolver detected
|
|
at the <varname>domain</varname> zone.
|
|
A server is detected to be lame either by an
|
|
invalid response or as a result of lookup in
|
|
BIND 9's address database (ADB), where lame
|
|
servers are cached.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>quota</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of times the resolver was unable
|
|
to send a query because it had exceeded the
|
|
permissible fetch quota for a server.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>neterr</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of erroneous results that the
|
|
resolver encountered in sending queries
|
|
at the <varname>domain</varname> zone.
|
|
One common case is when the remote server is
|
|
unreachable and the resolver receives an "ICMP
|
|
unreachable" error message.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>badresp</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of unexpected responses (other than
|
|
<varname>lame</varname>) to queries sent by the
|
|
resolver at the <varname>domain</varname> zone.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>adberr</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Failures in finding remote server addresses
|
|
of the <varname>domain</varname> zone in the ADB.
|
|
One common case of this is that the remote
|
|
server's name does not have any address records.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>findfail</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Failures to resolve remote server addresses.
|
|
This is a total number of failures throughout
|
|
the resolution process.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><varname>valfail</varname></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Failures of DNSSEC validation.
|
|
Validation failures are counted throughout
|
|
the resolution process (not limited to
|
|
the <varname>domain</varname> zone), but should
|
|
only happen in <varname>domain</varname>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<para>
|
|
At <command>debug</command> level 3 or higher, the same
|
|
messages as those at <command>debug</command> level 1 are
|
|
logged for errors other than SERVFAIL. Note that negative
|
|
responses such as NXDOMAIN are not errors, and are not logged
|
|
at this debug level.
|
|
</para>
|
|
<para>
|
|
At <command>debug</command> level 4 or higher, the
|
|
detailed context information logged at <command>debug</command>
|
|
level 2 is logged for errors other than SERVFAIL and
|
|
for negative responses such as NXDOMAIN.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="lwres_grammar"><info><title><command>lwres</command> Statement Grammar</title></info>
|
|
|
|
<para>
|
|
This is the grammar of the <command>lwres</command>
|
|
statement in the <filename>named.conf</filename> file:
|
|
</para>
|
|
|
|
<programlisting><command>lwres {</command>
|
|
[ <command>listen-on {</command>
|
|
( <replaceable>ip_addr</replaceable> [ <command>port</command> <replaceable>ip_port</replaceable> ] [ <command>dscp</command> <replaceable>ip_dscp</replaceable> ] <command>;</command> )
|
|
...
|
|
<command>};</command> ]
|
|
[ <command>view</command> <replaceable>view_name</replaceable><command>;</command> ]
|
|
[ <command>search {</command> <replaceable>domain_name</replaceable> <command>;</command> ... <command>};</command> ]
|
|
[ <command>ndots</command> <replaceable>number</replaceable><command>;</command> ]
|
|
[ <command>lwres-tasks</command> <replaceable>number</replaceable><command>;</command> ]
|
|
[ <command>lwres-clients</command> <replaceable>number</replaceable><command>;</command> ]
|
|
<command>};</command>
|
|
</programlisting>
|
|
|
|
</section>
|
|
<section xml:id="lwres_statement"><info><title><command>lwres</command> Statement Definition and Usage</title></info>
|
|
|
|
<para>
|
|
The <command>lwres</command> statement configures the
|
|
name
|
|
server to also act as a lightweight resolver server. (See
|
|
<xref linkend="lwresd"/>.) There may be multiple
|
|
<command>lwres</command> statements configuring
|
|
lightweight resolver servers with different properties.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>listen-on</command> statement specifies a
|
|
list of
|
|
IPv4 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 are accepted on
|
|
127.0.0.1,
|
|
port 921.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>view</command> statement binds this
|
|
instance of a
|
|
lightweight resolver daemon to a view in the DNS namespace, so that
|
|
the
|
|
response is constructed in the same manner as a normal DNS
|
|
query
|
|
matching this view. If this statement is omitted, the default view
|
|
is
|
|
used; if there is no default view, an error is triggered.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>search</command> statement is equivalent to
|
|
the
|
|
<command>search</command> statement in
|
|
<filename>/etc/resolv.conf</filename>. It provides a
|
|
list of domains
|
|
which are appended to relative names in queries.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>ndots</command> statement is equivalent to
|
|
the
|
|
<command>ndots</command> statement in
|
|
<filename>/etc/resolv.conf</filename>. 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.
|
|
</para>
|
|
<para>
|
|
The <option>lwres-tasks</option> statement specifies the number
|
|
of worker threads the lightweight resolver dedicates to serving
|
|
clients. By default, the number is the same as the number of CPUs on
|
|
the system; this can be overridden using the <option>-n</option>
|
|
command-line option when starting the server.
|
|
</para>
|
|
<para>
|
|
The <option>lwres-clients</option> statement specifies
|
|
the number of client objects per thread the lightweight
|
|
resolver should create to serve client queries.
|
|
By default, if the lightweight resolver runs as a part
|
|
of <command>named</command>, 256 client objects are
|
|
created for each task; if it runs as <command>lwresd</command>,
|
|
1024 client objects are created for each thread. The maximum
|
|
value is 32768; higher values are silently ignored and
|
|
the maximum is used instead.
|
|
Note that setting too high a value may overconsume
|
|
system resources.
|
|
</para>
|
|
<para>
|
|
The maximum number of client queries that the lightweight
|
|
resolver can handle at any one time equals
|
|
<option>lwres-tasks</option> times <option>lwres-clients</option>.
|
|
</para>
|
|
</section>
|
|
<section xml:id="masters_grammar"><info><title><command>masters</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="masters.grammar.xml"/>
|
|
</section>
|
|
|
|
<section xml:id="masters_statement"><info><title><command>masters</command> Statement Definition and
|
|
Usage</title></info>
|
|
|
|
<para><command>masters</command>
|
|
lists allow for a common set of primaries to be easily used by
|
|
multiple stub and secondary zones in their <command>masters</command>
|
|
or <command>also-notify</command> lists.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="options_grammar"><info><title><command>options</command> Statement Grammar</title></info>
|
|
|
|
<para>
|
|
This is the grammar of the <command>options</command>
|
|
statement in the <filename>named.conf</filename> file:
|
|
</para>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="options.grammar.xml"/>
|
|
</section>
|
|
|
|
<section xml:id="options"><info><title><command>options</command> Statement Definition and
|
|
Usage</title></info>
|
|
|
|
<para>
|
|
The <command>options</command> statement sets up global
|
|
options
|
|
to be used by <acronym>BIND</acronym>. This statement
|
|
may appear only
|
|
once in a configuration file. If there is no <command>options</command>
|
|
statement, an options block with each option set to its default is
|
|
used.
|
|
</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>attach-cache</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option allows multiple views to share a single cache
|
|
database.
|
|
Each view has its own cache database by default, but
|
|
if multiple views have the same operational policy
|
|
for name resolution and caching, those views can
|
|
share a single cache to save memory, and possibly
|
|
improve resolution efficiency, by using this option.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>attach-cache</command> option
|
|
may also be specified in <command>view</command>
|
|
statements, in which case it overrides the
|
|
global <command>attach-cache</command> option.
|
|
</para>
|
|
|
|
<para>
|
|
The <replaceable>cache_name</replaceable> specifies
|
|
the cache to be shared.
|
|
When the <command>named</command> server configures
|
|
views which are supposed to share a cache, it
|
|
creates a cache with the specified name for the
|
|
first view of these sharing views.
|
|
The rest of the views simply refer to the
|
|
already-created cache.
|
|
</para>
|
|
|
|
<para>
|
|
One common configuration to share a cache is to
|
|
allow all views to share a single cache.
|
|
This can be done by specifying
|
|
<command>attach-cache</command> as a global
|
|
option with an arbitrary name.
|
|
</para>
|
|
|
|
<para>
|
|
Another possible operation is to allow a subset of
|
|
all views to share a cache while the others
|
|
retain their own caches.
|
|
For example, if there are three views A, B, and C,
|
|
and only A and B should share a cache, specify the
|
|
<command>attach-cache</command> option as a view of A (or
|
|
B)'s option, referring to the other view name:
|
|
</para>
|
|
|
|
<programlisting>
|
|
view "A" {
|
|
// this view has its own cache
|
|
...
|
|
};
|
|
view "B" {
|
|
// this view refers to A's cache
|
|
attach-cache "A";
|
|
};
|
|
view "C" {
|
|
// this view has its own cache
|
|
...
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
Views that share a cache must have the same policy
|
|
on configurable parameters that may affect caching.
|
|
The current implementation requires the following
|
|
configurable options be consistent among these
|
|
views:
|
|
<command>check-names</command>,
|
|
<command>cleaning-interval</command>,
|
|
<command>dnssec-accept-expired</command>,
|
|
<command>dnssec-validation</command>,
|
|
<command>max-cache-ttl</command>,
|
|
<command>max-ncache-ttl</command>,
|
|
<command>max-cache-size</command>, and
|
|
<command>zero-no-soa-ttl</command>.
|
|
</para>
|
|
|
|
<para>
|
|
Note that there may be other parameters that may
|
|
cause confusion if they are inconsistent for
|
|
different views that share a single cache.
|
|
For example, if these views define different sets of
|
|
forwarders that can return different answers for the
|
|
same question, sharing the answer does not make
|
|
sense or could even be harmful.
|
|
It is administrator's responsibility to ensure that
|
|
configuration differences in different views do
|
|
not cause disruption with a shared cache.
|
|
</para>
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>directory</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the working directory of the server.
|
|
Any non-absolute pathnames in the configuration file are
|
|
taken as relative to this directory. The default
|
|
location for most server output files
|
|
(e.g., <filename>named.run</filename>) is this directory.
|
|
If a directory is not specified, the working directory
|
|
defaults to "<filename>.</filename>", the directory from
|
|
which the server was started. The directory specified
|
|
should be an absolute path. It is
|
|
<emphasis>strongly recommended</emphasis>
|
|
that the directory be writable by the effective user
|
|
ID of the <command>named</command> process.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnstap</command></term>
|
|
<listitem>
|
|
<para>
|
|
<command>dnstap</command> is a fast, flexible method
|
|
for capturing and logging DNS traffic. Developed by
|
|
Robert Edmonds at Farsight Security, Inc., and supported
|
|
by multiple DNS implementations, <command>dnstap</command>
|
|
uses
|
|
<command>libfstrm</command> (a lightweight high-speed
|
|
framing library, see
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://github.com/farsightsec/fstrm">https://github.com/farsightsec/fstrm</link>) to send
|
|
event payloads which are encoded using Protocol Buffers
|
|
(<command>libprotobuf-c</command>, a mechanism for
|
|
serializing structured data developed
|
|
by Google, Inc.; see
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://developers.google.com/protocol-buffers/">https://developers.google.com/protocol-buffers</link>).
|
|
</para>
|
|
<para>
|
|
To enable <command>dnstap</command> at compile time,
|
|
the <command>fstrm</command> and <command>protobuf-c</command>
|
|
libraries must be available, and <acronym>BIND</acronym> must be configured with
|
|
<option>--enable-dnstap</option>.
|
|
</para>
|
|
<para>
|
|
The <command>dnstap</command> option is a bracketed list
|
|
of message types to be logged. These may be set differently
|
|
for each view. Supported types are <literal>client</literal>,
|
|
<literal>auth</literal>, <literal>resolver</literal>, and
|
|
<literal>forwarder</literal>. Specifying type
|
|
<literal>all</literal> causes all <command>dnstap</command>
|
|
messages to be logged, regardless of type.
|
|
</para>
|
|
<para>
|
|
Each type may take an additional argument to indicate whether
|
|
to log <literal>query</literal> messages or
|
|
<literal>response</literal> messages; if not specified,
|
|
both queries and responses are logged.
|
|
</para>
|
|
<para>
|
|
Example: To log all authoritative queries and responses,
|
|
recursive client responses, and upstream queries sent by
|
|
the resolver, use:
|
|
<programlisting>dnstap {
|
|
auth;
|
|
client response;
|
|
resolver query;
|
|
};
|
|
</programlisting>
|
|
</para>
|
|
<para>
|
|
Logged <command>dnstap</command> messages can be parsed
|
|
using the <command>dnstap-read</command> utility (see
|
|
<xref linkend="man.dnstap-read"/> for details).
|
|
</para>
|
|
<para>
|
|
For more information on <command>dnstap</command>, see
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://dnstap.info">http://dnstap.info</link>.
|
|
</para>
|
|
<para>
|
|
The fstrm library has a number of tunables that are exposed
|
|
in <filename>named.conf</filename>, and can be modified
|
|
if necessary to improve performance or prevent loss of data.
|
|
These are:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<simpara>
|
|
<command>fstrm-set-buffer-hint</command>: The
|
|
threshold number of bytes to accumulate in the output
|
|
buffer before forcing a buffer flush. The minimum is
|
|
1024, the maximum is 65536, and the default is 8192.
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
<command>fstrm-set-flush-timeout</command>: The number
|
|
of seconds to allow unflushed data to remain in the
|
|
output buffer. The minimum is 1 second, the maximum is
|
|
600 seconds (10 minutes), and the default is 1 second.
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
<command>fstrm-set-output-notify-threshold</command>:
|
|
The number of outstanding queue entries to allow on
|
|
an input queue before waking the I/O thread.
|
|
The minimum is 1 and the default is 32.
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
<command>fstrm-set-output-queue-model</command>:
|
|
The queuing semantics to use for queue
|
|
objects. The default is <literal>mpsc</literal>
|
|
(multiple producer, single consumer); the other
|
|
option is <literal>spsc</literal> (single producer,
|
|
single consumer).
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
<command>fstrm-set-input-queue-size</command>: The
|
|
number of queue entries to allocate for each
|
|
input queue. This value must be a power of 2.
|
|
The minimum is 2, the maximum is 16384, and
|
|
the default is 512.
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
<command>fstrm-set-output-queue-size</command>:
|
|
The number of queue entries to allocate for each
|
|
output queue. The minimum is 2, the maximum is
|
|
system-dependent and based on <option>IOV_MAX</option>,
|
|
and the default is 64.
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
<command>fstrm-set-reopen-interval</command>:
|
|
The number of seconds to wait between attempts to
|
|
reopen a closed output stream. The minimum is 1 second,
|
|
the maximum is 600 seconds (10 minutes), and the default
|
|
is 5 seconds.
|
|
</simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
Note that all of the above minimum, maximum, and default
|
|
values are set by the <command>libfstrm</command> library,
|
|
and may be subject to change in future versions of the
|
|
library. See the <command>libfstrm</command> documentation
|
|
for more information.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnstap-output</command></term>
|
|
<listitem>
|
|
<para>
|
|
This configures the path to which the <command>dnstap</command>
|
|
frame stream is sent if <command>dnstap</command>
|
|
is enabled at compile time and active.
|
|
</para>
|
|
<para>
|
|
The first argument is either <literal>file</literal> or
|
|
<literal>unix</literal>, indicating whether the destination
|
|
is a file or a Unix domain socket. The second argument
|
|
is the path of the file or socket. (Note: when using a
|
|
socket, <command>dnstap</command> messages are
|
|
only sent if another process such as
|
|
<command>fstrm_capture</command>
|
|
(provided with <command>libfstrm</command>) is listening on
|
|
the socket.)
|
|
</para>
|
|
<para>
|
|
<command>dnstap-output</command> can only be set globally
|
|
in <command>options</command>. Currently, it can only be
|
|
set once while <command>named</command> is running;
|
|
once set, it cannot be changed by
|
|
<command>rndc reload</command> or
|
|
<command>rndc reconfig</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnstap-identity</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies an <command>identity</command> string to send in
|
|
<command>dnstap</command> messages. If set to
|
|
<literal>hostname</literal>, which is the default, the
|
|
server's hostname is sent. If set to
|
|
<literal>none</literal>, no identity string is sent.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnstap-version</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a <command>version</command> string to send in
|
|
<command>dnstap</command> messages. The default is the
|
|
version number of the <acronym>BIND</acronym> release. If set to
|
|
<literal>none</literal>, no version string is sent.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>geoip-directory</command></term>
|
|
<listitem>
|
|
<para>
|
|
When <command>named</command> is compiled using the
|
|
MaxMind GeoIP2 geolocation API, or the legacy GeoIP API,
|
|
this specifies the directory containing GeoIP
|
|
database files. By default, the option is set based on
|
|
the prefix used to build the <command>libmaxminddb</command>
|
|
module; for example, if the library is installed in
|
|
<filename>/usr/local/lib</filename>, then the default
|
|
<command>geoip-directory</command> is
|
|
<filename>/usr/local/share/GeoIP</filename>. On Windows,
|
|
the default is the <command>named</command> working
|
|
directory. See <xref linkend="acl"/> for details about
|
|
<command>geoip</command> ACLs.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>key-directory</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the
|
|
directory where the public and private DNSSEC key files
|
|
should be found when performing a dynamic update of secure zones, if different than the current working
|
|
directory. (Note that this option has no effect on the
|
|
paths for files containing non-DNSSEC keys such as
|
|
<filename>bind.keys</filename>,
|
|
<filename>rndc.key</filename>, or
|
|
<filename>session.key</filename>.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>lmdb-mapsize</command></term>
|
|
<listitem>
|
|
<para>
|
|
When <command>named</command> is built with liblmdb,
|
|
this option sets a maximum size for the memory map of
|
|
the new-zone database (NZD) in LMDB database format.
|
|
This database is used to store configuration information
|
|
for zones added using <command>rndc addzone</command>.
|
|
Note that this is not the NZD database file size, but
|
|
the largest size that the database may grow to.
|
|
</para>
|
|
<para>
|
|
Because the database file is memory mapped, its size is
|
|
limited by the address space of the <command>named</command> process. The
|
|
default of 32 megabytes was chosen to be usable with
|
|
32-bit <command>named</command> builds. The largest
|
|
permitted value is 1 terabyte. Given typical zone
|
|
configurations without elaborate ACLs, a 32 MB NZD file
|
|
ought to be able to hold configurations of about 100,000
|
|
zones.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>managed-keys-directory</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the directory in which to store the files that
|
|
track managed DNSSEC keys. By default, this is the working
|
|
directory. The directory <emphasis>must</emphasis>
|
|
be writable by the effective user ID of the
|
|
<command>named</command> process.
|
|
</para>
|
|
<para>
|
|
If <command>named</command> is not configured to use views,
|
|
managed keys for the server are tracked in a single
|
|
file called <filename>managed-keys.bind</filename>.
|
|
Otherwise, managed keys are tracked in separate files,
|
|
one file per view; each file name is the view name
|
|
(or, if it contains characters that are incompatible with
|
|
use as a file name, the SHA256 hash of the view name),
|
|
followed by the extension
|
|
<filename>.mkeys</filename>.
|
|
</para>
|
|
<para>
|
|
(Note: in earlier releases, file names for views
|
|
always used the SHA256 hash of the view name. To ensure
|
|
compatibility after upgrading, if a file using the old
|
|
name format is found to exist, it is used instead
|
|
of the new format.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>named-xfer</command></term>
|
|
<listitem>
|
|
<para>
|
|
<emphasis>This option is obsolete.</emphasis>
|
|
In <acronym>BIND</acronym> 9, no separate
|
|
<command>named-xfer</command> program is needed;
|
|
its functionality is built into the name server.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>tkey-gssapi-keytab</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the KRB5 keytab file to use for GSS-TSIG updates. If
|
|
this option is set and tkey-gssapi-credential is not
|
|
set, updates are allowed with any key
|
|
matching a principal in the specified keytab.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>tkey-gssapi-credential</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the security credential with which the server should
|
|
authenticate keys requested by the GSS-TSIG protocol.
|
|
Currently only Kerberos 5 authentication is available;
|
|
the credential is a Kerberos principal which the
|
|
server can acquire through the default system key
|
|
file, normally <filename>/etc/krb5.keytab</filename>.
|
|
The location of the keytab file can be overridden using the
|
|
<command>tkey-gssapi-keytab</command> option. Normally this principal is
|
|
of the form "<userinput>DNS/</userinput><varname>server.domain</varname>".
|
|
To use GSS-TSIG, <command>tkey-domain</command> must
|
|
also be set if a specific keytab is not set with
|
|
<command>tkey-gssapi-keytab</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>tkey-domain</command></term>
|
|
<listitem>
|
|
<para>
|
|
This domain is appended to the names of all shared keys
|
|
generated with <command>TKEY</command>. When a
|
|
client requests a <command>TKEY</command> exchange,
|
|
it may or may not specify the desired name for the
|
|
key. If present, the name of the shared key is
|
|
<varname>client-specified part</varname> +
|
|
<varname>tkey-domain</varname>. Otherwise, the
|
|
name of the shared key is <varname>random hex
|
|
digits</varname> + <varname>tkey-domain</varname>.
|
|
In most cases, the <command>domainname</command>
|
|
should be the server's domain name, or an otherwise
|
|
nonexistent subdomain like
|
|
"_tkey.<varname>domainname</varname>". If
|
|
using GSS-TSIG, this variable must be defined, unless
|
|
a specific keytab is specified using <command>tkey-gssapi-keytab</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>tkey-dhkey</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the Diffie-Hellman key used by the server
|
|
to generate shared keys with clients using the Diffie-Hellman
|
|
mode
|
|
of <command>TKEY</command>. The server must be
|
|
able to load the
|
|
public and private keys from files in the working directory.
|
|
In
|
|
most cases, the <varname>key_name</varname> should be the server's host name.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>cache-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is for testing only. Do not use.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dump-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of the file the server dumps
|
|
the database to, when instructed to do so with
|
|
<command>rndc dumpdb</command>.
|
|
If not specified, the default is <filename>named_dump.db</filename>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>memstatistics-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of the file the server writes memory
|
|
usage statistics to on exit. If not specified,
|
|
the default is <filename>named.memstats</filename>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>lock-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of a file on which <command>named</command>
|
|
attempts to acquire a file lock when starting for
|
|
the first time; if unsuccessful, the server
|
|
terminates, under the assumption that another
|
|
server is already running. If not specified, the default is
|
|
<filename>none</filename>.
|
|
</para>
|
|
<para>
|
|
Specifying <command>lock-file none</command> disables the
|
|
use of a lock file. <command>lock-file</command> is
|
|
ignored if <command>named</command> was run using the <option>-X</option>
|
|
option, which overrides it. Changes to
|
|
<command>lock-file</command> are ignored if
|
|
<command>named</command> is being reloaded or
|
|
reconfigured; it is only effective when the server is
|
|
first started.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>pid-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of the file the server writes its process ID
|
|
in. If not specified, the default is
|
|
<filename>/var/run/named/named.pid</filename>.
|
|
The PID file is used by programs that send signals to
|
|
the running
|
|
name server. Specifying <command>pid-file none</command> disables the
|
|
use of a PID file; no file is written and any
|
|
existing one is removed. Note that <command>none</command>
|
|
is a keyword, not a filename, and therefore is not enclosed
|
|
in
|
|
double quotes.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>recursing-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of the file where the server dumps
|
|
the queries that are currently recursing, when instructed
|
|
to do so with <command>rndc recursing</command>.
|
|
If not specified, the default is <filename>named.recursing</filename>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>statistics-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of the file the server appends statistics
|
|
to, when instructed to do so using <command>rndc stats</command>.
|
|
If not specified, the default is <filename>named.stats</filename> in the
|
|
server's current directory. The format of the file is
|
|
described
|
|
in <xref linkend="statsfile"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>bindkeys-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of a file to override the built-in trusted
|
|
keys provided by <command>named</command>.
|
|
See the discussion of <command>dnssec-validation</command>
|
|
for details. If not specified, the default is
|
|
<filename>/etc/bind.keys</filename>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>secroots-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of the file the server dumps
|
|
security roots to, when instructed to do so with
|
|
<command>rndc secroots</command>.
|
|
If not specified, the default is
|
|
<filename>named.secroots</filename>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>session-keyfile</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the pathname of the file into which to write a TSIG
|
|
session key generated by <command>named</command> for use by
|
|
<command>nsupdate -l</command>. If not specified, the
|
|
default is <filename>/var/run/named/session.key</filename>.
|
|
(See <xref linkend="dynamic_update_policies"/>, and in
|
|
particular the discussion of the
|
|
<command>update-policy</command> statement's
|
|
<userinput>local</userinput> option for more
|
|
information about this feature.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>session-keyname</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the key name to use for the TSIG session key.
|
|
If not specified, the default is <varname>local-ddns</varname>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>session-keyalg</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the algorithm to use for the TSIG session key.
|
|
Valid values are hmac-sha1, hmac-sha224, hmac-sha256,
|
|
hmac-sha384, hmac-sha512, and hmac-md5. If not
|
|
specified, the default is hmac-sha256.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>port</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the UDP/TCP port number the server uses to
|
|
receive and send DNS protocol traffic.
|
|
The default is 53. This option is mainly intended for server
|
|
testing;
|
|
a server using a port other than 53 is not able to
|
|
communicate with
|
|
the global DNS.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dscp</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the global Differentiated Services Code Point (DSCP)
|
|
value to classify outgoing DNS traffic, on operating
|
|
systems that support DSCP. Valid values are 0 through 63.
|
|
It is not configured by default.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>random-device</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a 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 option specifies the device (or file) from which
|
|
to read
|
|
entropy. If it is a file, operations requiring entropy will
|
|
fail when the
|
|
file has been exhausted. If <command>random-device</command> is not specified, the default value
|
|
is
|
|
<filename>/dev/random</filename>
|
|
(or equivalent) when present, and none otherwise. The
|
|
<command>random-device</command> option takes
|
|
effect during
|
|
the initial configuration load at server startup time and
|
|
is ignored on subsequent reloads.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>preferred-glue</command></term>
|
|
<listitem>
|
|
<para>
|
|
If specified, the listed type (A or AAAA) is emitted
|
|
before other glue
|
|
in the additional section of a query response.
|
|
The default is to prefer A records when responding
|
|
to queries that arrived via IPv4 and AAAA when
|
|
responding to queries that arrived via IPv6.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="root_delegation_only">
|
|
<term><command>root-delegation-only</command></term>
|
|
<listitem>
|
|
<para>
|
|
This turns on enforcement of delegation-only in TLDs
|
|
(top-level domains) and root zones with an optional
|
|
exclude list.
|
|
</para>
|
|
<para>
|
|
DS queries are expected to be made to and be answered by
|
|
delegation-only zones. Such queries and responses are
|
|
treated as an exception to delegation-only processing
|
|
and are not converted to NXDOMAIN responses, provided
|
|
a CNAME is not discovered at the query name.
|
|
</para>
|
|
<para>
|
|
If a delegation-only zone server also serves a child
|
|
zone, it is not always possible to determine whether
|
|
an answer comes from the delegation-only zone or the
|
|
child zone. SOA NS and DNSKEY records are apex-only
|
|
records and a matching response that contains
|
|
these records or DS is treated as coming from a
|
|
child zone. RRSIG records are also examined to see
|
|
if they are signed by a child zone, and the
|
|
authority section is examined to see if there
|
|
is evidence that the answer is from the child zone.
|
|
Answers that are determined to be from a child zone
|
|
are not converted to NXDOMAIN responses. Despite
|
|
all these checks, there is still a possibility of
|
|
false negatives when a child zone is being served.
|
|
</para>
|
|
<para>
|
|
Similarly, false positives can arise from empty nodes
|
|
(no records at the name) in the delegation-only zone
|
|
when the query type is not <varname>ANY</varname>.
|
|
</para>
|
|
<para>
|
|
Note that some TLDs are not delegation-only; e.g., "DE", "LV",
|
|
"US", and "MUSEUM". This list is not exhaustive.
|
|
</para>
|
|
|
|
<programlisting>
|
|
options {
|
|
root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
|
|
};
|
|
</programlisting>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>disable-algorithms</command></term>
|
|
<listitem>
|
|
<para>
|
|
This disables the specified DNSSEC algorithms at and below the
|
|
specified name.
|
|
Multiple <command>disable-algorithms</command>
|
|
statements are allowed.
|
|
Only the best-match <command>disable-algorithms</command>
|
|
clause is used to determine the algorithms.
|
|
</para>
|
|
<para>
|
|
If all supported algorithms are disabled, the zones covered
|
|
by the <command>disable-algorithms</command> setting are treated
|
|
as insecure.
|
|
</para>
|
|
<para>
|
|
Configured trust anchors in <command>trusted-keys</command>
|
|
or <command>managed-keys</command> that match a disabled
|
|
algorithm are ignored and treated as if they were not
|
|
configured.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>disable-ds-digests</command></term>
|
|
<listitem>
|
|
<para>
|
|
This disables the specified DS digest types at and below the
|
|
specified name.
|
|
Multiple <command>disable-ds-digests</command>
|
|
statements are allowed.
|
|
Only the best-match <command>disable-ds-digests</command>
|
|
clause is used to determine the digest types.
|
|
</para>
|
|
<para>
|
|
If all supported digest types are disabled, the zones covered
|
|
by <command>disable-ds-digests</command> are treated
|
|
as insecure.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-lookaside</command></term>
|
|
<listitem>
|
|
<para>
|
|
When set, <command>dnssec-lookaside</command> provides the
|
|
validator with an alternate method to validate DNSKEY
|
|
records at the top of a zone. When a DNSKEY is at or
|
|
below a domain specified by the deepest
|
|
<command>dnssec-lookaside</command>, and the normal DNSSEC
|
|
validation has left the key untrusted, the trust-anchor
|
|
is appended to the key name and a DLV record is
|
|
looked up to see if it can validate the key. If the DLV
|
|
record validates a DNSKEY (similarly to the way a DS
|
|
record does), the DNSKEY RRset is deemed to be trusted.
|
|
</para>
|
|
<para>
|
|
If <command>dnssec-lookaside</command> is set to
|
|
<userinput>no</userinput>, then <command>dnssec-lookaside</command>
|
|
is not used.
|
|
</para>
|
|
<para>
|
|
Note: the ISC-provided DLV service at
|
|
<literal>dlv.isc.org</literal> has been shut down.
|
|
The <command>dnssec-lookaside auto;</command>
|
|
configuration option, which set <command>named</command>
|
|
to use ISC DLV with minimal configuration, has
|
|
accordingly been removed.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-must-be-secure</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies hierarchies which must be or may not be secure
|
|
(signed and validated). If <userinput>yes</userinput>,
|
|
then <command>named</command> only accepts answers if
|
|
they are secure. If <userinput>no</userinput>, then normal
|
|
DNSSEC validation applies, allowing insecure answers to
|
|
be accepted. The specified domain must be under a
|
|
<command>trusted-keys</command> or
|
|
<command>managed-keys</command> statement, or
|
|
<command>dnssec-validation auto</command> must be active.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dns64</command></term>
|
|
<listitem>
|
|
<para>
|
|
This directive instructs <command>named</command> to
|
|
return mapped IPv4 addresses to AAAA queries when
|
|
there are no AAAA records. It is intended to be
|
|
used in conjunction with a NAT64. Each
|
|
<command>dns64</command> defines one DNS64 prefix.
|
|
Multiple DNS64 prefixes can be defined.
|
|
</para>
|
|
<para>
|
|
Compatible IPv6 prefixes have lengths of 32, 40, 48, 56,
|
|
64, and 96, per RFC 6052. Bits 64..71 inclusive must
|
|
be zero, with the most significant bit of the prefix in
|
|
position 0.
|
|
</para>
|
|
<para>
|
|
In addition, a reverse IP6.ARPA zone is created for
|
|
the prefix to provide a mapping from the IP6.ARPA names
|
|
to the corresponding IN-ADDR.ARPA names using synthesized
|
|
CNAMEs. <command>dns64-server</command> and
|
|
<command>dns64-contact</command> can be used to specify
|
|
the name of the server and contact for the zones. These
|
|
can be set at the view/options level but not
|
|
on a per-prefix basis.
|
|
</para>
|
|
<para>
|
|
Each <command>dns64</command> supports an optional
|
|
<command>clients</command> ACL that determines which
|
|
clients are affected by this directive. If not defined,
|
|
it defaults to <userinput>any;</userinput>.
|
|
</para>
|
|
<para>
|
|
Each <command>dns64</command> supports an optional
|
|
<command>mapped</command> ACL that selects which
|
|
IPv4 addresses are to be mapped in the corresponding
|
|
A RRset. If not defined, it defaults to
|
|
<userinput>any;</userinput>.
|
|
</para>
|
|
<para>
|
|
Normally, DNS64 does not apply to a domain name that
|
|
owns one or more AAAA records; these records are
|
|
simply returned. The optional
|
|
<command>exclude</command> ACL allows specification
|
|
of a list of IPv6 addresses that are ignored
|
|
if they appear in a domain name's AAAA records;
|
|
DNS64 is applied to any A records the domain
|
|
name owns. If not defined, <command>exclude</command>
|
|
defaults to ::ffff:0.0.0.0/96.
|
|
</para>
|
|
<para>
|
|
A optional <command>suffix</command> can also
|
|
be defined to set the bits trailing the mapped
|
|
IPv4 address bits. By default these bits are
|
|
set to <userinput>::</userinput>. The bits
|
|
matching the prefix and mapped IPv4 address
|
|
must be zero.
|
|
</para>
|
|
<para>
|
|
If <command>recursive-only</command> is set to
|
|
<command>yes</command>, the DNS64 synthesis
|
|
only happens for recursive queries. The default
|
|
is <command>no</command>.
|
|
</para>
|
|
<para>
|
|
If <command>break-dnssec</command> is set to
|
|
<command>yes</command>, the DNS64 synthesis
|
|
happens even if the result, if validated, would
|
|
cause a DNSSEC validation failure. If this option
|
|
is set to <command>no</command> (the default), the DO
|
|
is set on the incoming query, and there are RRSIGs on
|
|
the applicable records, then synthesis does not happen.
|
|
</para>
|
|
<programlisting>
|
|
acl rfc1918 { 10/8; 192.168/16; 172.16/12; };
|
|
|
|
dns64 64:FF9B::/96 {
|
|
clients { any; };
|
|
mapped { !rfc1918; any; };
|
|
exclude { 64:FF9B::/96; ::ffff:0000:0000/96; };
|
|
suffix ::;
|
|
};
|
|
</programlisting>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-loadkeys-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
When a zone is configured with <command>auto-dnssec
|
|
maintain;</command>, its key repository must be checked
|
|
periodically to see if any new keys have been added
|
|
or any existing keys' timing metadata has been updated
|
|
(see <xref linkend="man.dnssec-keygen"/> and
|
|
<xref linkend="man.dnssec-settime"/>). The
|
|
<command>dnssec-loadkeys-interval</command> option
|
|
sets the frequency of automatic repository checks, in
|
|
minutes. The default is <literal>60</literal> (1 hour),
|
|
the minimum is <literal>1</literal> (1 minute), and the
|
|
maximum is <literal>1440</literal> (24 hours); any higher
|
|
value is silently reduced.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-update-mode</command></term>
|
|
<listitem>
|
|
<para>
|
|
If this option is set to its default value of
|
|
<literal>maintain</literal> in a zone of type
|
|
<literal>master</literal> which is DNSSEC-signed
|
|
and configured to allow dynamic updates (see
|
|
<xref linkend="dynamic_update_policies"/>), and
|
|
if <command>named</command> has access to the
|
|
private signing key(s) for the zone, then
|
|
<command>named</command> automatically signs all new
|
|
or changed records and maintains signatures for the zone
|
|
by regenerating RRSIG records whenever they approach
|
|
their expiration date.
|
|
</para>
|
|
<para>
|
|
If the option is changed to <literal>no-resign</literal>,
|
|
then <command>named</command> signs all new or
|
|
changed records, but scheduled maintenance of
|
|
signatures is disabled.
|
|
</para>
|
|
<para>
|
|
With either of these settings, <command>named</command>
|
|
rejects updates to a DNSSEC-signed zone when the
|
|
signing keys are inactive or unavailable to
|
|
<command>named</command>. (A planned third option,
|
|
<literal>external</literal>, will disable all automatic
|
|
signing and allow DNSSEC data to be submitted into a zone
|
|
via dynamic update; this is not yet implemented.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>nta-lifetime</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the default lifetime, in seconds,
|
|
for negative trust anchors added
|
|
via <command>rndc nta</command>.
|
|
</para>
|
|
<para>
|
|
A negative trust anchor selectively disables
|
|
DNSSEC validation for zones that are known to be
|
|
failing because of misconfiguration, rather than
|
|
an attack. When data to be validated is
|
|
at or below an active NTA (and above any other
|
|
configured trust anchors), <command>named</command>
|
|
aborts the DNSSEC validation process and treats the data as
|
|
insecure rather than bogus. This continues until the
|
|
NTA's lifetime is elapsed. NTAs persist
|
|
across <command>named</command> restarts.
|
|
</para>
|
|
<para>
|
|
For convenience, TTL-style time-unit suffixes can be
|
|
used to specify the NTA lifetime in seconds, minutes,
|
|
or hours. <option>nta-lifetime</option> defaults to
|
|
one hour; it cannot exceed one week.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>nta-recheck</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies how often to check whether negative
|
|
trust anchors added via <command>rndc nta</command>
|
|
are still necessary.
|
|
</para>
|
|
<para>
|
|
A negative trust anchor is normally used when a
|
|
domain has stopped validating due to operator error;
|
|
it temporarily disables DNSSEC validation for that
|
|
domain. In the interest of ensuring that DNSSEC
|
|
validation is turned back on as soon as possible,
|
|
<command>named</command> periodically sends a
|
|
query to the domain, ignoring negative trust anchors,
|
|
to find out whether it can now be validated. If so,
|
|
the negative trust anchor is allowed to expire early.
|
|
</para>
|
|
<para>
|
|
Validity checks can be disabled for an individual
|
|
NTA by using <command>rndc nta -f</command>, or
|
|
for all NTAs by setting <option>nta-recheck</option>
|
|
to zero.
|
|
</para>
|
|
<para>
|
|
For convenience, TTL-style time-unit suffixes can be
|
|
used to specify the NTA recheck interval in seconds,
|
|
minutes, or hours. The default is five minutes. It
|
|
cannot be longer than <option>nta-lifetime</option>,
|
|
which cannot be longer than a week.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
|
|
<varlistentry>
|
|
<term><command>max-zone-ttl</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a maximum permissible TTL value in seconds.
|
|
For convenience, TTL-style time-unit suffixes may be
|
|
used to specify the maximum value.
|
|
When loading a zone file using a
|
|
<option>masterfile-format</option> of
|
|
<constant>text</constant> or <constant>raw</constant>,
|
|
any record encountered with a TTL higher than
|
|
<option>max-zone-ttl</option> causes the zone to
|
|
be rejected.
|
|
</para>
|
|
<para>
|
|
This is useful in DNSSEC-signed zones because when
|
|
rolling to a new DNSKEY, the old key needs to remain
|
|
available until RRSIG records have expired from
|
|
caches. The <option>max-zone-ttl</option> option guarantees
|
|
that the largest TTL in the zone is no higher
|
|
than the set value.
|
|
</para>
|
|
<para>
|
|
(Note: because <constant>map</constant>-format files
|
|
load directly into memory, this option cannot be
|
|
used with them.)
|
|
</para>
|
|
<para>
|
|
The default value is <constant>unlimited</constant>.
|
|
A <option>max-zone-ttl</option> of zero is treated as
|
|
<constant>unlimited</constant>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>serial-update-method</command></term>
|
|
<listitem>
|
|
<para>
|
|
Zones configured for dynamic DNS may use this
|
|
option to set the update method to be used for
|
|
the zone serial number in the SOA record.
|
|
</para>
|
|
<para>
|
|
With the default setting of
|
|
<command>serial-update-method increment;</command>, the
|
|
SOA serial number is incremented by one each time
|
|
the zone is updated.
|
|
</para>
|
|
<para>
|
|
When set to
|
|
<command>serial-update-method unixtime;</command>, the
|
|
SOA serial number is set to the number of seconds
|
|
since the Unix epoch, unless the serial number is
|
|
already greater than or equal to that value, in which
|
|
case it is simply incremented by one.
|
|
</para>
|
|
<para>
|
|
When set to
|
|
<command>serial-update-method date;</command>, the
|
|
new SOA serial number is the current date
|
|
in the form "YYYYMMDD", followed by two zeroes,
|
|
unless the existing serial number is already greater
|
|
than or equal to that value, in which case it is
|
|
incremented by one.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>zone-statistics</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>full</userinput>, the server collects
|
|
statistical data on all zones, unless specifically
|
|
turned off on a per-zone basis by specifying
|
|
<command>zone-statistics terse</command> or
|
|
<command>zone-statistics none</command>
|
|
in the <command>zone</command> statement.
|
|
The default is <userinput>terse</userinput>, providing
|
|
minimal statistics on zones (including name and
|
|
current serial number, but not query type
|
|
counters).
|
|
</para>
|
|
<para>
|
|
These statistics may be accessed via the
|
|
<command>statistics-channel</command> or
|
|
using <command>rndc stats</command>, which
|
|
dumps them to the file listed
|
|
in the <command>statistics-file</command>. See
|
|
also <xref linkend="statsfile"/>.
|
|
</para>
|
|
<para>
|
|
For backward compatibility with earlier versions
|
|
of BIND 9, the <command>zone-statistics</command>
|
|
option can also accept <userinput>yes</userinput>
|
|
or <userinput>no</userinput>; <userinput>yes</userinput>
|
|
has the same meaning as <userinput>full</userinput>.
|
|
As of <acronym>BIND</acronym> 9.10,
|
|
<userinput>no</userinput> has the same meaning
|
|
as <userinput>none</userinput>; previously, it
|
|
was the same as <userinput>terse</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<section xml:id="boolean_options"><info><title>Boolean Options</title></info>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>automatic-interface-scan</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput> and supported by the operating
|
|
system, this automatically rescans network interfaces when the
|
|
interface addresses are added or removed. The default is
|
|
<userinput>yes</userinput>. This configuration option does
|
|
not affect the time-based <command>interface-interval</command>
|
|
option; it is recommended to set the time-based
|
|
<command>interface-interval</command> to 0 when the operator
|
|
confirms that automatic interface scanning is supported by the
|
|
operating system.
|
|
</para>
|
|
<para>
|
|
The <command>automatic-interface-scan</command> implementation
|
|
uses routing sockets for the network interface discovery;
|
|
therefore, the operating system must support the routing
|
|
sockets for this feature to work.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-new-zones</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, then zones can be
|
|
added at runtime via <command>rndc addzone</command>.
|
|
The default is <userinput>no</userinput>.
|
|
</para>
|
|
<para>
|
|
Newly added zones' configuration parameters
|
|
are stored so that they can persist after the
|
|
server is restarted. The configuration information
|
|
is saved in a file called
|
|
<filename><replaceable>viewname</replaceable>.nzf</filename>
|
|
(or, if <command>named</command> is compiled with
|
|
liblmdb, in an LMDB database file called
|
|
<filename><replaceable>viewname</replaceable>.nzd</filename>).
|
|
<replaceable>viewname</replaceable> is the name of the
|
|
view, unless the view name contains characters that are
|
|
incompatible with use as a file name, in which case a
|
|
cryptographic hash of the view name is used instead.
|
|
</para>
|
|
<para>
|
|
Configurations for zones added at runtime are
|
|
stored either in a new-zone file (NZF) or a new-zone
|
|
database (NZD), depending on whether
|
|
<command>named</command> was linked with
|
|
liblmdb at compile time.
|
|
See <xref linkend="man.rndc"/> for further details
|
|
about <command>rndc addzone</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>auth-nxdomain</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, then the <command>AA</command> bit
|
|
is always set on NXDOMAIN responses, even if the server is
|
|
not actually
|
|
authoritative. The default is <userinput>no</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>deallocate-on-exit</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option was used in <acronym>BIND</acronym>
|
|
8 to enable checking
|
|
for memory leaks on exit. <acronym>BIND</acronym> 9 ignores the option and always performs
|
|
the checks.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>memstatistics</command></term>
|
|
<listitem>
|
|
<para>
|
|
This writes memory statistics to the file specified by
|
|
<command>memstatistics-file</command> at exit.
|
|
The default is <userinput>no</userinput> unless
|
|
<userinput>-m record</userinput> is specified on the command line, in
|
|
which case it is <userinput>yes</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dialup</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, 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. Although this setting has different effects
|
|
according
|
|
to zone type, it concentrates the zone maintenance so that
|
|
everything
|
|
happens quickly, once every <command>heartbeat-interval</command>,
|
|
ideally during a single call. It also suppresses some
|
|
normal
|
|
zone maintenance traffic. The default is <userinput>no</userinput>.
|
|
</para>
|
|
<para>
|
|
If specified in the <command>view</command> and
|
|
<command>zone</command> statements, the <command>dialup</command> option
|
|
overrides the global <command>dialup</command> option.
|
|
</para>
|
|
<para>
|
|
If the zone is a primary zone, the server sends out a
|
|
NOTIFY
|
|
request to all the secondaries (default). This should trigger the
|
|
zone serial
|
|
number check in the secondary (providing it supports NOTIFY),
|
|
allowing the secondary
|
|
to verify the zone while the connection is active.
|
|
The set of servers to which NOTIFY is sent can be controlled
|
|
by
|
|
<command>notify</command> and <command>also-notify</command>.
|
|
</para>
|
|
<para>
|
|
If the
|
|
zone is a secondary or stub zone, the server suppresses
|
|
the regular
|
|
"zone up to date" (refresh) queries and only performs them
|
|
when the
|
|
<command>heartbeat-interval</command> expires, in
|
|
addition to sending
|
|
NOTIFY requests.
|
|
</para>
|
|
<para>
|
|
Finer control can be achieved by using
|
|
<userinput>notify</userinput>, which only sends NOTIFY
|
|
messages;
|
|
<userinput>notify-passive</userinput>, which sends NOTIFY
|
|
messages and
|
|
suppresses the normal refresh queries; <userinput>refresh</userinput>,
|
|
which suppresses normal refresh processing and sends refresh
|
|
queries
|
|
when the <command>heartbeat-interval</command>
|
|
expires; and
|
|
<userinput>passive</userinput>, which disables normal
|
|
refresh
|
|
processing.
|
|
</para>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="4" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="3" colnum="3" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="4" colnum="4" colsep="0" colwidth="1.150in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
dialup mode
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
normal refresh
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
heart-beat refresh
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
heart-beat notify
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>no</command> (default)</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
yes
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>yes</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
yes
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
yes
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>notify</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
yes
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
yes
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>refresh</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
yes
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>passive</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>notify-passive</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
no
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
yes
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>
|
|
Note that normal NOTIFY processing is not affected by
|
|
<command>dialup</command>.
|
|
</para>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>fake-iquery</command></term>
|
|
<listitem>
|
|
<para>
|
|
In <acronym>BIND</acronym> 8, this option
|
|
enabled simulating the obsolete DNS query type
|
|
IQUERY. <acronym>BIND</acronym> 9 never does
|
|
IQUERY simulation.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>fetch-glue</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is obsolete.
|
|
In BIND 8, <userinput>fetch-glue yes</userinput>
|
|
caused the server to attempt to fetch glue resource records
|
|
it
|
|
did not have when constructing the additional
|
|
data section of a response. This is now considered a bad
|
|
idea
|
|
and BIND 9 never does it.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>flush-zones-on-shutdown</command></term>
|
|
<listitem>
|
|
<para>
|
|
When the nameserver exits upon receiving SIGTERM,
|
|
flush or do not flush any pending zone writes. The default
|
|
is
|
|
<command>flush-zones-on-shutdown</command> <userinput>no</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>geoip-use-ecs</command></term>
|
|
<listitem>
|
|
<para>
|
|
When BIND is compiled with GeoIP support and configured
|
|
with "geoip" ACL elements, this option indicates whether
|
|
the EDNS Client Subnet option, if present in a request,
|
|
should be used for matching against the GeoIP database.
|
|
The default is
|
|
<command>geoip-use-ecs</command> <userinput>yes</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>has-old-clients</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option was incorrectly implemented
|
|
in <acronym>BIND</acronym> 8, and is ignored by <acronym>BIND</acronym> 9.
|
|
To achieve the intended effect
|
|
of
|
|
<command>has-old-clients</command> <userinput>yes</userinput>, specify
|
|
the two separate options <command>auth-nxdomain</command> <userinput>yes</userinput>
|
|
and <command>rfc2308-type1</command> <userinput>no</userinput> instead.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>host-statistics</command></term>
|
|
<listitem>
|
|
<para>
|
|
In BIND 8, this enabled keeping of
|
|
statistics for every host that the name server interacts
|
|
with.
|
|
It is not implemented in BIND 9.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>root-key-sentinel</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, respond to root key sentinel probes as described in
|
|
draft-ietf-dnsop-kskroll-sentinel-08. The default is
|
|
<userinput>yes</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>maintain-ixfr-base</command></term>
|
|
<listitem>
|
|
<para>
|
|
<emphasis>This option is obsolete</emphasis>.
|
|
It was used in <acronym>BIND</acronym> 8 to
|
|
determine whether a transaction log was
|
|
kept for Incremental Zone Transfer. <acronym>BIND</acronym> 9 maintains a transaction
|
|
log whenever possible. To disable outgoing
|
|
incremental zone
|
|
transfers, use <command>provide-ixfr</command> <userinput>no</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>message-compression</command></term> <listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, DNS name compression is
|
|
used in responses to regular queries (not including
|
|
AXFR or IXFR, which always use compression). Setting
|
|
this option to <userinput>no</userinput> reduces CPU
|
|
usage on servers and may improve throughput. However,
|
|
it increases response size, which may cause more queries
|
|
to be processed using TCP; a server with compression
|
|
disabled is out of compliance with RFC 1123 Section
|
|
6.1.3.2. The default is <userinput>yes</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>minimal-responses</command></term>
|
|
<listitem>
|
|
<para>
|
|
If set to <userinput>yes</userinput>, then when generating
|
|
responses the server only adds 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.
|
|
</para>
|
|
<para>
|
|
When set to <userinput>no-auth</userinput>, the
|
|
server omits records from the authority section
|
|
unless they are required, but it may still add
|
|
records to the additional section. When set to
|
|
<userinput>no-auth-recursive</userinput>, this
|
|
is only done if the query is recursive. These
|
|
settings are useful when answering stub clients,
|
|
which usually ignore the authority section.
|
|
<userinput>no-auth-recursive</userinput> is
|
|
designed for mixed-mode servers that handle
|
|
both authoritative and recursive queries.
|
|
</para>
|
|
<para>
|
|
The default is <userinput>no</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>minimal-any</command></term>
|
|
<listitem>
|
|
<para>
|
|
If set to <userinput>yes</userinput>, the server replies with only one
|
|
of the RRsets for the query name, and its covering
|
|
RRSIGs if any, when
|
|
generating a positive response to a query of type
|
|
ANY over UDP, instead of replying with all known
|
|
RRsets for the name. Similarly, a query for type
|
|
RRSIG is answered with the RRSIG records covering
|
|
only one type. This can reduce the impact of some kinds
|
|
of attack traffic, without harming legitimate
|
|
clients. (Note, however, that the RRset returned is the
|
|
first one found in the database; it is not necessarily
|
|
the smallest available RRset.)
|
|
Additionally, <option>minimal-responses</option> is
|
|
turned on for these queries, so no unnecessary records
|
|
are added to the authority or additional sections.
|
|
The default is <userinput>no</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>multiple-cnames</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option was used in <acronym>BIND</acronym> 8 to allow
|
|
a domain name to have multiple CNAME records, in violation of
|
|
the DNS standards. <acronym>BIND</acronym> 9.2 onwards
|
|
always strictly enforces the CNAME rules both in primary
|
|
files and dynamic updates.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput> (the default),
|
|
DNS NOTIFY messages are sent when a zone the server is
|
|
authoritative for
|
|
changes; see <xref linkend="notify"/>. The messages are
|
|
sent to the
|
|
servers listed in the zone's NS records (except the primary
|
|
server identified
|
|
in the SOA MNAME field), and to any servers listed in the
|
|
<command>also-notify</command> option.
|
|
</para>
|
|
<para>
|
|
If <userinput>master-only</userinput>, notifies are only
|
|
sent
|
|
for primary zones.
|
|
If <userinput>explicit</userinput>, notifies are sent only
|
|
to
|
|
servers explicitly listed using <command>also-notify</command>.
|
|
If <userinput>no</userinput>, no notifies are sent.
|
|
</para>
|
|
<para>
|
|
The <command>notify</command> option may also be
|
|
specified in the <command>zone</command>
|
|
statement,
|
|
in which case it overrides the <command>options notify</command> statement.
|
|
It would only be necessary to turn off this option if it
|
|
caused secondary zones
|
|
to crash.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify-to-soa</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, do not check the name servers
|
|
in the NS RRset against the SOA MNAME. Normally a NOTIFY
|
|
message is not sent to the SOA MNAME (SOA ORIGIN), as it is
|
|
supposed to contain the name of the ultimate primary server.
|
|
Sometimes, however, a secondary server is listed as the SOA MNAME in
|
|
hidden primary configurations; in that case,
|
|
the ultimate primary should be set to still send NOTIFY messages to
|
|
all the name servers listed in the NS RRset.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>recursion</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, and a
|
|
DNS query requests recursion, then the server attempts
|
|
to do
|
|
all the work required to answer the query. If recursion is
|
|
off
|
|
and the server does not already know the answer, it
|
|
returns a
|
|
referral response. The default is
|
|
<userinput>yes</userinput>.
|
|
Note that setting <command>recursion no</command> 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.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>request-nsid</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, then an empty EDNS(0)
|
|
NSID (Name Server Identifier) option is sent with all
|
|
queries to authoritative name servers during iterative
|
|
resolution. If the authoritative server returns an NSID
|
|
option in its response, then its contents are logged in
|
|
the <command>resolver</command> category at level
|
|
<command>info</command>.
|
|
The default is <userinput>no</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>request-sit</command></term>
|
|
<listitem>
|
|
<para>
|
|
This experimental option is obsolete.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>require-server-cookie</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, require a valid server cookie before sending a full
|
|
response to a UDP request from a cookie-aware client.
|
|
BADCOOKIE is sent if there is a bad or nonexistent
|
|
server cookie.
|
|
The default is <userinput>no</userinput>.
|
|
</para>
|
|
<para>
|
|
Users wishing to test that DNS COOKIE clients correctly handle BADCOOKIE, or who are
|
|
getting a lot of forged DNS requests with DNS COOKIES
|
|
present, should set this to <userinput>yes</userinput>.
|
|
Setting this to <userinput>yes</userinput>
|
|
results in a reduced amplification effect in a reflection
|
|
attack, as the BADCOOKIE response is smaller than
|
|
a full response, while also requiring a legitimate client
|
|
to follow up with a second query with the new, valid, cookie.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>answer-cookie</command></term>
|
|
<listitem>
|
|
<para>
|
|
When set to the default value of <userinput>yes</userinput>,
|
|
COOKIE EDNS options are sent when applicable in
|
|
replies to client queries. If set to
|
|
<userinput>no</userinput>, COOKIE EDNS options are not
|
|
sent in replies. This can only be set at the global
|
|
options level, not per-view.
|
|
</para>
|
|
<para>
|
|
<command>answer-cookie no</command> is only intended as a
|
|
temporary measure, for use when <command>named</command>
|
|
shares an IP address with other servers that do not yet
|
|
support DNS COOKIE. A mismatch between servers on the
|
|
same address is not expected to cause operational
|
|
problems, but the option to disable COOKIE responses so
|
|
that all servers have the same behavior is provided out
|
|
of an abundance of caution. DNS COOKIE is an important
|
|
security mechanism, and should not be disabled unless
|
|
absolutely necessary.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>send-cookie</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, then a COOKIE EDNS
|
|
option is sent along with the query. If the
|
|
resolver has previously communicated with the server, the
|
|
COOKIE returned in the previous transaction is sent.
|
|
This is used by the server to determine whether
|
|
the resolver has talked to it before. A resolver
|
|
sending the correct COOKIE is assumed not to be an
|
|
off-path attacker sending a spoofed-source query;
|
|
the query is therefore unlikely to be part of a
|
|
reflection/amplification attack, so resolvers
|
|
sending a correct COOKIE option are not subject to
|
|
response rate limiting (RRL). Resolvers which
|
|
do not send a correct COOKIE option may be limited
|
|
to receiving smaller responses via the
|
|
<command>nocookie-udp-size</command> option.
|
|
The default is <userinput>yes</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>nocookie-udp-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum size of UDP responses that are
|
|
sent to queries without a valid server COOKIE. A value
|
|
below 128 is silently raised to 128. The default
|
|
value is 4096, but the <command>max-udp-size</command>
|
|
option may further limit the response size.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sit-secret</command></term>
|
|
<listitem>
|
|
<para>
|
|
This experimental option is obsolete.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>cookie-algorithm</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the algorithm to be used when generating the
|
|
server cookie; the options are "aes", "sha1", or "sha256".
|
|
The default is "aes" if supported by the cryptographic
|
|
library; otherwise, "sha256".
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>cookie-secret</command></term>
|
|
<listitem>
|
|
<para>
|
|
If set, this is a shared secret used for generating
|
|
and verifying EDNS COOKIE options
|
|
within an anycast cluster. If not set, the system
|
|
generates a random secret at startup. The
|
|
shared secret is encoded as a hex string and needs
|
|
to be 128 bits for AES128, 160 bits for SHA1, and
|
|
256 bits for SHA256.
|
|
</para>
|
|
<para>
|
|
If there are multiple secrets specified, the first
|
|
one listed in <filename>named.conf</filename> is
|
|
used to generate new server cookies. The others
|
|
are only used to verify returned cookies.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>rfc2308-type1</command></term>
|
|
<listitem>
|
|
<para>
|
|
Setting this to <userinput>yes</userinput>
|
|
causes the server to send NS records along with the SOA
|
|
record for negative
|
|
answers. The default is <userinput>no</userinput>.
|
|
</para>
|
|
<note>
|
|
<simpara>
|
|
This is not yet implemented in <acronym>BIND</acronym>
|
|
9.
|
|
</simpara>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>trust-anchor-telemetry</command></term>
|
|
<listitem>
|
|
<para>
|
|
This causes <command>named</command> to send specially formed
|
|
queries once per day to domains for which trust anchors
|
|
have been configured via <command>trusted-keys</command>,
|
|
<command>managed-keys</command>, or
|
|
<command>dnssec-validation auto</command>.
|
|
</para>
|
|
<para>
|
|
The query name used for these queries has the
|
|
form "_ta-xxxx(-xxxx)(...)".<domain>, where
|
|
each "xxxx" is a group of four hexadecimal digits
|
|
representing the key ID of a trusted DNSSEC key.
|
|
The key IDs for each domain are sorted smallest
|
|
to largest prior to encoding. The query type is NULL.
|
|
</para>
|
|
<para>
|
|
By monitoring these queries, zone operators are
|
|
able to see which resolvers have been updated to
|
|
trust a new key; this may help them decide when it
|
|
is safe to remove an old one.
|
|
</para>
|
|
<para>
|
|
The default is <userinput>yes</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>use-id-pool</command></term>
|
|
<listitem>
|
|
<para>
|
|
<emphasis>This option is obsolete</emphasis>.
|
|
<acronym>BIND</acronym> 9 always allocates query
|
|
IDs from a pool.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>use-ixfr</command></term>
|
|
<listitem>
|
|
<para>
|
|
<emphasis>This option is obsolete</emphasis>.
|
|
To disable IXFR to a particular server or
|
|
servers, see
|
|
the information on the <command>provide-ixfr</command> option
|
|
in <xref linkend="server_statement_definition_and_usage"/>.
|
|
See also
|
|
<xref linkend="incremental_zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>provide-ixfr</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>provide-ixfr</command> in
|
|
<xref linkend="server_statement_definition_and_usage"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>request-ixfr</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>request-ixfr</command> in
|
|
<xref linkend="server_statement_definition_and_usage"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>request-expire</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>request-expire</command> in
|
|
<xref linkend="server_statement_definition_and_usage"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>treat-cr-as-space</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option was used in <acronym>BIND</acronym>
|
|
8 to make
|
|
the server treat carriage return ("<command>\r</command>") 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 <acronym>BIND</acronym> 9, both UNIX "<command>\n</command>"
|
|
and NT/DOS "<command>\r\n</command>" newlines
|
|
are always accepted,
|
|
and the option is ignored.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>additional-from-auth</command></term>
|
|
<term><command>additional-from-cache</command></term>
|
|
<listitem>
|
|
|
|
<para>
|
|
These options control the behavior of an authoritative
|
|
server when
|
|
answering queries which have additional data, or when
|
|
following CNAME
|
|
and DNAME chains.
|
|
</para>
|
|
|
|
<para>
|
|
When both of these options are set to <userinput>yes</userinput>
|
|
(the default) and a
|
|
query is being answered from authoritative data (a zone
|
|
configured into the server), the additional data section of
|
|
the
|
|
reply is 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 secondary zones may be added and modified by
|
|
untrusted third parties. Also, avoiding
|
|
the search for this additional data speeds up server
|
|
operations
|
|
at the possible expense of additional queries to resolve
|
|
what would
|
|
otherwise be provided in the additional section.
|
|
</para>
|
|
|
|
<para>
|
|
For example, if a query asks for an MX record for host <literal>foo.example.com</literal>,
|
|
and the record found is "<literal>MX 10 mail.example.net</literal>", normally the address
|
|
records (A and AAAA) for <literal>mail.example.net</literal> are provided as well,
|
|
if known, even though they are not in the example.com zone.
|
|
Setting these options to <command>no</command>
|
|
disables this behavior and makes
|
|
the server only search for additional data in the zone it
|
|
answers from.
|
|
</para>
|
|
|
|
<para>
|
|
These options are intended for use in authoritative-only
|
|
servers, or in authoritative-only views. Attempts to set
|
|
them to <command>no</command> without also
|
|
specifying
|
|
<command>recursion no</command> will cause the
|
|
server to
|
|
ignore the options and log a warning message.
|
|
</para>
|
|
|
|
<para>
|
|
Specifying <command>additional-from-cache no</command> 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.
|
|
</para>
|
|
|
|
<para>
|
|
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 is not able to provide
|
|
upwards
|
|
referrals when <command>additional-from-cache no</command>
|
|
has been specified. Instead, it responds to such
|
|
queries
|
|
with REFUSED. This should not cause any problems since
|
|
upwards referrals are not required for the resolution
|
|
process.
|
|
</para>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>match-mapped-addresses</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, then an
|
|
IPv4-mapped IPv6 address matches any address-match
|
|
list entries that match the corresponding IPv4 address.
|
|
</para>
|
|
<para>
|
|
This option was introduced to work around a kernel quirk
|
|
in some operating systems that causes IPv4 TCP
|
|
connections, such as zone transfers, to be accepted on an
|
|
IPv6 socket using mapped addresses. This caused address-match
|
|
lists designed for IPv4 to fail to match. However,
|
|
<command>named</command> now solves this problem
|
|
internally. The use of this option is discouraged.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>filter-aaaa-on-v4</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is only available when
|
|
<acronym>BIND</acronym> 9 is compiled with the
|
|
<userinput>--enable-filter-aaaa</userinput> option on the
|
|
"configure" command line. It is intended to help the
|
|
transition from IPv4 to IPv6 by not giving IPv6 addresses
|
|
to DNS clients unless they have connections to the IPv6
|
|
Internet. This is not recommended unless absolutely
|
|
necessary. The default is <userinput>no</userinput>.
|
|
The <command>filter-aaaa-on-v4</command> option
|
|
may also be specified in <command>view</command> statements
|
|
to override the global <command>filter-aaaa-on-v4</command>
|
|
option.
|
|
</para>
|
|
<para>
|
|
If <userinput>yes</userinput>,
|
|
the DNS client is at an IPv4 address, in <command>filter-aaaa</command>,
|
|
and if the response does not include DNSSEC signatures,
|
|
then all AAAA records are deleted from the response.
|
|
This filtering applies to all responses and not only
|
|
authoritative responses.
|
|
</para>
|
|
<para>
|
|
If <userinput>break-dnssec</userinput>,
|
|
then AAAA records are deleted even when DNSSEC is enabled.
|
|
As suggested by the name, this causes the response to not verify,
|
|
because the DNSSEC protocol is designed to detect deletions.
|
|
</para>
|
|
<para>
|
|
This mechanism can erroneously cause other servers to
|
|
not give AAAA records to their clients.
|
|
A recursing server with both IPv6 and IPv4 network connections,
|
|
that queries an authoritative server using this mechanism
|
|
via IPv4, is denied AAAA records even if its client is
|
|
using IPv6.
|
|
</para>
|
|
<para>
|
|
This mechanism is applied to authoritative as well as
|
|
non-authoritative records.
|
|
A client using IPv4 that is not allowed recursion can
|
|
erroneously be given AAAA records because the server is not
|
|
allowed to check for A records.
|
|
</para>
|
|
<para>
|
|
Some AAAA records are given to IPv4 clients in glue records.
|
|
IPv4 clients that are servers can then erroneously
|
|
answer requests for AAAA records received via IPv4.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>filter-aaaa-on-v6</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is identical to <command>filter-aaaa-on-v4</command>,
|
|
except it filters AAAA responses to queries from IPv6
|
|
clients instead of IPv4 clients. To filter all
|
|
responses, set both options to <userinput>yes</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>ixfr-from-differences</command></term>
|
|
<listitem>
|
|
<para>
|
|
When <userinput>yes</userinput> and the server loads a new
|
|
version of a primary zone from its zone file or receives a
|
|
new version of a secondary file via zone transfer, it
|
|
compares the new version to the previous one and calculates
|
|
a set of differences. The differences are then logged in
|
|
the zone's journal file so that the changes can be
|
|
transmitted to downstream secondaries as an incremental zone
|
|
transfer.
|
|
</para>
|
|
<para>
|
|
By allowing incremental zone transfers to be used for
|
|
non-dynamic zones, this option saves bandwidth at the
|
|
expense of increased CPU and memory consumption at the
|
|
primary server.
|
|
In particular, if the new version of a zone is completely
|
|
different from the previous one, the set of differences
|
|
is of a size comparable to the combined size of the
|
|
old and new zone versions, and the server needs to
|
|
temporarily allocate memory to hold this complete
|
|
difference set.
|
|
</para>
|
|
<para><command>ixfr-from-differences</command>
|
|
also accepts <command>master</command> and
|
|
<command>slave</command> at the view and options
|
|
levels, which causes
|
|
<command>ixfr-from-differences</command> to be enabled for
|
|
all primary or secondary zones, respectively.
|
|
It is off by default.
|
|
</para>
|
|
<para>
|
|
Note: if inline signing is enabled for a zone, the
|
|
user-provided <command>ixfr-from-differences</command>
|
|
setting is ignored for that zone.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>multi-master</command></term>
|
|
<listitem>
|
|
<para>
|
|
This should be set when there are multiple primary servers for a zone
|
|
and the
|
|
addresses refer to different machines. If <userinput>yes</userinput>, <command>named</command> does
|
|
not log
|
|
when the serial number on the primary is less than what <command>named</command>
|
|
currently
|
|
has. The default is <userinput>no</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>auto-dnssec</command></term>
|
|
<listitem>
|
|
<para>
|
|
Zones configured for dynamic DNS may use this
|
|
option to allow varying levels of automatic DNSSEC key
|
|
management. There are three possible settings:
|
|
</para>
|
|
<para>
|
|
<command>auto-dnssec allow;</command> permits
|
|
keys to be updated and the zone fully re-signed
|
|
whenever the user issues the command <command>rndc sign
|
|
<replaceable>zonename</replaceable></command>.
|
|
</para>
|
|
<para>
|
|
<command>auto-dnssec maintain;</command> includes the
|
|
above, but also automatically adjusts the zone's DNSSEC
|
|
keys on a schedule, according to the keys' timing metadata
|
|
(see <xref linkend="man.dnssec-keygen"/> and
|
|
<xref linkend="man.dnssec-settime"/>). The command
|
|
<command>rndc sign
|
|
<replaceable>zonename</replaceable></command> causes
|
|
<command>named</command> to load keys from the key
|
|
repository and sign the zone with all keys that are
|
|
active.
|
|
<command>rndc loadkeys
|
|
<replaceable>zonename</replaceable></command> causes
|
|
<command>named</command> to load keys from the key
|
|
repository and schedule key maintenance events to occur
|
|
in the future, but it does not sign the full zone
|
|
immediately. Note: once keys have been loaded for a
|
|
zone the first time, the repository is searched
|
|
for changes periodically, regardless of whether
|
|
<command>rndc loadkeys</command> is used. The recheck
|
|
interval is defined by
|
|
<command>dnssec-loadkeys-interval</command>.)
|
|
</para>
|
|
<para>
|
|
The default setting is <command>auto-dnssec off</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-enable</command></term>
|
|
<listitem>
|
|
<para>
|
|
This indicates whether DNSSEC-related resource
|
|
records are to be returned by <command>named</command>.
|
|
If set to <userinput>no</userinput>,
|
|
<command>named</command> does not return DNSSEC-related
|
|
resource records unless specifically queried for.
|
|
The default is <userinput>yes</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-validation</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option enables DNSSEC validation in <command>named</command>.
|
|
Note that <command>dnssec-enable</command> also needs to be
|
|
set to <userinput>yes</userinput> to be effective.
|
|
If set to <userinput>no</userinput>, DNSSEC validation
|
|
is disabled.
|
|
</para>
|
|
<para>
|
|
If set to <userinput>auto</userinput>, DNSSEC validation
|
|
is enabled and a default trust anchor for the DNS root
|
|
zone is used. If set to <userinput>yes</userinput>,
|
|
DNSSEC validation is enabled, but a trust anchor must be
|
|
manually configured using a <command>trusted-keys</command>
|
|
or <command>managed-keys</command> statement. The default
|
|
is <userinput>yes</userinput>.
|
|
</para>
|
|
<para>
|
|
The default root trust anchor is stored in the file
|
|
<filename>bind.keys</filename>.
|
|
<command>named</command> loads that key at
|
|
startup if <command>dnssec-validation</command> is
|
|
set to <constant>auto</constant>. A copy of the file is
|
|
installed along with BIND 9, and is current as of the
|
|
release date. If the root key expires, a new copy of
|
|
<filename>bind.keys</filename> can be downloaded
|
|
from <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.isc.org/bind-keys">https://www.isc.org/bind-keys</link>.
|
|
</para>
|
|
<para>
|
|
(To prevent problems if <filename>bind.keys</filename> is
|
|
not found, the current trust anchor is also compiled in
|
|
to <command>named</command>. Relying on this is not
|
|
recommended, however, as it requires <command>named</command>
|
|
to be recompiled with a new key when the root key expires.)
|
|
</para>
|
|
<note>
|
|
<para>
|
|
<command>named</command> loads <emphasis>only</emphasis>
|
|
the root key from <filename>bind.keys</filename>.
|
|
The file cannot be used to store keys for other zones.
|
|
The root key in <filename>bind.keys</filename> is ignored
|
|
if <command>dnssec-validation auto</command> is not in
|
|
use.
|
|
</para>
|
|
<para>
|
|
Whenever the resolver sends out queries to an
|
|
EDNS-compliant server, it always sets the DO bit
|
|
indicating it can support DNSSEC responses, even if
|
|
<command>dnssec-validation</command> is off.
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-accept-expired</command></term>
|
|
<listitem>
|
|
<para>
|
|
This accepts expired signatures when verifying DNSSEC signatures.
|
|
The default is <userinput>no</userinput>.
|
|
Setting this option to <userinput>yes</userinput>
|
|
leaves <command>named</command> vulnerable to
|
|
replay attacks.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>querylog</command></term>
|
|
<listitem>
|
|
<para>
|
|
Query logging provides a complete log of all incoming
|
|
queries and all query errors. This provides more insight
|
|
into the server's activity, but with a cost to
|
|
performance which may be significant on heavily loaded
|
|
servers.
|
|
</para>
|
|
<para>
|
|
The <command>querylog</command> option specifies
|
|
whether query logging should be active when
|
|
<command>named</command> first starts.
|
|
If <command>querylog</command> is not specified, then
|
|
query logging is determined by the presence of the
|
|
logging category <command>queries</command>.
|
|
Query logging can also be activated at runtime using the
|
|
command <command>rndc querylog on</command>, or
|
|
deactivated with <command>rndc querylog off</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-names</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is used to restrict the character set and syntax
|
|
of
|
|
certain domain names in zone files and/or DNS responses
|
|
received
|
|
from the network. The default varies according to usage
|
|
area. For primary zones (i.e.,
|
|
<command>type master</command>),
|
|
the default is <command>fail</command>.
|
|
For secondary zones (<command>type slave</command>), the
|
|
default is <command>warn</command>.
|
|
For answers received from the network (<command>response</command>),
|
|
the default is <command>ignore</command>.
|
|
</para>
|
|
<para>
|
|
The rules for legal hostnames and mail domains are derived
|
|
from RFC 952 and RFC 821 as modified by RFC 1123.
|
|
</para>
|
|
<para><command>check-names</command>
|
|
applies to the owner names of A, AAAA, and MX records.
|
|
It also applies to the domain names in the RDATA of NS, SOA,
|
|
MX, and SRV records.
|
|
It further applies to the RDATA of PTR records where the owner
|
|
name indicates that it is a reverse lookup of a hostname
|
|
(the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-dup-records</command></term>
|
|
<listitem>
|
|
<para>
|
|
This checks primary zones for records that are treated as different
|
|
by DNSSEC but are semantically equal in plain DNS. The
|
|
default is to <command>warn</command>. Other possible
|
|
values are <command>fail</command> and
|
|
<command>ignore</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-mx</command></term>
|
|
<listitem>
|
|
<para>
|
|
This checks whether the MX record appears to refer to a IP address.
|
|
The default is to <command>warn</command>. Other possible
|
|
values are <command>fail</command> and
|
|
<command>ignore</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-wildcard</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is used to check for non-terminal wildcards.
|
|
The use of non-terminal wildcards is almost always as a
|
|
result of a failure
|
|
to understand the wildcard matching algorithm (RFC 1034).
|
|
This option
|
|
affects primary zones. The default (<command>yes</command>) is to check
|
|
for non-terminal wildcards and issue a warning.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-integrity</command></term>
|
|
<listitem>
|
|
<para>
|
|
This performs post-load zone integrity checks on primary
|
|
zones. It checks that MX and SRV records refer
|
|
to address (A or AAAA) records and that glue
|
|
address records exist for delegated zones. For
|
|
MX and SRV records, only in-zone hostnames are
|
|
checked (for out-of-zone hostnames, use
|
|
<command>named-checkzone</command>).
|
|
For NS records, only names below top-of-zone are
|
|
checked (for out-of-zone names and glue consistency
|
|
checks, use <command>named-checkzone</command>).
|
|
The default is <command>yes</command>.
|
|
</para>
|
|
<para>
|
|
The use of the SPF record to publish Sender
|
|
Policy Framework is deprecated, as the migration
|
|
from using TXT records to SPF records was abandoned.
|
|
Enabling this option also checks that a TXT Sender
|
|
Policy Framework record exists (starts with "v=spf1")
|
|
if there is an SPF record. Warnings are emitted if the
|
|
TXT record does not exist; they can be suppressed with
|
|
<command>check-spf</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-mx-cname</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <command>check-integrity</command> is set, then
|
|
fail, warn, or ignore MX records that refer
|
|
to CNAMES. The default is to <command>warn</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-srv-cname</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <command>check-integrity</command> is set, then
|
|
fail, warn, or ignore SRV records that refer
|
|
to CNAMES. The default is to <command>warn</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-sibling</command></term>
|
|
<listitem>
|
|
<para>
|
|
When performing integrity checks, also check that
|
|
sibling glue exists. The default is <command>yes</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-spf</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <command>check-integrity</command> is set,
|
|
check that there is a TXT Sender Policy Framework
|
|
record present (starts with "v=spf1") if there is an
|
|
SPF record present. The default is
|
|
<command>warn</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>zero-no-soa-ttl</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, when returning authoritative negative responses to
|
|
SOA queries, set the TTL of the SOA record returned in
|
|
the authority section to zero.
|
|
The default is <command>yes</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>zero-no-soa-ttl-cache</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, when caching a negative response to an SOA query
|
|
set the TTL to zero.
|
|
The default is <command>no</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>update-check-ksk</command></term>
|
|
<listitem>
|
|
<para>
|
|
When set to the default value of <literal>yes</literal>,
|
|
check the KSK bit in each key to determine how the key
|
|
should be used when generating RRSIGs for a secure zone.
|
|
</para>
|
|
<para>
|
|
Ordinarily, zone-signing keys (that is, keys without the
|
|
KSK bit set) are used to sign the entire zone, while
|
|
key-signing keys (keys with the KSK bit set) are only
|
|
used to sign the DNSKEY RRset at the zone apex.
|
|
However, if this option is set to <literal>no</literal>,
|
|
then the KSK bit is ignored; KSKs are treated as if they
|
|
were ZSKs and are used to sign the entire zone. This is
|
|
similar to the <command>dnssec-signzone -z</command>
|
|
command-line option.
|
|
</para>
|
|
<para>
|
|
When this option is set to <literal>yes</literal>, there
|
|
must be at least two active keys for every algorithm
|
|
represented in the DNSKEY RRset: at least one KSK and one
|
|
ZSK per algorithm. If there is any algorithm for which
|
|
this requirement is not met, this option is ignored
|
|
for that algorithm.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-dnskey-kskonly</command></term>
|
|
<listitem>
|
|
<para>
|
|
When this option and <command>update-check-ksk</command>
|
|
are both set to <literal>yes</literal>, only key-signing
|
|
keys (that is, keys with the KSK bit set) are used
|
|
to sign the DNSKEY RRset at the zone apex. Zone-signing
|
|
keys (keys without the KSK bit set) are used to sign
|
|
the remainder of the zone, but not the DNSKEY RRset.
|
|
This is similar to the
|
|
<command>dnssec-signzone -x</command> command-line option.
|
|
</para>
|
|
<para>
|
|
The default is <command>no</command>. If
|
|
<command>update-check-ksk</command> is set to
|
|
<literal>no</literal>, this option is ignored.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>try-tcp-refresh</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <userinput>yes</userinput>, try to refresh the zone using TCP if UDP queries fail.
|
|
The default is
|
|
<command>yes</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-secure-to-insecure</command></term>
|
|
<listitem>
|
|
<para>
|
|
This allows a dynamic zone to transition from secure to
|
|
insecure (i.e., signed to unsigned) by deleting all
|
|
of the DNSKEY records. The default is <command>no</command>.
|
|
If set to <command>yes</command>, and if the DNSKEY RRset
|
|
at the zone apex is deleted, all RRSIG and NSEC records
|
|
are removed from the zone as well.
|
|
</para>
|
|
<para>
|
|
If the zone uses NSEC3, it is also necessary to
|
|
delete the NSEC3PARAM RRset from the zone apex; this
|
|
causes the removal of all corresponding NSEC3 records.
|
|
(It is expected that this requirement will be eliminated
|
|
in a future release.)
|
|
</para>
|
|
<para>
|
|
Note that if a zone has been configured with
|
|
<command>auto-dnssec maintain</command> and the
|
|
private keys remain accessible in the key repository,
|
|
then the zone will be automatically signed again the
|
|
next time <command>named</command> is started.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="forwarding"><info><title>Forwarding</title></info>
|
|
|
|
<para>
|
|
The forwarding facility can be used to create a large site-wide
|
|
cache on a few servers, reducing traffic over links to external
|
|
name servers. 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.
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>forward</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is only meaningful if the
|
|
forwarders list is not empty. A value of <varname>first</varname> is
|
|
the default and causes the server to query the forwarders
|
|
first;
|
|
if that does not answer the question, the server then
|
|
looks for
|
|
the answer itself. If <varname>only</varname> is
|
|
specified, the
|
|
server only queries the forwarders.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>forwarders</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a list of IP addresses to which queries are
|
|
forwarded. The default is the empty list (no forwarding).
|
|
Each address in the list can be associated with an optional
|
|
port number and/or DSCP value, and a default port number and
|
|
DSCP value can be set for the entire list.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
<para>
|
|
Forwarding can also be configured on a per-domain basis, allowing
|
|
for the global forwarding options to be overridden in a variety
|
|
of ways. Particular domains can be set to use different
|
|
forwarders,
|
|
or have a different <command>forward only/first</command> behavior,
|
|
or not forward at all; see <xref linkend="zone_statement_grammar"/>.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="dual_stack"><info><title>Dual-stack Servers</title></info>
|
|
|
|
<para>
|
|
Dual-stack servers are used as servers of last resort, to work
|
|
around
|
|
problems in reachability due the lack of support for either IPv4
|
|
or IPv6
|
|
on the host machine.
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>dual-stack-servers</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies host names or addresses of machines with access to
|
|
both IPv4 and IPv6 transports. If a hostname is used, the
|
|
server must be able
|
|
to resolve the name using only the transport it has. If the
|
|
machine is dual-stacked, the <command>dual-stack-servers</command> parameter has no effect unless
|
|
access to a transport has been disabled on the command line
|
|
(e.g., <command>named -4</command>).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
|
|
<section xml:id="access_control"><info><title>Access Control</title></info>
|
|
|
|
|
|
<para>
|
|
Access to the server can be restricted based on the IP address
|
|
of the requesting system. See <xref linkend="address_match_lists"/> for
|
|
details on how to specify IP address lists.
|
|
</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-notify</command></term>
|
|
<listitem>
|
|
<para>
|
|
This ACL specifies which hosts are allowed to
|
|
notify this secondary server of zone changes in addition
|
|
to the zone primaries.
|
|
<command>allow-notify</command> may also be
|
|
specified in the
|
|
<command>zone</command> statement, in which case
|
|
it overrides the
|
|
<command>options allow-notify</command>
|
|
statement. It is only meaningful
|
|
for a secondary zone. If not specified, the default is to
|
|
process notify messages
|
|
only from a zone's primary.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-query</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which hosts are allowed to ask ordinary
|
|
DNS questions. <command>allow-query</command> may
|
|
also be specified in the <command>zone</command>
|
|
statement, in which case it overrides the
|
|
<command>options allow-query</command> statement.
|
|
If not specified, the default is to allow queries
|
|
from all hosts.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
<command>allow-query-cache</command> is
|
|
used to specify access to the cache.
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-query-on</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which local addresses can accept ordinary
|
|
DNS questions. This makes it possible, for instance,
|
|
to allow queries on internal-facing interfaces but
|
|
disallow them on external-facing ones, without
|
|
necessarily knowing the internal network's addresses.
|
|
</para>
|
|
<para>
|
|
Note that <command>allow-query-on</command> is only
|
|
checked for queries that are permitted by
|
|
<command>allow-query</command>. A query must be
|
|
allowed by both ACLs, or it is refused.
|
|
</para>
|
|
<para>
|
|
<command>allow-query-on</command> may
|
|
also be specified in the <command>zone</command>
|
|
statement, in which case it overrides the
|
|
<command>options allow-query-on</command> statement.
|
|
</para>
|
|
<para>
|
|
If not specified, the default is to allow queries
|
|
on all addresses.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
<command>allow-query-cache</command> is
|
|
used to specify access to the cache.
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-query-cache</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which hosts are allowed to get answers
|
|
from the cache. If <command>allow-query-cache</command>
|
|
is not set, BIND checks to see if the following parameters
|
|
are set, in order: <command>allow-recursion</command> and
|
|
<command>allow-query</command>
|
|
(unless <command>recursion no;</command> is
|
|
set, in which case <command>none;</command> is used).
|
|
If neither of those parameters is set, the default (<command>localnets;</command>
|
|
<command>localhost;</command>) is used.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-query-cache-on</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which local addresses can send answers
|
|
from the cache. If not specified, the default is
|
|
to allow cache queries on any address,
|
|
<command>localnets</command>, and
|
|
<command>localhost</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-recursion</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which hosts are allowed to make recursive
|
|
queries through this server. BIND checks to see if the
|
|
following parameters are set, in order:
|
|
<command>allow-recursion</command>, <command>allow-query-cache</command>,
|
|
and <command>allow-query</command>.
|
|
If none of those parameters are set, the default
|
|
(<command>localnets;</command>
|
|
<command>localhost;</command>) is used.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-recursion-on</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which local addresses can accept recursive
|
|
queries. If not specified, the default is to allow
|
|
recursive queries on all addresses.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-update</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which hosts are allowed to
|
|
submit Dynamic DNS updates for primary zones. The default is
|
|
to deny
|
|
updates from all hosts. Note that allowing updates based
|
|
on the requestor's IP address is insecure; see
|
|
<xref linkend="dynamic_update_security"/> for details.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-update-forwarding</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which hosts are allowed to
|
|
submit Dynamic DNS updates to secondary zones to be forwarded to
|
|
the
|
|
primary. The default is <userinput>{ none; }</userinput>,
|
|
which
|
|
means that no update forwarding is performed. To
|
|
enable
|
|
update forwarding, specify
|
|
<userinput>allow-update-forwarding { any; };</userinput>.
|
|
Specifying values other than <userinput>{ none; }</userinput> or
|
|
<userinput>{ any; }</userinput> is usually
|
|
counterproductive;
|
|
the responsibility for update access control should rest
|
|
with the
|
|
primary server, not the secondaries.
|
|
</para>
|
|
<para>
|
|
Note that enabling the update forwarding feature on a secondary
|
|
server
|
|
may expose primary servers to attacks if they rely on insecure
|
|
IP-address-based
|
|
access control; see <xref linkend="dynamic_update_security"/>
|
|
for more details.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-v6-synthesis</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option was introduced for the smooth transition from
|
|
AAAA
|
|
to A6 and from "nibble labels" to binary labels.
|
|
However, since both A6 and binary labels were then
|
|
deprecated,
|
|
this option was also deprecated.
|
|
It is now ignored with some warning messages.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-transfer</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies which hosts are allowed to
|
|
receive zone transfers from the server. <command>allow-transfer</command> may
|
|
also be specified in the <command>zone</command>
|
|
statement, in which
|
|
case it overrides the <command>options allow-transfer</command> statement.
|
|
If not specified, the default is to allow transfers to all
|
|
hosts.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>blackhole</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a list of addresses which the
|
|
server does accept queries from or use to resolve a
|
|
query. Queries
|
|
from these addresses are not responded to. The default
|
|
is <userinput>none</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>filter-aaaa</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a list of addresses to which
|
|
<command>filter-aaaa-on-v4</command>
|
|
and <command>filter-aaaa-on-v6</command>
|
|
apply. The default is <userinput>any</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>keep-response-order</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a list of addresses to which the server
|
|
sends responses to TCP queries, in the same order
|
|
in which they were received. This disables the
|
|
processing of TCP queries in parallel. The default
|
|
is <userinput>none</userinput>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>no-case-compress</command></term> <listitem>
|
|
<para>
|
|
This specifies a list of addresses which require responses
|
|
to use case-insensitive compression. This ACL can be
|
|
used when <command>named</command> needs to work with
|
|
clients that do not comply with the requirement in RFC
|
|
1034 to use case-insensitive name comparisons when
|
|
checking for matching domain names.
|
|
</para>
|
|
<para>
|
|
If left undefined, the ACL defaults to
|
|
<command>none</command>: case-insensitive compression
|
|
is used for all clients. If the ACL is defined and
|
|
matches a client, case is ignored when
|
|
compressing domain names in DNS responses sent to that
|
|
client.
|
|
</para>
|
|
<para>
|
|
This can result in slightly smaller responses; if
|
|
a response contains the names "example.com" and
|
|
"example.COM", case-insensitive compression treats
|
|
the second one as a duplicate. It also ensures
|
|
that the case of the query name exactly matches the
|
|
case of the owner names of returned records, rather
|
|
than matches the case of the records entered in
|
|
the zone file. This allows responses to exactly
|
|
match the query, which is required by some clients
|
|
due to incorrect use of case-sensitive comparisons.
|
|
</para>
|
|
<para>
|
|
Case-insensitive compression is <emphasis>always</emphasis>
|
|
used in AXFR and IXFR responses, regardless of whether
|
|
the client matches this ACL.
|
|
</para>
|
|
<para>
|
|
There are circumstances in which <command>named</command>
|
|
does not preserve the case of owner names of records:
|
|
if a zone file defines records of different types with
|
|
the same name, but the capitalization of the name is
|
|
different (e.g., "www.example.com/A" and
|
|
"WWW.EXAMPLE.COM/AAAA"), then all responses for that
|
|
name use the <emphasis>first</emphasis> version
|
|
of the name that was used in the zone file. This
|
|
limitation may be addressed in a future release. However,
|
|
domain names specified in the rdata of resource records
|
|
(i.e., records of type NS, MX, CNAME, etc.) always
|
|
have their case preserved unless the client matches this
|
|
ACL.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>resolver-query-timeout</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the amount of time in seconds that the
|
|
resolver spends attempting to resolve a recursive
|
|
query before failing. The default and minimum
|
|
is <literal>10</literal> and the maximum is
|
|
<literal>30</literal>. Setting it to
|
|
<literal>0</literal> results in the default
|
|
being used.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="interfaces"><info><title>Interfaces</title></info>
|
|
|
|
<para>
|
|
The interfaces and ports that the server answers queries
|
|
from may be specified using the <command>listen-on</command> option. <command>listen-on</command> takes
|
|
an optional port and an <varname>address_match_list</varname>
|
|
of IPv4 addresses. (IPv6 addresses are ignored, with a
|
|
logged warning.)
|
|
The server listens on all interfaces allowed by the address
|
|
match list. If a port is not specified, port 53 is used.
|
|
</para>
|
|
<para>
|
|
Multiple <command>listen-on</command> statements are
|
|
allowed.
|
|
For example:
|
|
</para>
|
|
|
|
<programlisting>listen-on { 5.6.7.8; };
|
|
listen-on port 1234 { !1.2.3.4; 1.2/16; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
enables the name server 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.
|
|
</para>
|
|
|
|
<para>
|
|
If no <command>listen-on</command> is specified, the
|
|
server listens on port 53 on all IPv4 interfaces.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>listen-on-v6</command> option is used to
|
|
specify the interfaces and the ports on which the server
|
|
listens for incoming queries sent using IPv6. If not specified,
|
|
the server listens on port 53 on all IPv6 interfaces.
|
|
</para>
|
|
|
|
<para>
|
|
When <programlisting>{ any; }</programlisting> is
|
|
specified
|
|
as the <varname>address_match_list</varname> for the
|
|
<command>listen-on-v6</command> option,
|
|
the server does not bind a separate socket to each IPv6 interface
|
|
address as it does for IPv4, if the operating system has enough API
|
|
support for IPv6 (specifically, if it conforms to RFC 3493 and RFC
|
|
3542).
|
|
Instead, it listens on the IPv6 wildcard address.
|
|
If the system only has incomplete API support for IPv6, however,
|
|
the behavior is the same as that for IPv4.
|
|
</para>
|
|
|
|
<para>
|
|
A list of particular IPv6 addresses can also be specified, in
|
|
which case
|
|
the server listens on a separate socket for each specified
|
|
address,
|
|
regardless of whether the desired API is supported by the system.
|
|
IPv4 addresses specified in <command>listen-on-v6</command>
|
|
are ignored, with a logged warning.
|
|
</para>
|
|
|
|
<para>
|
|
Multiple <command>listen-on-v6</command> options can
|
|
be used.
|
|
For example:
|
|
</para>
|
|
|
|
<programlisting>listen-on-v6 { any; };
|
|
listen-on-v6 port 1234 { !2001:db8::/32; any; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
enables the name server on port 53 for any IPv6 addresses
|
|
(with a single wildcard socket),
|
|
and on port 1234 of IPv6 addresses that are not in the prefix
|
|
2001:db8::/32 (with separate sockets for each matched address).
|
|
</para>
|
|
|
|
<para>
|
|
To instruct the server not to listen on any IPv6 address, use:
|
|
</para>
|
|
|
|
<programlisting>listen-on-v6 { none; };
|
|
</programlisting>
|
|
|
|
</section>
|
|
|
|
<section xml:id="query_address"><info><title>Query Address</title></info>
|
|
|
|
<para>
|
|
If the server does not know the answer to a question, it
|
|
queries other name servers. <command>query-source</command> specifies
|
|
the address and port used for such queries. For queries sent over
|
|
IPv6, there is a separate <command>query-source-v6</command> option.
|
|
If <command>address</command> is <command>*</command> (asterisk) or is omitted,
|
|
a wildcard IP address (<command>INADDR_ANY</command>)
|
|
is used.
|
|
</para>
|
|
|
|
<para>
|
|
If <command>port</command> is <command>*</command> or is omitted,
|
|
a random port number from a pre-configured
|
|
range is picked up and used for each query.
|
|
The port range(s) is specified in
|
|
the <command>use-v4-udp-ports</command> (for IPv4)
|
|
and <command>use-v6-udp-ports</command> (for IPv6)
|
|
options, excluding the ranges specified in
|
|
the <command>avoid-v4-udp-ports</command>
|
|
and <command>avoid-v6-udp-ports</command> options, respectively.
|
|
</para>
|
|
|
|
<para>
|
|
The defaults of the <command>query-source</command> and
|
|
<command>query-source-v6</command> options
|
|
are:
|
|
</para>
|
|
|
|
<programlisting>query-source address * port *;
|
|
query-source-v6 address * port *;
|
|
</programlisting>
|
|
|
|
<para>
|
|
If <command>use-v4-udp-ports</command> or
|
|
<command>use-v6-udp-ports</command> is unspecified,
|
|
<command>named</command> checks whether the operating
|
|
system provides a programming interface to retrieve the
|
|
system's default range for ephemeral ports.
|
|
If such an interface is available,
|
|
<command>named</command> uses the corresponding system
|
|
default range; otherwise, it uses its own defaults:
|
|
</para>
|
|
|
|
<programlisting>use-v4-udp-ports { range 1024 65535; };
|
|
use-v6-udp-ports { range 1024 65535; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
Note: make sure the ranges are sufficiently large for
|
|
security. A desirable size depends on several parameters,
|
|
but we generally recommend it contain at least 16384 ports
|
|
(14 bits of entropy).
|
|
Note also that the system's default range when used may be
|
|
too small for this purpose, and that the range may even be
|
|
changed while <command>named</command> is running; the new
|
|
range is automatically applied when <command>named</command>
|
|
is reloaded.
|
|
Explicit
|
|
configuration of <command>use-v4-udp-ports</command> and
|
|
<command>use-v6-udp-ports</command> is encouraged, so that the
|
|
ranges are sufficiently large and are reasonably
|
|
independent from the ranges used by other applications.
|
|
</para>
|
|
|
|
<para>
|
|
Note: the operational configuration
|
|
where <command>named</command> runs may prohibit the use
|
|
of some ports. For example, Unix systems do not allow
|
|
<command>named</command>, if run without root privilege,
|
|
to use ports less than 1024.
|
|
If such ports are included in the specified (or detected)
|
|
set of query ports, the corresponding query attempts will
|
|
fail, resulting in resolution failures or delay.
|
|
It is therefore important to configure the set of ports
|
|
that can be safely used in the expected operational environment.
|
|
</para>
|
|
|
|
<para>
|
|
The defaults of the <command>avoid-v4-udp-ports</command> and
|
|
<command>avoid-v6-udp-ports</command> options
|
|
are:
|
|
</para>
|
|
|
|
<programlisting>avoid-v4-udp-ports {};
|
|
avoid-v6-udp-ports {};
|
|
</programlisting>
|
|
|
|
<para>
|
|
Note: BIND 9.5.0 introduced
|
|
the <command>use-queryport-pool</command>
|
|
option to support a pool of such random ports, but this
|
|
option is now obsolete because reusing the same ports in
|
|
the pool may not be sufficiently secure.
|
|
For the same reason, it is generally strongly discouraged to
|
|
specify a particular port for the
|
|
<command>query-source</command> or
|
|
<command>query-source-v6</command> options;
|
|
it implicitly disables the use of randomized port numbers.
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>use-queryport-pool</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is obsolete.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>queryport-pool-ports</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is obsolete.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>queryport-pool-updateinterval</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is obsolete.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
<note>
|
|
<para>
|
|
The address specified in the <command>query-source</command> 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.
|
|
</para>
|
|
</note>
|
|
<note>
|
|
<para>
|
|
Solaris 2.5.1 and earlier does not support setting the source
|
|
address for TCP sockets.
|
|
</para>
|
|
</note>
|
|
<note>
|
|
<para>
|
|
See also <command>transfer-source</command> and
|
|
<command>notify-source</command>.
|
|
</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section xml:id="zone_transfers"><info><title>Zone Transfers</title></info>
|
|
|
|
<para>
|
|
<acronym>BIND</acronym> 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.
|
|
</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>also-notify</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option 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
|
|
quickly converge on stealth servers.
|
|
Optionally, a port may be specified with each
|
|
<command>also-notify</command> address to send
|
|
the notify messages to a port other than the
|
|
default of 53.
|
|
An optional TSIG key can also be specified with each
|
|
address to cause the notify messages to be signed; this
|
|
can be useful when sending notifies to multiple views.
|
|
In place of explicit addresses, one or more named
|
|
<command>masters</command> lists can be used.
|
|
</para>
|
|
<para>
|
|
If an <command>also-notify</command> list
|
|
is given in a <command>zone</command> statement,
|
|
it overrides
|
|
the <command>options also-notify</command>
|
|
statement. When a <command>zone notify</command>
|
|
statement
|
|
is set to <command>no</command>, the IP
|
|
addresses in the global <command>also-notify</command> list are
|
|
not sent NOTIFY messages for that zone. The default is
|
|
the empty
|
|
list (no global notification list).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-transfer-time-in</command></term>
|
|
<listitem>
|
|
<para>
|
|
Inbound zone transfers running longer than
|
|
this many minutes are terminated. The default is 120
|
|
minutes
|
|
(2 hours). The maximum value is 28 days (40320 minutes).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-transfer-idle-in</command></term>
|
|
<listitem>
|
|
<para>
|
|
Inbound zone transfers making no progress
|
|
in this many minutes are terminated. The default is 60
|
|
minutes
|
|
(1 hour). The maximum value is 28 days (40320 minutes).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-transfer-time-out</command></term>
|
|
<listitem>
|
|
<para>
|
|
Outbound zone transfers running longer than
|
|
this many minutes are terminated. The default is 120
|
|
minutes
|
|
(2 hours). The maximum value is 28 days (40320 minutes).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-transfer-idle-out</command></term>
|
|
<listitem>
|
|
<para>
|
|
Outbound zone transfers making no progress
|
|
in this many minutes are terminated. The default is 60
|
|
minutes (1
|
|
hour). The maximum value is 28 days (40320 minutes).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify-rate</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the rate at which NOTIFY requests are sent
|
|
during normal zone maintenance operations. (NOTIFY
|
|
requests due to initial zone loading are subject
|
|
to a separate rate limit; see below.) The default is
|
|
20 per second.
|
|
The lowest possible rate is one per second; when set
|
|
to zero, it is silently raised to one.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>startup-notify-rate</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the rate at which NOTIFY requests are sent
|
|
when the name server is first starting up, or when
|
|
zones have been newly added to the name server.
|
|
The default is 20 per second.
|
|
The lowest possible rate is one per second; when set
|
|
to zero, it is silently raised to one.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>serial-query-rate</command></term>
|
|
<listitem>
|
|
<para>
|
|
Secondary servers periodically query primary
|
|
servers to find out if zone serial numbers have
|
|
changed. Each such query uses a minute amount of
|
|
the secondary 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
|
|
<command>serial-query-rate</command> option, an
|
|
integer, is the maximum number of queries sent
|
|
per second. The default is 20 per second.
|
|
The lowest possible rate is one per second; when set
|
|
to zero, it is silently raised to one.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>serial-queries</command></term>
|
|
<listitem>
|
|
<para>
|
|
BIND 9 does not limit the number of outstanding
|
|
serial queries and ignores the <command>serial-queries</command> option.
|
|
Instead, it limits the rate at which the queries are sent
|
|
as defined using the <command>serial-query-rate</command> option.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfer-format</command></term>
|
|
<listitem>
|
|
|
|
<para>
|
|
Zone transfers can be sent using two different formats,
|
|
<command>one-answer</command> and
|
|
<command>many-answers</command>.
|
|
The <command>transfer-format</command> option is used
|
|
on the primary server to determine which format it sends.
|
|
<command>one-answer</command> uses one DNS message per
|
|
resource record transferred.
|
|
<command>many-answers</command> packs as many resource
|
|
records as possible into one message.
|
|
<command>many-answers</command> is more efficient; the default is <command>many-answers</command>.
|
|
The <command>many-answers</command> format is also supported by
|
|
recent Microsoft Windows name servers.
|
|
<command>transfer-format</command> may be overridden on a
|
|
per-server basis by using the <command>server</command>
|
|
statement.
|
|
</para>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfer-message-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is an upper bound on the uncompressed size of DNS
|
|
messages used in zone transfers over TCP. If a message
|
|
grows larger than this size, additional messages are
|
|
used to complete the zone transfer. (Note, however,
|
|
that this is a hint, not a hard limit; if a message
|
|
contains a single resource record whose RDATA does not
|
|
fit within the size limit, a larger message will be
|
|
permitted so the record can be transferred.)
|
|
</para>
|
|
<para>
|
|
Valid values are between 512 and 65535 octets; any
|
|
values outside that range are adjusted to the nearest
|
|
value within it. The default is <literal>20480</literal>,
|
|
which was selected to improve message compression;
|
|
most DNS messages of this size will compress to less
|
|
than 16536 bytes. Larger messages cannot be compressed
|
|
as effectively, because 16536 is the largest permissible
|
|
compression offset pointer in a DNS message.
|
|
</para>
|
|
<para>
|
|
This option is mainly intended for server testing;
|
|
there is rarely any benefit in setting a value other
|
|
than the default.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfers-in</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the maximum number of inbound zone transfers
|
|
that can run concurrently. The default value is <literal>10</literal>.
|
|
Increasing <command>transfers-in</command> may
|
|
speed up the convergence
|
|
of secondary zones, but it also may increase the load on the
|
|
local system.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfers-out</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the maximum number of outbound zone transfers
|
|
that can run concurrently. Zone transfer requests in
|
|
excess
|
|
of the limit are refused. The default value is <literal>10</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfers-per-ns</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the maximum number of inbound zone transfers
|
|
that can concurrently transfer from a given remote
|
|
name server.
|
|
The default value is <literal>2</literal>.
|
|
Increasing <command>transfers-per-ns</command>
|
|
may
|
|
speed up the convergence of secondary zones, but it also may
|
|
increase
|
|
the load on the remote name server. <command>transfers-per-ns</command> may
|
|
be overridden on a per-server basis by using the <command>transfers</command> phrase
|
|
of the <command>server</command> statement.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfer-source</command></term>
|
|
<listitem>
|
|
<para><command>transfer-source</command>
|
|
determines which local address is 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 is usually the address
|
|
of the interface "closest to" the remote end. This
|
|
address must appear in the remote end's
|
|
<command>allow-transfer</command> option for the
|
|
zone being transferred, if one is specified. This
|
|
statement sets the
|
|
<command>transfer-source</command> for all zones,
|
|
but can be overridden on a per-view or per-zone
|
|
basis by including a
|
|
<command>transfer-source</command> statement within
|
|
the <command>view</command> or
|
|
<command>zone</command> block in the configuration
|
|
file.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
Solaris 2.5.1 and earlier does not support setting the
|
|
source address for TCP sockets.
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfer-source-v6</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is the same as <command>transfer-source</command>,
|
|
except zone transfers are performed using IPv6.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>alt-transfer-source</command></term>
|
|
<listitem>
|
|
<para>
|
|
This indicates an alternate transfer source if the one listed in
|
|
<command>transfer-source</command> fails and
|
|
<command>use-alt-transfer-source</command> is
|
|
set.
|
|
</para>
|
|
<note><simpara>
|
|
To avoid using the alternate transfer source,
|
|
set <command>use-alt-transfer-source</command>
|
|
appropriately and do not depend upon
|
|
getting an answer back to the first refresh
|
|
query.
|
|
</simpara></note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>alt-transfer-source-v6</command></term>
|
|
<listitem>
|
|
<para>
|
|
This indicates an alternate transfer source if the one listed in
|
|
<command>transfer-source-v6</command> fails and
|
|
<command>use-alt-transfer-source</command> is
|
|
set.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>use-alt-transfer-source</command></term>
|
|
<listitem>
|
|
<para>
|
|
This indicates whether the alternate transfer sources should be used. If views are
|
|
specified, this defaults to <command>no</command>;
|
|
otherwise, it defaults to
|
|
<command>yes</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify-source</command></term>
|
|
<listitem>
|
|
<para><command>notify-source</command>
|
|
determines which local source address, and
|
|
optionally UDP port, is used to send NOTIFY
|
|
messages. This address must appear in the secondary
|
|
server's <command>masters</command> zone clause or
|
|
in an <command>allow-notify</command> clause. This
|
|
statement sets the <command>notify-source</command>
|
|
for all zones, but can be overridden on a per-zone or
|
|
per-view basis by including a
|
|
<command>notify-source</command> statement within
|
|
the <command>zone</command> or
|
|
<command>view</command> block in the configuration
|
|
file.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
Solaris 2.5.1 and earlier does not support setting the
|
|
source address for TCP sockets.
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify-source-v6</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option acts like <command>notify-source</command>,
|
|
but applies to notify messages sent to IPv6 addresses.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="port_lists"><info><title>UDP Port Lists</title></info>
|
|
|
|
<para>
|
|
<command>use-v4-udp-ports</command>,
|
|
<command>avoid-v4-udp-ports</command>,
|
|
<command>use-v6-udp-ports</command>, and
|
|
<command>avoid-v6-udp-ports</command>
|
|
specify a list of IPv4 and IPv6 UDP ports that are
|
|
or are not used as source ports for UDP messages.
|
|
See <xref linkend="query_address"/> about how the
|
|
available ports are determined.
|
|
For example, with the following configuration:
|
|
</para>
|
|
|
|
<programlisting>
|
|
use-v6-udp-ports { range 32768 65535; };
|
|
avoid-v6-udp-ports { 40000; range 50000 60000; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
UDP ports of IPv6 messages sent
|
|
from <command>named</command> are in one
|
|
of the following ranges: 32768 to 39999, 40001 to 49999,
|
|
and 60001 to 65535.
|
|
</para>
|
|
|
|
<para>
|
|
<command>avoid-v4-udp-ports</command> and
|
|
<command>avoid-v6-udp-ports</command> can be used
|
|
to prevent <command>named</command> from choosing as its random source port a
|
|
port that is blocked by a firewall or a port that is
|
|
used by other applications;
|
|
if a query went out with a source port blocked by a
|
|
firewall, the
|
|
answer would not pass through the firewall and the name server would
|
|
have to query again.
|
|
Note: the desired range can also be represented only with
|
|
<command>use-v4-udp-ports</command> and
|
|
<command>use-v6-udp-ports</command>, and the
|
|
<command>avoid-</command> options are redundant in that
|
|
sense; they are provided for backward compatibility and
|
|
to possibly simplify the port specification.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="resource_limits"><info><title>Operating System Resource Limits</title></info>
|
|
|
|
<para>
|
|
The server's usage of many system resources can be limited.
|
|
Scaled values are allowed when specifying resource limits. For
|
|
example, <command>1G</command> can be used instead of
|
|
<command>1073741824</command> to specify a limit of
|
|
one
|
|
gigabyte. <command>unlimited</command> requests
|
|
unlimited use, or the
|
|
maximum available amount. <command>default</command>
|
|
uses the limit
|
|
that was in force when the server was started. See the description
|
|
of <command>size_spec</command> in <xref linkend="configuration_file_elements"/>.
|
|
</para>
|
|
|
|
<para>
|
|
The following options set operating system resource limits for
|
|
the name server process. Some operating systems do not support
|
|
some or
|
|
any of the limits; on such systems, a warning is issued if
|
|
an
|
|
unsupported limit is used.
|
|
</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>coresize</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum size of a core dump. The default
|
|
is <literal>default</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>datasize</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum amount of data memory the server
|
|
may use. The default is <literal>default</literal>.
|
|
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 to limit 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. To limit the amount
|
|
of memory used by the server, use the
|
|
<command>max-cache-size</command> and
|
|
<command>recursive-clients</command>
|
|
options instead.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>files</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum number of files the server
|
|
may have open concurrently. The default is <literal>unlimited</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>stacksize</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum amount of stack memory the server
|
|
may use. The default is <literal>default</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="server_resource_limits"><info><title>Server Resource Limits</title></info>
|
|
|
|
<para>
|
|
The following options set limits on the server's
|
|
resource consumption that are enforced internally by the
|
|
server rather than by the operating system.
|
|
</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>max-ixfr-log-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is obsolete; it is accepted
|
|
and ignored for BIND 8 compatibility. The option
|
|
<command>max-journal-size</command> performs a
|
|
similar function in BIND 9.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-journal-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets a maximum size for each journal file
|
|
(see <xref linkend="journal"/>). When the journal file
|
|
approaches
|
|
the specified size, some of the oldest transactions in the
|
|
journal
|
|
are automatically removed. The largest permitted
|
|
value is 2 gigabytes. The default is
|
|
<literal>unlimited</literal>, which also
|
|
means 2 gigabytes.
|
|
This option may also be set on a per-zone basis.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-records</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum number of records permitted in a zone.
|
|
The default is zero, which means the maximum is unlimited.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>host-statistics-max</command></term>
|
|
<listitem>
|
|
<para>
|
|
In BIND 8, this specified the maximum number of host statistics
|
|
entries to be kept.
|
|
It is not implemented in BIND 9.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>recursive-clients</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum number (a "hard quota") of simultaneous
|
|
recursive lookups the server performs on behalf
|
|
of clients. The default is
|
|
<literal>1000</literal>. Because each recursing
|
|
client uses a fair
|
|
bit of memory (on the order of 20 kilobytes), the
|
|
value of the
|
|
<command>recursive-clients</command> option may
|
|
have to be decreased on hosts with limited memory.
|
|
</para>
|
|
<para>
|
|
<option>recursive-clients</option> defines a "hard
|
|
quota" limit for pending recursive clients; when more
|
|
clients than this are pending, new incoming requests
|
|
are not accepted, and for each incoming request
|
|
a previous pending request is dropped.
|
|
</para>
|
|
<para>
|
|
A "soft quota" is also set. When this lower
|
|
quota is exceeded, incoming requests are accepted, but
|
|
for each one, a pending request is dropped.
|
|
If <option>recursive-clients</option> is greater than
|
|
1000, the soft quota is set to
|
|
<option>recursive-clients</option> minus 100;
|
|
otherwise it is set to 90% of
|
|
<option>recursive-clients</option>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>tcp-clients</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the maximum number of simultaneous client TCP
|
|
connections that the server accepts.
|
|
The default is <literal>150</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="clients-per-query">
|
|
<term xml:id="cpq_term"><command>clients-per-query</command></term>;
|
|
<term><command>max-clients-per-query</command></term>
|
|
<listitem>
|
|
<para>These set the
|
|
initial value (minimum) and maximum number of recursive
|
|
simultaneous clients for any given query
|
|
(<qname,qtype,qclass>) that the server accepts
|
|
before dropping additional clients. <command>named</command> attempts to
|
|
self-tune this value and changes are logged. The
|
|
default values are 10 and 100.
|
|
</para>
|
|
<para>
|
|
This value should reflect how many queries come in for
|
|
a given name in the time it takes to resolve that name.
|
|
If the number of queries exceeds this value, <command>named</command>
|
|
assumes that it is dealing with a non-responsive zone
|
|
and drops additional queries. If it gets a response
|
|
after dropping queries, it raises the estimate. The
|
|
estimate is then lowered in 20 minutes if it has
|
|
remained unchanged.
|
|
</para>
|
|
<para>
|
|
If <command>clients-per-query</command> is set to zero,
|
|
there is no limit on the number of clients per query
|
|
and no queries are dropped.
|
|
</para>
|
|
<para>
|
|
If <command>max-clients-per-query</command> is set to zero,
|
|
there is no upper bound other than imposed by
|
|
<command>recursive-clients</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="fetches-per-zone">
|
|
<term><command>fetches-per-zone</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum number of simultaneous iterative
|
|
queries to any one domain that the server
|
|
permits before blocking new queries for data
|
|
in or beneath that zone.
|
|
This value should reflect how many fetches would
|
|
normally be sent to any one zone in the time it
|
|
would take to resolve them. It should be smaller
|
|
than <option>recursive-clients</option>.
|
|
</para>
|
|
<para>
|
|
When many clients simultaneously query for the
|
|
same name and type, the clients are all attached
|
|
to the same fetch, up to the
|
|
<option>max-clients-per-query</option> limit,
|
|
and only one iterative query is sent.
|
|
However, when clients are simultaneously
|
|
querying for <emphasis>different</emphasis> names
|
|
or types, multiple queries are sent and
|
|
<option>max-clients-per-query</option> is not
|
|
effective as a limit.
|
|
</para>
|
|
<para>
|
|
Optionally, this value may be followed by the keyword
|
|
<literal>drop</literal> or <literal>fail</literal>,
|
|
indicating whether queries which exceed the fetch
|
|
quota for a zone are dropped with no response,
|
|
or answered with SERVFAIL. The default is
|
|
<literal>drop</literal>.
|
|
</para>
|
|
<para>
|
|
If <command>fetches-per-zone</command> is set to zero,
|
|
there is no limit on the number of fetches per query
|
|
and no queries are dropped. The default is zero.
|
|
</para>
|
|
<para>
|
|
The current list of active fetches can be dumped by
|
|
running <command>rndc recursing</command>. The list
|
|
includes the number of active fetches for each
|
|
domain and the number of queries that have been
|
|
passed or dropped as a result of the
|
|
<option>fetches-per-zone</option> limit. (Note:
|
|
these counters are not cumulative over time; whenever
|
|
the number of active fetches for a domain drops to
|
|
zero, the counter for that domain is deleted, and the
|
|
next time a fetch is sent to that domain, it is
|
|
recreated with the counters set to zero.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="fetches-per-server">
|
|
<term><command>fetches-per-server</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum number of simultaneous iterative
|
|
queries that the server allows to be sent to
|
|
a single upstream name server before blocking
|
|
additional queries.
|
|
This value should reflect how many fetches would
|
|
normally be sent to any one server in the time it
|
|
would take to resolve them. It should be smaller
|
|
than <option>recursive-clients</option>.
|
|
</para>
|
|
<para>
|
|
Optionally, this value may be followed by the keyword
|
|
<literal>drop</literal> or <literal>fail</literal>,
|
|
indicating whether queries are dropped with no
|
|
response or answered with SERVFAIL, when all of the
|
|
servers authoritative for a zone are found to have
|
|
exceeded the per-server quota. The default is
|
|
<literal>fail</literal>.
|
|
</para>
|
|
<para>
|
|
If <command>fetches-per-server</command> is set to zero,
|
|
there is no limit on the number of fetches per query
|
|
and no queries are dropped. The default is zero.
|
|
</para>
|
|
<para>
|
|
The <command>fetches-per-server</command> quota is
|
|
dynamically adjusted in response to detected
|
|
congestion. As queries are sent to a server
|
|
and are either answered or time out, an
|
|
exponentially weighted moving average is calculated
|
|
of the ratio of timeouts to responses. If the
|
|
current average timeout ratio rises above a "high"
|
|
threshold, then <command>fetches-per-server</command>
|
|
is reduced for that server. If the timeout ratio
|
|
drops below a "low" threshold, then
|
|
<command>fetches-per-server</command> is increased.
|
|
The <command>fetch-quota-params</command> options
|
|
can be used to adjust the parameters for this
|
|
calculation.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>fetch-quota-params</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the parameters to use for dynamic resizing of
|
|
the <option>fetches-per-server</option> quota in
|
|
response to detected congestion.
|
|
</para>
|
|
<para>
|
|
The first argument is an integer value indicating
|
|
how frequently to recalculate the moving average
|
|
of the ratio of timeouts to responses for each
|
|
server. The default is 100, meaning that BIND recalculates
|
|
the average ratio after every 100 queries have either
|
|
been answered or timed out.
|
|
</para>
|
|
<para>
|
|
The remaining three arguments represent the "low"
|
|
threshold (defaulting to a timeout ratio of 0.1),
|
|
the "high" threshold (defaulting to a timeout
|
|
ratio of 0.3), and the discount rate for
|
|
the moving average (defaulting to 0.7).
|
|
A higher discount rate causes recent events to
|
|
weigh more heavily when calculating the moving
|
|
average; a lower discount rate causes past
|
|
events to weigh more heavily, smoothing out
|
|
short-term blips in the timeout ratio.
|
|
These arguments are all fixed-point numbers with
|
|
precision of 1/100; at most two places after
|
|
the decimal point are significant.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>reserved-sockets</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the number of file descriptors reserved for TCP, stdio,
|
|
etc. This needs to be big enough to cover the number of
|
|
interfaces <command>named</command> listens on plus
|
|
<command>tcp-clients</command>, as well as
|
|
to provide room for outgoing TCP queries and incoming zone
|
|
transfers. The default is <literal>512</literal>.
|
|
The minimum value is <literal>128</literal> and the
|
|
maximum value is <literal>128</literal> fewer than
|
|
maxsockets (-S). This option may be removed in the future.
|
|
</para>
|
|
<para>
|
|
This option has little effect on Windows.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-cache-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum amount of memory to use for the
|
|
server's cache, in bytes or percentage of total physical memory.
|
|
When the amount of data in the cache
|
|
reaches this limit, the server causes records to
|
|
expire prematurely, following an LRU-based strategy, so
|
|
that the limit is not exceeded.
|
|
The keyword <userinput>unlimited</userinput>,
|
|
or the value 0, places no limit on the cache size;
|
|
records are purged from the cache only when their
|
|
TTLs expire.
|
|
Any positive values less than 2MB are ignored
|
|
and reset to 2MB.
|
|
In a server with multiple views, the limit applies
|
|
separately to the cache of each view.
|
|
The default is <userinput>90%</userinput>.
|
|
On systems where detection of the amount of physical
|
|
memory is not supported, values represented as a percentage
|
|
fall back to unlimited.
|
|
Note that the detection of physical memory is done only
|
|
once at startup, so <command>named</command> does not
|
|
adjust the cache size if the amount of physical memory
|
|
is changed during runtime.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>tcp-listen-queue</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the listen-queue depth. The default and minimum is 10.
|
|
If the kernel supports the accept filter "dataready", this
|
|
also controls how
|
|
many TCP connections are queued in kernel space
|
|
waiting for
|
|
some data before being passed to accept. Non-zero values
|
|
less than 10 are silently raised. A value of 0 may also
|
|
be used; on most platforms this sets the listen-queue
|
|
length to a system-defined default value.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="intervals"><info><title>Periodic Task Intervals</title></info>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>cleaning-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
This interval is effectively obsolete. Previously,
|
|
the server removed expired resource records
|
|
from the cache every <command>cleaning-interval</command> minutes.
|
|
<acronym>BIND</acronym> 9 now manages cache
|
|
memory in a more sophisticated manner and does not
|
|
rely on periodic cleaning anymore.
|
|
Specifying this option therefore has no effect on
|
|
the server's behavior.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>heartbeat-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
The server performs zone maintenance tasks
|
|
for all zones marked as <command>dialup</command> whenever this
|
|
interval expires. The default is 60 minutes. Reasonable
|
|
values are up
|
|
to 1 day (1440 minutes). The maximum value is 28 days
|
|
(40320 minutes).
|
|
If set to 0, no zone maintenance for these zones occurs.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>interface-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
The server scans the network interface list
|
|
every <command>interface-interval</command>
|
|
minutes. The default
|
|
is 60 minutes; the maximum value is 28 days (40320 minutes).
|
|
If set to 0, interface scanning only occurs when
|
|
the configuration file is loaded, or when
|
|
<command>automatic-interface-scan</command> is enabled
|
|
and supported by the operating system. After the scan, the
|
|
server begins listening for queries on any newly
|
|
discovered interfaces (provided they are allowed by the
|
|
<command>listen-on</command> configuration), and
|
|
stops listening on interfaces that have gone away.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>statistics-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
Name server statistics are logged
|
|
every <command>statistics-interval</command>
|
|
minutes. The default is
|
|
60, and the maximum value is 28 days (40320 minutes).
|
|
If set to 0, no statistics are logged.
|
|
</para><note>
|
|
<simpara>
|
|
This option is not implemented in
|
|
<acronym>BIND</acronym> 9.
|
|
</simpara>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>topology</command></term>
|
|
<listitem>
|
|
<para>
|
|
In BIND 8, this option indicated network topology
|
|
so that preferential treatment could be given to
|
|
the topologically closest name servers when sending
|
|
queries. It is not implemented in BIND 9.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="the_sortlist_statement"><info><title>The <command>sortlist</command> Statement</title></info>
|
|
|
|
<para>
|
|
The response to a DNS query may consist of multiple resource
|
|
records (RRs) forming a resource record set (RRset). The name
|
|
server normally returns the RRs within the RRset in an
|
|
indeterminate order (but see the <command>rrset-order</command>
|
|
statement in <xref linkend="rrset_ordering"/>). 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 name
|
|
servers, not all the clients.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>sortlist</command> statement (see below) takes an
|
|
<command>address_match_list</command> and interprets it in a
|
|
special way. Each top-level statement in the
|
|
<command>sortlist</command> must itself be an explicit
|
|
<command>address_match_list</command> with one or two elements.
|
|
The first element (which may be an IP address, an IP prefix, an
|
|
ACL name, or a nested <command>address_match_list</command>) of
|
|
each top-level list is checked against the source address of
|
|
the query until a match is found. When the addresses in the
|
|
first element overlap, the first rule to match is selected.
|
|
</para>
|
|
<para>
|
|
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 interpreted as a topology preference
|
|
list. 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.
|
|
</para>
|
|
<para>
|
|
In the following example, any queries received from any of the
|
|
addresses of the host itself 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 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 only prefer other addresses on
|
|
their directly connected networks.
|
|
</para>
|
|
|
|
<programlisting>sortlist {
|
|
// IF the local host
|
|
// THEN first fit on the following nets
|
|
{ localhost;
|
|
{ localnets;
|
|
192.168.1/24;
|
|
{ 192.168.2/24; 192.168.3/24; }; }; };
|
|
// IF on class C 192.168.1 THEN use .1, or .2 or .3
|
|
{ 192.168.1/24;
|
|
{ 192.168.1/24;
|
|
{ 192.168.2/24; 192.168.3/24; }; }; };
|
|
// IF on class C 192.168.2 THEN use .2, or .1 or .3
|
|
{ 192.168.2/24;
|
|
{ 192.168.2/24;
|
|
{ 192.168.1/24; 192.168.3/24; }; }; };
|
|
// IF on class C 192.168.3 THEN use .3, or .1 or .2
|
|
{ 192.168.3/24;
|
|
{ 192.168.3/24;
|
|
{ 192.168.1/24; 192.168.2/24; }; }; };
|
|
// IF .4 or .5 THEN prefer that net
|
|
{ { 192.168.4/24; 192.168.5/24; };
|
|
};
|
|
};</programlisting>
|
|
|
|
<para>
|
|
The following example illustrates reasonable behavior for the
|
|
local host and hosts on directly connected networks. Responses sent to queries from
|
|
the local host favor any of the directly connected
|
|
networks. Responses sent to queries from any other hosts on a
|
|
directly connected network prefer addresses on that same
|
|
network. Responses to other queries are not sorted.
|
|
</para>
|
|
|
|
<programlisting>sortlist {
|
|
{ localhost; localnets; };
|
|
{ localnets; };
|
|
};
|
|
</programlisting>
|
|
|
|
</section>
|
|
<section xml:id="rrset_ordering"><info><title xml:id="rrset_ordering_title">RRset Ordering</title></info>
|
|
|
|
<para>
|
|
When multiple records are returned in an answer, it may be
|
|
useful to configure the order of the records placed into the
|
|
response.
|
|
The <command>rrset-order</command> statement permits
|
|
configuration
|
|
of the ordering of the records in a multiple-record response.
|
|
See also the <command>sortlist</command> statement,
|
|
<xref linkend="the_sortlist_statement"/>.
|
|
</para>
|
|
|
|
<para>
|
|
An <command>order_spec</command> is defined as
|
|
follows:
|
|
</para>
|
|
<para>
|
|
<optional>class <replaceable>class_name</replaceable></optional>
|
|
<optional>type <replaceable>type_name</replaceable></optional>
|
|
<optional>name <replaceable>"domain_name"</replaceable></optional>
|
|
order <replaceable>ordering</replaceable>
|
|
</para>
|
|
<para>
|
|
If no class is specified, the default is <command>ANY</command>.
|
|
If no type is specified, the default is <command>ANY</command>.
|
|
If no name is specified, the default is "<command>*</command>" (asterisk).
|
|
</para>
|
|
<para>
|
|
The legal values for <command>ordering</command> are:
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="0.750in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.750in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>fixed</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Records are returned in the order they
|
|
are defined in the zone file.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>random</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Records are returned in a random order.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>cyclic</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Records are returned in a cyclic round-robin order, rotating by one record per query.
|
|
</para>
|
|
<para>
|
|
If <acronym>BIND</acronym> is configured with the
|
|
"--enable-fixed-rrset" option at compile time,
|
|
the initial ordering of the RRset matches the
|
|
one specified in the zone file.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<para>
|
|
For example:
|
|
</para>
|
|
|
|
<programlisting>rrset-order {
|
|
class IN type A name "host.example.com" order random;
|
|
order cyclic;
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
causes any responses for type A records in class IN, that
|
|
have "<literal>host.example.com</literal>" as a
|
|
suffix, to always be returned
|
|
in random order. All other records are returned in cyclic order.
|
|
</para>
|
|
<para>
|
|
If multiple <command>rrset-order</command> statements
|
|
appear, they are not combined; the last one applies.
|
|
</para>
|
|
<para>
|
|
By default, records are returned in random order.
|
|
</para>
|
|
|
|
<note>
|
|
<simpara>
|
|
In this release of <acronym>BIND</acronym> 9, the
|
|
<command>rrset-order</command> statement does not support
|
|
"fixed" ordering by default. Fixed ordering can be enabled
|
|
at compile time by specifying "--enable-fixed-rrset" on
|
|
the "configure" command line.
|
|
</simpara>
|
|
</note>
|
|
</section>
|
|
|
|
<section xml:id="tuning"><info><title>Tuning</title></info>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>lame-ttl</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the number of seconds to cache a
|
|
lame server indication. 0 disables caching. (This is
|
|
<emphasis role="bold">NOT</emphasis> recommended.)
|
|
The default is <literal>600</literal> (10 minutes) and the
|
|
maximum value is
|
|
<literal>1800</literal> (30 minutes).
|
|
</para>
|
|
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>servfail-ttl</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the number of seconds to cache a
|
|
SERVFAIL response due to DNSSEC validation failure or
|
|
other general server failure. If set to
|
|
<literal>0</literal>, SERVFAIL caching is disabled.
|
|
The SERVFAIL cache is not consulted if a query has
|
|
the CD (Checking Disabled) bit set; this allows a
|
|
query that failed due to DNSSEC validation to be retried
|
|
without waiting for the SERVFAIL TTL to expire.
|
|
</para>
|
|
<para>
|
|
The maximum value is <literal>30</literal>
|
|
seconds; any higher value is silently
|
|
reduced. The default is <literal>1</literal>
|
|
second.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-ncache-ttl</command></term>
|
|
<listitem>
|
|
<para>
|
|
To reduce network traffic and increase performance,
|
|
the server stores negative answers. <command>max-ncache-ttl</command> is
|
|
used to set a maximum retention time for these answers in
|
|
the server,
|
|
in seconds. The default
|
|
<command>max-ncache-ttl</command> is <literal>10800</literal> seconds (3 hours).
|
|
<command>max-ncache-ttl</command> cannot exceed
|
|
7 days and is
|
|
silently truncated to 7 days if set to a greater value.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-cache-ttl</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum time for which the server
|
|
caches ordinary (positive) answers, in seconds.
|
|
The default is 604800 (one week).
|
|
A value of zero may cause all queries to return
|
|
SERVFAIL, because of lost caches of intermediate
|
|
RRsets (such as NS and glue AAAA/A records) in the
|
|
resolution process.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>min-roots</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the minimum number of root servers that
|
|
is required for a request for the root servers to be
|
|
accepted. The default
|
|
is <userinput>2</userinput>.
|
|
</para>
|
|
<note>
|
|
<simpara>
|
|
This is not implemented in <acronym>BIND</acronym> 9.
|
|
</simpara>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sig-validity-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the number of days into the future that
|
|
DNSSEC signatures that are automatically generated as a
|
|
result of dynamic updates (<xref linkend="dynamic_update"/>) will expire. There
|
|
is an optional second field which specifies how
|
|
long before expiry that the signatures are
|
|
regenerated. If not specified, the signatures are
|
|
regenerated at 1/4 of base interval. The second
|
|
field is specified in days if the base interval is
|
|
greater than 7 days; otherwise it is specified in hours.
|
|
The default base interval is <literal>30</literal> days,
|
|
giving a re-signing interval of 7 1/2 days. The maximum
|
|
value is 10 years (3660 days).
|
|
</para>
|
|
<para>
|
|
The signature inception time is unconditionally
|
|
set to one hour before the current time, to allow
|
|
for a limited amount of clock skew.
|
|
</para>
|
|
<para>
|
|
The <command>sig-validity-interval</command>
|
|
should be at least several multiples of the SOA
|
|
expire interval, to allow for reasonable interaction
|
|
between the various timer and expiry dates.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sig-signing-nodes</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the maximum number of nodes to be
|
|
examined in each quantum, when signing a zone with
|
|
a new DNSKEY. The default is
|
|
<literal>100</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sig-signing-signatures</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a threshold number of signatures that
|
|
terminates processing a quantum, when signing
|
|
a zone with a new DNSKEY. The default is
|
|
<literal>10</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sig-signing-type</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a private RDATA type to be used when generating
|
|
signing-state records. The default is
|
|
<literal>65534</literal>.
|
|
</para>
|
|
<para>
|
|
This parameter may be removed
|
|
in a future version, once there is a standard type.
|
|
</para>
|
|
<para>
|
|
Signing-state records are used internally by
|
|
<command>named</command> to track the current state of
|
|
a zone-signing process, i.e., whether it is still active
|
|
or has been completed. The records can be inspected
|
|
using the command
|
|
<command>rndc signing -list <replaceable>zone</replaceable></command>.
|
|
Once <command>named</command> has finished signing
|
|
a zone with a particular key, the signing-state
|
|
record associated with that key can be removed from
|
|
the zone by running
|
|
<command>rndc signing -clear <replaceable>keyid/algorithm</replaceable> <replaceable>zone</replaceable></command>.
|
|
To clear all of the completed signing-state
|
|
records for a zone, use
|
|
<command>rndc signing -clear all <replaceable>zone</replaceable></command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>min-refresh-time</command></term>
|
|
<term><command>max-refresh-time</command></term>
|
|
<term><command>min-retry-time</command></term>
|
|
<term><command>max-retry-time</command></term>
|
|
<listitem>
|
|
<para>
|
|
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,
|
|
up to a hard-coded maximum expiry of 24 weeks. However,
|
|
these values are set by the primary, giving secondary server
|
|
administrators little control over their contents.
|
|
</para>
|
|
<para>
|
|
These options allow the administrator to set a minimum and
|
|
maximum refresh and retry time in seconds per-zone,
|
|
per-view, or globally. These options are valid for
|
|
secondary and stub zones, and clamp the SOA refresh and
|
|
retry times to the specified values.
|
|
</para>
|
|
<para>
|
|
The following defaults apply:
|
|
<command>min-refresh-time</command> 300 seconds,
|
|
<command>max-refresh-time</command> 2419200 seconds
|
|
(4 weeks), <command>min-retry-time</command> 500 seconds,
|
|
and <command>max-retry-time</command> 1209600 seconds
|
|
(2 weeks).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>edns-udp-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum advertised EDNS UDP buffer size, in
|
|
bytes, to control the size of packets received from
|
|
authoritative servers in response to recursive queries.
|
|
Valid values are 512 to 4096; values outside this range
|
|
are silently adjusted to the nearest value within
|
|
it. The default value is 4096.
|
|
</para>
|
|
<para>
|
|
The usual reason for setting
|
|
<command>edns-udp-size</command> to a non-default value
|
|
is to get UDP answers to pass through broken firewalls
|
|
that block fragmented packets and/or block UDP DNS
|
|
packets that are greater than 512 bytes.
|
|
</para>
|
|
<para>
|
|
When <command>named</command> first queries a remote
|
|
server, it advertises a UDP buffer size of 512, as
|
|
this has the greatest chance of success on the first try.
|
|
</para>
|
|
<para>
|
|
If the initial response times out, <command>named</command>
|
|
tries again with plain DNS; if that is successful,
|
|
it is taken as evidence that the server does not
|
|
support EDNS. After enough failures using EDNS and
|
|
successes using plain DNS, <command>named</command>
|
|
defaults to plain DNS for future communications
|
|
with that server. If that happens, <command>named</command>
|
|
periodically sends an EDNS query to see if the situation has
|
|
improved.
|
|
</para>
|
|
<para>
|
|
However, if the initial query is successful with
|
|
EDNS advertising a buffer size of 512, then
|
|
<command>named</command> advertises progressively
|
|
larger buffer sizes on successive queries, until
|
|
responses begin timing out or
|
|
<command>edns-udp-size</command> is reached.
|
|
</para>
|
|
<para>
|
|
The default buffer sizes used by <command>named</command>
|
|
are 512, 1232, 1432, and 4096, but never exceed
|
|
<command>edns-udp-size</command>. (The values 1232 and
|
|
1432 are chosen to allow for an IPv4-/IPv6-encapsulated
|
|
UDP message to be sent without fragmentation at the
|
|
minimum MTU sizes for Ethernet and IPv6 networks.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-udp-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum EDNS UDP message size that
|
|
<command>named</command> sends, in bytes.
|
|
Valid values are 512 to 4096; values outside this
|
|
range are silently adjusted to the nearest
|
|
value within it. The default value is 4096.
|
|
</para>
|
|
<para>
|
|
This value applies to responses sent by a server; to
|
|
set the advertised buffer size in queries, see
|
|
<command>edns-udp-size</command>.
|
|
</para>
|
|
<para>
|
|
The usual reason for setting
|
|
<command>max-udp-size</command> to a non-default
|
|
value is to allow UDP answers to pass through broken
|
|
firewalls that block fragmented packets and/or
|
|
block UDP packets that are greater than 512 bytes.
|
|
This is independent of the advertised receive
|
|
buffer (<command>edns-udp-size</command>).
|
|
</para>
|
|
<para>
|
|
Setting this to a low value encourages additional
|
|
TCP traffic to the name server.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>masterfile-format</command></term>
|
|
<listitem>
|
|
<para>This specifies
|
|
the file format of zone files (see
|
|
<xref linkend="zonefile_format"/>).
|
|
The default value is <constant>text</constant>, which is the
|
|
standard textual representation, except for secondary zones,
|
|
in which the default value is <constant>raw</constant>.
|
|
Files in formats other than <constant>text</constant> are
|
|
typically expected to be generated by the
|
|
<command>named-compilezone</command> tool, or dumped by
|
|
<command>named</command>.
|
|
</para>
|
|
<para>
|
|
Note that when a zone file in a format other than
|
|
<constant>text</constant> is loaded, <command>named</command>
|
|
may omit some of the checks which would be performed for a
|
|
file in <constant>text</constant> format. In particular,
|
|
<command>check-names</command> checks do not apply
|
|
for the <constant>raw</constant> format. This means
|
|
a zone file in the <constant>raw</constant> format
|
|
must be generated with the same check level as that
|
|
specified in the <command>named</command> configuration
|
|
file. Also, <constant>map</constant> format files are
|
|
loaded directly into memory via memory mapping, with only
|
|
minimal checking.
|
|
</para>
|
|
<para>
|
|
This statement sets the
|
|
<command>masterfile-format</command> for all zones,
|
|
but can be overridden on a per-zone or per-view basis
|
|
by including a <command>masterfile-format</command>
|
|
statement within the <command>zone</command> or
|
|
<command>view</command> block in the configuration
|
|
file.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>masterfile-style</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the formatting of zone files during dump,
|
|
when the <option>masterfile-format</option> is
|
|
<constant>text</constant>. This option is ignored
|
|
with any other <option>masterfile-format</option>.
|
|
</para>
|
|
<para>
|
|
When set to <constant>relative</constant>,
|
|
records are printed in a multi-line format, with owner
|
|
names expressed relative to a shared origin. When set
|
|
to <constant>full</constant>, records are printed in
|
|
a single-line format with absolute owner names.
|
|
The <constant>full</constant> format is most suitable
|
|
when a zone file needs to be processed automatically
|
|
by a script. The <constant>relative</constant> format
|
|
is more human-readable, and is thus suitable when a
|
|
zone is to be edited by hand. The default is
|
|
<constant>relative</constant>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="max-recursion-depth">
|
|
<term><command>max-recursion-depth</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum number of levels of recursion
|
|
that are permitted at any one time while servicing
|
|
a recursive query. Resolving a name may require
|
|
looking up a name server address, which in turn
|
|
requires resolving another name, etc.; if the number
|
|
of recursions exceeds this value, the recursive
|
|
query is terminated and returns SERVFAIL. The
|
|
default is 7.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="max-recursion-queries">
|
|
<term><command>max-recursion-queries</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum number of iterative queries that
|
|
may be sent while servicing a recursive query.
|
|
If more queries are sent, the recursive query
|
|
is terminated and returns SERVFAIL. The default is 75.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify-delay</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the delay, in seconds, between sending sets of NOTIFY
|
|
messages for a zone. The default is 5 seconds.
|
|
</para>
|
|
<para>
|
|
The overall rate at which NOTIFY messages are sent for all
|
|
zones is controlled by <command>serial-query-rate</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-rsa-exponent-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the maximum RSA exponent size, in bits, that is
|
|
accepted when validating. Valid values are 35
|
|
to 4096 bits. The default, zero, is also accepted
|
|
and is equivalent to 4096.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>prefetch</command></term>
|
|
<listitem>
|
|
<para>
|
|
When a query is received for cached data which
|
|
is to expire shortly, <command>named</command> can
|
|
refresh the data from the authoritative server
|
|
immediately, ensuring that the cache always has an
|
|
answer available.
|
|
</para>
|
|
<para>
|
|
<option>prefetch</option> specifies the
|
|
"trigger" TTL value at which prefetch of the current
|
|
query takes place; when a cache record with a
|
|
lower TTL value is encountered during query processing,
|
|
it is refreshed. Valid trigger TTL values are 1 to
|
|
10 seconds. Values larger than 10 seconds are silently
|
|
reduced to 10.
|
|
Setting a trigger TTL to zero causes
|
|
prefetch to be disabled.
|
|
The default trigger TTL is <literal>2</literal>.
|
|
</para>
|
|
<para>
|
|
An optional second argument specifies the "eligibility"
|
|
TTL: the smallest <emphasis>original</emphasis>
|
|
TTL value that is accepted for a record to be
|
|
eligible for prefetching. The eligibility TTL must
|
|
be at least six seconds longer than the trigger TTL;
|
|
if not, <command>named</command> silently
|
|
adjusts it upward.
|
|
The default eligibility TTL is <literal>9</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>v6-bias</command></term>
|
|
<listitem>
|
|
<para>
|
|
When determining the next name server to try,
|
|
this indicates by how many milliseconds to prefer IPv6 name servers.
|
|
The default is <literal>50</literal> milliseconds.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="builtin"><info><title>Built-in Server Information Zones</title></info>
|
|
|
|
<para>
|
|
The server provides some helpful diagnostic information
|
|
through a number of built-in zones under the
|
|
pseudo-top-level-domain <literal>bind</literal> in the
|
|
<command>CHAOS</command> class. These zones are part
|
|
of a
|
|
built-in view (see <xref linkend="view_statement_grammar"/>) of
|
|
class
|
|
<command>CHAOS</command>, which is separate from the
|
|
default view of class <command>IN</command>. Most global
|
|
configuration options (<command>allow-query</command>,
|
|
etc.) apply to this view, but some are locally
|
|
overridden: <command>notify</command>,
|
|
<command>recursion</command>, and
|
|
<command>allow-new-zones</command> are
|
|
always set to <userinput>no</userinput>, and
|
|
<command>rate-limit</command> is set to allow
|
|
three responses per second.
|
|
</para>
|
|
<para>
|
|
To disable these zones, use the options
|
|
below or hide the built-in <command>CHAOS</command>
|
|
view by
|
|
defining an explicit view of class <command>CHAOS</command>
|
|
that matches all clients.
|
|
</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>version</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the version the server should report
|
|
via a query of the name <literal>version.bind</literal>
|
|
with type <command>TXT</command> and class <command>CHAOS</command>.
|
|
The default is the real version number of this server.
|
|
Specifying <command>version none</command>
|
|
disables processing of the queries.
|
|
</para>
|
|
<para>
|
|
Setting <command>version</command> to any value
|
|
(including <literal>none</literal>) also
|
|
disables queries for <literal>authors.bind TXT CH</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>hostname</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the hostname the server should report via a query of
|
|
the name <filename>hostname.bind</filename>
|
|
with type <command>TXT</command> and class <command>CHAOS</command>.
|
|
This defaults to the hostname of the machine hosting the
|
|
name server, as
|
|
found by the <command>gethostname()</command> function. The primary purpose of such queries
|
|
is to
|
|
identify which of a group of anycast servers is actually
|
|
answering the queries. Specifying <command>hostname none;</command>
|
|
disables processing of the queries.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>server-id</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the ID the server should report when receiving a Name
|
|
Server Identifier (NSID) query, or a query of the name
|
|
<filename>ID.SERVER</filename> with type
|
|
<command>TXT</command> and class <command>CHAOS</command>.
|
|
The primary purpose of such queries is to
|
|
identify which of a group of anycast servers is actually
|
|
answering the queries. Specifying <command>server-id none;</command>
|
|
disables processing of the queries.
|
|
Specifying <command>server-id hostname;</command> causes <command>named</command> to
|
|
use the hostname as found by the <command>gethostname()</command> function.
|
|
The default <command>server-id</command> is <command>none</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="empty"><info><title>Built-in Empty Zones</title></info>
|
|
|
|
<para>
|
|
The <command>named</command> server has some built-in
|
|
empty zones, for SOA and NS records only.
|
|
These are for zones that should normally be answered locally
|
|
and which queries should not be sent to the Internet's root
|
|
servers. The official servers which cover these namespaces
|
|
return NXDOMAIN responses to these queries. In particular,
|
|
these cover the reverse namespaces for addresses from
|
|
RFC 1918, RFC 4193, RFC 5737, and RFC 6598. They also include the
|
|
reverse namespace for the IPv6 local address (locally assigned),
|
|
IPv6 link local addresses, the IPv6 loopback address, and the
|
|
IPv6 unknown address.
|
|
</para>
|
|
<para>
|
|
The server attempts to determine if a built-in zone
|
|
already exists or is active (covered by a forward-only
|
|
forwarding declaration) and does not create an empty
|
|
zone if either is true.
|
|
</para>
|
|
<para>
|
|
The current list of empty zones is:
|
|
<itemizedlist>
|
|
<listitem>10.IN-ADDR.ARPA</listitem>
|
|
<listitem>16.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>17.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>18.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>19.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>20.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>21.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>22.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>23.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>24.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>25.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>26.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>27.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>28.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>29.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>30.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>31.172.IN-ADDR.ARPA</listitem>
|
|
<listitem>168.192.IN-ADDR.ARPA</listitem>
|
|
<listitem>64.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>65.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>66.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>67.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>68.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>69.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>70.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>71.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>72.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>73.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>74.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>75.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>76.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>77.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>78.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>79.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>80.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>81.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>82.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>83.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>84.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>85.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>86.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>87.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>88.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>89.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>90.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>91.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>92.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>93.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>94.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>95.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>96.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>97.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>98.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>99.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>100.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>101.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>102.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>103.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>104.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>105.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>106.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>107.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>108.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>109.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>110.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>111.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>112.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>113.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>114.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>115.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>116.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>117.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>118.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>119.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>120.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>121.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>122.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>123.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>124.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>125.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>126.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>127.100.IN-ADDR.ARPA</listitem>
|
|
<listitem>0.IN-ADDR.ARPA</listitem>
|
|
<listitem>127.IN-ADDR.ARPA</listitem>
|
|
<listitem>254.169.IN-ADDR.ARPA</listitem>
|
|
<listitem>2.0.192.IN-ADDR.ARPA</listitem>
|
|
<listitem>100.51.198.IN-ADDR.ARPA</listitem>
|
|
<listitem>113.0.203.IN-ADDR.ARPA</listitem>
|
|
<listitem>255.255.255.255.IN-ADDR.ARPA</listitem>
|
|
<listitem>0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</listitem>
|
|
<listitem>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</listitem>
|
|
<listitem>8.B.D.0.1.0.0.2.IP6.ARPA</listitem>
|
|
<listitem>D.F.IP6.ARPA</listitem>
|
|
<listitem>8.E.F.IP6.ARPA</listitem>
|
|
<listitem>9.E.F.IP6.ARPA</listitem>
|
|
<listitem>A.E.F.IP6.ARPA</listitem>
|
|
<listitem>B.E.F.IP6.ARPA</listitem>
|
|
<listitem>EMPTY.AS112.ARPA</listitem>
|
|
<listitem>HOME.ARPA</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
Empty zones can be set at the view level and only apply to
|
|
views of class IN. Disabled empty zones are only inherited
|
|
from options if there are no disabled empty zones specified
|
|
at the view level. To override the options list of disabled
|
|
zones, disable the root zone at the view level. For example:
|
|
<programlisting>
|
|
disable-empty-zone ".";
|
|
</programlisting>
|
|
</para>
|
|
<para>
|
|
If using the address ranges covered here,
|
|
reverse zones covering the addresses should already be in place.
|
|
In practice this appears to not be the case, with many queries
|
|
being made to the infrastructure servers for names in these
|
|
spaces. So many, in fact, that sacrificial servers had
|
|
to be deployed to channel the query load away from the
|
|
infrastructure servers.
|
|
</para>
|
|
<note><simpara>
|
|
The real parent servers for these zones should disable all
|
|
empty zones under the parent zone they serve. For the real
|
|
root servers, this is all built-in empty zones. This
|
|
enables them to return referrals to deeper in the tree.
|
|
</simpara></note>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>empty-server</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the server name that appears in the returned
|
|
SOA record for empty zones. If none is specified,
|
|
the zone's name is used.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>empty-contact</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the contact name that appears in the returned
|
|
SOA record for empty zones. If none is specified,
|
|
"." is used.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>empty-zones-enable</command></term>
|
|
<listitem>
|
|
<para>
|
|
This enables or disables all empty zones. By default, they
|
|
are enabled.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>disable-empty-zone</command></term>
|
|
<listitem>
|
|
<para>
|
|
This disables individual empty zones. By default, none are
|
|
disabled. This option can be specified multiple times.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
|
|
<section xml:id="acache"><info><title>Additional Section Caching</title></info>
|
|
|
|
|
|
<para>
|
|
The additional section cache, also called <command>acache</command>,
|
|
is an internal cache to improve the response performance of BIND 9.
|
|
When additional section caching is enabled, BIND 9
|
|
caches an internal shortcut to the additional section content for
|
|
each answer RR.
|
|
Note that <command>acache</command> is an internal caching
|
|
mechanism of BIND 9, and is not related to the DNS caching
|
|
server function.
|
|
</para>
|
|
|
|
<para>
|
|
Additional section caching does not change the
|
|
response content (except the RRsets ordering of the additional
|
|
section; see below), but can improve the response performance
|
|
significantly.
|
|
It is particularly effective when BIND 9 acts as an authoritative
|
|
server for a zone that has many delegations with many glue RRs.
|
|
</para>
|
|
|
|
<para>
|
|
To obtain the maximum performance improvement
|
|
from additional section caching, setting
|
|
<command>additional-from-cache</command>
|
|
to <command>no</command> is recommended, since the current
|
|
implementation of <command>acache</command>
|
|
does not shortcut additional section information from the
|
|
DNS cache data.
|
|
</para>
|
|
|
|
<para>
|
|
One obvious disadvantage of <command>acache</command> is
|
|
that it requires much more
|
|
memory for the internal cached data.
|
|
Thus, if the response performance does not matter and memory
|
|
consumption is more critical, the
|
|
<command>acache</command> mechanism can be
|
|
disabled by setting <command>acache-enable</command> to
|
|
<command>no</command>.
|
|
It is also possible to specify the upper limit of memory
|
|
consumption
|
|
for <command>acache</command> by using <command>max-acache-size</command>.
|
|
</para>
|
|
|
|
<para>
|
|
Additional section caching also has a minor effect on the
|
|
RRset ordering in the additional section.
|
|
Without <command>acache</command>,
|
|
<command>cyclic</command> order is effective for the additional
|
|
section as well as for the answer and authority sections.
|
|
However, additional section caching fixes the ordering when it
|
|
first caches an RRset for the additional section, and the same
|
|
ordering is kept in succeeding responses, regardless of the
|
|
setting of <command>rrset-order</command>.
|
|
The effect of this should be minor, however, since an
|
|
RRset in the additional section
|
|
typically only contains a small number of RRs (and in many cases
|
|
only a single RR), so the
|
|
ordering is not significant.
|
|
</para>
|
|
|
|
<para>
|
|
The following is a summary of options related to
|
|
<command>acache</command>.
|
|
</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>acache-enable</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <command>yes</command>, additional section caching is
|
|
enabled. The default value is <command>no</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>acache-cleaning-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
The server removes stale cache entries, based on an LRU-based
|
|
algorithm, every <command>acache-cleaning-interval</command> minutes.
|
|
The default is 60 minutes.
|
|
If set to 0, no periodic cleaning occurs.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-acache-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is the maximum amount of memory, in bytes, to use for the server's acache.
|
|
When the amount of data in the acache reaches this limit,
|
|
the server
|
|
cleans more aggressively so that the limit is not
|
|
exceeded.
|
|
In a server with multiple views, the limit applies
|
|
separately to the
|
|
<command>acache</command> of each view.
|
|
The default is <literal>16M</literal>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="content_filtering"><info><title>Content Filtering</title></info>
|
|
|
|
<para>
|
|
<acronym>BIND</acronym> 9 provides the ability to filter
|
|
out responses from external DNS servers containing
|
|
certain types of data in the answer section.
|
|
Specifically, it can reject address (A or AAAA) records if
|
|
the corresponding IPv4 or IPv6 addresses match the given
|
|
<varname>address_match_list</varname> of the
|
|
<command>deny-answer-addresses</command> option.
|
|
It can also reject CNAME or DNAME records if the "alias"
|
|
name (i.e., the CNAME alias or the substituted query name
|
|
due to DNAME) matches the
|
|
given <varname>namelist</varname> of the
|
|
<command>deny-answer-aliases</command> option, where
|
|
"match" means the alias name is a subdomain of one of
|
|
the <varname>name_list</varname> elements.
|
|
If the optional <varname>namelist</varname> is specified
|
|
with <command>except-from</command>, records whose query name
|
|
matches the list are accepted regardless of the filter
|
|
setting.
|
|
Likewise, if the alias name is a subdomain of the
|
|
corresponding zone, the <command>deny-answer-aliases</command>
|
|
filter does not apply;
|
|
for example, even if "example.com" is specified for
|
|
<command>deny-answer-aliases</command>,
|
|
</para>
|
|
<programlisting>www.example.com. CNAME xxx.example.com.</programlisting>
|
|
|
|
<para>
|
|
returned by an "example.com" server is accepted.
|
|
</para>
|
|
|
|
<para>
|
|
In the <varname>address_match_list</varname> of the
|
|
<command>deny-answer-addresses</command> option, only
|
|
<varname>ip_addr</varname>
|
|
and <varname>ip_prefix</varname>
|
|
are meaningful;
|
|
any <varname>key_id</varname> is silently ignored.
|
|
</para>
|
|
|
|
<para>
|
|
If a response message is rejected due to the filtering,
|
|
the entire message is discarded without being cached, and
|
|
a SERVFAIL error is returned to the client.
|
|
</para>
|
|
|
|
<para>
|
|
This filtering is intended to prevent "DNS rebinding attacks," in
|
|
which an attacker, in response to a query for a domain name the
|
|
attacker controls, returns an IP address within the user's own network or
|
|
an alias name within the user's own domain.
|
|
A naive web browser or script could then serve as an
|
|
unintended proxy, allowing the attacker
|
|
to get access to an internal node of the local network
|
|
that could not be externally accessed otherwise.
|
|
See the paper available at
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://dl.acm.org/doi/10.1145/1315245.1315298">
|
|
https://dl.acm.org/doi/10.1145/1315245.1315298
|
|
</link>
|
|
for more details about these attacks.
|
|
</para>
|
|
|
|
<para>
|
|
For example, with a domain named "example.net" and
|
|
an internal network using an IPv4 prefix 192.0.2.0/24,
|
|
an administrator might specify the following rules:
|
|
</para>
|
|
|
|
<programlisting>deny-answer-addresses { 192.0.2.0/24; } except-from { "example.net"; };
|
|
deny-answer-aliases { "example.net"; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
If an external attacker let a web browser in the local
|
|
network look up an IPv4 address of "attacker.example.com",
|
|
the attacker's DNS server would return a response like this:
|
|
</para>
|
|
|
|
<programlisting>attacker.example.com. A 192.0.2.1</programlisting>
|
|
|
|
<para>
|
|
in the answer section.
|
|
Since the rdata of this record (the IPv4 address) matches
|
|
the specified prefix 192.0.2.0/24, this response would be
|
|
ignored.
|
|
</para>
|
|
|
|
<para>
|
|
On the other hand, if the browser looked up a legitimate
|
|
internal web server "www.example.net" and the
|
|
following response were returned to
|
|
the <acronym>BIND</acronym> 9 server:
|
|
</para>
|
|
|
|
<programlisting>www.example.net. A 192.0.2.2</programlisting>
|
|
|
|
<para>
|
|
it would be accepted, since the owner name "www.example.net"
|
|
matches the <command>except-from</command> element,
|
|
"example.net".
|
|
</para>
|
|
|
|
<para>
|
|
Note that this is not really an attack on the DNS per se.
|
|
In fact, there is nothing wrong with having an "external" name
|
|
mapped to an "internal" IP address or domain name
|
|
from the DNS point of view;
|
|
it might actually be provided for a legitimate purpose,
|
|
such as for debugging.
|
|
As long as the mapping is provided by the correct owner,
|
|
it either is not possible or does not make sense to detect
|
|
whether the intent of the mapping is legitimate
|
|
within the DNS.
|
|
The "rebinding" attack must primarily be protected at the
|
|
application that uses the DNS.
|
|
For a large site, however, it may be difficult to protect
|
|
all possible applications at once.
|
|
This filtering feature is provided only to help such an
|
|
operational environment;
|
|
turning it on is generally discouraged unless there is
|
|
no other choice and the attack is a
|
|
real threat to applications.
|
|
</para>
|
|
|
|
<para>
|
|
Care should be particularly taken if using this
|
|
option for addresses within 127.0.0.0/8.
|
|
These addresses are obviously "internal," but many
|
|
applications conventionally rely on a DNS mapping from
|
|
some name to such an address.
|
|
Filtering out DNS records containing this address
|
|
spuriously can break such applications.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="rpz"><info><title>Response Policy Zone (RPZ) Rewriting</title></info>
|
|
|
|
<para>
|
|
<acronym>BIND</acronym> 9 includes a limited
|
|
mechanism to modify DNS responses for requests
|
|
analogous to email anti-spam DNS rejection lists.
|
|
Responses can be changed to deny the existence of domains (NXDOMAIN),
|
|
deny the existence of IP addresses for domains (NODATA),
|
|
or contain other IP addresses or data.
|
|
</para>
|
|
|
|
<para>
|
|
Response policy zones are named in the
|
|
<command>response-policy</command> option for the view or among the
|
|
global options if there is no <command>response-policy</command> option for the view.
|
|
Response policy zones are ordinary DNS zones containing RRsets
|
|
that can be queried normally if allowed.
|
|
It is usually best to restrict those queries with something like
|
|
<command>allow-query { localhost; };</command>.
|
|
Note that zones using <command>masterfile-format map</command>
|
|
cannot be used as policy zones.
|
|
</para>
|
|
|
|
<para>
|
|
A <command>response-policy</command> option can support
|
|
multiple policy zones. To maximize performance, a radix
|
|
tree is used to quickly identify response policy zones
|
|
containing triggers that match the current query. This
|
|
imposes an upper limit of 32 on the number of policy zones
|
|
in a single <command>response-policy</command> option; more
|
|
than that is a configuration error.
|
|
</para>
|
|
|
|
<para>
|
|
Rules encoded in response policy zones are processed after
|
|
those defined in <link linkend="access_control">Access Control Lists
|
|
(ACLs)</link>. All queries from clients which are not
|
|
permitted access to the resolver are answered with a
|
|
status code of REFUSED, regardless of configured RPZ rules.
|
|
</para>
|
|
|
|
<para>
|
|
Five policy triggers can be encoded in RPZ records.
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>RPZ-CLIENT-IP</command></term>
|
|
<listitem>
|
|
<para>
|
|
IP records are triggered by the IP address of the
|
|
DNS client.
|
|
Client IP address triggers are encoded in records that have
|
|
owner names that are subdomains of
|
|
<command>rpz-client-ip</command>, relativized to the
|
|
policy zone origin name,
|
|
and encode an address or address block.
|
|
IPv4 addresses are represented as
|
|
<userinput>prefixlength.B4.B3.B2.B1.rpz-client-ip</userinput>.
|
|
The IPv4 prefix length must be between 1 and 32.
|
|
All four bytes - B4, B3, B2, and B1 - must be present.
|
|
B4 is the decimal value of the least significant byte of the
|
|
IPv4 address as in IN-ADDR.ARPA.
|
|
</para>
|
|
|
|
<para>
|
|
IPv6 addresses are encoded in a format similar
|
|
to the standard IPv6 text representation,
|
|
<userinput>prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-client-ip</userinput>.
|
|
Each of W8,...,W1 is a one- to four-digit hexadecimal number
|
|
representing 16 bits of the IPv6 address as in the standard
|
|
text representation of IPv6 addresses, but reversed as in
|
|
IP6.ARPA. (Note that this representation of IPv6
|
|
address is different from IP6.ARPA where each hex
|
|
digit occupies a label.)
|
|
All 8 words must be present except when one set of consecutive
|
|
zero words is replaced with <userinput>.zz.</userinput>,
|
|
analogous to double colons (::) in standard IPv6 text
|
|
encodings.
|
|
The IPv6 prefix length must be between 1 and 128.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>QNAME</command></term>
|
|
<listitem>
|
|
<para>
|
|
QNAME policy records are triggered by query names of
|
|
requests and targets of CNAME records resolved to generate
|
|
the response.
|
|
The owner name of a QNAME policy record is
|
|
the query name relativized to the policy zone.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>RPZ-IP</command></term>
|
|
<listitem>
|
|
<para>
|
|
IP triggers are IP addresses in an
|
|
A or AAAA record in the ANSWER section of a response.
|
|
They are encoded like client-IP triggers, except as
|
|
subdomains of <command>rpz-ip</command>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>RPZ-NSDNAME</command></term>
|
|
<listitem>
|
|
<para>
|
|
NSDNAME triggers match names of authoritative servers
|
|
for the query name, a parent of the query name, a CNAME for
|
|
the query name, or a parent of a CNAME.
|
|
They are encoded as subdomains of
|
|
<command>rpz-nsdname</command>, relativized
|
|
to the RPZ origin name.
|
|
NSIP triggers match IP addresses in A and
|
|
AAAA RRsets for domains that can be checked against NSDNAME
|
|
policy records. The
|
|
<command>nsdname-enable</command> phrase turns NSDNAME
|
|
triggers off or on for a single policy zone or for all
|
|
zones.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
If authoritative nameservers for the query name are not
|
|
yet known, <command>named</command> recursively
|
|
looks up the authoritative servers for the query name
|
|
before applying an RPZ-NSDNAME rule,
|
|
which can cause a processing delay. To speed up
|
|
processing at the cost of precision, the
|
|
<command>nsdname-wait-recurse</command> option
|
|
can be used; when set to <userinput>no</userinput>,
|
|
RPZ-NSDNAME rules are only applied when authoritative
|
|
servers for the query name have already been looked up and
|
|
cached. If authoritative servers for the query name
|
|
are not in the cache, the RPZ-NSDNAME rule is
|
|
ignored, but the authoritative servers for the query name
|
|
are looked up in the background and the rule is
|
|
applied to subsequent queries. The default is
|
|
<userinput>yes</userinput>, meaning RPZ-NSDNAME
|
|
rules are always applied, even if authoritative
|
|
servers for the query name need to be looked up first.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>RPZ-NSIP</command></term>
|
|
<listitem>
|
|
<para>
|
|
NSIP triggers match the IP addresses of authoritative
|
|
servers. They are enncoded like IP triggers, except as
|
|
subdomains of <command>rpz-nsip</command>.
|
|
NSDNAME and NSIP triggers are checked only for names with at
|
|
least <command>min-ns-dots</command> dots.
|
|
The default value of <command>min-ns-dots</command> is
|
|
1, to exclude top-level domains.
|
|
</para>
|
|
<para>
|
|
If a name server's IP address is not yet known,
|
|
<command>named</command> recursively looks up
|
|
the IP address before applying an RPZ-NSIP rule,
|
|
which can cause a processing delay. To speed up
|
|
processing at the cost of precision, the
|
|
<command>nsip-wait-recurse</command> option
|
|
can be used: when set to <userinput>no</userinput>,
|
|
RPZ-NSIP rules are only applied when a name
|
|
server's IP address has already been looked up and
|
|
cached. If a server's IP address is not in the
|
|
cache, the RPZ-NSIP rule is ignored,
|
|
but the address is looked up in the
|
|
background and the rule is applied
|
|
to subsequent queries. The default is
|
|
<userinput>yes</userinput>, meaning RPZ-NSIP
|
|
rules are always applied, even if an
|
|
address needs to be looked up first.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
The query response is checked against all response policy zones,
|
|
so two or more policy records can be triggered by a response.
|
|
Because DNS responses are rewritten according to at most one
|
|
policy record, a single record encoding an action (other than
|
|
<command>DISABLED</command> actions) must be chosen.
|
|
Triggers, or the records that encode them, are chosen for
|
|
rewriting in the following order:
|
|
<orderedlist inheritnum="ignore" continuation="restarts">
|
|
<listitem>Choose the triggered record in the zone that appears
|
|
first in the <command>response-policy</command> option.
|
|
</listitem>
|
|
<listitem>Prefer CLIENT-IP to QNAME to IP to NSDNAME to NSIP
|
|
triggers in a single zone.
|
|
</listitem>
|
|
<listitem>Among NSDNAME triggers, prefer the
|
|
trigger that matches the smallest name under the DNSSEC ordering.
|
|
</listitem>
|
|
<listitem>Among IP or NSIP triggers, prefer the trigger
|
|
with the longest prefix.
|
|
</listitem>
|
|
<listitem>Among triggers with the same prefix length,
|
|
prefer the IP or NSIP trigger that matches
|
|
the smallest IP address.
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<para>
|
|
When the processing of a response is restarted to resolve
|
|
DNAME or CNAME records and a policy record set has
|
|
not been triggered,
|
|
all response policy zones are again consulted for the
|
|
DNAME or CNAME names and addresses.
|
|
</para>
|
|
|
|
<para>
|
|
RPZ record sets are any types of DNS record, except
|
|
DNAME or DNSSEC, that encode actions or responses to
|
|
individual queries.
|
|
Any of the policies can be used with any of the triggers.
|
|
For example, while the <command>TCP-only</command> policy is
|
|
commonly used with <command>client-IP</command> triggers,
|
|
it can be used with any type of trigger to force the use of
|
|
TCP for responses with owner names in a zone.
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>PASSTHRU</command></term>
|
|
<listitem>
|
|
<para>
|
|
The auto-acceptance policy is specified
|
|
by a CNAME whose target is <command>rpz-passthru</command>.
|
|
It causes the response to not be rewritten
|
|
and is most often used to "poke holes" in policies for
|
|
CIDR blocks.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>DROP</command></term>
|
|
<listitem>
|
|
<para>
|
|
The auto-rejection policy is specified
|
|
by a CNAME whose target is <command>rpz-drop</command>.
|
|
It causes the response to be discarded.
|
|
Nothing is sent to the DNS client.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>TCP-Only</command></term>
|
|
<listitem>
|
|
<para>
|
|
The "slip" policy is specified
|
|
by a CNAME whose target is <command>rpz-tcp-only</command>.
|
|
It changes UDP responses to short, truncated DNS responses
|
|
that require the DNS client to try again with TCP.
|
|
It is used to mitigate distributed DNS reflection attacks.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>NXDOMAIN</command></term>
|
|
<listitem>
|
|
<para>
|
|
The "domain undefined" response is encoded
|
|
by a CNAME whose target is the root domain (.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>NODATA</command></term>
|
|
<listitem>
|
|
<para>
|
|
The empty set of resource records is specified by a
|
|
CNAME whose target is the wildcard top-level
|
|
domain (<literal>*.</literal>).
|
|
It rewrites the response to NODATA or ANCOUNT=0.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>Local Data</command></term>
|
|
<listitem>
|
|
<para>
|
|
A set of ordinary DNS records can be used to answer queries.
|
|
Queries for record types not the set are answered with
|
|
NODATA.
|
|
</para>
|
|
|
|
<para>
|
|
A special form of local data is a CNAME whose target is a
|
|
wildcard such as *.example.com.
|
|
It is used as if an ordinary CNAME after the asterisk (*)
|
|
has been replaced with the query name.
|
|
This special form is useful for query logging in the
|
|
walled garden's authoritative DNS server.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
All of the actions specified in all of the individual records
|
|
in a policy zone
|
|
can be overridden with a <command>policy</command> clause in the
|
|
<command>response-policy</command> option.
|
|
An organization using a policy zone provided by another
|
|
organization might use this mechanism to redirect domains
|
|
to its own walled garden.
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>GIVEN</command></term>
|
|
<listitem>
|
|
<para>The placeholder policy says "do not override but
|
|
perform the action specified in the zone."
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>DISABLED</command></term>
|
|
<listitem>
|
|
<para>
|
|
The testing override policy causes policy zone records to do
|
|
nothing but log what they would have done if the
|
|
policy zone were not disabled.
|
|
The response to the DNS query is written (or not)
|
|
according to any triggered policy records that are not
|
|
disabled.
|
|
Disabled policy zones should appear first,
|
|
because they are often not logged
|
|
if a higher-precedence trigger is found first.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>PASSTHRU</command></term>,
|
|
<term><command>DROP</command></term>,
|
|
<term><command>TCP-Only</command></term>,
|
|
<term><command>NXDOMAIN</command></term>,
|
|
and
|
|
<term><command>NODATA</command></term>
|
|
<listitem>
|
|
<para>
|
|
each override the corresponding per-record policy.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>CNAME domain</command></term>
|
|
<listitem>
|
|
<para>
|
|
causes all RPZ policy records to act as if they were
|
|
"cname domain" records.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
By default, the actions encoded in a response policy zone
|
|
are applied only to queries that ask for recursion (RD=1).
|
|
That default can be changed for a single policy zone, or for
|
|
all response policy zones in a view,
|
|
with a <command>recursive-only no</command> clause.
|
|
This feature is useful for serving the same zone files
|
|
both inside and outside an RFC 1918 cloud and using RPZ to
|
|
delete answers that would otherwise contain RFC 1918 values
|
|
on the externally visible name server or view.
|
|
</para>
|
|
|
|
<para>
|
|
Also by default, RPZ actions are applied only to DNS requests
|
|
that either do not request DNSSEC metadata (DO=0) or when no
|
|
DNSSEC records are available for the requested name in the original
|
|
zone (not the response policy zone). This default can be
|
|
changed for all response policy zones in a view with a
|
|
<command>break-dnssec yes</command> clause. In that case, RPZ
|
|
actions are applied regardless of DNSSEC. The name of the
|
|
clause option reflects the fact that results rewritten by RPZ
|
|
actions cannot verify.
|
|
</para>
|
|
|
|
<para>
|
|
No DNS records are needed for a QNAME or Client-IP trigger;
|
|
the name or IP address itself is sufficient,
|
|
so in principle the query name need not be recursively resolved.
|
|
However, not resolving the requested
|
|
name can leak the fact that response policy rewriting is in use,
|
|
and that the name is listed in a policy zone, to operators of
|
|
servers for listed names. To prevent that information leak, by
|
|
default any recursion needed for a request is done before any
|
|
policy triggers are considered. Because listed domains often
|
|
have slow authoritative servers, this behavior can cost
|
|
significant time.
|
|
The <command>qname-wait-recurse no</command> option
|
|
overrides that default behavior when recursion cannot
|
|
change a non-error response.
|
|
The option does not affect QNAME or client-IP triggers
|
|
in policy zones listed
|
|
after other zones containing IP, NSIP, and NSDNAME triggers, because
|
|
those may depend on the A, AAAA, and NS records that would be
|
|
found during recursive resolution. It also does not affect
|
|
DNSSEC requests (DO=1) unless <command>break-dnssec yes</command>
|
|
is in use, because the response would depend on whether
|
|
RRSIG records were found during resolution.
|
|
Using this option can cause error responses such as SERVFAIL to
|
|
appear to be rewritten, since no recursion is being done to
|
|
discover problems at the authoritative server.
|
|
</para>
|
|
|
|
<para>
|
|
The TTL of a record modified by RPZ policies is set from the
|
|
TTL of the relevant record in the policy zone. It is then limited
|
|
to a maximum value.
|
|
The <command>max-policy-ttl</command> clause changes the
|
|
maximum number of seconds from its default of 5.
|
|
</para>
|
|
|
|
<para>
|
|
For example, an administrator might use this option statement:
|
|
</para>
|
|
<programlisting> response-policy { zone "badlist"; };</programlisting>
|
|
<para>
|
|
and this zone statement:
|
|
</para>
|
|
<programlisting> zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };</programlisting>
|
|
<para>
|
|
with this zone file:
|
|
</para>
|
|
<programlisting>$TTL 1H
|
|
@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
|
|
NS LOCALHOST.
|
|
|
|
; QNAME policy records. There are no periods (.) after the owner names.
|
|
nxdomain.domain.com CNAME . ; NXDOMAIN policy
|
|
*.nxdomain.domain.com CNAME . ; NXDOMAIN policy
|
|
nodata.domain.com CNAME *. ; NODATA policy
|
|
*.nodata.domain.com CNAME *. ; NODATA policy
|
|
bad.domain.com A 10.0.0.1 ; redirect to a walled garden
|
|
AAAA 2001:2::1
|
|
bzone.domain.com CNAME garden.example.com.
|
|
|
|
; do not rewrite (PASSTHRU) OK.DOMAIN.COM
|
|
ok.domain.com CNAME rpz-passthru.
|
|
|
|
; redirect x.bzone.domain.com to x.bzone.domain.com.garden.example.com
|
|
*.bzone.domain.com CNAME *.garden.example.com.
|
|
|
|
|
|
; IP policy records that rewrite all responses containing A records in 127/8
|
|
; except 127.0.0.1
|
|
8.0.0.0.127.rpz-ip CNAME .
|
|
32.1.0.0.127.rpz-ip CNAME rpz-passthru.
|
|
|
|
; NSDNAME and NSIP policy records
|
|
ns.domain.com.rpz-nsdname CNAME .
|
|
48.zz.2.2001.rpz-nsip CNAME .
|
|
|
|
; auto-reject and auto-accept some DNS clients
|
|
112.zz.2001.rpz-client-ip CNAME rpz-drop.
|
|
8.0.0.0.127.rpz-client-ip CNAME rpz-drop.
|
|
|
|
; force some DNS clients and responses in the example.com zone to TCP
|
|
16.0.0.1.10.rpz-client-ip CNAME rpz-tcp-only.
|
|
example.com CNAME rpz-tcp-only.
|
|
*.example.com CNAME rpz-tcp-only.
|
|
|
|
</programlisting>
|
|
<para>
|
|
RPZ can affect server performance.
|
|
Each configured response policy zone requires the server to
|
|
perform one to four additional database lookups before a
|
|
query can be answered.
|
|
For example, a DNS server with four policy zones, each with all
|
|
four kinds of response triggers (QNAME, IP, NSIP, and
|
|
NSDNAME), requires a total of 17 times as many database
|
|
lookups as a similar DNS server with no response policy zones.
|
|
A <acronym>BIND</acronym> 9 server with adequate memory and one
|
|
response policy zone with QNAME and IP triggers might achieve a
|
|
maximum queries-per-second (QPS) rate about 20% lower.
|
|
A server with four response policy zones with QNAME and IP
|
|
triggers might have a maximum QPS rate about 50% lower.
|
|
</para>
|
|
|
|
<para>
|
|
Responses rewritten by RPZ are counted in the
|
|
<command>RPZRewrites</command> statistics.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>log</command> clause can be used to optionally
|
|
turn off rewrite logging for a particular response policy
|
|
zone. By default, all rewrites are logged.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="rrl"><info><title>Response Rate Limiting</title></info>
|
|
|
|
<para>
|
|
Excessive, almost identical UDP <emphasis>responses</emphasis>
|
|
can be controlled by configuring a
|
|
<command>rate-limit</command> clause in an
|
|
<command>options</command> or <command>view</command> statement.
|
|
This mechanism keeps authoritative BIND 9 from being used
|
|
to amplify reflection denial of service (DoS) attacks.
|
|
Short, truncated (TC=1) responses can be sent to provide
|
|
rate-limited responses to legitimate clients within
|
|
a range of forged, attacked IP addresses.
|
|
Legitimate clients react to dropped or truncated responses
|
|
by retrying with UDP or with TCP, respectively.
|
|
</para>
|
|
|
|
<para>
|
|
This mechanism is intended for authoritative DNS servers.
|
|
It can be used on recursive servers, but can slow
|
|
applications such as SMTP servers (mail receivers) and
|
|
HTTP clients (web browsers) that repeatedly request the
|
|
same domains.
|
|
When possible, closing "open" recursive servers is better.
|
|
</para>
|
|
|
|
<para>
|
|
Response rate limiting uses a "credit" or "token bucket" scheme.
|
|
Each combination of identical response and client
|
|
has a conceptual "account" that earns a specified number
|
|
of credits every second.
|
|
A prospective response debits its account by one.
|
|
Responses are dropped or truncated
|
|
while the account is negative.
|
|
Responses are tracked within a rolling window of time
|
|
which defaults to 15 seconds, but which can be configured with
|
|
the <command>window</command> option to any value from
|
|
1 to 3600 seconds (1 hour).
|
|
The account cannot become more positive than
|
|
the per-second limit
|
|
or more negative than <command>window</command>
|
|
times the per-second limit.
|
|
When the specified number of credits for a class of
|
|
responses is set to 0, those responses are not rate-limited.
|
|
</para>
|
|
|
|
<para>
|
|
The notions of "identical response" and "DNS client"
|
|
for rate limiting are not simplistic.
|
|
All responses to an address block are counted as if to a
|
|
single client.
|
|
The prefix lengths of address blocks are
|
|
specified with <command>ipv4-prefix-length</command> (default 24)
|
|
and <command>ipv6-prefix-length</command> (default 56).
|
|
</para>
|
|
|
|
<para>
|
|
All non-empty responses for a valid domain name (qname)
|
|
and record type (qtype) are identical and have a limit specified
|
|
with <command>responses-per-second</command>
|
|
(default 0 or no limit).
|
|
All empty (NODATA) responses for a valid domain,
|
|
regardless of query type, are identical.
|
|
Responses in the NODATA class are limited by
|
|
<command>nodata-per-second</command>
|
|
(default <command>responses-per-second</command>).
|
|
Requests for any and all undefined subdomains of a given
|
|
valid domain result in NXDOMAIN errors, and are identical
|
|
regardless of query type.
|
|
They are limited by <command>nxdomains-per-second</command>
|
|
(default <command>responses-per-second</command>).
|
|
This controls some attacks using random names, but
|
|
can be relaxed or turned off (set to 0)
|
|
on servers that expect many legitimate
|
|
NXDOMAIN responses, such as from anti-spam rejection lists.
|
|
Referrals or delegations to the server of a given
|
|
domain are identical and are limited by
|
|
<command>referrals-per-second</command>
|
|
(default <command>responses-per-second</command>).
|
|
</para>
|
|
|
|
<para>
|
|
Responses generated from local wildcards are counted and limited
|
|
as if they were for the parent domain name.
|
|
This controls flooding using random.wild.example.com.
|
|
</para>
|
|
|
|
<para>
|
|
All requests that result in DNS errors other
|
|
than NXDOMAIN, such as SERVFAIL and FORMERR, are identical
|
|
regardless of requested name (qname) or record type (qtype).
|
|
This controls attacks using invalid requests or distant,
|
|
broken authoritative servers.
|
|
By default the limit on errors is the same as the
|
|
<command>responses-per-second</command> value,
|
|
but it can be set separately with
|
|
<command>errors-per-second</command>.
|
|
</para>
|
|
|
|
<para>
|
|
Many attacks using DNS involve UDP requests with forged source
|
|
addresses.
|
|
Rate limiting prevents the use of BIND 9 to flood a network
|
|
with responses to requests with forged source addresses,
|
|
but could let a third party block responses to legitimate requests.
|
|
There is a mechanism that can answer some legitimate
|
|
requests from a client whose address is being forged in a flood.
|
|
Setting <command>slip</command> to 2 (its default) causes every
|
|
other UDP request to be answered with a small truncated (TC=1)
|
|
response.
|
|
The small size and reduced frequency, and resulting lack of
|
|
amplification, of "slipped" responses make them unattractive
|
|
for reflection DoS attacks.
|
|
<command>slip</command> must be between 0 and 10.
|
|
A value of 0 does not "slip";
|
|
no truncated responses are sent due to rate limiting.
|
|
Rather, all responses are dropped.
|
|
A value of 1 causes every response to slip;
|
|
values between 2 and 10 cause every nth response to slip.
|
|
Some error responses, including REFUSED and SERVFAIL,
|
|
cannot be replaced with truncated responses and are instead
|
|
leaked at the <command>slip</command> rate.
|
|
</para>
|
|
|
|
<para>
|
|
(Note: dropped responses from an authoritative server may
|
|
reduce the difficulty of a third party successfully forging
|
|
a response to a recursive resolver. The best security
|
|
against forged responses is for authoritative operators
|
|
to sign their zones using DNSSEC and for resolver operators
|
|
to validate the responses. When this is not an option,
|
|
operators who are more concerned with response integrity
|
|
than with flood mitigation may consider setting
|
|
<command>slip</command> to 1, causing all rate-limited
|
|
responses to be truncated rather than dropped. This reduces
|
|
the effectiveness of rate-limiting against reflection attacks.)
|
|
</para>
|
|
|
|
<para>
|
|
When the approximate query-per-second rate exceeds
|
|
the <command>qps-scale</command> value,
|
|
the <command>responses-per-second</command>,
|
|
<command>errors-per-second</command>,
|
|
<command>nxdomains-per-second</command>, and
|
|
<command>all-per-second</command> values are reduced by the
|
|
ratio of the current rate to the <command>qps-scale</command> value.
|
|
This feature can tighten defenses during attacks.
|
|
For example, with
|
|
<command>qps-scale 250; responses-per-second 20;</command> and
|
|
a total query rate of 1000 queries/second for all queries from
|
|
all DNS clients including via TCP,
|
|
then the effective responses/second limit changes to
|
|
(250/1000)*20, or 5.
|
|
Responses sent via TCP are not limited
|
|
but are counted to compute the query-per-second rate.
|
|
</para>
|
|
|
|
<para>
|
|
Communities of DNS clients can be given their own parameters or no
|
|
rate limiting by putting
|
|
<command>rate-limit</command> statements in <command>view</command>
|
|
statements instead of in the global <command>option</command>
|
|
statement.
|
|
A <command>rate-limit</command> statement in a view replaces,
|
|
rather than supplements, a <command>rate-limit</command>
|
|
statement among the main options.
|
|
DNS clients within a view can be exempted from rate limits
|
|
with the <command>exempt-clients</command> clause.
|
|
</para>
|
|
|
|
<para>
|
|
UDP responses of all kinds can be limited with the
|
|
<command>all-per-second</command> phrase. This rate
|
|
limiting is unlike the rate limiting provided by
|
|
<command>responses-per-second</command>,
|
|
<command>errors-per-second</command>, and
|
|
<command>nxdomains-per-second</command> on a DNS server,
|
|
which are often invisible to the victim of a DNS
|
|
reflection attack. Unless the forged requests of the
|
|
attack are the same as the legitimate requests of the
|
|
victim, the victim's requests are not affected. Responses
|
|
affected by an <command>all-per-second</command> limit
|
|
are always dropped; the <command>slip</command> value
|
|
has no effect. An <command>all-per-second</command>
|
|
limit should be at least 4 times as large as the other
|
|
limits, because single DNS clients often send bursts
|
|
of legitimate requests. For example, the receipt of a
|
|
single mail message can prompt requests from an SMTP
|
|
server for NS, PTR, A, and AAAA records as the incoming
|
|
SMTP/TCP/IP connection is considered. The SMTP server
|
|
can need additional NS, A, AAAA, MX, TXT, and SPF records
|
|
as it considers the SMTP <command>Mail From</command>
|
|
command. Web browsers often repeatedly resolve the
|
|
same names that are duplicated in HTML <IMG> tags
|
|
in a page. <command>all-per-second</command> is similar
|
|
to the rate limiting offered by firewalls but is often
|
|
inferior. Attacks that justify ignoring the contents
|
|
of DNS responses are likely to be attacks on the DNS
|
|
server itself. They usually should be discarded before
|
|
the DNS server spends resources make TCP connections
|
|
or parsing DNS requests, but that rate limiting must
|
|
be done before the DNS server sees the requests.
|
|
</para>
|
|
|
|
<para>
|
|
The maximum size of the table used to track requests and
|
|
rate-limit responses is set with <command>max-table-size</command>.
|
|
Each entry in the table is between 40 and 80 bytes.
|
|
The table needs approximately as many entries as the number
|
|
of requests received per second.
|
|
The default is 20,000.
|
|
To reduce the cold start of growing the table,
|
|
<command>min-table-size</command> (default 500)
|
|
can set the minimum table size.
|
|
Enable <command>rate-limit</command> category logging to monitor
|
|
expansions of the table and inform
|
|
choices for the initial and maximum table size.
|
|
</para>
|
|
|
|
<para>
|
|
Use <command>log-only yes</command> to test rate-limiting parameters
|
|
without actually dropping any requests.
|
|
</para>
|
|
|
|
<para>
|
|
Responses dropped by rate limits are included in the
|
|
<command>RateDropped</command> and <command>QryDropped</command>
|
|
statistics.
|
|
Responses that truncated by rate limits are included in
|
|
<command>RateSlipped</command> and <command>RespTruncated</command>.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="nxdomain_redirect"><info><title>NXDOMAIN Redirection</title></info>
|
|
<para>
|
|
<command>named</command> supports NXDOMAIN redirection via two methods:
|
|
<itemizedlist>
|
|
<listitem>Redirect zone <xref linkend="zone_statement_grammar"/></listitem>
|
|
<listitem>Redirect namespace</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
With either method, when <command>named</command> gets an NXDOMAIN response
|
|
it examines a separate namespace to see if the NXDOMAIN
|
|
response should be replaced with an alternative response.
|
|
</para>
|
|
<para>
|
|
With a redirect zone (<command>zone "." { type redirect; };</command>), the
|
|
data used to replace the NXDOMAIN is held in a single
|
|
zone which is not part of the normal namespace. All the
|
|
redirect information is contained in the zone; there are
|
|
no delegations.
|
|
</para>
|
|
<para>
|
|
With a redirect namespace (<command>option { nxdomain-redirect
|
|
<suffix> };</command>), the data used to replace the
|
|
NXDOMAIN is part of the normal namespace and is looked up by
|
|
appending the specified suffix to the original query name.
|
|
This roughly doubles the cache required to process NXDOMAIN
|
|
responses, as both the original NXDOMAIN response and
|
|
the replacement data (or a NXDOMAIN indicating that there
|
|
is no replacement) must be stored.
|
|
</para>
|
|
<para>
|
|
If both a redirect zone and a redirect namespace are configured,
|
|
the redirect zone is tried first.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="server_statement_grammar"><info><title><command>server</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="server.grammar.xml"/>
|
|
</section>
|
|
|
|
<section xml:id="server_statement_definition_and_usage"><info><title><command>server</command> Statement Definition and
|
|
Usage</title></info>
|
|
|
|
<para>
|
|
The <command>server</command> statement defines
|
|
characteristics
|
|
to be associated with a remote name server. If a prefix length is
|
|
specified, then a range of servers is covered. Only the most
|
|
specific
|
|
server clause applies, regardless of the order in
|
|
<filename>named.conf</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>server</command> statement can occur at
|
|
the top level of the
|
|
configuration file or inside a <command>view</command>
|
|
statement.
|
|
If a <command>view</command> statement contains
|
|
one or more <command>server</command> statements, only
|
|
those
|
|
apply to the view and any top-level ones are ignored.
|
|
If a view contains no <command>server</command>
|
|
statements,
|
|
any top-level <command>server</command> statements are
|
|
used as
|
|
defaults.
|
|
</para>
|
|
|
|
<para>
|
|
If a remote server is giving out bad data,
|
|
marking it as bogus prevents further queries to it. The
|
|
default
|
|
value of <command>bogus</command> is <command>no</command>.
|
|
</para>
|
|
<para>
|
|
The <command>provide-ixfr</command> clause determines
|
|
whether
|
|
the local server, acting as primary, responds with an
|
|
incremental
|
|
zone transfer when the given remote server, a secondary, requests it.
|
|
If set to <command>yes</command>, incremental transfer
|
|
is provided
|
|
whenever possible. If set to <command>no</command>,
|
|
all transfers
|
|
to the remote server are non-incremental. If not set, the
|
|
value
|
|
of the <command>provide-ixfr</command> option in the
|
|
view or
|
|
global options block is used as a default.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>request-ixfr</command> clause determines
|
|
whether
|
|
the local server, acting as a secondary, requests incremental zone
|
|
transfers from the given remote server, a primary. If not set, the
|
|
value of the <command>request-ixfr</command> option in
|
|
the view or global options block is used as a default. It may
|
|
also be set in the zone block; if set there, it
|
|
overrides the global or view setting for that zone.
|
|
</para>
|
|
|
|
<para>
|
|
IXFR requests to servers that do not support IXFR
|
|
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 <command>yes</command> should always work.
|
|
The purpose of the <command>provide-ixfr</command> and
|
|
<command>request-ixfr</command> clauses is
|
|
to make it possible to disable the use of IXFR even when both
|
|
primary
|
|
and secondary claim to support it: for example, if one of the servers
|
|
is buggy and crashes or corrupts data when IXFR is used.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>request-expire</command> clause determines
|
|
whether the local server, when acting as a secondary,
|
|
requests the EDNS EXPIRE value. The EDNS EXPIRE value
|
|
indicates the remaining time before the zone data
|
|
expires and needs to be refreshed. This is used
|
|
when a secondary server transfers a zone from another
|
|
secondary server; when transferring from the primary, the
|
|
expiration timer is set from the EXPIRE field of the SOA
|
|
record instead.
|
|
The default is <command>yes</command>.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>edns</command> clause determines whether
|
|
the local server attempts to use EDNS when communicating
|
|
with the remote server. The default is <command>yes</command>.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>edns-udp-size</command> option sets the
|
|
EDNS UDP size that is advertised by <command>named</command>
|
|
when querying the remote server. Valid values are 512
|
|
to 4096 bytes; values outside this range are silently
|
|
adjusted to the nearest value within it. This option
|
|
is useful when advertising a different value
|
|
to this server than the value advertised globally:
|
|
for example, when there is a firewall at the remote
|
|
site that is blocking large replies. Note: currently,
|
|
this sets a single UDP size for all packets sent to the
|
|
server; <command>named</command> does not deviate from
|
|
this value. This differs from the behavior of
|
|
<command>edns-udp-size</command> in <command>options</command>
|
|
or <command>view</command> statements, where it specifies
|
|
a maximum value. The <command>server</command> statement
|
|
behavior may be brought into conformance with the
|
|
<command>options/view</command> behavior in future releases.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>edns-version</command> option sets the
|
|
maximum EDNS VERSION that is sent to the server(s)
|
|
by the resolver. The actual EDNS version sent is still
|
|
subject to normal EDNS version-negotiation rules (see
|
|
RFC 6891), the maximum EDNS version supported by the
|
|
server, and any other heuristics that indicate that a
|
|
lower version should be sent. This option is intended
|
|
to be used when a remote server reacts badly to a given
|
|
EDNS version or higher; it should be set to the highest
|
|
version the remote server is known to support. Valid
|
|
values are 0 to 255; higher values are silently
|
|
adjusted. This option is not needed until higher
|
|
EDNS versions than 0 are in use.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>max-udp-size</command> option sets the
|
|
maximum EDNS UDP message size <command>named</command>
|
|
sends. Valid values are 512 to 4096 bytes; values
|
|
outside this range are silently adjusted. This
|
|
option is useful when there is a firewall
|
|
that is blocking large replies from <command>named</command>.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>tcp-only</command> option sets the transport
|
|
protocol to TCP. The default is to use the UDP transport
|
|
and to fallback on TCP only when a truncated response
|
|
is received.
|
|
</para>
|
|
|
|
<para>
|
|
The server supports two zone transfer methods. The first, <command>one-answer</command>,
|
|
uses one DNS message per resource record transferred. <command>many-answers</command> packs
|
|
as many resource records as possible into a single message, which is
|
|
more efficient. It is possible to specify which method
|
|
to use for a server via the <command>transfer-format</command> option;
|
|
If not set there, the <command>transfer-format</command>
|
|
specified
|
|
by the <command>options</command> statement is
|
|
used.
|
|
</para>
|
|
|
|
<para><command>transfers</command>
|
|
is used to limit the number of concurrent inbound zone
|
|
transfers from the specified server. If no
|
|
<command>transfers</command> clause is specified, the
|
|
limit is set according to the
|
|
<command>transfers-per-ns</command> option.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>keys</command> clause identifies a
|
|
<command>key_id</command> defined by the <command>key</command> statement,
|
|
to be used for transaction security (TSIG, <xref linkend="tsig"/>)
|
|
when talking to the remote server.
|
|
When a request is sent to the remote server, a request signature
|
|
is 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.
|
|
</para>
|
|
|
|
<para>
|
|
Only a single key per server is currently supported.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>transfer-source</command> and
|
|
<command>transfer-source-v6</command> clauses specify
|
|
the IPv4 and IPv6 source
|
|
address, respectively, to be used for zone transfer with the remote server.
|
|
For an IPv4 remote server, only <command>transfer-source</command> can
|
|
be specified.
|
|
Similarly, for an IPv6 remote server, only
|
|
<command>transfer-source-v6</command> can be
|
|
specified.
|
|
For more details, see the description of
|
|
<command>transfer-source</command> and
|
|
<command>transfer-source-v6</command> in
|
|
<xref linkend="zone_transfers"/>.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>notify-source</command> and
|
|
<command>notify-source-v6</command> clauses specify the
|
|
IPv4 and IPv6 source address, respectively, to be used for notify
|
|
messages sent to remote servers. For an
|
|
IPv4 remote server, only <command>notify-source</command>
|
|
can be specified. Similarly, for an IPv6 remote server,
|
|
only <command>notify-source-v6</command> can be specified.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>query-source</command> and
|
|
<command>query-source-v6</command> clauses specify the
|
|
IPv4 and IPv6 source address, respectively, to be used for queries
|
|
sent to remote servers. For an IPv4
|
|
remote server, only <command>query-source</command> can
|
|
be specified. Similarly, for an IPv6 remote server,
|
|
only <command>query-source-v6</command> can be specified.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>request-nsid</command> clause determines
|
|
whether the local server adds an NSID EDNS option
|
|
to requests sent to the server. This overrides
|
|
<command>request-nsid</command> set at the view or
|
|
option level.
|
|
</para>
|
|
|
|
<para>
|
|
The <command>send-cookie</command> clause determines
|
|
whether the local server adds a COOKIE EDNS option
|
|
to requests sent to the server. This overrides
|
|
<command>send-cookie</command> set at the view or
|
|
option level. The <command>named</command> server may
|
|
determine that COOKIE is not supported by the remote server
|
|
and not add a COOKIE EDNS option to requests.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="statschannels"><info><title><command>statistics-channels</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="statistics-channels.grammar.xml"/>
|
|
</section>
|
|
|
|
<section xml:id="statistics_channels"><info><title><command>statistics-channels</command> Statement Definition and
|
|
Usage</title></info>
|
|
|
|
<para>
|
|
The <command>statistics-channels</command> statement
|
|
declares communication channels to be used by system
|
|
administrators to get access to statistics information on
|
|
the name server.
|
|
</para>
|
|
|
|
<para>
|
|
This statement is intended to be flexible to support multiple
|
|
communication protocols in the future, but currently only
|
|
HTTP access is supported.
|
|
It requires that BIND 9 be compiled with libxml2 and/or
|
|
json-c (also known as libjson0); the
|
|
<command>statistics-channels</command> statement is
|
|
still accepted even if it is built without the library,
|
|
but any HTTP access fails with an error.
|
|
</para>
|
|
|
|
<para>
|
|
An <command>inet</command> control channel is a TCP socket
|
|
listening at the specified <command>ip_port</command> on the
|
|
specified <command>ip_addr</command>, which can be an IPv4 or IPv6
|
|
address. An <command>ip_addr</command> of <literal>*</literal>
|
|
(asterisk) is
|
|
interpreted as the IPv4 wildcard address; connections are
|
|
accepted on any of the system's IPv4 addresses.
|
|
To listen on the IPv6 wildcard address,
|
|
use an <command>ip_addr</command> of <literal>::</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
If no port is specified, port 80 is used for HTTP channels.
|
|
The asterisk (<literal>*</literal>) cannot be used for
|
|
<command>ip_port</command>.
|
|
</para>
|
|
|
|
<para>
|
|
Attempts to open a statistics channel are
|
|
restricted by the optional <command>allow</command> clause.
|
|
Connections to the statistics channel are permitted based on the
|
|
<command>address_match_list</command>.
|
|
If no <command>allow</command> clause is present,
|
|
<command>named</command> accepts connection
|
|
attempts from any address; since the statistics may
|
|
contain sensitive internal information, it is highly
|
|
recommended to restrict the source of connection requests
|
|
appropriately.
|
|
</para>
|
|
|
|
<para>
|
|
If no <command>statistics-channels</command> statement is present,
|
|
<command>named</command> does not open any communication channels.
|
|
</para>
|
|
|
|
<para>
|
|
The statistics are available in various formats and views,
|
|
depending on the URI used to access them. For example, if
|
|
the statistics channel is configured to listen on 127.0.0.1
|
|
port 8888, then the statistics are accessible in XML format at
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/">http://127.0.0.1:8888/</link> or
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml">http://127.0.0.1:8888/xml</link>. A CSS file is
|
|
included, which can format the XML statistics into tables
|
|
when viewed with a stylesheet-capable browser, and into
|
|
charts and graphs using the Google Charts API when using a
|
|
JavaScript-capable browser.
|
|
</para>
|
|
|
|
<para>
|
|
Broken-out subsets of the statistics can be viewed at
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/status">http://127.0.0.1:8888/xml/v3/status</link>
|
|
(server uptime and last reconfiguration time),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/server">http://127.0.0.1:8888/xml/v3/server</link>
|
|
(server and resolver statistics),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/zones">http://127.0.0.1:8888/xml/v3/zones</link>
|
|
(zone statistics),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/net">http://127.0.0.1:8888/xml/v3/net</link>
|
|
(network status and socket statistics),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/mem">http://127.0.0.1:8888/xml/v3/mem</link>
|
|
(memory manager statistics),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/tasks">http://127.0.0.1:8888/xml/v3/tasks</link>
|
|
(task manager statistics), and
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/traffic">http://127.0.0.1:8888/xml/v3/traffic</link>
|
|
(traffic sizes).
|
|
</para>
|
|
|
|
<para>
|
|
The full set of statistics can also be read in JSON format at
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json">http://127.0.0.1:8888/json</link>,
|
|
with the broken-out subsets at
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/status">http://127.0.0.1:8888/json/v1/status</link>
|
|
(server uptime and last reconfiguration time),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/server">http://127.0.0.1:8888/json/v1/server</link>
|
|
(server and resolver statistics),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/zones">http://127.0.0.1:8888/json/v1/zones</link>
|
|
(zone statistics),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/net">http://127.0.0.1:8888/json/v1/net</link>
|
|
(network status and socket statistics),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/mem">http://127.0.0.1:8888/json/v1/mem</link>
|
|
(memory manager statistics),
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/tasks">http://127.0.0.1:8888/json/v1/tasks</link>
|
|
(task manager statistics), and
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/traffic">http://127.0.0.1:8888/json/v1/traffic</link>
|
|
(traffic sizes).
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="trusted-keys"><info><title><command>trusted-keys</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="trusted-keys.grammar.xml"/>
|
|
</section>
|
|
<section xml:id="trusted_keys"><info><title><command>trusted-keys</command> Statement Definition
|
|
and Usage</title></info>
|
|
|
|
<para>
|
|
The <command>trusted-keys</command> statement defines
|
|
DNSSEC security roots. DNSSEC is described in <xref linkend="DNSSEC"/>. 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 because its parent zone is
|
|
unsigned. Once a key has been configured as a trusted
|
|
key, it is treated as if it has been validated and
|
|
proven secure. The resolver attempts DNSSEC validation
|
|
on all DNS data in subdomains of a security root.
|
|
</para>
|
|
<para>
|
|
All keys (and corresponding zones) listed in
|
|
<command>trusted-keys</command> are deemed to exist regardless
|
|
of what parent zones say. Similarly, for all keys listed in
|
|
<command>trusted-keys</command>, only those keys are
|
|
used to validate the DNSKEY RRset. The parent's DS RRset
|
|
is not used.
|
|
</para>
|
|
<para>
|
|
The <command>trusted-keys</command> statement can contain
|
|
multiple key entries, each consisting of the key's
|
|
domain name, flags, protocol, and algorithm, and the Base64
|
|
representation of the key data.
|
|
Spaces, tabs, newlines, and carriage returns are ignored
|
|
in the key data, so the configuration may be split into
|
|
multiple lines.
|
|
</para>
|
|
<para>
|
|
<command>trusted-keys</command> may be set at the top level
|
|
of <filename>named.conf</filename> or within a view. If it is
|
|
set in both places, they are additive; keys defined at the top
|
|
level are inherited by all views, but keys defined in a view
|
|
are only used within that view.
|
|
</para>
|
|
<para>
|
|
Validation below specified names can be temporarily disabled
|
|
by using <command>rndc nta</command>.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="managed_keys"><info><title><command>managed-keys</command> Statement Grammar</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="managed-keys.grammar.xml"/>
|
|
</section>
|
|
<section xml:id="managed-keys"><info><title><command>managed-keys</command> Statement Definition
|
|
and Usage</title></info>
|
|
|
|
<para>
|
|
The <command>managed-keys</command> statement, like
|
|
<command>trusted-keys</command>, defines DNSSEC
|
|
security roots. The difference is that
|
|
<command>managed-keys</command> can be kept up-to-date
|
|
automatically, without intervention from the resolver
|
|
operator.
|
|
</para>
|
|
<para>
|
|
Suppose, for example, that a zone's key-signing
|
|
key was compromised, and the zone owner had to revoke and
|
|
replace the key. A resolver which had the old key in a
|
|
<command>trusted-keys</command> statement would be
|
|
unable to validate this zone; it would
|
|
reply with a SERVFAIL response code. This would
|
|
continue until the resolver operator updated the
|
|
<command>trusted-keys</command> statement with the new key.
|
|
</para>
|
|
<para>
|
|
If, however, the zone were listed in a
|
|
<command>managed-keys</command> statement instead, the
|
|
zone owner could add a "stand-by" key to the zone in advance.
|
|
<command>named</command> would store the stand-by key, and
|
|
when the original key was revoked, <command>named</command>
|
|
would be able to transition smoothly to the new key. It would
|
|
also recognize that the old key had been revoked and cease
|
|
using that key to validate answers, minimizing the damage that
|
|
the compromised key could do.
|
|
</para>
|
|
<para>
|
|
A <command>managed-keys</command> statement contains a list of
|
|
the keys to be managed, along with information about how the
|
|
keys are to be initialized for the first time. The only
|
|
initialization method currently supported is
|
|
<literal>initial-key</literal>.
|
|
This means the <command>managed-keys</command> statement must
|
|
contain a copy of the initializing key. (Future releases may
|
|
allow keys to be initialized by other methods, eliminating this
|
|
requirement.)
|
|
</para>
|
|
<para>
|
|
Consequently, a <command>managed-keys</command> statement
|
|
appears similar to a <command>trusted-keys</command> statement, differing
|
|
by the presence of the second field, which contains the keyword
|
|
<literal>initial-key</literal>. The difference is, whereas the
|
|
keys listed in a <command>trusted-keys</command> continue to be
|
|
trusted until they are removed from
|
|
<filename>named.conf</filename>, an initializing key listed
|
|
in a <command>managed-keys</command> statement is only trusted
|
|
<emphasis>once</emphasis>: for as long as it takes to load the
|
|
managed-key database and start the RFC 5011 key-maintenance
|
|
process.
|
|
</para>
|
|
<para>
|
|
The first time <command>named</command> runs with a managed key
|
|
configured in <filename>named.conf</filename>, it fetches the
|
|
DNSKEY RRset directly from the zone apex, and validates it
|
|
using the key specified in the <command>managed-keys</command>
|
|
statement. If the DNSKEY RRset is validly signed, then it is
|
|
used as the basis for a new managed-keys database.
|
|
</para>
|
|
<para>
|
|
From that point on, whenever <command>named</command> runs, it
|
|
sees the <command>managed-keys</command> statement, checks to
|
|
make sure RFC 5011 key maintenance has already been initialized
|
|
for the specified domain, and if so, simply moves on. The
|
|
key specified in the <command>managed-keys</command>
|
|
statement is not used to validate answers; it is
|
|
superseded by the key or keys stored in the managed-keys database.
|
|
</para>
|
|
<para>
|
|
The next time <command>named</command> runs after a name
|
|
has been <emphasis>removed</emphasis> from the
|
|
<command>managed-keys</command> statement, the corresponding
|
|
zone is removed from the managed-keys database,
|
|
and RFC 5011 key maintenance is no longer used for that
|
|
domain.
|
|
</para>
|
|
<para>
|
|
In the current implementation, the managed-keys database
|
|
is stored as a master-format zone file.
|
|
</para>
|
|
<para>
|
|
On servers which do not use views, this file is named
|
|
<filename>managed-keys.bind</filename>. When views are in
|
|
use, there is a separate managed-keys database for each
|
|
view; the filename is the view name (or, if a view name
|
|
contains characters which would make it illegal as a filename,
|
|
a hash of the view name), followed by
|
|
the suffix <filename>.mkeys</filename>.
|
|
</para>
|
|
<para>
|
|
When the key database is changed, the zone is updated.
|
|
As with any other dynamic zone, changes are written
|
|
into a journal file, e.g.,
|
|
<filename>managed-keys.bind.jnl</filename> or
|
|
<filename>internal.mkeys.jnl</filename>.
|
|
Changes are committed to the zone file as soon as
|
|
possible afterward, usually within 30
|
|
seconds. Whenever <command>named</command> is using
|
|
automatic key maintenance, the zone file and journal file
|
|
can be expected to exist in the working directory.
|
|
(For this reason, among others, the working directory
|
|
should be always be writable by <command>named</command>.)
|
|
</para>
|
|
<para>
|
|
If the <command>dnssec-validation</command> option is
|
|
set to <userinput>auto</userinput>, <command>named</command>
|
|
automatically initializes a managed key for the
|
|
root zone. The key that is used to initialize the
|
|
key-maintenance process is stored in <filename>bind.keys</filename>;
|
|
the location of this file can be overridden with the
|
|
<command>bindkeys-file</command> option. As a fallback
|
|
in the event no <filename>bind.keys</filename> can be
|
|
found, the initializing key is also compiled directly
|
|
into <command>named</command>.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="view_statement_grammar"><info><title><command>view</command> Statement Grammar</title></info>
|
|
|
|
<programlisting><command>view</command> <replaceable>view_name</replaceable> [ <replaceable>class</replaceable> ] <command>{</command>
|
|
<command>match-clients {</command> <replaceable>address_match_list</replaceable> <command>}</command> ;
|
|
<command>match-destinations {</command> <replaceable>address_match_list</replaceable> <command>}</command> ;
|
|
<command>match-recursive-only</command> <replaceable>yes_or_no</replaceable> ;
|
|
[ <replaceable>view_option</replaceable> ; ... ]
|
|
[ <replaceable>zone_statement</replaceable> ; ... ]
|
|
<command>} </command>;
|
|
</programlisting>
|
|
|
|
</section>
|
|
<section xml:id="view_statement"><info><title><command>view</command> Statement Definition and Usage</title></info>
|
|
|
|
<para>
|
|
The <command>view</command> statement is a powerful
|
|
feature
|
|
of <acronym>BIND</acronym> 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.
|
|
</para>
|
|
|
|
<para>
|
|
Each <command>view</command> statement defines a view
|
|
of the
|
|
DNS namespace that is seen by a subset of clients. A client
|
|
matches
|
|
a view if its source IP address matches the
|
|
<varname>address_match_list</varname> of the view's
|
|
<command>match-clients</command> clause and its
|
|
destination IP address matches
|
|
the <varname>address_match_list</varname> of the
|
|
view's
|
|
<command>match-destinations</command> clause. If not
|
|
specified, both
|
|
<command>match-clients</command> and <command>match-destinations</command>
|
|
default to matching all addresses. In addition to checking IP
|
|
addresses,
|
|
<command>match-clients</command> and <command>match-destinations</command>
|
|
can also take <command>keys</command> which provide an
|
|
mechanism for the
|
|
client to select the view. A view can also be specified
|
|
as <command>match-recursive-only</command>, which
|
|
means that only recursive
|
|
requests from matching clients match that view.
|
|
The order of the <command>view</command> statements is
|
|
significant;
|
|
a client request is resolved in the context of the first
|
|
<command>view</command> that it matches.
|
|
</para>
|
|
|
|
<para>
|
|
Zones defined within a <command>view</command>
|
|
statement are
|
|
only accessible to clients that match the <command>view</command>.
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Many of the options given in the <command>options</command> statement
|
|
can also be used within a <command>view</command>
|
|
statement, and then
|
|
apply only when resolving queries with that view. When no
|
|
view-specific
|
|
value is given, the value in the <command>options</command> statement
|
|
is used as a default. Also, zone options can have default values
|
|
specified
|
|
in the <command>view</command> statement; these
|
|
view-specific defaults
|
|
take precedence over those in the <command>options</command> statement.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
If there are no <command>view</command> statements in
|
|
the config
|
|
file, a default view that matches any client is automatically
|
|
created
|
|
in class IN. Any <command>zone</command> statements
|
|
specified on
|
|
the top level of the configuration file are considered to be part
|
|
of
|
|
this default view, and the <command>options</command>
|
|
statement
|
|
applies to the default view. If any explicit <command>view</command>
|
|
statements are present, all <command>zone</command>
|
|
statements must
|
|
occur inside <command>view</command> statements.
|
|
</para>
|
|
|
|
<para>
|
|
Here is an example of a typical split DNS setup implemented
|
|
using <command>view</command> statements:
|
|
</para>
|
|
|
|
<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 all clients not matched by the
|
|
// previous view.
|
|
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";
|
|
};
|
|
};
|
|
</programlisting>
|
|
|
|
</section>
|
|
<section xml:id="zone_statement_grammar"><info><title><command>zone</command>
|
|
Statement Grammar</title></info>
|
|
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="master.zoneopt.xml"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="slave.zoneopt.xml"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="hint.zoneopt.xml"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="stub.zoneopt.xml"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="static-stub.zoneopt.xml"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="forward.zoneopt.xml"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="redirect.zoneopt.xml"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="delegation-only.zoneopt.xml"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="in-view.zoneopt.xml"/>
|
|
|
|
</section>
|
|
<section xml:id="zone_statement"><info><title><command>zone</command> Statement Definition and Usage</title></info>
|
|
|
|
<section xml:id="zone_types"><info><title>Zone Types</title></info>
|
|
<para>
|
|
The <command>type</command> keyword is required
|
|
for the <command>zone</command> configuration unless
|
|
it is an <command>in-view</command> configuration. Its
|
|
acceptable values are: <varname>master</varname>,
|
|
<varname>slave</varname>, <varname>hint</varname>,
|
|
<varname>stub</varname>, <varname>static-stub</varname>,
|
|
<varname>forward</varname>, <varname>redirect</varname>,
|
|
or <varname>delegation-only</varname>.
|
|
</para>
|
|
<note>
|
|
Later versions of BIND added <command>type primary</command>
|
|
and <command>type secondary</command> as synonyms for
|
|
<command>type master</command> and <command>type slave</command>,
|
|
as those terms are in more common use now. BIND 9.11's
|
|
configuration syntax predates this change.
|
|
</note>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
|
|
<!--colspec colname="1" colnum="1" colsep="0" colwidth="1.108in"/-->
|
|
<!--colspec colname="2" colnum="2" colsep="0" colwidth="4.017in"/-->
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="*"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="4*"/>
|
|
<tbody valign="top">
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>master</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The server has a master copy of the data
|
|
for the zone and is able to provide authoritative
|
|
answers for it.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>slave</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A secondary zone, replicating a primary zone
|
|
provided by another authoritative server.
|
|
The <command>masters</command> list
|
|
specifies one or more IP addresses
|
|
of primary servers that the secondary contacts to update
|
|
its copy of the zone.
|
|
Masters list elements can also be names of other
|
|
masters lists.
|
|
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 primary can also be done with
|
|
per-server TSIG keys.
|
|
If a file is specified, then the
|
|
replica is 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 startup 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 filenames. For
|
|
example,
|
|
a secondary server for the zone <literal>example.com</literal> might place
|
|
the zone contents into a file called
|
|
<filename>ex/example.com</filename> where <filename>ex/</filename> is
|
|
just the first two letters of the zone name. (Most
|
|
operating systems
|
|
behave very slowly if there are 100000 files in
|
|
a single directory.)
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>hint</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The initial set of root name servers is
|
|
specified using a hint zone. When the server starts,
|
|
it uses
|
|
the root hints to find a root name server and get the
|
|
most recent
|
|
list of root name servers. 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 default hints.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>stub</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A stub zone is similar to a secondary zone,
|
|
except that it replicates only the NS records of a
|
|
primary zone instead
|
|
of the entire zone. Stub zones are not a standard part
|
|
of the DNS;
|
|
they are a feature specific to the <acronym>BIND</acronym> implementation.
|
|
</para>
|
|
|
|
<para>
|
|
Stub zones can be used to eliminate the need for a glue
|
|
NS record
|
|
in a parent zone, at the expense of maintaining a stub
|
|
zone entry and
|
|
a set of name server addresses in <filename>named.conf</filename>.
|
|
This usage is not recommended for new configurations,
|
|
and BIND 9
|
|
supports it only in a limited way.
|
|
If a <acronym>BIND</acronym> 9 primary, serving a parent
|
|
zone, has child stub zones configured, all the secondary
|
|
servers for the
|
|
parent zone also need to have the same child stub
|
|
zones
|
|
configured.
|
|
</para>
|
|
|
|
<para>
|
|
Stub zones can also be used as a way to force 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
|
|
RFC 1918 addressing may be configured with stub zones
|
|
for
|
|
<literal>10.in-addr.arpa</literal>
|
|
to use a set of internal name servers as the
|
|
authoritative
|
|
servers for that domain.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>static-stub</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A static-stub zone is similar to a stub zone
|
|
with the following exceptions:
|
|
the zone data is statically configured, rather
|
|
than transferred from a primary server; and
|
|
when recursion is necessary for a query that
|
|
matches a static-stub zone, the locally
|
|
configured data (name server names and glue addresses)
|
|
is always used, even if different authoritative
|
|
information is cached.
|
|
</para>
|
|
<para>
|
|
Zone data is configured via the
|
|
<command>server-addresses</command> and
|
|
<command>server-names</command> zone options.
|
|
</para>
|
|
<para>
|
|
The zone data is maintained in the form of NS
|
|
and (if necessary) glue A or AAAA RRs
|
|
internally, which can be seen by dumping zone
|
|
databases by <command>rndc dumpdb -all</command>.
|
|
The configured RRs are considered local configuration
|
|
parameters rather than public data.
|
|
Non-recursive queries (i.e., those with the RD
|
|
bit off) to a static-stub zone are therefore
|
|
prohibited and are responded to with REFUSED.
|
|
</para>
|
|
<para>
|
|
Since the data is statically configured, no
|
|
zone maintenance action takes place for a static-stub
|
|
zone.
|
|
For example, there is no periodic refresh
|
|
attempt, and an incoming notify message
|
|
will be rejected with an rcode of NOTAUTH.
|
|
</para>
|
|
<para>
|
|
Each static-stub zone is configured with
|
|
internally generated NS and (if necessary)
|
|
glue A or AAAA RRs.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>forward</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
A forward zone is a way to configure
|
|
forwarding on a per-domain basis. A <command>zone</command> statement
|
|
of type <command>forward</command> can
|
|
contain a <command>forward</command>
|
|
and/or <command>forwarders</command>
|
|
statement,
|
|
which applies to queries within the domain given by
|
|
the zone
|
|
name. If no <command>forwarders</command>
|
|
statement is present, or
|
|
an empty list for <command>forwarders</command> is given, then no
|
|
forwarding is done for the domain, canceling the
|
|
effects of
|
|
any forwarders in the <command>options</command> statement. Thus,
|
|
to use this type of zone to change the
|
|
behavior of the
|
|
global <command>forward</command> option
|
|
(that is, "forward first"
|
|
to, then "forward only", or vice versa), but
|
|
use the same
|
|
servers as set globally, re-specify the
|
|
global forwarders.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>redirect</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Redirect zones are used to provide answers to
|
|
queries when normal resolution would result in
|
|
NXDOMAIN being returned.
|
|
Only one redirect zone is supported
|
|
per view. <command>allow-query</command> can be
|
|
used to restrict which clients see these answers.
|
|
</para>
|
|
<para>
|
|
If the client has requested DNSSEC records (DO=1) and
|
|
the NXDOMAIN response is signed, no substitution
|
|
occurs.
|
|
</para>
|
|
<para>
|
|
To redirect all NXDOMAIN responses to
|
|
100.100.100.2 and
|
|
2001:ffff:ffff::100.100.100.2,
|
|
configure a type <varname>redirect</varname> zone named ".",
|
|
with the zone file containing wildcard records
|
|
that point to the desired addresses:
|
|
<literal>*. IN A 100.100.100.2</literal>
|
|
and
|
|
<literal>*. IN AAAA 2001:ffff:ffff::100.100.100.2</literal>.
|
|
</para>
|
|
<para>
|
|
As another example, to redirect all Spanish names (under .ES),
|
|
use similar entries but with the names
|
|
"*.ES." instead of "*.". To redirect all
|
|
commercial Spanish names (under COM.ES),
|
|
use wildcard entries called "*.COM.ES.".
|
|
</para>
|
|
<para>
|
|
Note that the redirect zone supports all
|
|
possible types; it is not limited to A and
|
|
AAAA records.
|
|
</para>
|
|
<para>
|
|
Because redirect zones are not referenced
|
|
directly by name, they are not kept in the
|
|
zone lookup table with normal primary and secondary
|
|
zones. Consequently, it is not currently possible
|
|
to use
|
|
<command>rndc reload
|
|
<replaceable>zonename</replaceable></command>
|
|
to reload a redirect zone. However, when using
|
|
<command>rndc reload</command> without specifying
|
|
a zone name, redirect zones are reloaded along
|
|
with other zones.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>delegation-only</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This zone type is used to enforce the delegation-only
|
|
status of infrastructure zones (e.g., COM,
|
|
NET, ORG). Any answer that is received
|
|
without an explicit or implicit delegation
|
|
in the authority section is treated
|
|
as NXDOMAIN. This does not apply to the
|
|
zone apex, and should not be applied to
|
|
leaf zones.
|
|
</para>
|
|
<para>
|
|
<varname>delegation-only</varname> has no
|
|
effect on answers received from forwarders.
|
|
</para>
|
|
<para>
|
|
See caveats in <xref linkend="root_delegation_only"/>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>in-view</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
When using multiple views, a primary or secondary zone
|
|
configured in one view can be referenced in a
|
|
subsequent view. This allows both views to serve the
|
|
same zone without the overhead of loading it more
|
|
than once. This is configured using a
|
|
<varname>zone</varname> statement, with an
|
|
<varname>in-view</varname> option specifying the
|
|
view in which the zone is defined.
|
|
A <varname>zone</varname> statement containing
|
|
<varname>in-view</varname> does not need to specify
|
|
a type, since that is part of the zone definition
|
|
in the other view.
|
|
</para>
|
|
<para>
|
|
See <xref linkend="multiple_views"/> for more information.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
|
|
<section xml:id="class"><info><title>Class</title></info>
|
|
|
|
<para>
|
|
The zone's name may optionally be followed by a class. If
|
|
a class is not specified, class <literal>IN</literal> (for <varname>Internet</varname>),
|
|
is assumed. This is correct for the vast majority of cases.
|
|
</para>
|
|
<para>
|
|
The <literal>hesiod</literal> class is
|
|
named for an information service from MIT's Project Athena. It was
|
|
used to share information about various systems databases, such
|
|
as users, groups, printers, and so on. The keyword
|
|
<literal>HS</literal> is
|
|
a synonym for hesiod.
|
|
</para>
|
|
<para>
|
|
Another MIT development is Chaosnet, a LAN protocol created
|
|
in the mid-1970s. Zone data for it can be specified with the <literal>CHAOS</literal> class.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="zone_options"><info><title>Zone Options</title></info>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-notify</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>allow-notify</command> in <xref linkend="access_control"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-query</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>allow-query</command> in <xref linkend="access_control"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-query-on</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>allow-query-on</command> in <xref linkend="access_control"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-transfer</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of <command>allow-transfer</command>
|
|
in <xref linkend="access_control"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-update</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of <command>allow-update</command>
|
|
in <xref linkend="access_control"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>update-policy</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies a "Simple Secure Update" policy. See
|
|
<xref linkend="dynamic_update_policies"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>allow-update-forwarding</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of <command>allow-update-forwarding</command>
|
|
in <xref linkend="access_control"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>also-notify</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is only meaningful if <command>notify</command>
|
|
is
|
|
active for this zone. The set of machines that
|
|
receive a
|
|
<literal>DNS NOTIFY</literal> message
|
|
for this zone is made up of all the listed name servers
|
|
(other than
|
|
the primary) for the zone, plus any IP addresses
|
|
specified
|
|
with <command>also-notify</command>. A port
|
|
may be specified
|
|
with each <command>also-notify</command>
|
|
address to send the notify
|
|
messages to a port other than the default of 53.
|
|
A TSIG key may also be specified to cause the
|
|
<literal>NOTIFY</literal> to be signed by the
|
|
given key.
|
|
<command>also-notify</command> is not
|
|
meaningful for stub zones.
|
|
The default is the empty list.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-names</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is used to restrict the character set and
|
|
syntax of
|
|
certain domain names in zone files and/or DNS responses
|
|
received from the
|
|
network. The default varies according to zone type.
|
|
For primary zones the default is <command>fail</command>;
|
|
for secondary zones the default is <command>warn</command>.
|
|
It is not implemented for <command>hint</command> zones.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-mx</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>check-mx</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-spf</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>check-spf</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-wildcard</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>check-wildcard</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-integrity</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>check-integrity</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>check-sibling</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>check-sibling</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>zero-no-soa-ttl</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>zero-no-soa-ttl</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>update-check-ksk</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>update-check-ksk</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-loadkeys-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>dnssec-loadkeys-interval</command> in <xref linkend="options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-update-mode</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>dnssec-update-mode</command> in <xref linkend="options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-dnskey-kskonly</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>dnssec-dnskey-kskonly</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>try-tcp-refresh</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>try-tcp-refresh</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>database</command></term>
|
|
<listitem>
|
|
<para>
|
|
This specifies the type of database to be used to store the
|
|
zone data. The string following the <command>database</command> 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.
|
|
</para>
|
|
<para>
|
|
The default is <userinput>"rbt"</userinput>, BIND 9's
|
|
native in-memory
|
|
red-black tree database. This database does not take
|
|
arguments.
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dialup</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>dialup</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>delegation-only</command></term>
|
|
<listitem>
|
|
<para>
|
|
This flag only applies to forward, hint, and stub
|
|
zones. If set to <userinput>yes</userinput>,
|
|
then the zone is treated as if it is
|
|
also a delegation-only type zone.
|
|
</para>
|
|
<para>
|
|
See caveats in <xref linkend="root_delegation_only"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This sets the zone's filename. In <command>master</command>,
|
|
<command>hint</command>, and <command>redirect</command>
|
|
zones which do not have <command>masters</command>
|
|
defined, zone data is loaded from this file. In
|
|
<command>slave</command>, <command>stub</command>, and
|
|
<command>redirect</command> zones which do have
|
|
<command>masters</command> defined, zone data is
|
|
retrieved from another server and saved in this file.
|
|
This option is not applicable to other zone types.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>forward</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is only meaningful if the zone has a forwarders
|
|
list. The <command>only</command> value causes
|
|
the lookup to fail
|
|
after trying the forwarders and getting no answer, while <command>first</command>
|
|
allows a normal lookup to be tried.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>forwarders</command></term>
|
|
<listitem>
|
|
<para>
|
|
This is used to override the list of global forwarders.
|
|
If it is not specified in a zone of type <command>forward</command>,
|
|
no forwarding is done for the zone and the global options are
|
|
not used.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>ixfr-base</command></term>
|
|
<listitem>
|
|
<para>
|
|
This was used in <acronym>BIND</acronym> 8 to
|
|
specify the name
|
|
of the transaction log (journal) file for dynamic update
|
|
and IXFR.
|
|
<acronym>BIND</acronym> 9 ignores the option
|
|
and constructs the name of the journal
|
|
file by appending "<filename>.jnl</filename>"
|
|
to the name of the
|
|
zone file.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>ixfr-tmp-file</command></term>
|
|
<listitem>
|
|
<para>
|
|
This was an undocumented option in <acronym>BIND</acronym> 8.
|
|
It is ignored in <acronym>BIND</acronym> 9.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>journal</command></term>
|
|
<listitem>
|
|
<para>
|
|
This allows the default journal's filename to be overridden.
|
|
The default is the zone's filename with "<filename>.jnl</filename>" appended.
|
|
This is applicable to primary (<command>master</command>)
|
|
and secondary (<command>slave</command>) zones.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-journal-size</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>max-journal-size</command> in <xref linkend="server_resource_limits"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-records</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>max-records</command> in <xref linkend="server_resource_limits"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-transfer-time-in</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>max-transfer-time-in</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-transfer-idle-in</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>max-transfer-idle-in</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-transfer-time-out</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>max-transfer-time-out</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-transfer-idle-out</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>max-transfer-idle-out</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>notify</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify-delay</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>notify-delay</command> in <xref linkend="tuning"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify-to-soa</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>notify-to-soa</command> in
|
|
<xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>pubkey</command></term>
|
|
<listitem>
|
|
<para>
|
|
In <acronym>BIND</acronym> 8, this option was
|
|
intended to specify
|
|
a public zone key for verification of signatures in DNSSEC-signed
|
|
zones when they were loaded from disk. <acronym>BIND</acronym> 9 does not verify signatures
|
|
on load and ignores the option.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>zone-statistics</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>zone-statistics</command> in
|
|
<xref linkend="options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>server-addresses</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is only meaningful for static-stub zones.
|
|
This is a list of IP addresses to which queries
|
|
should be sent in recursive resolution for the
|
|
zone.
|
|
A non-empty list for this option internally
|
|
configures the apex NS RR with associated glue A or
|
|
AAAA RRs.
|
|
</para>
|
|
<para>
|
|
For example, if "example.com" is configured as a
|
|
static-stub zone with 192.0.2.1 and 2001:db8::1234
|
|
in a <command>server-addresses</command> option,
|
|
the following RRs are internally configured:
|
|
</para>
|
|
<programlisting>example.com. NS example.com.
|
|
example.com. A 192.0.2.1
|
|
example.com. AAAA 2001:db8::1234</programlisting>
|
|
<para>
|
|
These records are used internally to resolve
|
|
names under the static-stub zone.
|
|
For instance, if the server receives a query for
|
|
"www.example.com" with the RD bit on, the server
|
|
initiates recursive resolution and sends
|
|
queries to 192.0.2.1 and/or 2001:db8::1234.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>server-names</command></term>
|
|
<listitem>
|
|
<para>
|
|
This option is only meaningful for static-stub zones.
|
|
This is a list of domain names of name servers that
|
|
act as authoritative servers of the static-stub
|
|
zone.
|
|
These names are resolved to IP addresses when
|
|
<command>named</command> needs to send queries to
|
|
these servers.
|
|
For this supplemental resolution to be successful,
|
|
these names must not be a subdomain of the origin
|
|
name of the static-stub zone.
|
|
That is, when "example.net" is the origin of a
|
|
static-stub zone, "ns.example" and
|
|
"master.example.com" can be specified in the
|
|
<command>server-names</command> option, but
|
|
"ns.example.net" cannot; it is rejected by
|
|
the configuration parser.
|
|
</para>
|
|
<para>
|
|
A non-empty list for this option internally
|
|
configures the apex NS RR with the specified names.
|
|
For example, if "example.com" is configured as a
|
|
static-stub zone with "ns1.example.net" and
|
|
"ns2.example.net"
|
|
in a <command>server-names</command> option,
|
|
the following RRs are internally configured:
|
|
</para>
|
|
|
|
<programlisting>example.com. NS ns1.example.net.
|
|
example.com. NS ns2.example.net.
|
|
</programlisting>
|
|
|
|
<para>
|
|
These records are used internally to resolve
|
|
names under the static-stub zone.
|
|
For instance, if the server receives a query for
|
|
"www.example.com" with the RD bit on, the server
|
|
initiates recursive resolution,
|
|
resolves "ns1.example.net" and/or
|
|
"ns2.example.net" to IP addresses, and then sends
|
|
queries to one or more of these addresses.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sig-validity-interval</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>sig-validity-interval</command> in <xref linkend="tuning"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sig-signing-nodes</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>sig-signing-nodes</command> in <xref linkend="tuning"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sig-signing-signatures</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>sig-signing-signatures</command> in <xref linkend="tuning"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>sig-signing-type</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>sig-signing-type</command> in <xref linkend="tuning"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfer-source</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>transfer-source</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>transfer-source-v6</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>transfer-source-v6</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>alt-transfer-source</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>alt-transfer-source</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>alt-transfer-source-v6</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>alt-transfer-source-v6</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>use-alt-transfer-source</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>use-alt-transfer-source</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
|
|
<varlistentry>
|
|
<term><command>notify-source</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>notify-source</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>notify-source-v6</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>notify-source-v6</command> in <xref linkend="zone_transfers"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>min-refresh-time</command></term>
|
|
<term><command>max-refresh-time</command></term>
|
|
<term><command>min-retry-time</command></term>
|
|
<term><command>max-retry-time</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the descriptions in <xref linkend="tuning"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>ixfr-from-differences</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>ixfr-from-differences</command> in <xref linkend="boolean_options"/>.
|
|
(Note that the <command>ixfr-from-differences</command>
|
|
choices of <userinput>master</userinput> and
|
|
<userinput>slave</userinput> are not
|
|
available at the zone level.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>key-directory</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>key-directory</command> in <xref linkend="options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>auto-dnssec</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>auto-dnssec</command> in
|
|
<xref linkend="options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>serial-update-method</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>serial-update-method</command> in
|
|
<xref linkend="options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>inline-signing</command></term>
|
|
<listitem>
|
|
<para>
|
|
If <literal>yes</literal>, this enables
|
|
"bump in the wire" signing of a zone, where an
|
|
unsigned zone is transferred in or loaded from
|
|
disk and a signed version of the zone is served,
|
|
with, possibly, a different serial number. This
|
|
behavior is disabled by default.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>multi-master</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of <command>multi-master</command> in
|
|
<xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>masterfile-format</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of <command>masterfile-format</command>
|
|
in <xref linkend="tuning"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>max-zone-ttl</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of <command>max-zone-ttl</command>
|
|
in <xref linkend="options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>dnssec-secure-to-insecure</command></term>
|
|
<listitem>
|
|
<para>
|
|
See the description of
|
|
<command>dnssec-secure-to-insecure</command> in <xref linkend="boolean_options"/>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</section>
|
|
<section xml:id="dynamic_update_policies"><info><title>Dynamic Update Policies</title></info>
|
|
|
|
<para><acronym>BIND</acronym> 9 supports two
|
|
methods of granting clients the right to perform
|
|
dynamic updates to a zone, configured by the
|
|
<command>allow-update</command> and
|
|
<command>update-policy</command> options.
|
|
</para>
|
|
<para>
|
|
The <command>allow-update</command> clause is a simple
|
|
access control list. Any client that matches
|
|
the ACL is granted permission to update any record
|
|
in the zone.
|
|
</para>
|
|
<para>
|
|
The <command>update-policy</command> clause
|
|
allows more fine-grained control over which updates are
|
|
allowed. It specifies a set of rules, in which each rule
|
|
either grants or denies permission for one or more
|
|
names in the zone to be updated by one or more
|
|
identities. Identity is determined by the key that
|
|
signed the update request, using either TSIG or SIG(0).
|
|
In most cases, <command>update-policy</command> rules
|
|
only apply to key-based identities. There is no way
|
|
to specify update permissions based on client source
|
|
address.
|
|
</para>
|
|
<para>
|
|
<command>update-policy</command> rules are only meaningful
|
|
for primary zones (type <command>master</command>), and are
|
|
not allowed in any other zone type.
|
|
It is a configuration error to specify both
|
|
<command>allow-update</command> and
|
|
<command>update-policy</command> at the same time.
|
|
</para>
|
|
<para>
|
|
A pre-defined <command>update-policy</command> rule can be
|
|
switched on with the command
|
|
<command>update-policy local;</command>.
|
|
<command>named</command> automatically generates a TSIG session
|
|
key when starting and stores it in a file; this key can then
|
|
be used by local clients to update the zone while
|
|
<command>named</command> is running.
|
|
By default, the session key is stored in the file
|
|
<filename>/var/run/named/session.key</filename>, the key name
|
|
is "local-ddns", and the key algorithm is HMAC-SHA256.
|
|
These values are configurable with the
|
|
<command>session-keyfile</command>,
|
|
<command>session-keyname</command>, and
|
|
<command>session-keyalg</command> options, respectively.
|
|
A client running on the local system, if run with appropriate
|
|
permissions, may read the session key from the key file and
|
|
use it to sign update requests. The zone's update
|
|
policy is set to allow that key to change any record
|
|
within the zone. Assuming the key name is "local-ddns",
|
|
this policy is equivalent to:
|
|
</para>
|
|
|
|
<programlisting>update-policy { grant local-ddns zonesub any; };
|
|
</programlisting>
|
|
|
|
<para>
|
|
with the additional restriction that only clients
|
|
connecting from the local system are permitted to send
|
|
updates.
|
|
</para>
|
|
<para>
|
|
Note that only one session key is generated by
|
|
<command>named</command>; all zones configured to use
|
|
<command>update-policy local</command> accept the same key.
|
|
</para>
|
|
<para>
|
|
The command <command>nsupdate -l</command> implements this
|
|
feature, sending requests to localhost and signing them using
|
|
the key retrieved from the session key file.
|
|
</para>
|
|
|
|
<para>
|
|
Other rule definitions look like this:
|
|
</para>
|
|
|
|
<programlisting>
|
|
( <command>grant</command> | <command>deny</command> ) <replaceable>identity</replaceable> <replaceable>ruletype</replaceable> <optional> <replaceable>name</replaceable> </optional> <optional> <replaceable>types</replaceable> </optional>
|
|
</programlisting>
|
|
|
|
<para>
|
|
Each rule grants or denies privileges. Rules are checked
|
|
in the order in which they are specified in the
|
|
<command>update-policy</command> statement. Once a message
|
|
has successfully matched a rule, the operation is immediately
|
|
granted or denied, and no further rules are examined. There
|
|
are 13 types of rules; the rule type is specified by the
|
|
<command>ruletype</command> field, and the interpretation
|
|
of other fields varies depending on the rule type.
|
|
</para>
|
|
<para>
|
|
In general, a rule is matched when the
|
|
key that signed an update request matches the
|
|
<command>identity</command> field, the name of the record
|
|
to be updated matches the <command>name</command> field
|
|
(in the manner specified by the <command>ruletype</command>
|
|
field), and the type of the record to be updated matches the
|
|
<command>types</command> field. Details for each rule type
|
|
are described below.
|
|
</para>
|
|
<para>
|
|
The <command>identity</command> field must be set to
|
|
a fully qualified domain name. In most cases, this
|
|
represents the name of the TSIG or SIG(0) key that must be
|
|
used to sign the update request. If the specified name is a
|
|
wildcard, it is subject to DNS wildcard expansion, and the
|
|
rule may apply to multiple identities. When a TKEY exchange
|
|
has been used to create a shared secret, the identity of
|
|
the key used to authenticate the TKEY exchange is
|
|
used as the identity of the shared secret. Some rule types
|
|
use identities matching the client's Kerberos principal
|
|
(e.g, <userinput>"host/machine@REALM"</userinput>) or
|
|
Windows realm (<userinput>machine$@REALM</userinput>).
|
|
</para>
|
|
<para>
|
|
The <replaceable>name</replaceable> field also specifies
|
|
a fully qualified domain name. This often
|
|
represents the name of the record to be updated.
|
|
Interpretation of this field is dependent on rule type.
|
|
</para>
|
|
<para>
|
|
If no <command>types</command> are explicitly specified,
|
|
then a rule matches all types except RRSIG, NS, SOA, NSEC,
|
|
and NSEC3. Types may be specified by name, including
|
|
"ANY"; ANY matches all types except NSEC and NSEC3,
|
|
which can never be updated. Note that when an attempt
|
|
is made to delete all records associated with a name,
|
|
the rules are checked for each existing record type.
|
|
</para>
|
|
<para>
|
|
The <replaceable>ruletype</replaceable> field has 16
|
|
values:
|
|
<varname>name</varname>, <varname>subdomain</varname>,
|
|
<varname>zonesub</varname>, <varname>wildcard</varname>,
|
|
<varname>self</varname>, <varname>selfsub</varname>,
|
|
<varname>selfwild</varname>, <varname>ms-self</varname>,
|
|
<varname>ms-selfsub</varname>, <varname>ms-subdomain</varname>,
|
|
<varname>krb5-self</varname>, <varname>krb5-selfsub</varname>,
|
|
<varname>krb5-subdomain</varname>, <varname>tcp-self</varname>,
|
|
<varname>6to4-self</varname>, and <varname>external</varname>.
|
|
</para>
|
|
<informaltable>
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="0.819in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.681in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>name</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
With exact-match semantics, this rule matches
|
|
when the name being updated is identical
|
|
to the contents of the
|
|
<replaceable>name</replaceable> field.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>subdomain</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This rule matches when the name being updated
|
|
is a subdomain of, or identical to, the
|
|
contents of the <replaceable>name</replaceable>
|
|
field.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>zonesub</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This rule is similar to subdomain, except that
|
|
it matches when the name being updated is a
|
|
subdomain of the zone in which the
|
|
<command>update-policy</command> statement
|
|
appears. This obviates the need to type the zone
|
|
name twice, and enables the use of a standard
|
|
<command>update-policy</command> statement in
|
|
multiple zones without modification.
|
|
</para>
|
|
<para>
|
|
When this rule is used, the
|
|
<replaceable>name</replaceable> field is omitted.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>wildcard</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
The <replaceable>name</replaceable> field
|
|
is subject to DNS wildcard expansion, and
|
|
this rule matches when the name being updated
|
|
is a valid expansion of the wildcard.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>self</varname>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This rule matches when the name of the record
|
|
being updated matches the contents of the
|
|
<replaceable>identity</replaceable> field.
|
|
The <replaceable>name</replaceable> field
|
|
is ignored. To avoid confusion, it is recommended
|
|
that this field be set to the same value as the
|
|
<replaceable>identity</replaceable> field or to
|
|
"."
|
|
</para>
|
|
<para>
|
|
The <varname>self</varname> rule type is
|
|
most useful when allowing one key per
|
|
name to update, where the key has the same
|
|
name as the record to be updated. In this case,
|
|
the <replaceable>identity</replaceable> field
|
|
can be specified as <constant>*</constant>
|
|
(asterisk).
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>selfsub</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This rule is similar to <varname>self</varname>,
|
|
except that subdomains of <varname>self</varname>
|
|
can also be updated.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>selfwild</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This rule is similar to <varname>self</varname>,
|
|
except that only subdomains of
|
|
<varname>self</varname> can be updated.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ms-self</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
When a client sends an UPDATE using a Windows
|
|
machine principal (for example, "machine$@REALM"),
|
|
this rule allows records with the absolute name
|
|
of "machine.REALM" to be updated.
|
|
</para>
|
|
<para>
|
|
The realm to be matched is specified in the
|
|
<replaceable>identity</replaceable> field.
|
|
</para>
|
|
<para>
|
|
The <replaceable>name</replaceable> field has
|
|
no effect on this rule; it should be set to "."
|
|
as a placeholder.
|
|
</para>
|
|
<para>
|
|
For example,
|
|
<userinput>grant EXAMPLE.COM ms-self . A AAAA</userinput>
|
|
allows any machine with a valid principal in
|
|
the realm <userinput>EXAMPLE.COM</userinput> to update
|
|
its own address records.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ms-selfsub</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This is similar to <command>ms-self</command>,
|
|
except it also allows updates to any subdomain of
|
|
the name specified in the Windows machine
|
|
principal, not just to the name itself.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>ms-subdomain</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
When a client sends an UPDATE using a Windows
|
|
machine principal (for example, "machine$@REALM"),
|
|
this rule allows any machine in the specified
|
|
realm to update any record in the zone or in a
|
|
specified subdomain of the zone.
|
|
</para>
|
|
<para>
|
|
The realm to be matched is specified in the
|
|
<replaceable>identity</replaceable> field.
|
|
</para>
|
|
<para>
|
|
The <replaceable>name</replaceable> field
|
|
specifies the subdomain that may be updated.
|
|
If set to "." or any other name at or above
|
|
the zone apex, any name in the zone can be
|
|
updated.
|
|
</para>
|
|
<para>
|
|
For example, if <command>update-policy</command>
|
|
for the zone "example.com" includes
|
|
<userinput>grant EXAMPLE.COM ms-subdomain hosts.example.com. A AAAA</userinput>,
|
|
any machine with a valid principal in
|
|
the realm <userinput>EXAMPLE.COM</userinput> is
|
|
able to update address records at or below
|
|
"hosts.example.com".
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>krb5-self</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
When a client sends an UPDATE using a
|
|
Kerberos machine principal (for example,
|
|
"host/machine@REALM"), this rule allows
|
|
records with the absolute name of "machine"
|
|
to be updated, provided it has been authenticated
|
|
by REALM. This is similar but not identical
|
|
to <command>ms-self</command>, due to the
|
|
"machine" part of the Kerberos principal
|
|
being an absolute name instead of an unqualified
|
|
name.
|
|
</para>
|
|
<para>
|
|
The realm to be matched is specified in the
|
|
<replaceable>identity</replaceable> field.
|
|
</para>
|
|
<para>
|
|
The <replaceable>name</replaceable> field has
|
|
no effect on this rule; it should be set to "."
|
|
as a placeholder.
|
|
</para>
|
|
<para>
|
|
For example,
|
|
<userinput>grant EXAMPLE.COM krb5-self . A AAAA</userinput>
|
|
allows any machine with a valid principal in
|
|
the realm <userinput>EXAMPLE.COM</userinput> to update
|
|
its own address records.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>krb5-selfsub</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This is similar to <command>krb5-self</command>,
|
|
except it also allows updates to any subdomain of
|
|
the name specified in the "machine" part of the
|
|
Kerberos principal, not just to the name itself.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>krb5-subdomain</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This rule is identical to
|
|
<command>ms-subdomain</command>, except that it works
|
|
with Kerberos machine principals (i.e.,
|
|
"host/machine@REALM") rather than Windows machine
|
|
principals.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>tcp-self</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This rule allows updates that have been sent via
|
|
TCP and for which the standard mapping from the
|
|
client's IP address into the
|
|
<literal>in-addr.arpa</literal> and
|
|
<literal>ip6.arpa</literal>
|
|
namespaces matches the name to be updated.
|
|
The <command>identity</command> field must match
|
|
that name. The <command>name</command> field
|
|
should be set to ".".
|
|
Note that, since identity is based on the client's
|
|
IP address, it is not necessary for update request
|
|
messages to be signed.
|
|
</para>
|
|
<note>
|
|
It is theoretically possible to spoof these TCP
|
|
sessions.
|
|
</note>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>6to4-self</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This allows the name matching a 6to4 IPv6 prefix,
|
|
as specified in RFC 3056, to be updated by any
|
|
TCP connection from either the 6to4 network or
|
|
from the corresponding IPv4 address. This is
|
|
intended to allow NS or DNAME RRsets to be added
|
|
to the <literal>ip6.arpa</literal> reverse tree.
|
|
</para>
|
|
<para>
|
|
The <command>identity</command> field must match
|
|
the 6to4 prefix in <literal>ip6.arpa</literal>.
|
|
The <command>name</command> field should
|
|
be set to ".".
|
|
Note that, since identity is based on the client's
|
|
IP address, it is not necessary for update request
|
|
messages to be signed.
|
|
</para>
|
|
<para>
|
|
In addition, if specified for an
|
|
<literal>ip6.arpa</literal> name outside of the
|
|
<literal>2.0.0.2.ip6.arpa</literal> namespace,
|
|
the corresponding /48 reverse name can be updated.
|
|
For example, TCP/IPv6 connections
|
|
from 2001:DB8:ED0C::/48 can update records at
|
|
<literal>C.0.D.E.8.B.D.0.1.0.0.2.ip6.arpa</literal>.
|
|
</para>
|
|
<note>
|
|
It is theoretically possible to spoof these TCP
|
|
sessions.
|
|
</note>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<varname>external</varname>
|
|
</para>
|
|
</entry> <entry colname="2">
|
|
<para>
|
|
This rule allows <command>named</command>
|
|
to defer the decision of whether to allow a
|
|
given update to an external daemon.
|
|
</para>
|
|
<para>
|
|
The method of communicating with the daemon is
|
|
specified in the <replaceable>identity</replaceable>
|
|
field, the format of which is
|
|
"<constant>local:</constant><replaceable>path</replaceable>",
|
|
where <replaceable>path</replaceable> is the location
|
|
of a Unix-domain socket. (Currently, "local" is the
|
|
only supported mechanism.)
|
|
</para>
|
|
<para>
|
|
Requests to the external daemon are sent over the
|
|
Unix-domain socket as datagrams with the following
|
|
format:
|
|
</para>
|
|
<programlisting>
|
|
Protocol version number (4 bytes, network byte order, currently 1)
|
|
Request length (4 bytes, network byte order)
|
|
Signer (null-terminated string)
|
|
Name (null-terminated string)
|
|
TCP source address (null-terminated string)
|
|
Rdata type (null-terminated string)
|
|
Key (null-terminated string)
|
|
TKEY token length (4 bytes, network byte order)
|
|
TKEY token (remainder of packet)</programlisting>
|
|
<para>
|
|
The daemon replies with a four-byte value in
|
|
network byte order, containing either 0 or 1; 0
|
|
indicates that the specified update is not
|
|
permitted, and 1 indicates that it is.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
|
|
<section xml:id="multiple_views"><info><title>Multiple Views</title></info>
|
|
|
|
<para>
|
|
When multiple views are in use, a zone may be
|
|
referenced by more than one of them. Often, the views
|
|
contain different zones with the same name, allowing
|
|
different clients to receive different answers for the same
|
|
queries. At times, however, it is desirable for multiple
|
|
views to contain identical zones. The
|
|
<command>in-view</command> zone option provides an efficient
|
|
way to do this; it allows a view to reference a zone that
|
|
was defined in a previously configured view. Example:
|
|
</para>
|
|
<programlisting>
|
|
view internal {
|
|
match-clients { 10/8; };
|
|
|
|
zone example.com {
|
|
type master;
|
|
file "example-external.db";
|
|
};
|
|
};
|
|
|
|
view external {
|
|
match-clients { any; };
|
|
|
|
zone example.com {
|
|
in-view internal;
|
|
};
|
|
};
|
|
</programlisting>
|
|
<para>
|
|
An <command>in-view</command> option cannot refer to a view
|
|
that is configured later in the configuration file.
|
|
</para>
|
|
<para>
|
|
A <command>zone</command> statement which uses the
|
|
<command>in-view</command> option may not use any other
|
|
, with the exception of <command>forward</command>
|
|
and <command>forwarders</command>. (These options control
|
|
the behavior of the containing view, rather than change
|
|
the zone object itself.)
|
|
</para>
|
|
<para>
|
|
Zone-level ACLs (e.g., allow-query, allow-transfer), and
|
|
other configuration details of the zone, are all set
|
|
in the view the referenced zone is defined in. Be
|
|
careful to ensure that ACLs are wide enough
|
|
for all views referencing the zone.
|
|
</para>
|
|
<para>
|
|
An <command>in-view</command> zone cannot be used as a
|
|
response policy zone.
|
|
</para>
|
|
<para>
|
|
An <command>in-view</command> zone is not intended to reference
|
|
a <command>forward</command> zone.
|
|
</para>
|
|
</section>
|
|
|
|
</section>
|
|
</section>
|
|
<section xml:id="zone_file"><info><title>Zone File</title></info>
|
|
|
|
<section xml:id="types_of_resource_records_and_when_to_use_them"><info><title>Types of Resource Records and When to Use Them</title></info>
|
|
|
|
<para>
|
|
This section, largely borrowed from RFC 1034, describes the
|
|
concept of a Resource Record (RR) and explains when each type is used.
|
|
Since the publication of RFC 1034, several new RRs have been
|
|
identified
|
|
and implemented in the DNS. These are also included.
|
|
</para>
|
|
<section><info><title>Resource Records</title></info>
|
|
|
|
<para>
|
|
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 name servers, 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 <xref linkend="the_sortlist_statement"/> and <xref linkend="rrset_ordering"/>.
|
|
</para>
|
|
|
|
<para>
|
|
The components of a Resource Record are:
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.000in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.500in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
owner name
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The domain name where the RR is found.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
type
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
An encoded 16-bit value that specifies
|
|
the type of the resource record.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
TTL
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
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.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
class
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
An encoded 16-bit value that identifies
|
|
a protocol family or an instance of a protocol.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
RDATA
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The resource data. The format of the
|
|
data is type- and sometimes class-specific.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<para>
|
|
For a complete list of <emphasis>types</emphasis> of valid RRs,
|
|
including those that have been obsoleted,
|
|
please refer to https://en.wikipedia.org/wiki/List_of_DNS_record_types.
|
|
</para>
|
|
|
|
<para>
|
|
The following <emphasis>classes</emphasis> of resource records
|
|
are currently valid in the DNS:
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0"><tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.625in"/>
|
|
<tbody>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
IN
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The Internet.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
CH
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Chaosnet, a LAN protocol created at MIT in the
|
|
mid-1970s.
|
|
It was rarely used for its historical purpose, but was reused for
|
|
BIND's
|
|
built-in server information zones, e.g.,
|
|
<literal>version.bind</literal>.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
HS
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Hesiod, an information service
|
|
developed by MIT's Project Athena. It was used to share
|
|
information
|
|
about various systems databases, such as users,
|
|
groups, printers,
|
|
etc.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>
|
|
The owner name is often implicit, rather than forming an
|
|
integral
|
|
part of the RR. For example, many name servers 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.
|
|
</para>
|
|
<para>
|
|
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; that also times out, but follows 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, and then increased back to its former value
|
|
following
|
|
the change.
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</section>
|
|
<section xml:id="rr_text"><info><title>Textual Expression of RRs</title></info>
|
|
|
|
<para>
|
|
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 name server or resolver. In the examples provided
|
|
in
|
|
RFC 1034, a style similar to that used in zone 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.
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
Following the owner are 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. 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 interest of clarity.
|
|
</para>
|
|
<para>
|
|
The resource data or RDATA section of the RR is given using
|
|
knowledge of the typical representation for the data.
|
|
</para>
|
|
<para>
|
|
For example, the RRs carried in a message might be shown as:
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0"><tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.381in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="1.020in"/>
|
|
<colspec colname="3" colnum="3" colsep="0" colwidth="2.099in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>ISI.EDU.</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>MX</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>10 VENERA.ISI.EDU.</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para/>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>MX</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>10 VAXA.ISI.EDU</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>VENERA.ISI.EDU</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>128.9.0.32</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para/>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>10.1.0.52</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>VAXA.ISI.EDU</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>10.2.0.27</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para/>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>128.9.0.33</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
The above example shows six RRs, with two RRs at each of three
|
|
domain names.
|
|
</para>
|
|
<para>
|
|
Here is another possible example:
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0"><tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.491in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="1.067in"/>
|
|
<colspec colname="3" colnum="3" colsep="0" colwidth="2.067in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>XX.LCS.MIT.EDU.</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>IN A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>10.0.0.44</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1"/>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>CH A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>MIT.EDU. 2420</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<para>
|
|
This example shows two addresses for
|
|
<literal>XX.LCS.MIT.EDU</literal>, each of a different class.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="mx_records"><info><title>Discussion of MX Records</title></info>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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 falls 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 is delivered.
|
|
It <emphasis>must</emphasis> have an associated address record
|
|
(A or AAAA); CNAME is not sufficient.
|
|
</para>
|
|
<para>
|
|
For a given domain, if there is both a CNAME record and an
|
|
MX record, the MX record is in error, and is ignored.
|
|
Instead,
|
|
the mail is delivered to the server specified in the MX
|
|
record
|
|
pointed to by the CNAME.
|
|
For example:
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="3Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.708in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="0.444in"/>
|
|
<colspec colname="3" colnum="3" colsep="0" colwidth="0.444in"/>
|
|
<colspec colname="4" colnum="4" colsep="0" colwidth="0.976in"/>
|
|
<colspec colname="5" colnum="5" colsep="0" colwidth="1.553in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>example.com.</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>IN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>MX</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
<literal>10</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para>
|
|
<literal>mail.example.com.</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para/>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>IN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>MX</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
<literal>10</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para>
|
|
<literal>mail2.example.com.</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para/>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>IN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>MX</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
<literal>20</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para>
|
|
<literal>mail.backup.org.</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>mail.example.com.</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>IN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
<literal>10.0.0.1</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para/>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>mail2.example.com.</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>IN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<literal>A</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="4">
|
|
<para>
|
|
<literal>10.0.0.2</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="5">
|
|
<para/>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable><para>
|
|
Mail delivery is attempted to <literal>mail.example.com</literal> and
|
|
<literal>mail2.example.com</literal> (in
|
|
any order); if neither of those succeeds, delivery to <literal>mail.backup.org</literal>
|
|
is attempted.
|
|
</para>
|
|
</section>
|
|
<section xml:id="Setting_TTLs"><info><title>Setting TTLs</title></info>
|
|
|
|
<para>
|
|
The time-to- (TTL) 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 an RR can be cached before it
|
|
should be discarded. The following three types of TTLs are
|
|
currently
|
|
used in a zone file.
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="0.750in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="4.375in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
SOA
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The last field in the SOA is the negative
|
|
caching TTL. This controls how long other servers
|
|
cache no-such-domain
|
|
(NXDOMAIN) responses from this server.
|
|
</para>
|
|
<para>
|
|
The maximum time for
|
|
negative caching is 3 hours (3h).
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
$TTL
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
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.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
RR TTLs
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Each RR can have a TTL as the second
|
|
field in the RR, which controls how long other
|
|
servers can cache it.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<para>
|
|
All of these TTLs default to units of seconds, though units
|
|
can be explicitly specified: for example, <literal>1h30m</literal>.
|
|
</para>
|
|
</section>
|
|
<section xml:id="ipv4_reverse"><info><title>Inverse Mapping in IPv4</title></info>
|
|
|
|
<para>
|
|
Reverse name resolution (that is, translation from IP address
|
|
to name) is achieved by means of the <emphasis>in-addr.arpa</emphasis> 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 <optional>example.com</optional> domain:
|
|
</para>
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>$ORIGIN</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>2.1.10.in-addr.arpa</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>
|
|
<literal>3</literal>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<literal>IN PTR foo.example.com.</literal>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<note>
|
|
<para>
|
|
The <command>$ORIGIN</command> line in this example
|
|
is only to provide context; it does not
|
|
necessarily
|
|
appear in the actual usage. It is only used here to indicate
|
|
that the example is relative to the listed origin.
|
|
</para>
|
|
</note>
|
|
</section>
|
|
<section xml:id="zone_directives"><info><title>Other Zone File Directives</title></info>
|
|
|
|
<para>
|
|
The DNS "master file" format was initially defined in RFC 1035 and
|
|
has subsequently been extended. While the format
|
|
itself
|
|
is class-independent, all records in a zone file must be of the
|
|
same
|
|
class.
|
|
</para>
|
|
<para>
|
|
Master file directives include <command>$ORIGIN</command>, <command>$INCLUDE</command>,
|
|
and <command>$TTL.</command>
|
|
</para>
|
|
<section xml:id="atsign"><info><title>The <command>@</command> (at-sign)</title></info>
|
|
|
|
<para>
|
|
When used in the label (or name) field, the asperand or
|
|
at-sign (@) symbol represents the current origin.
|
|
At the start of the zone file, it is the
|
|
<<varname>zone_name</varname>>, followed by a
|
|
trailing dot (.).
|
|
</para>
|
|
</section>
|
|
<section xml:id="origin_directive"><info><title>The <command>$ORIGIN</command> Directive</title></info>
|
|
|
|
<para>
|
|
Syntax: <command>$ORIGIN</command>
|
|
<replaceable>domain-name</replaceable>
|
|
<optional><replaceable>comment</replaceable></optional>
|
|
</para>
|
|
<para><command>$ORIGIN</command>
|
|
sets the domain name that is appended to any
|
|
unqualified records. When a zone is first read, there
|
|
is an implicit <command>$ORIGIN</command>
|
|
<<varname>zone_name</varname>><command>.</command>;
|
|
note the trailing dot.
|
|
The current <command>$ORIGIN</command> is appended to
|
|
the domain specified in the <command>$ORIGIN</command>
|
|
argument if it is not absolute.
|
|
</para>
|
|
|
|
<programlisting>
|
|
$ORIGIN example.com.
|
|
WWW CNAME MAIN-SERVER
|
|
</programlisting>
|
|
|
|
<para>
|
|
is equivalent to
|
|
</para>
|
|
|
|
<programlisting>
|
|
WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
|
|
</programlisting>
|
|
|
|
</section>
|
|
<section xml:id="include_directive"><info><title>The <command>$INCLUDE</command> Directive</title></info>
|
|
|
|
<para>
|
|
Syntax: <command>$INCLUDE</command>
|
|
<replaceable>filename</replaceable>
|
|
<optional>
|
|
<replaceable>origin</replaceable> </optional>
|
|
<optional> <replaceable>comment</replaceable> </optional>
|
|
</para>
|
|
<para>
|
|
This reads and processes the file <filename>filename</filename> as
|
|
if it were included in the file at this point. If <command>origin</command> is
|
|
specified, the file is processed with <command>$ORIGIN</command> set
|
|
to that value; otherwise, the current <command>$ORIGIN</command> is
|
|
used.
|
|
</para>
|
|
<para>
|
|
The origin and the current domain name
|
|
revert to the values they had prior to the <command>$INCLUDE</command> once
|
|
the file has been read.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
RFC 1035 specifies that the current origin should be restored
|
|
after
|
|
an <command>$INCLUDE</command>, 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.
|
|
</para>
|
|
</note>
|
|
</section>
|
|
<section xml:id="ttl_directive"><info><title>The <command>$TTL</command> Directive</title></info>
|
|
|
|
<para>
|
|
Syntax: <command>$TTL</command>
|
|
<replaceable>default-ttl</replaceable>
|
|
<optional>
|
|
<replaceable>comment</replaceable> </optional>
|
|
</para>
|
|
<para>
|
|
This sets the default Time-To-Live (TTL) for subsequent records
|
|
with undefined TTLs. Valid TTLs are of the range 0-2147483647
|
|
seconds.
|
|
</para>
|
|
<para><command>$TTL</command>
|
|
is defined in RFC 2308.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
<section xml:id="generate_directive"><info><title><acronym>BIND</acronym> Primary File Extension: the <command>$GENERATE</command> Directive</title></info>
|
|
|
|
<para>
|
|
Syntax: <command>$GENERATE</command>
|
|
<replaceable>range</replaceable>
|
|
<replaceable>lhs</replaceable>
|
|
<optional><replaceable>ttl</replaceable></optional>
|
|
<optional><replaceable>class</replaceable></optional>
|
|
<replaceable>type</replaceable>
|
|
<replaceable>rhs</replaceable>
|
|
<optional><replaceable>comment</replaceable></optional>
|
|
</para>
|
|
<para><command>$GENERATE</command>
|
|
is used to create a series of resource records that only
|
|
differ from each other by an
|
|
iterator. <command>$GENERATE</command> 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.
|
|
</para>
|
|
|
|
<programlisting>$ORIGIN 0.0.192.IN-ADDR.ARPA.
|
|
$GENERATE 1-2 @ NS SERVER$.EXAMPLE.
|
|
$GENERATE 1-127 $ CNAME $.0</programlisting>
|
|
|
|
<para>
|
|
is equivalent to
|
|
</para>
|
|
|
|
<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.
|
|
</programlisting>
|
|
|
|
<para>
|
|
Both generate a set of A and MX records. Note the MX's right-hand
|
|
side is a quoted string. The quotes are stripped when the
|
|
right-hand side is processed.
|
|
</para>
|
|
|
|
<programlisting>
|
|
$ORIGIN EXAMPLE.
|
|
$GENERATE 1-127 HOST-$ A 1.2.3.$
|
|
$GENERATE 1-127 HOST-$ MX "0 ."</programlisting>
|
|
|
|
<para>
|
|
is equivalent to
|
|
</para>
|
|
|
|
<programlisting>HOST-1.EXAMPLE. A 1.2.3.1
|
|
HOST-1.EXAMPLE. MX 0 .
|
|
HOST-2.EXAMPLE. A 1.2.3.2
|
|
HOST-2.EXAMPLE. MX 0 .
|
|
HOST-3.EXAMPLE. A 1.2.3.3
|
|
HOST-3.EXAMPLE. MX 0 .
|
|
...
|
|
HOST-127.EXAMPLE. A 1.2.3.127
|
|
HOST-127.EXAMPLE. MX 0 .
|
|
</programlisting>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="4.250in"/>
|
|
<tbody>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>range</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
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. "start", "stop", and "step" must be positive
|
|
integers between 0 and (2^31)-1. "start" must not be
|
|
larger than "stop".
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>lhs</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>This
|
|
describes the owner name of the resource records
|
|
to be created. Any single <command>$</command>
|
|
(dollar sign)
|
|
symbols within the <command>lhs</command> string
|
|
are replaced by the iterator value.
|
|
|
|
To get a $ in the output, escape the
|
|
<command>$</command> using a backslash
|
|
<command>\</command>,
|
|
e.g., <command>\$</command>. The
|
|
<command>$</command> may optionally be followed
|
|
by modifiers which change the offset from the
|
|
iterator, field width, and base.
|
|
|
|
Modifiers are introduced by a
|
|
<command>{</command> (left brace) immediately following the
|
|
<command>$</command>, as in
|
|
<command>${offset[,width[,base]]}</command>.
|
|
For example, <command>${-20,3,d}</command>
|
|
subtracts 20 from the current value and prints the
|
|
result as a decimal in a zero-padded field of
|
|
width 3.
|
|
|
|
Available output forms are decimal
|
|
(<command>d</command>), octal
|
|
(<command>o</command>), hexadecimal
|
|
(<command>x</command> or <command>X</command>
|
|
for uppercase), and nibble
|
|
(<command>n</command> or <command>N</command>
|
|
for uppercase). The default modifier is
|
|
<command>${0,0,d}</command>. If the
|
|
<command>lhs</command> is not absolute, the
|
|
current <command>$ORIGIN</command> is appended
|
|
to the name.
|
|
</para>
|
|
<para>
|
|
In nibble mode, the value is treated as
|
|
if it were a reversed hexadecimal string,
|
|
with each hexadecimal digit as a separate
|
|
label. The width field includes the label
|
|
separator.
|
|
</para>
|
|
<para>
|
|
For compatibility with earlier versions,
|
|
<command>$$</command> is still recognized as
|
|
indicating a literal $ in the output.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ttl</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This specifies the time-to-live of the generated records. If
|
|
not specified, this is inherited using the
|
|
normal TTL inheritance rules.
|
|
</para>
|
|
<para><command>class</command>
|
|
and <command>ttl</command> can be
|
|
entered in either order.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>class</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This specifies the class of the generated records.
|
|
This must match the zone class if it is
|
|
specified.
|
|
</para>
|
|
<para><command>class</command>
|
|
and <command>ttl</command> can be
|
|
entered in either order.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>type</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This can be any valid type.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>rhs</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<command>rhs</command> is an optionally quoted string.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
<para>
|
|
The <command>$GENERATE</command> directive is a <acronym>BIND</acronym> extension
|
|
and not part of the standard zone file format.
|
|
</para>
|
|
<para>
|
|
BIND 8 did not support the optional TTL and CLASS fields.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="zonefile_format"><info><title>Additional File Formats</title></info>
|
|
|
|
<para>
|
|
In addition to the standard text format, BIND 9
|
|
supports the ability to read or dump to zone files in
|
|
other formats.
|
|
</para>
|
|
<para>
|
|
The <constant>raw</constant> format is
|
|
a binary representation of zone data in a manner similar
|
|
to that used in zone transfers. Since it does not require
|
|
parsing text, load time is significantly reduced.
|
|
</para>
|
|
<para>
|
|
An even faster alternative is the <constant>map</constant>
|
|
format, which is an image of a <acronym>BIND</acronym> 9
|
|
in-memory zone database; it can be loaded
|
|
directly into memory via the <command>mmap()</command>
|
|
function and the zone can begin serving queries almost
|
|
immediately.
|
|
</para>
|
|
<para>
|
|
For a primary server, a zone file in
|
|
<constant>raw</constant> or <constant>map</constant>
|
|
format is expected to be generated from a textual zone
|
|
file by the <command>named-compilezone</command> command.
|
|
For a secondary server or for a dynamic zone, the zone file is automatically
|
|
generated when
|
|
<command>named</command> dumps the zone contents after
|
|
zone transfer or when applying prior updates, if one of these formats is specified by the
|
|
<command>masterfile-format</command> option.
|
|
</para>
|
|
<para>
|
|
If a zone file in a binary format needs manual modification,
|
|
it first must be converted to a textual form by the
|
|
<command>named-compilezone</command> command. Make any
|
|
necessary modifications to the text file, and
|
|
then convert it to the binary form via the
|
|
<command>named-compilezone</command> command again.
|
|
</para>
|
|
<para>
|
|
Note that <command>map</command> format is extremely
|
|
architecture-specific. A <constant>map</constant>
|
|
file <emphasis>cannot</emphasis> be used on a system
|
|
with different pointer size, endianness, or data alignment
|
|
than the system on which it was generated, and should in
|
|
general be used only inside a single system.
|
|
While <constant>raw</constant> format uses
|
|
network byte order and avoids architecture-dependent
|
|
data alignment so that it is as portable as
|
|
possible, it is also primarily expected to be used
|
|
inside the same single system. To export a
|
|
zone file in either <constant>raw</constant> or
|
|
<constant>map</constant> format, or make a
|
|
portable backup of such a file, conversion to
|
|
<constant>text</constant> format is recommended.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="statistics"><info><title>BIND 9 Statistics</title></info>
|
|
|
|
<para>
|
|
<acronym>BIND</acronym> 9 maintains lots of statistics
|
|
information and provides several interfaces for users to
|
|
access those statistics.
|
|
The available statistics include all statistics counters
|
|
that are meaningful in <acronym>BIND</acronym> 9,
|
|
and other information that is considered useful.
|
|
</para>
|
|
|
|
<para>
|
|
The statistics information is categorized into the following
|
|
sections:
|
|
</para>
|
|
|
|
<informaltable frame="all">
|
|
<tgroup cols="2">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="3.300in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="2.625in"/>
|
|
<tbody>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>Incoming Requests</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of incoming DNS requests for each OPCODE.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>Incoming Queries</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of incoming queries for each RR type.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>Outgoing Queries</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
The number of outgoing queries for each RR
|
|
type sent from the internal resolver,
|
|
maintained per view.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>Name Server Statistics</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Statistics counters for incoming request processing.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>Zone Maintenance Statistics</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Statistics counters regarding zone maintenance
|
|
operations, such as zone transfers.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>Resolver Statistics</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Statistics counters for name resolutions
|
|
performed in the internal resolver,
|
|
maintained per view.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>Cache DB RRsets</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Statistics counters related to cache contents,
|
|
maintained per view.
|
|
</para>
|
|
<para>
|
|
The "NXDOMAIN" counter is the number of names
|
|
that have been cached as nonexistent.
|
|
Counters named for RR types indicate the
|
|
number of active RRsets for each type in the cache
|
|
database.
|
|
</para>
|
|
<para>
|
|
If an RR type name is preceded by an exclamation
|
|
point (!), it represents the number of records in the
|
|
cache which indicate that the type does not exist
|
|
for a particular name; this is also known as "NXRRSET".
|
|
If an RR type name is preceded by a hash mark (#), it
|
|
represents the number of RRsets for this type that are
|
|
present in the cache but whose TTLs have expired; these
|
|
RRsets may only be used if stale answers are enabled.
|
|
If an RR type name is preceded by a tilde (~), it
|
|
represents the number of RRsets for this type that are
|
|
present in the cache database but are marked for garbage
|
|
collection; these RRsets cannot be used.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para>Socket I/O Statistics</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
Statistics counters for network-related events.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>
|
|
A subset of Name Server Statistics is collected and shown
|
|
per zone for which the server has the authority, when
|
|
<command>zone-statistics</command> is set to
|
|
<userinput>full</userinput> (or <userinput>yes</userinput>),
|
|
for backward compatibility. See the description of
|
|
<command>zone-statistics</command> in <xref linkend="options"/>
|
|
for further details.
|
|
</para>
|
|
|
|
<para>
|
|
These statistics counters are shown with their zone and
|
|
view names. The view name is omitted when the server is
|
|
not configured with explicit views.</para>
|
|
|
|
<para>
|
|
There are currently two user interfaces to get access to the
|
|
statistics.
|
|
One is in plain-text format, dumped to the file specified
|
|
by the <command>statistics-file</command> configuration option;
|
|
the other is remotely accessible via a statistics channel
|
|
when the <command>statistics-channels</command> statement
|
|
is specified in the configuration file
|
|
(see <xref linkend="statschannels"/>.)
|
|
</para>
|
|
|
|
<section xml:id="statsfile"><info><title>The Statistics File</title></info>
|
|
|
|
<para>
|
|
The text format statistics dump begins with a line, like:
|
|
</para>
|
|
<para>
|
|
<command>+++ Statistics Dump +++ (973798949)</command>
|
|
</para>
|
|
<para>
|
|
The number in parentheses is a standard
|
|
Unix-style timestamp, measured in seconds since January 1, 1970.
|
|
|
|
Following
|
|
that line is a set of statistics information, which is categorized
|
|
as described above.
|
|
Each section begins with a line, like:
|
|
</para>
|
|
|
|
<para>
|
|
<command>++ Name Server Statistics ++</command>
|
|
</para>
|
|
|
|
<para>
|
|
Each section consists of lines, each containing the statistics
|
|
counter value followed by its textual description;
|
|
see below for available counters.
|
|
For brevity, counters that have a value of 0 are not shown
|
|
in the statistics file.
|
|
</para>
|
|
|
|
<para>
|
|
The statistics dump ends with the line where the
|
|
number is identical to the number in the beginning line; for example:
|
|
</para>
|
|
<para>
|
|
<command>--- Statistics Dump --- (973798949)</command>
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="statistics_counters"><info><title>Statistics Counters</title></info>
|
|
|
|
<para>
|
|
The following tables summarize the statistics counters that
|
|
<acronym>BIND</acronym> 9 provides.
|
|
For each row of the tables, the leftmost column is the
|
|
abbreviated symbol name of that counter;
|
|
these symbols are shown in the statistics information
|
|
accessed via an HTTP statistics channel.
|
|
The rightmost column gives the description of the counter,
|
|
which is also shown in the statistics file,
|
|
but, in this document, may be slightly modified
|
|
for better readability.
|
|
Additional notes may also be provided in this column.
|
|
When a middle column exists between these two columns,
|
|
it gives the corresponding counter name of the
|
|
<acronym>BIND</acronym> 8 statistics, if applicable.
|
|
</para>
|
|
|
|
<section xml:id="stats_counters"><info><title>Name Server Statistics Counters</title></info>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="3" colnum="3" colsep="0" colwidth="3.350in"/>
|
|
<tbody>
|
|
<row>
|
|
<entry colname="1">
|
|
<para>
|
|
<emphasis>Symbol</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<emphasis>BIND 8 Symbol</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<emphasis>Description</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Requestv4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of IPv4 requests received.
|
|
Note: this also counts non-query requests.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Requestv6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of IPv6 requests received.
|
|
Note: this also counts non-query requests.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ReqEdns0</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of requests received with EDNS(0).
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ReqBadEDNSVer</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of requests received with an unsupported EDNS version.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ReqTSIG</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of requests received with TSIG.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ReqSIG0</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of requests received with SIG(0).
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ReqBadSIG</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of requests received with an invalid (TSIG or SIG(0)) signature.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ReqTCP</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RTCP</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of TCP requests received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>AuthQryRej</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RUQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of rejected authoritative (non-recursive) queries.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>RecQryRej</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RURQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of rejected recursive queries.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>XfrRej</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RUXFR</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of rejected zone transfer requests.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>UpdateRej</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RUUpd</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of rejected dynamic update requests.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Response</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SAns</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of responses sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>RespTruncated</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of truncated responses sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>RespEDNS0</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of responses sent with EDNS(0).
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>RespTSIG</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of responses sent with TSIG.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>RespSIG0</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of responses sent with SIG(0).
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QrySuccess</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in a successful answer,
|
|
meaning queries which return a NOERROR response
|
|
with at least one answer RR.
|
|
This corresponds to the
|
|
<command>success</command> counter
|
|
of previous versions of
|
|
<acronym>BIND</acronym> 9.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryAuthAns</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in an authoritative answer.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryNoauthAns</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SNaAns</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in a non-authoritative answer.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryReferral</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in a referral answer.
|
|
This corresponds to the
|
|
<command>referral</command> counter
|
|
of previous versions of
|
|
<acronym>BIND</acronym> 9.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryNxrrset</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in NOERROR responses with no data.
|
|
This corresponds to the
|
|
<command>nxrrset</command> counter
|
|
of previous versions of
|
|
<acronym>BIND</acronym> 9.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QrySERVFAIL</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SFail</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in SERVFAIL.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryFORMERR</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SFErr</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in FORMERR.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryNXDOMAIN</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SNXD</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in NXDOMAIN.
|
|
This corresponds to the
|
|
<command>nxdomain</command> counter
|
|
of previous versions of
|
|
<acronym>BIND</acronym> 9.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryRecursion</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RFwdQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that caused the server
|
|
to perform recursion in order to find the final answer.
|
|
This corresponds to the
|
|
<command>recursion</command> counter
|
|
of previous versions of
|
|
<acronym>BIND</acronym> 9.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryDuplicate</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RDupQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries which the server attempted to
|
|
recurse but for which it discovered an existing query with the same
|
|
IP address, port, query ID, name, type, and class
|
|
already being processed.
|
|
This corresponds to the
|
|
<command>duplicate</command> counter
|
|
of previous versions of
|
|
<acronym>BIND</acronym> 9.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryDropped</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of recursive queries for which the server
|
|
discovered an excessive number of existing
|
|
recursive queries for the same name, type, and
|
|
class, and which were subsequently dropped.
|
|
This is the number of dropped queries due to
|
|
the reason explained with the
|
|
<command>clients-per-query</command>
|
|
and
|
|
<command>max-clients-per-query</command>
|
|
options
|
|
(see the description about
|
|
<xref endterm="cpq_term" linkend="clients-per-query"/>.)
|
|
This corresponds to the
|
|
<command>dropped</command> counter
|
|
of previous versions of
|
|
<acronym>BIND</acronym> 9.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryFailure</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of query failures.
|
|
This corresponds to the
|
|
<command>failure</command> counter
|
|
of previous versions of
|
|
<acronym>BIND</acronym> 9.
|
|
Note: this counter is provided mainly for
|
|
backward compatibility with the previous versions;
|
|
normally, more fine-grained counters such as
|
|
<command>AuthQryRej</command> and
|
|
<command>RecQryRej</command>
|
|
that would also fall into this counter are provided,
|
|
so this counter is not of much
|
|
interest in practice.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryNXRedir</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in NXDOMAIN that were redirected.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryNXRedirRLookup</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries that resulted in NXDOMAIN that were redirected
|
|
and resulted in a successful remote lookup.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>XfrReqDone</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of requested and completed zone transfers.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>UpdateReqFwd</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of forwarded update requests.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>UpdateRespFwd</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of forwarded update responses.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>UpdateFwdFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of forwarded dynamic updates that failed.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>UpdateDone</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of completed dynamic updates.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>UpdateFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of failed dynamic updates.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>UpdateBadPrereq</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of dynamic updates rejected due to a prerequisite failure.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>RateDropped</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of responses dropped due to rate limits.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>RateSlipped</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of responses truncated by rate limits.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>RPZRewrites</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of response policy zone rewrites.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
|
|
<section xml:id="zone_stats"><info><title>Zone Maintenance Statistics Counters</title></info>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
|
|
<tbody>
|
|
<row>
|
|
<entry colname="1">
|
|
<para>
|
|
<emphasis>Symbol</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<emphasis>Description</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>NotifyOutv4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of IPv4 notifies sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>NotifyOutv6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of IPv6 notifies sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>NotifyInv4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of IPv4 notifies received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>NotifyInv6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of IPv6 notifies received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>NotifyRej</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of incoming notifies rejected.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>SOAOutv4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of IPv4 SOA queries sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>SOAOutv6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of IPv6 SOA queries sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>AXFRReqv4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of requested IPv4 AXFRs.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>AXFRReqv6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of requested IPv6 AXFRs.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>IXFRReqv4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of requested IPv4 IXFRs.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>IXFRReqv6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of requested IPv6 IXFRs.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>XfrSuccess</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of successful zone transfer requests.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>XfrFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of failed zone transfer requests.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
|
|
<section xml:id="resolver_stats"><info><title>Resolver Statistics Counters</title></info>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="3" colnum="3" colsep="0" colwidth="3.350in"/>
|
|
<tbody>
|
|
<row>
|
|
<entry colname="1">
|
|
<para>
|
|
<emphasis>Symbol</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<emphasis>BIND 8 Symbol</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
<emphasis>Description</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Queryv4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SFwdQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of IPv4 queries sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Queryv6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SFwdQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of IPv6 queries sent.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Responsev4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RR</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of IPv4 responses received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Responsev6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RR</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of IPv6 responses received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>NXDOMAIN</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RNXD</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of NXDOMAINs received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>SERVFAIL</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RFail</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of SERVFAILs received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>FORMERR</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RFErr</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of FORMERRs received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>OtherError</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RErr</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of other errors received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>EDNS0Fail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of EDNS(0) query failures.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Mismatch</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RDupR</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of mismatched responses received,
|
|
meaning the DNS ID, response's source address,
|
|
and/or the response's source port does not
|
|
match what was expected.
|
|
(The port must be 53 or as defined by
|
|
the <command>port</command> option.)
|
|
This may be an indication of a cache
|
|
poisoning attempt.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Truncated</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of truncated responses received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Lame</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>RLame</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of lame delegations received.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>Retry</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SDupQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of query retries performed.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QueryAbort</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of queries aborted due to quota control.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QuerySockFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of failures in opening query sockets.
|
|
One common reason for such failures is a
|
|
due to a limitation on file descriptors.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QueryTimeout</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of query timeouts.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>GlueFetchv4</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SSysQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of IPv4 NS address fetches invoked.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>GlueFetchv6</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command>SSysQ</command></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of IPv6 NS address fetches invoked.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>GlueFetchv4Fail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of failed IPv4 NS address fetches.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>GlueFetchv6Fail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of failed IPv6 NS address fetches.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ValAttempt</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of attempted DNSSEC validations.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ValOk</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of successful DNSSEC validations.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ValNegOk</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of successful DNSSEC validations on negative information.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>ValFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This indicates the number of failed DNSSEC validations.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command>QryRTTnn</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para><command/></para>
|
|
</entry>
|
|
<entry colname="3">
|
|
<para>
|
|
This provides a frequency table on query round-trip times (RTTs).
|
|
Each <command>nn</command> specifies the corresponding
|
|
frequency.
|
|
In the sequence of
|
|
<command>nn_1</command>,
|
|
<command>nn_2</command>,
|
|
...,
|
|
<command>nn_m</command>,
|
|
the value of <command>nn_i</command> is the
|
|
number of queries whose RTTs are between
|
|
<command>nn_(i-1)</command> (inclusive) and
|
|
<command>nn_i</command> (exclusive) milliseconds.
|
|
For the sake of convenience, we define
|
|
<command>nn_0</command> to be 0.
|
|
The last entry should be represented as
|
|
<command>nn_m+</command>, which means the
|
|
number of queries whose RTTs are equal to or greater than
|
|
<command>nn_m</command> milliseconds.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
</section>
|
|
|
|
<section xml:id="socket_stats"><info><title>Socket I/O Statistics Counters</title></info>
|
|
|
|
<para>
|
|
Socket I/O statistics counters are defined per socket
|
|
type, which are
|
|
<command>UDP4</command> (UDP/IPv4),
|
|
<command>UDP6</command> (UDP/IPv6),
|
|
<command>TCP4</command> (TCP/IPv4),
|
|
<command>TCP6</command> (TCP/IPv6),
|
|
<command>Unix</command> (Unix Domain), and
|
|
<command>FDwatch</command> (sockets opened outside the
|
|
socket module).
|
|
In the following table, <command><TYPE></command>
|
|
represents a socket type.
|
|
Not all counters are available for all socket types;
|
|
exceptions are noted in the description field.
|
|
</para>
|
|
|
|
<informaltable colsep="0" rowsep="0">
|
|
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
|
|
<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
|
|
<colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
|
|
<tbody>
|
|
<row>
|
|
<entry colname="1">
|
|
<para>
|
|
<emphasis>Symbol</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
<emphasis>Description</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>Open</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of sockets opened successfully.
|
|
This counter does not apply to the
|
|
<command>FDwatch</command> type.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>OpenFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of failures to open sockets.
|
|
This counter does not apply to the
|
|
<command>FDwatch</command> type.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>Close</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of closed sockets.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>BindFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of failures to bind sockets.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>ConnFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of failures to connect sockets.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>Conn</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of connections established successfully.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>AcceptFail</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of failures to accept incoming connection requests.
|
|
This counter does not apply to the
|
|
<command>UDP</command> and
|
|
<command>FDwatch</command> types.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>Accept</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of incoming connections successfully accepted.
|
|
This counter does not apply to the
|
|
<command>UDP</command> and
|
|
<command>FDwatch</command> types.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>SendErr</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of errors in socket send operations.
|
|
This counter corresponds
|
|
to the <command>SErr</command> counter of
|
|
<command>BIND</command> 8.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
<row rowsep="0">
|
|
<entry colname="1">
|
|
<para><command><TYPE>RecvErr</command></para>
|
|
</entry>
|
|
<entry colname="2">
|
|
<para>
|
|
This indicates the number of errors in socket receive operations,
|
|
including errors of send operations on a
|
|
connected UDP socket, notified by an ICMP error
|
|
message.
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
|
|
<section xml:id="bind8_compatibility"><info><title>Compatibility with <emphasis>BIND</emphasis> 8 Counters</title></info>
|
|
|
|
<para>
|
|
Most statistics counters that were available
|
|
in <command>BIND</command> 8 are also supported in
|
|
<command>BIND</command> 9, as shown in the above tables.
|
|
Here are notes about other counters that do not appear
|
|
in these tables.
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><command>RFwdR,SFwdR</command></term>
|
|
<listitem>
|
|
<para>
|
|
These counters are not supported,
|
|
because <command>BIND</command> 9 does not adopt
|
|
the notion of <emphasis>forwarding</emphasis>
|
|
as <command>BIND</command> 8 did.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>RAXFR</command></term>
|
|
<listitem>
|
|
<para>
|
|
This counter is accessible in the Incoming Queries section.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>RIQ</command></term>
|
|
<listitem>
|
|
<para>
|
|
This counter is accessible in the Incoming Requests section.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><command>ROpts</command></term>
|
|
<listitem>
|
|
<para>
|
|
This counter is not supported,
|
|
because <command>BIND</command> 9 does not care
|
|
about IP options.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
</section>
|
|
</section>
|
|
|
|
</chapter>
|
|
<chapter xml:id="Bv9ARM.ch07"><info><title><acronym>BIND</acronym> 9 Security Considerations</title></info>
|
|
|
|
<section xml:id="Access_Control_Lists"><info><title>Access Control Lists</title></info>
|
|
|
|
<para>
|
|
Access Control Lists (ACLs) are address match lists that
|
|
can be set up and nicknamed for future use in
|
|
<command>allow-notify</command>, <command>allow-query</command>,
|
|
<command>allow-query-on</command>, <command>allow-recursion</command>,
|
|
<command>blackhole</command>, <command>allow-transfer</command>,
|
|
<command>match-clients</command>, etc.
|
|
</para>
|
|
<para>
|
|
ACLs give users finer control over who can access
|
|
the name server, without cluttering up configuration files with huge
|
|
lists of IP addresses.
|
|
</para>
|
|
<para>
|
|
It is a <emphasis>good idea</emphasis> to use ACLs, and to
|
|
control access. Limiting access to the server by
|
|
outside parties can help prevent spoofing and denial of service
|
|
(DoS) attacks against the server.
|
|
</para>
|
|
<para>
|
|
ACLs match clients on the basis of up to three characteristics:
|
|
1) The client's IP address; 2) the TSIG or SIG(0) key that was
|
|
used to sign the request, if any; and 3) an address prefix
|
|
encoded in an EDNS Client-Subnet option, if any.
|
|
</para>
|
|
<para>
|
|
Here is an example of ACLs based on client addresses:
|
|
</para>
|
|
|
|
<programlisting>
|
|
// Set up an ACL named "bogusnets" that blocks
|
|
// RFC 1918 space and some reserved space, which is
|
|
// commonly used in spoofing attacks.
|
|
acl bogusnets {
|
|
0.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
|
|
10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
|
|
};
|
|
|
|
// Set up an ACL called our-nets. Replace this with the
|
|
// real IP numbers.
|
|
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
|
|
options {
|
|
...
|
|
...
|
|
allow-query { our-nets; };
|
|
allow-recursion { our-nets; };
|
|
...
|
|
blackhole { bogusnets; };
|
|
...
|
|
};
|
|
|
|
zone "example.com" {
|
|
type master;
|
|
file "m/example.com";
|
|
allow-query { any; };
|
|
};
|
|
</programlisting>
|
|
|
|
<para>
|
|
This allows authoritative queries for "example.com" from any
|
|
address, but recursive queries only from the networks specified
|
|
in "our-nets", and no queries at all from the networks
|
|
specified in "bogusnets".
|
|
</para>
|
|
<para>
|
|
In addition to network addresses and prefixes, which are
|
|
matched against the source address of the DNS request, ACLs
|
|
may include <option>key</option> elements, which specify the
|
|
name of a TSIG or SIG(0) key, or <option>ecs</option>
|
|
elements, which specify a network prefix but are only matched
|
|
if that prefix matches an EDNS client-subnet option included
|
|
in the request.
|
|
</para>
|
|
<para>
|
|
The EDNS Client-Subnet (ECS) option is used by a recursive
|
|
resolver to inform an authoritative name server of the network
|
|
address block from which the original query was received, enabling
|
|
authoritative servers to give different answers to the same
|
|
resolver for different resolver clients. An ACL containing
|
|
an element of the form
|
|
<command>ecs <replaceable>prefix</replaceable></command>
|
|
will match if a request arrives in containing an ECS option
|
|
encoding an address within that prefix. If the request has no
|
|
ECS option, then "ecs" elements are simply ignored. Addresses
|
|
in ACLs that are not prefixed with "ecs" are matched only
|
|
against the source address.
|
|
</para>
|
|
<note>
|
|
<simpara>
|
|
(Note: the authoritative ECS implementation in
|
|
<command>named</command> is based on an early version of the
|
|
specification, and is known to have incompatibilities with
|
|
other implementations. It is also inefficient, requiring
|
|
a separate view for each client subnet to be sent different
|
|
answers, and it is unable to correct for overlapping subnets in
|
|
the configuration. It can be used for testing purposes, but is
|
|
not recommended for production use.)
|
|
</simpara>
|
|
</note>
|
|
<para>
|
|
When <acronym>BIND</acronym> 9 is built with GeoIP support,
|
|
ACLs can also be used for geographic access restrictions.
|
|
This is done by specifying an ACL element of the form:
|
|
<command>geoip <optional>db <replaceable>database</replaceable></optional> <replaceable>field</replaceable> <replaceable>value</replaceable></command>
|
|
</para>
|
|
<para>
|
|
The <replaceable>field</replaceable> parameter indicates which field
|
|
to search for a match. Available fields are "country",
|
|
"region", "city", "continent", "postal" (postal code),
|
|
"metro" (metro code), "area" (area code), "tz" (timezone),
|
|
"isp", "asnum", and "domain".
|
|
</para>
|
|
<para>
|
|
<replaceable>value</replaceable> is the value to search
|
|
for within the database. A string may be quoted if it
|
|
contains spaces or other special characters. An "asnum"
|
|
search for autonomous system number can be specified using
|
|
the string "ASNNNN" or the integer NNNN.
|
|
When "country" search is specified with a string that is two
|
|
characters long, it must be a standard ISO-3166-1
|
|
two-letter country code; otherwise, it is interpreted as
|
|
the full name of the country. Similarly, if
|
|
"region" is the search term and the string is two characters long,
|
|
it is treated as a standard two-letter state or province
|
|
abbreviation; otherwise, it is treated as the full name of the
|
|
state or province.
|
|
</para>
|
|
<para>
|
|
The <replaceable>database</replaceable> field indicates which
|
|
GeoIP database to search for a match. In most cases this is
|
|
unnecessary, because most search fields can only be found in
|
|
a single database. However, searches for "continent" or "country"
|
|
can be answered from either the "city" or "country" databases,
|
|
so for these search types, specifying a
|
|
<replaceable>database</replaceable>
|
|
forces the query to be answered from that database and no
|
|
other. If <replaceable>database</replaceable> is not
|
|
specified, these queries are first answered from the "city"
|
|
database if it is installed, and then from the "country" database if it
|
|
is installed. Valid database names are
|
|
"country", "city", "asnum", "isp", and "domain". (If using
|
|
the legacy GeoIP API, "netspeed" and "org" databases are also
|
|
available.)
|
|
</para>
|
|
<para>
|
|
By default, if a DNS query includes an EDNS Client-Subnet (ECS)
|
|
option which encodes a non-zero address prefix, then GeoIP ACL
|
|
elements are matched against that address prefix. Otherwise,
|
|
they are matched against the source address of the query. To
|
|
prevent GeoIP ACLs from matching against ECS options, set
|
|
the <command>geoip-use-ecs</command> to <literal>no</literal>.
|
|
</para>
|
|
<para>
|
|
Some example GeoIP ACLs:
|
|
</para>
|
|
<programlisting>geoip country US;
|
|
geoip country JP;
|
|
geoip db country country Canada;
|
|
geoip region WA;
|
|
geoip city "San Francisco";
|
|
geoip region Oklahoma;
|
|
geoip postal 95062;
|
|
geoip tz "America/Los_Angeles";
|
|
geoip org "Internet Systems Consortium";
|
|
</programlisting>
|
|
|
|
<para>
|
|
ACLs use a "first-match" logic rather than "best-match";
|
|
if an address prefix matches an ACL element, then that ACL
|
|
is considered to have matched even if a later element would
|
|
have matched more specifically. For example, the ACL
|
|
<command>{ 10/8; !10.0.0.1; }</command> would actually
|
|
match a query from 10.0.0.1, because the first element
|
|
indicates that the query should be accepted, and the second
|
|
element is ignored.
|
|
</para>
|
|
<para>
|
|
When using "nested" ACLs (that is, ACLs included or referenced
|
|
within other ACLs), a negative match of a nested ACL tells
|
|
the containing ACL to continue looking for matches. This
|
|
enables complex ACLs to be constructed, in which multiple
|
|
client characteristics can be checked at the same time. For
|
|
example, to construct an ACL which allows a query only when
|
|
it originates from a particular network <emphasis>and</emphasis>
|
|
only when it is signed with a particular key, use:
|
|
</para>
|
|
<programlisting>
|
|
allow-query { !{ !10/8; any; }; key example; };
|
|
</programlisting>
|
|
<para>
|
|
Within the nested ACL, any address that is
|
|
<emphasis>not</emphasis> in the 10/8 network prefix is
|
|
rejected, which terminates processing of the
|
|
ACL. Any address that <emphasis>is</emphasis> in the 10/8
|
|
network prefix is accepted, but this causes a negative
|
|
match of the nested ACL, so the containing ACL continues
|
|
processing. The query is accepted if it is signed
|
|
by the key "example", and rejected otherwise. The ACL, then,
|
|
only matches when <emphasis>both</emphasis> conditions
|
|
are true.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="chroot_and_setuid"><info><title><command>Chroot</command> and <command>Setuid</command></title></info>
|
|
|
|
<para>
|
|
On Unix servers, it is possible to run <acronym>BIND</acronym>
|
|
in a <emphasis>chrooted</emphasis> environment (using
|
|
the <command>chroot()</command> function) by specifying
|
|
the <option>-t</option> option for <command>named</command>.
|
|
This can help improve system security by placing
|
|
<acronym>BIND</acronym> in a "sandbox," which limits
|
|
the damage done if a server is compromised.
|
|
</para>
|
|
<para>
|
|
Another useful feature in the Unix version of <acronym>BIND</acronym> is the
|
|
ability to run the daemon as an unprivileged user (<option>-u</option> <replaceable>user</replaceable>).
|
|
We suggest running as an unprivileged user when using the <command>chroot</command> feature.
|
|
</para>
|
|
<para>
|
|
Here is an example command line to load <acronym>BIND</acronym> in a <command>chroot</command> sandbox,
|
|
<command>/var/named</command>, and to run <command>named</command> <command>setuid</command> to
|
|
user 202:
|
|
</para>
|
|
<para>
|
|
<userinput>/usr/local/sbin/named -u 202 -t /var/named</userinput>
|
|
</para>
|
|
|
|
<section xml:id="chroot"><info><title>The <command>chroot</command> Environment</title></info>
|
|
|
|
<para>
|
|
For a <command>chroot</command> environment
|
|
to work properly in a particular directory (for example,
|
|
<filename>/var/named</filename>), the
|
|
environment must include everything
|
|
<acronym>BIND</acronym> needs to run. From
|
|
<acronym>BIND</acronym>'s point of view,
|
|
<filename>/var/named</filename> is the root of the
|
|
filesystem; the values of
|
|
options like <command>directory</command> and
|
|
<command>pid-file</command> must be adjusted to account for this.
|
|
</para>
|
|
<para>
|
|
Unlike with earlier versions of BIND,
|
|
<command>named</command> does <emphasis>not</emphasis> typically need to be compiled
|
|
statically, nor do shared libraries need to be installed under the new root.
|
|
However, depending on the operating system, it may be necessary
|
|
to set up locations such as
|
|
<filename>/dev/zero</filename>,
|
|
<filename>/dev/random</filename>,
|
|
<filename>/dev/log</filename>, and
|
|
<filename>/etc/localtime</filename>.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="setuid"><info><title>Using the <command>setuid</command> Function</title></info>
|
|
|
|
<para>
|
|
Prior to running the <command>named</command> daemon,
|
|
use
|
|
the <command>touch</command> utility (to change file
|
|
access and
|
|
modification times) or the <command>chown</command>
|
|
utility (to
|
|
set the user id and/or group id) on files
|
|
where <acronym>BIND</acronym>
|
|
should write.
|
|
</para>
|
|
<note><simpara>
|
|
If the <command>named</command> daemon is running as an
|
|
unprivileged user, it cannot bind to new restricted
|
|
ports if the server is reloaded.
|
|
</simpara></note>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="dynamic_update_security"><info><title>Dynamic Update Security</title></info>
|
|
|
|
<para>
|
|
Access to the dynamic
|
|
update facility should be strictly limited. In earlier versions of
|
|
<acronym>BIND</acronym>, the only way to do this was
|
|
based on the IP
|
|
address of the host requesting the update, by listing an IP address
|
|
or
|
|
network prefix in the <command>allow-update</command>
|
|
zone option.
|
|
This method is insecure, since the source address of the update UDP
|
|
packet
|
|
is easily forged. Also note that if the IP addresses allowed by the
|
|
<command>allow-update</command> option include the
|
|
address of a secondary
|
|
server which performs forwarding of dynamic updates, the primary can
|
|
be
|
|
trivially attacked by sending the update to the secondary, which
|
|
forwards it to the primary with its own source IP address - causing the
|
|
primary to approve it without question.
|
|
</para>
|
|
|
|
<para>
|
|
For these reasons, we strongly recommend that updates be
|
|
cryptographically authenticated by means of transaction signatures
|
|
(TSIG). That is, the <command>allow-update</command>
|
|
option should
|
|
list only TSIG key names, not IP addresses or network
|
|
prefixes. Alternatively, the <command>update-policy</command>
|
|
option can be used.
|
|
</para>
|
|
|
|
<para>
|
|
Some sites choose to keep all dynamically updated DNS data
|
|
in a subdomain and delegate that subdomain to a separate zone. This
|
|
way, the top-level zone containing critical data, such as the IP
|
|
addresses
|
|
of public web and mail servers, need not allow dynamic update at
|
|
all.
|
|
</para>
|
|
|
|
</section>
|
|
</chapter>
|
|
|
|
<chapter xml:id="Bv9ARM.ch08"><info><title>Troubleshooting</title></info>
|
|
|
|
<section xml:id="common_problems"><info><title>Common Problems</title></info>
|
|
|
|
<section><info><title>It's Not Working; How Can I Figure Out What's Wrong?</title></info>
|
|
|
|
<para>
|
|
The best solution to installation and
|
|
configuration issues is to take preventive measures by setting
|
|
up logging files beforehand. The log files provide a
|
|
source of hints and information that can be used to identify
|
|
what went wrong and fix the problem.
|
|
</para>
|
|
|
|
</section>
|
|
</section>
|
|
<section><info><title>Incrementing and Changing the Serial Number</title></info>
|
|
|
|
<para>
|
|
Zone serial numbers are just numbers — they are not
|
|
date-related. However, many people set them to a number that
|
|
represents a date, usually of the form YYYYMMDDRR.
|
|
Occasionally they make a mistake and set the serial number to a
|
|
date in the future, then try to correct it by setting
|
|
it to the current date. This causes problems because
|
|
serial numbers are used to indicate that a zone has been
|
|
updated. If the serial number on the secondary server is
|
|
lower than the serial number on the primary, the secondary
|
|
server attempts to update its copy of the zone.
|
|
</para>
|
|
|
|
<para>
|
|
Setting the serial number to a lower number on the primary
|
|
server than the one on the secondary server means that the secondary will not perform
|
|
updates to its copy of the zone.
|
|
</para>
|
|
|
|
<para>
|
|
The solution to this is to add 2147483647 (2^31-1) to the
|
|
number, reload the zone and make sure all secondaries have updated to
|
|
the new zone serial number, then reset it to the desired number
|
|
and reload the zone again.
|
|
</para>
|
|
|
|
</section>
|
|
<section xml:id="more_help"><info><title>Where Can I Get Help?</title></info>
|
|
|
|
<para>
|
|
The BIND-users mailing list, at https://lists.isc.org/mailman/listinfo/bind-users,
|
|
is an excellent resource for peer user support. In addition, <acronym>ISC</acronym> maintains a
|
|
Knowledgebase of helpful articles at https://kb.isc.org.
|
|
</para>
|
|
|
|
<para>
|
|
Internet Systems Consortium
|
|
(<acronym>ISC</acronym>) offers annual
|
|
support agreements for <acronym>BIND</acronym>9, ISC <acronym>DHCP</acronym>, and Kea DHCP.
|
|
All paid support contracts include advance security notifications; some levels include
|
|
service level agreements (SLAs), premium software features, and increased priority on bug fixes
|
|
and feature requests.
|
|
</para>
|
|
|
|
<para>
|
|
Please contact
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="mailto:info@isc.org">info@isc.org</link> or visit
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.isc.org/contact/">https://www.isc.org/contact/</link>
|
|
for more information.
|
|
</para>
|
|
</section>
|
|
</chapter>
|
|
|
|
<appendix xml:id="Bv9ARM.ch09"><info><title>Release Notes</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="notes.xml"/>
|
|
</appendix>
|
|
|
|
<appendix xml:id="Bv9ARM.ch10"><info><title>A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym></title></info>
|
|
<para xml:id="historical_dns_information">
|
|
Although the Domain Name
|
|
System "officially" began in 1984 with the publication of RFC 920, the
|
|
core of the new system was described in 1983 in RFCs 882 and
|
|
883. From 1984 to 1987, the ARPAnet (the precursor to today's
|
|
Internet) became a testbed of experimentation for developing the
|
|
new naming/addressing scheme in a rapidly expanding,
|
|
operational network environment. New RFCs were written and
|
|
published in 1987 that modified the original documents to
|
|
incorporate improvements based on the working model. RFC 1034,
|
|
"Domain Names-Concepts and Facilities," and RFC 1035, "Domain
|
|
Names-Implementation and Specification," were published and
|
|
became the standards upon which all <acronym>DNS</acronym> implementations are
|
|
built.
|
|
</para>
|
|
|
|
<para>
|
|
The first working domain name server, called "Jeeves," was
|
|
written in 1983-84 by Paul Mockapetris for operation on DEC
|
|
Tops-20
|
|
machines located at the University of Southern California's
|
|
Information
|
|
Sciences Institute (USC-ISI) and SRI International's Network
|
|
Information
|
|
Center (SRI-NIC). A <acronym>DNS</acronym> server for
|
|
Unix machines, the Berkeley Internet
|
|
Name Domain (<acronym>BIND</acronym>) package, was
|
|
written soon after by a group of
|
|
graduate students at the University of California at Berkeley
|
|
under
|
|
a grant from the US Defense Advanced Research Projects
|
|
Administration
|
|
(DARPA).
|
|
</para>
|
|
<para>
|
|
Versions of <acronym>BIND</acronym> through
|
|
4.8.3 were maintained by the Computer
|
|
Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark
|
|
Painter, David Riggle, and Songnian Zhou made up the initial <acronym>BIND</acronym>
|
|
project team. After that, additional work on the software package
|
|
was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment
|
|
Corporation
|
|
employee on loan to the CSRG, worked on <acronym>BIND</acronym> for 2 years, from 1985
|
|
to 1987. Many other people also contributed to <acronym>BIND</acronym> development
|
|
during that time: Doug Kingston, Craig Partridge, Smoot
|
|
Carl-Mitchell,
|
|
Mike Muuss, Jim Bloom and Mike Schwartz. <acronym>BIND</acronym> maintenance was subsequently
|
|
handled by Mike Karels and Øivind Kure.
|
|
</para>
|
|
<para>
|
|
<acronym>BIND</acronym> versions 4.9 and 4.9.1 were
|
|
released by Digital Equipment
|
|
Corporation (which became Compaq Computer Corporation and eventually merged with Hewlett-Packard). Paul Vixie, then
|
|
a DEC employee, became <acronym>BIND</acronym>'s
|
|
primary caretaker. He was assisted
|
|
by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan
|
|
Beecher, Andrew
|
|
Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat
|
|
Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe
|
|
Wolfhugel, and others.
|
|
</para>
|
|
<para>
|
|
In 1994, <acronym>BIND</acronym> version 4.9.2 was sponsored by
|
|
Vixie Enterprises. Paul
|
|
Vixie became <acronym>BIND</acronym>'s principal
|
|
architect/programmer.
|
|
</para>
|
|
<para>
|
|
<acronym>BIND</acronym> versions from 4.9.3 onward
|
|
have been developed and maintained
|
|
by Internet Systems Consortium and its predecessor,
|
|
the Internet Software Consortium, with support provided
|
|
by ISC's sponsors.
|
|
</para>
|
|
<para>
|
|
As co-architects/programmers, Bob Halley and
|
|
Paul Vixie released the first production-ready version of
|
|
<acronym>BIND</acronym> version 8 in May 1997.
|
|
</para>
|
|
<para>
|
|
BIND version 9 was released in September 2000 and is a
|
|
major rewrite of nearly all aspects of the underlying
|
|
BIND architecture.
|
|
</para>
|
|
<para>
|
|
BIND versions 4 and 8 are officially deprecated.
|
|
No additional development is done
|
|
on BIND version 4 or BIND version 8.
|
|
</para>
|
|
<para>
|
|
<acronym>BIND</acronym> development work is made
|
|
possible today by the sponsorship
|
|
of corporations who purchase professional support services from ISC
|
|
(https://www.isc.org/contact/) and/or donate to our mission, and by the tireless efforts of
|
|
numerous individuals.
|
|
</para>
|
|
</appendix>
|
|
|
|
<appendix xml:id="Bv9ARM.ch11"><info><title>General <acronym>DNS</acronym> Reference Information</title></info>
|
|
|
|
<section xml:id="ipv6addresses"><info><title>IPv6 addresses (AAAA)</title></info>
|
|
|
|
<para>
|
|
IPv6 addresses are 128-bit identifiers, for interfaces and
|
|
sets of interfaces, which were introduced in the <acronym>DNS</acronym> to facilitate
|
|
scalable Internet routing. There are three types of addresses: <emphasis>Unicast</emphasis>,
|
|
an identifier for a single interface;
|
|
<emphasis>Anycast</emphasis>,
|
|
an identifier for a set of interfaces; and <emphasis>Multicast</emphasis>,
|
|
an identifier for a set of interfaces. Here we describe the global
|
|
Unicast address scheme. For more information, see RFC 3587,
|
|
"IPv6 Global Unicast Address Format."
|
|
</para>
|
|
<para>
|
|
IPv6 unicast addresses consist of a
|
|
<emphasis>global routing prefix</emphasis>, a
|
|
<emphasis>subnet identifier</emphasis>, and an
|
|
<emphasis>interface identifier</emphasis>.
|
|
</para>
|
|
<para>
|
|
The global routing prefix is provided by the
|
|
upstream provider or ISP, and roughly corresponds to the
|
|
IPv4 <emphasis>network</emphasis> section
|
|
of the address range.
|
|
|
|
The subnet identifier is for local subnetting, much
|
|
like subnetting an
|
|
IPv4 /16 network into /24 subnets.
|
|
|
|
The interface identifier is the address of an individual
|
|
interface on a given network; in IPv6, addresses belong to
|
|
interfaces rather than to machines.
|
|
</para>
|
|
<para>
|
|
The subnetting capability of IPv6 is much more flexible than
|
|
that of IPv4; subnetting can be carried out on bit boundaries,
|
|
in much the same way as Classless InterDomain Routing
|
|
(CIDR), and the DNS PTR representation ("nibble" format)
|
|
makes setting up reverse zones easier.
|
|
</para>
|
|
<para>
|
|
The interface identifier must be unique on the local link,
|
|
and is usually generated automatically by the IPv6
|
|
implementation, although it is usually possible to
|
|
override the default setting if necessary. A typical IPv6
|
|
address might look like:
|
|
<command>2001:db8:201:9:a00:20ff:fe81:2b32</command>.
|
|
</para>
|
|
<para>
|
|
IPv6 address specifications often contain long strings
|
|
of zeros, so the architects have included a shorthand for
|
|
specifying
|
|
them. The double colon ("::") indicates the longest possible
|
|
string
|
|
of zeros that can fit, and can be used only once in an address.
|
|
</para>
|
|
</section>
|
|
<section xml:id="bibliography"><info><title>Bibliography (and Suggested Reading)</title></info>
|
|
|
|
<section xml:id="rfcs"><info><title>Request for Comments (RFCs)</title></info>
|
|
|
|
<para>
|
|
Specification documents for the Internet protocol suite, including
|
|
the <acronym>DNS</acronym>, are published as part of
|
|
the Request for Comments (RFCs)
|
|
series of technical notes. The standards themselves are defined
|
|
by the Internet Engineering Task Force (IETF) and the Internet
|
|
Engineering Steering Group (IESG). RFCs can be obtained online at:
|
|
</para>
|
|
<para>
|
|
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://datatracker.ietf.org/doc/">
|
|
https://datatracker.ietf.org/doc/
|
|
</link>
|
|
</para>
|
|
|
|
<bibliography><title/>
|
|
<bibliodiv><title>Standards</title>
|
|
<!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
|
|
|
|
<biblioentry>
|
|
<abbrev>RFC974</abbrev>
|
|
<author><personname><surname>Partridge</surname><firstname>C.</firstname></personname></author>
|
|
<title>Mail Routing and the Domain System</title>
|
|
<pubdate>January 1986</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1034</abbrev>
|
|
<author><personname><surname>Mockapetris</surname><firstname>P.V.</firstname></personname></author>
|
|
<title>Domain Names — Concepts and Facilities</title>
|
|
<pubdate>November 1987</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1035</abbrev>
|
|
<author><personname><surname>Mockapetris</surname><firstname>P. V.</firstname></personname></author> <title>Domain Names — Implementation and
|
|
Specification</title>
|
|
<pubdate>November 1987</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv xml:id="proposed_standards" xreflabel="Proposed Standards"><title>Proposed Standards</title>
|
|
|
|
<!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
|
|
<biblioentry>
|
|
<abbrev>RFC2181</abbrev>
|
|
<author><personname><surname>Elz</surname><firstname>R., R. Bush</firstname></personname></author>
|
|
<title>Clarifications to the <acronym>DNS</acronym>
|
|
Specification</title>
|
|
<pubdate>July 1997</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2308</abbrev>
|
|
<author><personname><surname>Andrews</surname><firstname>M.</firstname></personname></author>
|
|
<title>Negative Caching of <acronym>DNS</acronym>
|
|
Queries</title>
|
|
<pubdate>March 1998</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1995</abbrev>
|
|
<author><personname><surname>Ohta</surname><firstname>M.</firstname></personname></author>
|
|
<title>Incremental Zone Transfer in <acronym>DNS</acronym></title>
|
|
<pubdate>August 1996</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1996</abbrev>
|
|
<author><personname><surname>Vixie</surname><firstname>P.</firstname></personname></author>
|
|
<title>A Mechanism for Prompt Notification of Zone Changes</title>
|
|
<pubdate>August 1996</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2136</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Vixie</surname><firstname>P.</firstname></personname></author>
|
|
<author><personname><firstname>S.</firstname><surname>Thomson</surname></personname></author>
|
|
<author><personname><firstname>Y.</firstname><surname>Rekhter</surname></personname></author>
|
|
<author><personname><firstname>J.</firstname><surname>Bound</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Dynamic Updates in the Domain Name System</title>
|
|
<pubdate>April 1997</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2671</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Extension Mechanisms for DNS (EDNS0)</title>
|
|
<pubdate>August 1997</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2672</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>M.</firstname><surname>Crawford</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Non-Terminal DNS Name Redirection</title>
|
|
<pubdate>August 1999</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2845</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Vixie</surname><firstname>P.</firstname></personname></author>
|
|
<author><personname><firstname>O.</firstname><surname>Gudmundsson</surname></personname></author>
|
|
<author><personname><firstname>D.</firstname><surname>Eastlake</surname><lineage>3rd</lineage></personname></author>
|
|
<author><personname><firstname>B.</firstname><surname>Wellington</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG)</title>
|
|
<pubdate>May 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2930</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>D.</firstname><surname>Eastlake</surname><lineage>3rd</lineage></personname></author>
|
|
</authorgroup>
|
|
<title>Secret Key Establishment for DNS (TKEY RR)</title>
|
|
<pubdate>September 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2931</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>D.</firstname><surname>Eastlake</surname><lineage>3rd</lineage></personname></author>
|
|
</authorgroup>
|
|
<title>DNS Request and Transaction Signatures (SIG(0)s)</title>
|
|
<pubdate>September 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3007</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>B.</firstname><surname>Wellington</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Secure Domain Name System (DNS) Dynamic Update</title>
|
|
<pubdate>November 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3645</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>S.</firstname><surname>Kwan</surname></personname></author>
|
|
<author><personname><firstname>P.</firstname><surname>Garg</surname></personname></author>
|
|
<author><personname><firstname>J.</firstname><surname>Gilroy</surname></personname></author>
|
|
<author><personname><firstname>L.</firstname><surname>Esibov</surname></personname></author>
|
|
<author><personname><firstname>J.</firstname><surname>Westhead</surname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Hall</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Generic Security Service Algorithm for Secret
|
|
Key Transaction Authentication for DNS
|
|
(GSS-TSIG)</title>
|
|
<pubdate>October 2003</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title><acronym>DNS</acronym> Security Proposed Standards</title>
|
|
|
|
<biblioentry>
|
|
<abbrev>RFC3225</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>D.</firstname><surname>Conrad</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Indicating Resolver Support of DNSSEC</title>
|
|
<pubdate>December 2001</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3833</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>D.</firstname><surname>Atkins</surname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Austein</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Threat Analysis of the Domain Name System (DNS)</title>
|
|
<pubdate>August 2004</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC4033</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>R.</firstname><surname>Arends</surname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Austein</surname></personname></author>
|
|
<author><personname><firstname>M.</firstname><surname>Larson</surname></personname></author>
|
|
<author><personname><firstname>D.</firstname><surname>Massey</surname></personname></author>
|
|
<author><personname><firstname>S.</firstname><surname>Rose</surname></personname></author>
|
|
</authorgroup>
|
|
<title>DNS Security Introduction and Requirements</title>
|
|
<pubdate>March 2005</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC4034</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>R.</firstname><surname>Arends</surname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Austein</surname></personname></author>
|
|
<author><personname><firstname>M.</firstname><surname>Larson</surname></personname></author>
|
|
<author><personname><firstname>D.</firstname><surname>Massey</surname></personname></author>
|
|
<author><personname><firstname>S.</firstname><surname>Rose</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Resource Records for the DNS Security Extensions</title>
|
|
<pubdate>March 2005</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC4035</abbrev>
|
|
<authorgroup>
|
|
<author><personname><firstname>R.</firstname><surname>Arends</surname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Austein</surname></personname></author>
|
|
<author><personname><firstname>M.</firstname><surname>Larson</surname></personname></author>
|
|
<author><personname><firstname>D.</firstname><surname>Massey</surname></personname></author>
|
|
<author><personname><firstname>S.</firstname><surname>Rose</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Protocol Modifications for the DNS
|
|
Security Extensions</title>
|
|
<pubdate>March 2005</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title>Other Important RFCs About <acronym>DNS</acronym>
|
|
Implementation</title>
|
|
|
|
<biblioentry>
|
|
<abbrev>RFC1535</abbrev>
|
|
<author><personname><surname>Gavron</surname><firstname>E.</firstname></personname></author>
|
|
<title>A Security Problem and Proposed Correction With Widely
|
|
Deployed <acronym>DNS</acronym> Software</title>
|
|
<pubdate>October 1993</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1536</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Kumar</surname><firstname>A.</firstname></personname></author>
|
|
<author><personname><firstname>J.</firstname><surname>Postel</surname></personname></author>
|
|
<author><personname><firstname>C.</firstname><surname>Neuman</surname></personname></author>
|
|
<author><personname><firstname>P.</firstname><surname>Danzig</surname></personname></author>
|
|
<author><personname><firstname>S.</firstname><surname>Miller</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Common <acronym>DNS</acronym> Implementation
|
|
Errors and Suggested Fixes</title>
|
|
<pubdate>October 1993</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1982</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Elz</surname><firstname>R.</firstname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Bush</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Serial Number Arithmetic</title>
|
|
<pubdate>August 1996</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC4074</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Morishita</surname><firstname>Y.</firstname></personname></author>
|
|
<author><personname><firstname>T.</firstname><surname>Jinmei</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Common Misbehaviour Against <acronym>DNS</acronym>
|
|
Queries for IPv6 Addresses</title>
|
|
<pubdate>May 2005</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title>Resource Record Types</title>
|
|
|
|
<biblioentry>
|
|
<abbrev>RFC1183</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Everhart</surname><firstname>C.F.</firstname></personname></author>
|
|
<author><personname><firstname>L. A.</firstname><surname>Mamakos</surname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Ullmann</surname></personname></author>
|
|
<author><personname><firstname>P.</firstname><surname>Mockapetris</surname></personname></author>
|
|
</authorgroup>
|
|
<title>New <acronym>DNS</acronym> RR Definitions</title>
|
|
<pubdate>October 1990</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1706</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Manning</surname><firstname>B.</firstname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Colella</surname></personname></author>
|
|
</authorgroup>
|
|
<title><acronym>DNS</acronym> NSAP Resource Records</title>
|
|
<pubdate>October 1994</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2168</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Daniel</surname><firstname>R.</firstname></personname></author>
|
|
<author><personname><firstname>M.</firstname><surname>Mealling</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Resolution of Uniform Resource Identifiers using
|
|
the Domain Name System</title>
|
|
<pubdate>June 1997</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1876</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Davis</surname><firstname>C.</firstname></personname></author>
|
|
<author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
|
|
<author><personname><firstname>T.</firstname><firstname>Goodwin</firstname></personname></author>
|
|
<author><personname><firstname>I.</firstname><surname>Dickinson</surname></personname></author>
|
|
</authorgroup>
|
|
<title>A Means for Expressing Location Information in the
|
|
Domain
|
|
Name System</title>
|
|
<pubdate>January 1996</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2052</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Gulbrandsen</surname><firstname>A.</firstname></personname></author>
|
|
<author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
|
|
</authorgroup>
|
|
<title>A <acronym>DNS</acronym> RR for Specifying the
|
|
Location of
|
|
Services</title>
|
|
<pubdate>October 1996</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2163</abbrev>
|
|
<author><personname><surname>Allocchio</surname><firstname>A.</firstname></personname></author>
|
|
<title>Using the Internet <acronym>DNS</acronym> to
|
|
Distribute MIXER
|
|
Conformant Global Address Mapping</title>
|
|
<pubdate>January 1998</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2230</abbrev>
|
|
<author><personname><surname>Atkinson</surname><firstname>R.</firstname></personname></author>
|
|
<title>Key Exchange Delegation Record for the <acronym>DNS</acronym></title>
|
|
<pubdate>October 1997</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2536</abbrev>
|
|
<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
|
|
<title>DSA KEYs and SIGs in the Domain Name System (DNS)</title>
|
|
<pubdate>March 1999</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2537</abbrev>
|
|
<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
|
|
<title>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</title>
|
|
<pubdate>March 1999</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2538</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
|
|
<author><personname><surname>Gudmundsson</surname><firstname>O.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Storing Certificates in the Domain Name System (DNS)</title>
|
|
<pubdate>March 1999</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2539</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
|
|
</authorgroup>
|
|
<title>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</title>
|
|
<pubdate>March 1999</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2540</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
|
|
</authorgroup>
|
|
<title>Detached Domain Name System (DNS) Information</title>
|
|
<pubdate>March 1999</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2782</abbrev>
|
|
<author><personname><surname>Gulbrandsen</surname><firstname>A.</firstname></personname></author>
|
|
<author><personname><surname>Vixie</surname><firstname>P.</firstname></personname></author>
|
|
<author><personname><surname>Esibov</surname><firstname>L.</firstname></personname></author>
|
|
<title>A DNS RR for specifying the location of services (DNS SRV)</title>
|
|
<pubdate>February 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2915</abbrev>
|
|
<author><personname><surname>Mealling</surname><firstname>M.</firstname></personname></author>
|
|
<author><personname><surname>Daniel</surname><firstname>R.</firstname></personname></author>
|
|
<title>The Naming Authority Pointer (NAPTR) DNS Resource Record</title>
|
|
<pubdate>September 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3110</abbrev>
|
|
<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
|
|
<title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
|
|
<pubdate>May 2001</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3123</abbrev>
|
|
<author><personname><surname>Koch</surname><firstname>P.</firstname></personname></author>
|
|
<title>A DNS RR Type for Lists of Address Prefixes (APL RR)</title>
|
|
<pubdate>June 2001</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3596</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Thomson</surname><firstname>S.</firstname></personname></author>
|
|
<author><personname><firstname>C.</firstname><surname>Huitema</surname></personname></author>
|
|
<author><personname><firstname>V.</firstname><surname>Ksinant</surname></personname></author>
|
|
<author><personname><firstname>M.</firstname><surname>Souissi</surname></personname></author>
|
|
</authorgroup>
|
|
<title><acronym>DNS</acronym> Extensions to support IP
|
|
version 6</title>
|
|
<pubdate>October 2003</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3597</abbrev>
|
|
<author><personname><surname>Gustafsson</surname><firstname>A.</firstname></personname></author>
|
|
<title>Handling of Unknown DNS Resource Record (RR) Types</title>
|
|
<pubdate>September 2003</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title><acronym>DNS</acronym> and the Internet</title>
|
|
|
|
<biblioentry>
|
|
<abbrev>RFC1101</abbrev>
|
|
<author><personname><surname>Mockapetris</surname><firstname>P. V.</firstname></personname></author>
|
|
<title><acronym>DNS</acronym> Encoding of Network Names
|
|
and Other Types</title>
|
|
<pubdate>April 1989</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1123</abbrev>
|
|
<author><personname><surname>Braden</surname><surname>R.</surname></personname></author>
|
|
<title>Requirements for Internet Hosts - Application and
|
|
Support</title>
|
|
<pubdate>October 1989</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1591</abbrev>
|
|
<author><personname><surname>Postel</surname><firstname>J.</firstname></personname></author>
|
|
<title>Domain Name System Structure and Delegation</title>
|
|
<pubdate>March 1994</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2317</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Eidnes</surname><firstname>H.</firstname></personname></author>
|
|
<author><personname><firstname>G.</firstname><surname>de Groot</surname></personname></author>
|
|
<author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Classless IN-ADDR.ARPA Delegation</title>
|
|
<pubdate>March 1998</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2826</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Internet Architecture Board</surname></personname></author>
|
|
</authorgroup>
|
|
<title>IAB Technical Comment on the Unique DNS Root</title>
|
|
<pubdate>May 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2929</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
|
|
<author><personname><surname>Brunner-Williams</surname><firstname>E.</firstname></personname></author>
|
|
<author><personname><surname>Manning</surname><firstname>B.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Domain Name System (DNS) IANA Considerations</title>
|
|
<pubdate>September 2000</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title><acronym>DNS</acronym> Operations</title>
|
|
|
|
<biblioentry>
|
|
<abbrev>RFC1033</abbrev>
|
|
<author><personname><surname>Lottor</surname><firstname>M.</firstname></personname></author>
|
|
<title>Domain administrators operations guide</title>
|
|
<pubdate>November 1987</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1537</abbrev>
|
|
<author><personname><surname>Beertema</surname><firstname>P.</firstname></personname></author>
|
|
<title>Common <acronym>DNS</acronym> Data File
|
|
Configuration Errors</title>
|
|
<pubdate>October 1993</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1912</abbrev>
|
|
<author><personname><surname>Barr</surname><firstname>D.</firstname></personname></author>
|
|
<title>Common <acronym>DNS</acronym> Operational and
|
|
Configuration Errors</title>
|
|
<pubdate>February 1996</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2010</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Manning</surname><firstname>B.</firstname></personname></author>
|
|
<author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Operational Criteria for Root Name Servers</title>
|
|
<pubdate>October 1996</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2219</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Hamilton</surname><firstname>M.</firstname></personname></author>
|
|
<author><personname><firstname>R.</firstname><surname>Wright</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Use of <acronym>DNS</acronym> Aliases for
|
|
Network Services</title>
|
|
<pubdate>October 1997</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title>Internationalized Domain Names</title>
|
|
|
|
<biblioentry>
|
|
<abbrev>RFC2825</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>IAB</surname></personname></author>
|
|
<author><personname><surname>Daigle</surname><firstname>R.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>A Tangled Web: Issues of I18N, Domain Names,
|
|
and the Other Internet protocols</title>
|
|
<pubdate>May 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3490</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Faltstrom</surname><firstname>P.</firstname></personname></author>
|
|
<author><personname><surname>Hoffman</surname><firstname>P.</firstname></personname></author>
|
|
<author><personname><surname>Costello</surname><firstname>A.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Internationalizing Domain Names in Applications (IDNA)</title>
|
|
<pubdate>March 2003</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3491</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Hoffman</surname><firstname>P.</firstname></personname></author>
|
|
<author><personname><surname>Blanchet</surname><firstname>M.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Nameprep: A Stringprep Profile for Internationalized Domain Names</title>
|
|
<pubdate>March 2003</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3492</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Costello</surname><firstname>A.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Punycode: A Bootstring encoding of Unicode
|
|
for Internationalized Domain Names in
|
|
Applications (IDNA)</title>
|
|
<pubdate>March 2003</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title>Other <acronym>DNS</acronym>-related RFCs</title>
|
|
|
|
<note>
|
|
<para>
|
|
Note: the following list of RFCs, although
|
|
<acronym>DNS</acronym>-related, are not
|
|
concerned with implementing software.
|
|
</para>
|
|
</note>
|
|
<biblioentry>
|
|
<abbrev>RFC1464</abbrev>
|
|
<author><personname><surname>Rosenbaum</surname><firstname>R.</firstname></personname></author>
|
|
<title>Using the Domain Name System To Store Arbitrary String
|
|
Attributes</title>
|
|
<pubdate>May 1993</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1713</abbrev>
|
|
<author><personname><surname>Romao</surname><firstname>A.</firstname></personname></author>
|
|
<title>Tools for <acronym>DNS</acronym> Debugging</title>
|
|
<pubdate>November 1994</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC1794</abbrev>
|
|
<author><personname><surname>Brisco</surname><firstname>T.</firstname></personname></author>
|
|
<title><acronym>DNS</acronym> Support for Load
|
|
Balancing</title>
|
|
<pubdate>April 1995</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2240</abbrev>
|
|
<author><personname><surname>Vaughan</surname><firstname>O.</firstname></personname></author>
|
|
<title>A Legal Basis for Domain Name Allocation</title>
|
|
<pubdate>November 1997</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2345</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Klensin</surname><firstname>J.</firstname></personname></author>
|
|
<author><personname><firstname>T.</firstname><surname>Wolf</surname></personname></author>
|
|
<author><personname><firstname>G.</firstname><surname>Oglesby</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Domain Names and Company Name Retrieval</title>
|
|
<pubdate>May 1998</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2352</abbrev>
|
|
<author><personname><surname>Vaughan</surname><firstname>O.</firstname></personname></author>
|
|
<title>A Convention For Using Legal Names as Domain Names</title>
|
|
<pubdate>May 1998</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3071</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Klensin</surname><firstname>J.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Reflections on the DNS, RFC 1591, and Categories of Domains</title>
|
|
<pubdate>February 2001</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3258</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Hardie</surname><firstname>T.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Distributing Authoritative Name Servers via
|
|
Shared Unicast Addresses</title>
|
|
<pubdate>April 2002</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3901</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Durand</surname><firstname>A.</firstname></personname></author>
|
|
<author><personname><firstname>J.</firstname><surname>Ihren</surname></personname></author>
|
|
</authorgroup>
|
|
<title>DNS IPv6 Transport Operational Guidelines</title>
|
|
<pubdate>September 2004</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title>Obsolete and Unimplemented Experimental RFC</title>
|
|
|
|
<biblioentry>
|
|
<abbrev>RFC1712</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Farrell</surname><firstname>C.</firstname></personname></author>
|
|
<author><personname><firstname>M.</firstname><surname>Schulze</surname></personname></author>
|
|
<author><personname><firstname>S.</firstname><surname>Pleitner</surname></personname></author>
|
|
<author><personname><firstname>D.</firstname><surname>Baldoni</surname></personname></author>
|
|
</authorgroup>
|
|
<title><acronym>DNS</acronym> Encoding of Geographical
|
|
Location</title>
|
|
<pubdate>November 1994</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2673</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Crawford</surname><firstname>M.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Binary Labels in the Domain Name System</title>
|
|
<pubdate>August 1999</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2874</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Crawford</surname><firstname>M.</firstname></personname></author>
|
|
<author><personname><surname>Huitema</surname><firstname>C.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>DNS Extensions to Support IPv6 Address Aggregation
|
|
and Renumbering</title>
|
|
<pubdate>July 2000</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
<bibliodiv><title>Obsoleted DNS Security RFCs</title>
|
|
|
|
<note>
|
|
<para>
|
|
Most of these have been consolidated into RFC4033,
|
|
RFC4034 and RFC4035 which collectively describe DNSSECbis.
|
|
</para>
|
|
</note>
|
|
<biblioentry>
|
|
<abbrev>RFC2065</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Eastlake</surname><lineage>3rd</lineage><firstname>D.</firstname></personname></author>
|
|
<author><personname><firstname>C.</firstname><surname>Kaufman</surname></personname></author>
|
|
</authorgroup>
|
|
<title>Domain Name System Security Extensions</title>
|
|
<pubdate>January 1997</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2137</abbrev>
|
|
<author><personname><surname>Eastlake</surname><lineage>3rd</lineage><firstname>D.</firstname></personname></author>
|
|
<title>Secure Domain Name System Dynamic Update</title>
|
|
<pubdate>April 1997</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC2535</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Eastlake</surname><lineage>3rd</lineage><firstname>D.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Domain Name System Security Extensions</title>
|
|
<pubdate>March 1999</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3008</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Wellington</surname><firstname>B.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Domain Name System Security (DNSSEC)
|
|
Signing Authority</title>
|
|
<pubdate>November 2000</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3090</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Lewis</surname><firstname>E.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>DNS Security Extension Clarification on Zone Status</title>
|
|
<pubdate>March 2001</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3445</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Massey</surname><firstname>D.</firstname></personname></author>
|
|
<author><personname><surname>Rose</surname><firstname>S.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Limiting the Scope of the KEY Resource Record (RR)</title>
|
|
<pubdate>December 2002</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3655</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Wellington</surname><firstname>B.</firstname></personname></author>
|
|
<author><personname><surname>Gudmundsson</surname><firstname>O.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Redefinition of DNS Authenticated Data (AD) bit</title>
|
|
<pubdate>November 2003</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3658</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Gudmundsson</surname><firstname>O.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Delegation Signer (DS) Resource Record (RR)</title>
|
|
<pubdate>December 2003</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3755</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Weiler</surname><firstname>S.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Legacy Resolver Compatibility for Delegation Signer (DS)</title>
|
|
<pubdate>May 2004</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3757</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Kolkman</surname><firstname>O.</firstname></personname></author>
|
|
<author><personname><surname>Schlyter</surname><firstname>J.</firstname></personname></author>
|
|
<author><personname><surname>Lewis</surname><firstname>E.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>Domain Name System KEY (DNSKEY) Resource Record
|
|
(RR) Secure Entry Point (SEP) Flag</title>
|
|
<pubdate>April 2004</pubdate>
|
|
</biblioentry>
|
|
<biblioentry>
|
|
<abbrev>RFC3845</abbrev>
|
|
<authorgroup>
|
|
<author><personname><surname>Schlyter</surname><firstname>J.</firstname></personname></author>
|
|
</authorgroup>
|
|
<title>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</title>
|
|
<pubdate>August 2004</pubdate>
|
|
</biblioentry>
|
|
</bibliodiv>
|
|
</bibliography>
|
|
</section>
|
|
<section xml:id="internet_drafts"><title>Internet Drafts</title>
|
|
|
|
<para>
|
|
Internet Drafts (IDs) are rough-draft working documents of
|
|
the Internet Engineering Task Force. They are, in essence, RFCs
|
|
in the preliminary stages of development. Implementors are
|
|
cautioned not
|
|
to regard IDs as archival, and they should not be quoted or cited
|
|
in any formal documents unless accompanied by the disclaimer that
|
|
they are "works in progress." IDs have a lifespan of six months
|
|
after which they are deleted unless updated by their authors.
|
|
</para>
|
|
</section>
|
|
<section xml:id="more_about_bind"><info><title>Other Documents About <acronym>BIND</acronym></title></info>
|
|
|
|
<para/>
|
|
<bibliography><title/>
|
|
<biblioentry>
|
|
<authorgroup>
|
|
<author><personname><surname>Albitz</surname><firstname>Paul</firstname></personname></author>
|
|
<author><personname><firstname>Cricket</firstname><surname>Liu</surname></personname></author>
|
|
</authorgroup>
|
|
<title><acronym>DNS</acronym> and <acronym>BIND</acronym></title>
|
|
<copyright>
|
|
<year>1998</year>
|
|
<holder>Sebastopol, CA: O'Reilly and Associates</holder>
|
|
</copyright>
|
|
</biblioentry>
|
|
</bibliography>
|
|
</section>
|
|
</section>
|
|
</appendix>
|
|
|
|
<appendix xml:id="Bv9ARM.ch12"><info><title>BIND 9 DNS Library Support</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="libdns.xml"/>
|
|
</appendix>
|
|
|
|
<reference xml:id="Bv9ARM.ch13"><info><title>Manual pages</title></info>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/arpaname.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/confgen/ddns-confgen.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/delv/delv.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dig/dig.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/python/dnssec-checkds.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/python/dnssec-coverage.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-dsfromkey.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-importkey.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-keyfromlabel.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-keygen.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/python/dnssec-keymgr.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-revoke.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-settime.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-signzone.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-verify.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/dnstap-read.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/genrandom.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dig/host.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/isc-hmac-fixup.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/named/lwresd.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/mdig.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/check/named-checkconf.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/check/named-checkzone.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/named-journalprint.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/named-nzd2nzf.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/named-rrchecker.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/named/named.conf.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/named/named.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/nsec3hash.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dig/nslookup.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/nsupdate/nsupdate.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/pkcs11/pkcs11-destroy.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/pkcs11/pkcs11-keygen.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/pkcs11/pkcs11-list.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/pkcs11/pkcs11-tokens.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/confgen/rndc-confgen.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/rndc/rndc.conf.docbook"/>
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/rndc/rndc.docbook"/>
|
|
</reference>
|
|
|
|
</book>
|