Gecko [ www.utparral.edu.mx ]

Name	Size	Permission
_static	[ DIR ]	drwxr-xr-x
chapter10.html	22.05 KB	-rw-r--r--
chapter1.html	34.51 KB	-rw-r--r--
chapter2.html	15.73 KB	-rw-r--r--
chapter3.html	131.95 KB	-rw-r--r--
chapter4.html	48.77 KB	-rw-r--r--
chapter5.html	81.82 KB	-rw-r--r--
chapter6.html	145.29 KB	-rw-r--r--
chapter7.html	52.45 KB	-rw-r--r--
chapter9.html	18.56 KB	-rw-r--r--
dnssec-guide.html	436.46 KB	-rw-r--r--
general.html	46.95 KB	-rw-r--r--
genindex.html	203.17 KB	-rw-r--r--
history.html	9.97 KB	-rw-r--r--
index.html	28.49 KB	-rw-r--r--
manpages.html	803.05 KB	-rw-r--r--
notes.html	238.02 KB	-rw-r--r--
reference.html	1.4 MB	-rw-r--r--
search.html	5.21 KB	-rw-r--r--

Code Editor : chapter3.html

<!DOCTYPE html>
<html class="writer-html5" lang="en" >
<head>
 <meta charset="utf-8" /><meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" />

<body class="wy-body-for-nav"> 
 <div class="wy-grid-for-nav">
 <nav data-toggle="wy-nav-shift" class="wy-nav-side">
 <div class="wy-side-scroll">
 <div class="wy-side-nav-search" >
 <a href="index.html" class="icon icon-home"> BIND 9
 </a>
 <div class="version">
 9.18.39-0ubuntu0.22.04.2-Ubuntu
 </div>
<div role="search">
 <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
 <input type="text" name="q" placeholder="Search docs" />
 <input type="hidden" name="check_keywords" value="yes" />
 <input type="hidden" name="area" value="default" />
 </form>
</div>
 </div><div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu">
 <ul class="current">
<li class="toctree-l1"><a class="reference internal" href="chapter1.html">1. Introduction to DNS and BIND 9</a></li>
<li class="toctree-l1"><a class="reference internal" href="chapter2.html">2. Resource Requirements</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">3. Configurations and Zone Files</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#introduction">3.1. Introduction</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#named-conf-base-file">3.1.1. <code class="docutils literal notranslate">named.conf</code> Base File</a></li>
<li class="toctree-l3"><a class="reference internal" href="#example-com-base-zone-file">3.1.2. example.com base zone file</a></li>
<li class="toctree-l3"><a class="reference internal" href="#other-zone-files">3.1.3. Other Zone Files</a></li>
<li class="toctree-l3"><a class="reference internal" href="#localhost-zone-file">3.1.4. localhost Zone File</a></li>
<li class="toctree-l3"><a class="reference internal" href="#localhost-reverse-mapped-zone-file">3.1.5. localhost Reverse-Mapped Zone File</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#authoritative-name-servers">3.2. Authoritative Name Servers</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#primary-authoritative-name-server">3.2.1. Primary Authoritative Name Server</a></li>
<li class="toctree-l3"><a class="reference internal" href="#secondary-authoritative-name-server">3.2.2. Secondary Authoritative Name Server</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#resolver-caching-name-servers">3.3. Resolver (Caching Name Servers)</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#additional-zone-files">3.3.1. Additional Zone Files</a><ul>
<li class="toctree-l4"><a class="reference internal" href="#root-servers-hint-zone-file">3.3.1.1. Root Servers (Hint) Zone File</a></li>
<li class="toctree-l4"><a class="reference internal" href="#private-ip-reverse-map-zone-files">3.3.1.2. Private IP Reverse Map Zone Files</a></li>
</ul>
</li>
<li class="toctree-l3"><a class="reference internal" href="#resolver-configuration">3.3.2. Resolver Configuration</a></li>
<li class="toctree-l3"><a class="reference internal" href="#forwarding-resolver-configuration">3.3.3. Forwarding Resolver Configuration</a></li>
<li class="toctree-l3"><a class="reference internal" href="#selective-forwarding-resolver-configuration">3.3.4. Selective Forwarding Resolver Configuration</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#load-balancing">3.4. Load Balancing</a></li>
<li class="toctree-l2"><a class="reference internal" href="#soa-rr">3.5. Zone File</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#resource-records">3.5.1. Resource Records</a><ul>
<li class="toctree-l4"><a class="reference internal" href="#textual-expression-of-rrs">3.5.1.1. Textual Expression of RRs</a></li>
</ul>
</li>
<li class="toctree-l3"><a class="reference internal" href="#discussion-of-mx-records">3.5.2. Discussion of MX Records</a></li>
<li class="toctree-l3"><a class="reference internal" href="#setting-ttls">3.5.3. Setting TTLs</a></li>
<li class="toctree-l3"><a class="reference internal" href="#inverse-mapping-in-ipv4">3.5.4. Inverse Mapping in IPv4</a></li>
<li class="toctree-l3"><a class="reference internal" href="#other-zone-file-directives">3.5.5. Other Zone File Directives</a><ul>
<li class="toctree-l4"><a class="reference internal" href="#the-at-sign">3.5.5.1. The &#64; (at-sign)</a></li>
<li class="toctree-l4"><a class="reference internal" href="#the-origin-directive">3.5.5.2. The $ORIGIN Directive</a></li>
<li class="toctree-l4"><a class="reference internal" href="#the-include-directive">3.5.5.3. The $INCLUDE Directive</a></li>
<li class="toctree-l4"><a class="reference internal" href="#the-ttl-directive">3.5.5.4. The $TTL Directive</a></li>
</ul>
</li>
<li class="toctree-l3"><a class="reference internal" href="#bind-primary-file-extension-the-generate-directive">3.5.6. BIND Primary File Extension: the $GENERATE Directive</a></li>
<li class="toctree-l3"><a class="reference internal" href="#additional-file-formats">3.5.7. Additional File Formats</a></li>
</ul>
</li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="chapter4.html">4. Name Server Operations</a></li>
<li class="toctree-l1"><a class="reference internal" href="chapter5.html">5. DNSSEC</a></li>
<li class="toctree-l1"><a class="reference internal" href="chapter6.html">6. Advanced Configurations</a></li>
<li class="toctree-l1"><a class="reference internal" href="chapter7.html">7. Security Configurations</a></li>
<li class="toctree-l1"><a class="reference internal" href="reference.html">8. Configuration Reference</a></li>
<li class="toctree-l1"><a class="reference internal" href="chapter9.html">9. Troubleshooting</a></li>
<li class="toctree-l1"><a class="reference internal" href="chapter10.html">10. Building BIND 9</a></li>
</ul>
Appendices
<ul>
<li class="toctree-l1"><a class="reference internal" href="notes.html">Release Notes</a></li>
<li class="toctree-l1"><a class="reference internal" href="changelog.html">Changelog</a></li>
<li class="toctree-l1"><a class="reference internal" href="dnssec-guide.html">DNSSEC Guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="history.html">A Brief History of the DNS and BIND</a></li>
<li class="toctree-l1"><a class="reference internal" href="general.html">General DNS Reference Information</a></li>
<li class="toctree-l1"><a class="reference internal" href="manpages.html">Manual Pages</a></li>
</ul>

</div>
 </div>
 </nav>

<div class="wy-nav-content">
 <div class="rst-content">
 <div role="navigation" aria-label="Page navigation">
 <ul class="wy-breadcrumbs">
 <li><a href="index.html" class="icon icon-home"></a> &raquo;</li>
 <li>3. Configurations and Zone Files</li>
 <li class="wy-breadcrumbs-aside">
 <a href="_sources/chapter3.rst.txt" rel="nofollow"> View page source</a>
 </li>
 </ul>
 <hr/>
</div>
 <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
 <div itemprop="articleBody">
 
 <section id="configurations-and-zone-files">
<h1>3. Configurations and Zone Files<a class="headerlink" href="#configurations-and-zone-files" title="Permalink to this headline"></a></h1>
<section id="introduction">
<h2>3.1. Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline"></a></h2>
BIND 9 uses a single configuration file called <a class="reference internal" href="reference.html#named-conf">named.conf</a>.
which is typically located in either /etc/namedb or
/usr/local/etc/namedb.
<blockquote>
<div><div class="admonition note">
Note
If <a class="reference internal" href="chapter4.html#ops-rndc">rndc</a> is being used locally (on the same host
as BIND 9) then an additional file <a class="reference internal" href="manpages.html#std-iscman-rndc.conf"><code class="xref std std-iscman docutils literal notranslate">rndc.conf</code></a> may be present, though
<a class="reference internal" href="manpages.html#std-iscman-rndc"><code class="xref std std-iscman docutils literal notranslate">rndc</code></a> operates without this file. If <a class="reference internal" href="manpages.html#std-iscman-rndc"><code class="xref std std-iscman docutils literal notranslate">rndc</code></a> is being run
from a remote host then an <a class="reference internal" href="manpages.html#std-iscman-rndc.conf"><code class="xref std std-iscman docutils literal notranslate">rndc.conf</code></a> file must be present as it
defines the link characteristics and properties.
</div>
</div></blockquote>
Depending on the functionality of the system, one or more zone files is
required.
The samples given throughout this and subsequent chapters use a standard base
format for both the <a class="reference internal" href="manpages.html#std-iscman-named.conf"><code class="xref std std-iscman docutils literal notranslate">named.conf</code></a> and the zone files for example.com. The
intent is for the reader to see the evolution from a common base as features
are added or removed.
<section id="named-conf-base-file">
<h3>3.1.1. <code class="docutils literal notranslate">named.conf</code> Base File<a class="headerlink" href="#named-conf-base-file" title="Permalink to this headline"></a></h3>
This file illustrates the typical format and layout style used for
<a class="reference internal" href="manpages.html#std-iscman-named.conf"><code class="xref std std-iscman docutils literal notranslate">named.conf</code></a> and provides a basic logging service, which may be extended
as required by the user.
<div class="highlight-c notranslate"><div class="highlight"><pre>// base named.conf file
// Recommended that you always maintain a change log in this file as shown here
// options clause defining the server-wide properties
options {
 // all relative paths use this directory as a base
 directory &quot;/var&quot;;
 // version statement for security to avoid hacking known weaknesses
 // if the real version number is revealed
 version &quot;not currently available&quot;;
};

// logging clause
// log to /var/log/named/example.log all events from info UP in severity (no debug)
// uses 3 files in rotation swaps files when size reaches 250K
// failure messages that occur before logging is established are
// in syslog (/var/log/messages)
//
logging {
 channel example_log {
 // uses a relative path name and the directory statement to
 // expand to /var/log/named/example.log
 file &quot;log/named/example.log&quot; versions 3 size 250k;
 // only log info and up messages - all others discarded
 severity info;
 };
 category default {
 example_log;
 };
};
</pre></div>
</div>
The <a class="reference internal" href="reference.html#namedconf-statement-logging" title="namedconf-statement-logging"><code class="xref any namedconf namedconf-ref docutils literal notranslate">logging</code></a> and <a class="reference internal" href="reference.html#namedconf-statement-options" title="namedconf-statement-options"><code class="xref namedconf namedconf-ref docutils literal notranslate">options</code></a> blocks
and <a class="reference internal" href="reference.html#namedconf-statement-category" title="namedconf-statement-category"><code class="xref any namedconf namedconf-ref docutils literal notranslate">category</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-channel" title="namedconf-statement-channel"><code class="xref any namedconf namedconf-ref docutils literal notranslate">channel</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-directory" title="namedconf-statement-directory"><code class="xref any namedconf namedconf-ref docutils literal notranslate">directory</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-file" title="namedconf-statement-file"><code class="xref any namedconf namedconf-ref docutils literal notranslate">file</code></a>, and <a class="reference internal" href="reference.html#namedconf-statement-severity" title="namedconf-statement-severity"><code class="xref any namedconf namedconf-ref docutils literal notranslate">severity</code></a>
statements are all described further in the appropriate sections of this ARM.
</section>
<section id="example-com-base-zone-file">
<h3>3.1.2. example.com base zone file<a class="headerlink" href="#example-com-base-zone-file" title="Permalink to this headline"></a></h3>
The following is a complete zone file for the domain example.com, which
illustrates a number of common features. Comments in the file explain these
features where appropriate. Zone files consist of <a class="reference internal" href="#zone-file">Resource Records (RR)</a>, which describe the zone’s characteristics or properties.
<div class="highlight-none notranslate"><div class="highlight"><pre> 1; base zone file for example.com
 2$TTL 2d ; default TTL for zone
 3$ORIGIN example.com. ; base domain-name
 4; Start of Authority RR defining the key characteristics of the zone (domain)
 5@ IN SOA ns1.example.com. hostmaster.example.com. (
 6 2003080800 ; serial number
 7 12h ; refresh
 8 15m ; update retry
 9 3w ; expiry
10 2h ; minimum
11 )
12; name server RR for the domain
13 IN NS ns1.example.com.
14; the second name server is external to this zone (domain)
15 IN NS ns2.example.net.
16; mail server RRs for the zone (domain)
17 3w IN MX 10 mail.example.com.
18; the second mail servers is external to the zone (domain)
19 IN MX 20 mail.example.net.
20; domain hosts includes NS and MX records defined above
21; plus any others required
22; for instance a user query for the A RR of joe.example.com will
23; return the IPv4 address 192.168.254.6 from this zone file
24ns1 IN A 192.168.254.2
25mail IN A 192.168.254.4
26joe IN A 192.168.254.6
27www IN A 192.168.254.7
28; aliases ftp (ftp server) to an external domain
29ftp IN CNAME ftp.example.net.
</pre></div>
</div>
This type of zone file is frequently referred to as a forward-mapped zone
file, since it maps domain names to some other value, while a
<a class="reference internal" href="#ipv4-reverse">reverse-mapped zone file</a> maps an IP address to a domain
name. The zone file is called example.com for no good reason except that
it is the domain name of the zone it describes; as always, users are free to
use whatever file-naming convention is appropriate to their needs.
</section>
<section id="other-zone-files">
<h3>3.1.3. Other Zone Files<a class="headerlink" href="#other-zone-files" title="Permalink to this headline"></a></h3>
Depending on the configuration additional zone files may or should be present.
Their format and functionality are briefly described here.
</section>
<section id="localhost-zone-file">
<h3>3.1.4. localhost Zone File<a class="headerlink" href="#localhost-zone-file" title="Permalink to this headline"></a></h3>
All end-user systems are shipped with a <code class="docutils literal notranslate">hosts</code> file (usually located in
/etc). This file is normally configured to map the name localhost (the name
used by applications when they run locally) to the loopback address. It is
argued, reasonably, that a forward-mapped zone file for localhost is
therefore not strictly required. This manual does use the BIND 9 distribution
file <code class="docutils literal notranslate">localhost-forward.db</code> (normally in /etc/namedb/master or
/usr/local/etc/namedb/master) in all configuration samples for the following
reasons:
<ol class="arabic simple">
<li>Many users elect to delete the <code class="docutils literal notranslate">hosts</code> file for security reasons (it is a
potential target of serious domain name redirection/poisoning attacks).</li>
<li>Systems normally lookup any name (including domain names) using the
<code class="docutils literal notranslate">hosts</code> file first (if present), followed by DNS. However, the
<code class="docutils literal notranslate">nsswitch.conf</code> file (typically in /etc) controls this order (normally
hosts: file dns), allowing the order to be changed or the file value
to be deleted entirely depending on local needs. Unless the BIND
administrator controls this file and knows its values, it is unsafe to
assume that localhost is forward-mapped correctly.</li>
<li>As a reminder to users that unnecessary queries for localhost form a
non-trivial volume of DNS queries on the public network, which affects DNS
performance for all users.</li>
</ol>
Users may, however, elect at their discretion not to implement this file since,
depending on the operational environment, it may not be essential.
The BIND 9 distribution file <code class="docutils literal notranslate">localhost-forward.db</code> format is shown for
completeness and provides for both IPv4 and IPv6 localhost resolution. The zone
(domain) name is localhost.
<div class="highlight-none notranslate"><div class="highlight"><pre>$TTL 3h
localhost. SOA localhost. nobody.localhost. 42 1d 12h 1w 3h
 NS localhost.
 A 127.0.0.1
 AAAA ::1
</pre></div>
</div>
<div class="admonition note">
Note
Readers of a certain age or disposition may note the reference in this file to the late,
lamented Douglas Noel Adams.
</div>
</section>
<section id="localhost-reverse-mapped-zone-file">
<h3>3.1.5. localhost Reverse-Mapped Zone File<a class="headerlink" href="#localhost-reverse-mapped-zone-file" title="Permalink to this headline"></a></h3>
This zone file allows any query requesting the name associated with the
loopback IP (127.0.0.1). This file is required to prevent unnecessary queries
from reaching the public DNS hierarchy. The BIND 9 distribution file
<code class="docutils literal notranslate">localhost.rev</code> is shown for completeness:
<div class="highlight-none notranslate"><div class="highlight"><pre>$TTL 1D
@ IN SOA localhost. root.localhost. (
 2007091701 ; serial
 30800 ; refresh
 7200 ; retry
 604800 ; expire
 300 ) ; minimum
 IN NS localhost.
1 IN PTR localhost.
</pre></div>
</div>
</section>
</section>
<section id="authoritative-name-servers">
<h2>3.2. Authoritative Name Servers<a class="headerlink" href="#authoritative-name-servers" title="Permalink to this headline"></a></h2>
These provide authoritative answers to user queries for the zones
they support: for instance, the zone data describing the domain name example.com. An
authoritative name server may support one or many zones.
Each zone may be defined as either a primary or a secondary. A primary zone
reads its zone data directly from a file system. A secondary zone obtains its zone
data from the primary zone using a process called zone transfer. Both the primary
and the secondary zones provide authoritative data for their zone; there is no difference
in the answer to a query from a primary or a secondary zone. An authoritative name server
may support any combination of primary and secondary zones.
<div class="admonition note">
Note
The terms primary and secondary do not imply any access
priority. Resolvers (name servers that provide the complete answers to user
queries) are not aware of (and cannot find out) whether an authoritative
answer comes from the primary or secondary name server. Instead, the
resolver uses the list of authoritative servers for the zone (there must be
at least two) and maintains a Round Trip Time (RTT) - the time taken to
respond to the query - for each server in the list. The resolver uses the
lowest-value server (the fastest) as its preferred server for the zone and
continues to do so until its RTT becomes higher than the next slowest in its
list, at which time that one becomes the preferred server.
For reasons of backward compatibility BIND 9 treats “primary” and “master” as
synonyms, as well as “secondary” and “slave.”
</div>
The following diagram shows the relationship between the primary and secondary
name servers. The text below explains the process in detail.
<figure class="align-center" id="id4">
<img alt="_images/primary-secondary.png" src="_images/primary-secondary.png" />
<figcaption>
Authoritative Primary and Secondary Name Servers<a class="headerlink" href="#id4" title="Permalink to this image"></a>
</figcaption>
</figure>
The numbers in parentheses in the following text refer to the numbered items in the diagram above.
<ol class="arabic simple">
<li>The authoritative primary name server always loads (or reloads) its zone
files from (1) a local or networked filestore.</li>
<li>The authoritative secondary name server always loads its zone data from a
primary via a zone transfer operation. Zone transfer may use AXFR
(complete zone transfer) or IXFR (incremental zone transfer), but only
if both primary and secondary name servers support the service. The zone
transfer process (either AXFR or IXFR) works as follows:
<ol class="loweralpha simple">
<li>The secondary name server for the zone reads (3 and 4) the
<a class="reference internal" href="#soa-rr">SOA RR</a> periodically. The interval is defined by the refresh
parameter of the Start of Authority (SOA) RR.</li>
<li>The secondary compares the serial number parameter of the SOA RR
received from the primary with the serial number in the SOA RR of its
current zone data.</li>
<li>If the received serial number is arithmetically greater (higher) than the
current one, the secondary initiates a zone transfer (5) using AXFR or IXFR
(depending on the primary and secondary configuration), using TCP over
port 53 (6).</li>
</ol>
</li>
<li>The typically recommended zone refresh times for the SOA RR (the time
interval when the secondary reads or polls the primary for the zone SOA RR)
are multiples of hours to reduce traffic loads. Worst-case zone change
propagation can therefore take extended periods.</li>
<li>The optional NOTIFY (<a class="rfc reference external" href="https://tools.ietf.org/html/rfc1996.html">RFC 1996</a>) feature (2) is automatically configured;
use the <a class="reference internal" href="reference.html#namedconf-statement-notify" title="namedconf-statement-notify"><code class="xref namedconf namedconf-ref docutils literal notranslate">notify</code></a> statement to turn off the feature.
Whenever the primary loads or reloads a zone, it sends a NOTIFY message to
the configured secondary (or secondaries) and may optionally be configured
to send the NOTIFY message to other hosts using the
<a class="reference internal" href="reference.html#namedconf-statement-also-notify" title="namedconf-statement-also-notify"><code class="xref any namedconf namedconf-ref docutils literal notranslate">also-notify</code></a> statement. The NOTIFY message simply
indicates to the secondary that the primary has loaded or reloaded the zone.
On receipt of the NOTIFY message, the secondary respons to indicate it has received the NOTIFY and immediately reads the SOA RR
from the primary (as described in section 2 a. above). If the zone file has
changed, propagation is practically immediate.</li>
</ol>
The authoritative samples all use NOTIFY but identify the statements used, so
that they can be removed if not required.
<section id="primary-authoritative-name-server">
<h3>3.2.1. Primary Authoritative Name Server<a class="headerlink" href="#primary-authoritative-name-server" title="Permalink to this headline"></a></h3>
The zone files are unmodified <a class="reference internal" href="#base-zone-file">from the base samples</a> but
the <a class="reference internal" href="manpages.html#std-iscman-named.conf"><code class="xref std std-iscman docutils literal notranslate">named.conf</code></a> file has been modified as shown:
<div class="highlight-c notranslate"><div class="highlight"><pre>// authoritative primary named.conf file
// options clause defining the server-wide properties
options {
 // all relative paths use this directory as a base
 directory &quot;/var&quot;;
 // version statement for security to avoid hacking known weaknesses
 // if the real version number is revealed
 version &quot;not currently available&quot;;
 // This is the default - allows user queries from any IP
 allow-query { any; };
 // normal server operations may place items in the cache
 // this prevents any user query from accessing these items
 // only authoritative zone data will be returned
 allow-query-cache { none; };
 // Do not provide recursive service to user queries
 recursion no;
};
// logging clause
// log to /var/log/named/example.log all events from info UP in severity (no debug)
// uses 3 files in rotation swaps files when size reaches 250K
// failure messages that occur before logging is established are
// in syslog (/var/log/messages)
//
logging {
 channel example_log {
 // uses a relative path name and the directory statement to
 // expand to /var/log/named/example.log
 file &quot;log/named/example.log&quot; versions 3 size 250k;
 // only log info and up messages - all others discarded
 severity info;
 };
 category default {
 example_log;
 };
};
// Provide forward mapping zone for localhost
// (optional)
zone &quot;localhost&quot; {
 type primary;
 file &quot;master/localhost-forward.db&quot;;
 notify no;
};
// Provide reverse mapping zone for the loopback
// address 127.0.0.1
zone &quot;0.0.127.in-addr.arpa&quot; {
 type primary;
 file &quot;localhost.rev&quot;;
 notify no;
};
// We are the primary server for example.com
zone &quot;example.com&quot; {
 // this is the primary name server for the zone
 type primary;
 file &quot;example.com&quot;;
 // this is the default
 notify yes;
 // IP addresses of secondary servers allowed to
 // transfer example.com from this server
 allow-transfer {
 192.168.4.14;
 192.168.5.53;
 };
};
</pre></div>
</div>
The added statements and blocks are commented in the above file.
The <a class="reference internal" href="reference.html#namedconf-statement-zone" title="namedconf-statement-zone"><code class="xref any namedconf namedconf-ref docutils literal notranslate">zone</code></a> block, and <a class="reference internal" href="reference.html#namedconf-statement-allow-query" title="namedconf-statement-allow-query"><code class="xref any namedconf namedconf-ref docutils literal notranslate">allow-query</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-allow-query-cache" title="namedconf-statement-allow-query-cache"><code class="xref any namedconf namedconf-ref docutils literal notranslate">allow-query-cache</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-allow-transfer" title="namedconf-statement-allow-transfer"><code class="xref any namedconf namedconf-ref docutils literal notranslate">allow-transfer</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-file" title="namedconf-statement-file"><code class="xref any namedconf namedconf-ref docutils literal notranslate">file</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-notify" title="namedconf-statement-notify"><code class="xref namedconf namedconf-ref docutils literal notranslate">notify</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-recursion" title="namedconf-statement-recursion"><code class="xref any namedconf namedconf-ref docutils literal notranslate">recursion</code></a>, and <a class="reference internal" href="reference.html#namedconf-statement-type" title="namedconf-statement-type"><code class="xref any namedconf namedconf-ref docutils literal notranslate">type</code></a>
statements are described in detail in the appropriate sections.
</section>
<section id="secondary-authoritative-name-server">
<h3>3.2.2. Secondary Authoritative Name Server<a class="headerlink" href="#secondary-authoritative-name-server" title="Permalink to this headline"></a></h3>
The zone files <code class="docutils literal notranslate">local-host-forward.db</code> and <code class="docutils literal notranslate">localhost.rev</code> are unmodified
<a class="reference internal" href="#base-zone-file">from the base samples</a>. The example.com zone file is
not required (the zone file is obtained from the primary via zone transfer).
The <a class="reference internal" href="reference.html#named-conf">named.conf</a> file has been modified as shown:
<div class="highlight-c notranslate"><div class="highlight"><pre>// authoritative secondary named.conf file
// options clause defining the server-wide properties
options {
 // all relative paths use this directory as a base
 directory &quot;/var&quot;;
 // version statement for security to avoid hacking known weaknesses
 // if the real version number is revealed
 version &quot;not currently available&quot;;
 // This is the default - allows user queries from any IP
 allow-query { any; };
 // normal server operations may place items in the cache
 // this prevents any user query from accessing these items
 // only authoritative zone data will be returned
 allow-query-cache { none; };
 // Do not provide recursive service to user queries
 recursion no;
};
// logging clause
// log to /var/log/named/example.log all events from info UP in severity (no debug)
// uses 3 files in rotation swaps files when size reaches 250K
// failure messages that occur before logging is established are
// in syslog (/var/log/messages)
//
logging {
 channel example_log {
 // uses a relative path name and the directory statement to
 // expand to /var/log/named/example.log
 file &quot;log/named/example.log&quot; versions 3 size 250k;
 // only log info and up messages - all others discarded
 severity info;
 };
 category default {
 example_log;
 };
};
// Provide forward mapping zone for localhost
// (optional)
zone &quot;localhost&quot; {
 type primary;
 file &quot;master/localhost-forward.db&quot;;
 notify no;
};
// Provide reverse mapping zone for the loopback
// address 127.0.0.1
zone &quot;0.0.127.in-addr.arpa&quot; {
 type primary;
 file &quot;localhost.rev&quot;;
 notify no;
};
// We are the secondary server for example.com
zone &quot;example.com&quot; {
 // this is a secondary server for the zone
 type secondary;
 // the file statement here allows the secondary to save
 // each zone transfer so that in the event of a program restart
 // the zone can be loaded immediately and the server can start
 // to respond to queries without waiting for a zone transfer
 file &quot;example.com.saved&quot;;
 // IP address of example.com primary server
 primaries { 192.168.254.2; };
};
</pre></div>
</div>
The statements and blocks added are all commented in the above file.
The <a class="reference internal" href="reference.html#namedconf-statement-zone" title="namedconf-statement-zone"><code class="xref any namedconf namedconf-ref docutils literal notranslate">zone</code></a> block, and <a class="reference internal" href="reference.html#namedconf-statement-allow-query" title="namedconf-statement-allow-query"><code class="xref any namedconf namedconf-ref docutils literal notranslate">allow-query</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-allow-query-cache" title="namedconf-statement-allow-query-cache"><code class="xref any namedconf namedconf-ref docutils literal notranslate">allow-query-cache</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-allow-transfer" title="namedconf-statement-allow-transfer"><code class="xref any namedconf namedconf-ref docutils literal notranslate">allow-transfer</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-file" title="namedconf-statement-file"><code class="xref any namedconf namedconf-ref docutils literal notranslate">file</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-primaries" title="namedconf-statement-primaries"><code class="xref namedconf namedconf-ref docutils literal notranslate">primaries</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-recursion" title="namedconf-statement-recursion"><code class="xref any namedconf namedconf-ref docutils literal notranslate">recursion</code></a>, and <a class="reference internal" href="reference.html#namedconf-statement-type" title="namedconf-statement-type"><code class="xref any namedconf namedconf-ref docutils literal notranslate">type</code></a> statements are described in
detail in the appropriate sections.
If NOTIFY is not being used, no changes are required in this
<a class="reference internal" href="reference.html#named-conf">named.conf</a> file, since it is the primary that initiates the NOTIFY
message.
<div class="admonition note">
Note
Just when the reader thought they understood primary and secondary, things
can get more complicated. A secondary zone can also be a primary to other
secondaries: <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</code></a>, by default, sends NOTIFY messages for every
zone it loads. Specifying <a class="reference internal" href="chapter6.html#notify">notify primary-only;</a> in the
<a class="reference internal" href="reference.html#namedconf-statement-zone" title="namedconf-statement-zone"><code class="xref any namedconf namedconf-ref docutils literal notranslate">zone</code></a> block for the secondary causes <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</code></a> to
only send NOTIFY messages for primary zones that it loads.
</div>
</section>
</section>
<section id="resolver-caching-name-servers">
<h2>3.3. Resolver (Caching Name Servers)<a class="headerlink" href="#resolver-caching-name-servers" title="Permalink to this headline"></a></h2>
Resolvers handle <a class="reference internal" href="chapter1.html#recursive-query">recursive user queries</a> and provide
complete answers; that is, they issue one or more <a class="reference internal" href="chapter1.html#iterative-query">iterative queries</a> to the DNS hierarchy. Having obtained a complete answer (or
an error), a resolver passes the answer to the user and places it in its cache.
Subsequent user requests for the same query will be answered from the
resolver’s cache until the <a class="reference internal" href="#term-TTL">TTL</a> of the cached answer has expired, when
it will be flushed from the cache; the next user query that requests the same
information results in a new series of queries to the DNS hierarchy.
Resolvers are frequently referred to by a bewildering variety of names,
including caching name servers, recursive name servers, forwarding resolvers,
area resolvers, and full-service resolvers.
The following diagram shows how resolvers can function in a typical networked
environment:
<figure class="align-center">
<img alt="_images/resolver-forward.png" src="_images/resolver-forward.png" />
</figure>
Resolver and Forwarding Resolver
<ol class="arabic simple">
<li>End-user systems are all distributed with a local stub resolver as a
standard feature. Today, the majority of stub resolvers also provide a local
cache service to speed up user response times.</li>
<li>A stub resolver has limited functionality; specifically, it cannot follow
<a class="reference internal" href="chapter1.html#referral">referrals</a>. When a stub resolver receives a request for a
name from a local program, such as a browser, and the answer is not in its
local cache, it sends a <a class="reference internal" href="chapter1.html#recursive-query">recursive user query</a> (1) to
a locally configured resolver (5), which may have the answer available in
its cache. If it does not, it issues <a class="reference internal" href="chapter1.html#iterative-query">iterative
queries</a> (2) to the DNS hierarchy to obtain the answer. The
resolver to which the local system sends the user query is configured, for
Linux and Unix hosts, in <code class="docutils literal notranslate">/etc/resolv.conf</code>; for Windows users it is
configured or changed via the Control Panel or Settings interface.</li>
<li>Alternatively, the user query can be sent to a forwarding resolver (4).
Forwarding resolvers on first glance look fairly pointless, since they
appear to be acting as a simple pass-though and, like the stub resolver,
require a full-service resolver (5). However, forwarding resolvers can be
very powerful additions to a network for the following reasons:
<ol class="loweralpha simple">
<li>Cost and Performance. Each recursive user query (1) at the forwarding
resolver (4) results in two messages - the query and its answer. The resolver
(5) may have to issue three, four, or more query pairs (2) to get the required
answer. Traffic is reduced dramatically, increasing performance or reducing
cost (if the link is tariffed). Additionally, since the forwarding resolver is
typically shared across multiple hosts, its cache is more likely to contain
answers, again improving user performance.</li>
<li>Network Maintenance. Forwarding resolvers (4) can be used to ease the burden
of local administration by providing a single point at which changes to remote
name servers can be managed, rather than having to update all hosts. Thus, all
hosts in a particular network section or area can be configured to point to a
forwarding resolver, which can be configured to stream DNS traffic as desired
and changed over time with minimal effort.</li>
<li>Sanitizing Traffic. Especially in larger private networks it may be sensible
to stream DNS traffic using a forwarding resolver structure. The forwarding
resolver (4) may be configured, for example, to handle all in-domain traffic
(relatively safe) and forward all external traffic to a hardened resolver
(5).</li>
<li>Stealth Networks. Forwarding resolvers are extensively used in <a class="reference internal" href="chapter6.html#split-dns-sample">stealth
or split networks</a>.</li>
</ol>
</li>
<li>Forwarding resolvers (4) can be configured to forward all traffic to a
resolver (5), or to only forward selective traffic (5) while directly
resolving other traffic (3).</li>
</ol>
<div class="admonition attention">
Attention
While the diagram above shows recursive user queries
arriving via interface (1), there is nothing to stop them from arriving via
interface (2) via the public network. If no limits are placed on the source
IPs that can send such queries, the resolver is termed an open resolver.
Indeed, when the world was young this was the way things worked on the
Internet. Much has changed and what seems to be a friendly, generous action
can be used by rogue actors to cause all kinds of problems including
Denial of Service (DoS) attacks. Resolvers should always be configured
to limit the IP addresses that can use their services. BIND 9 provides a
number of statements and blocks to simplify defining these IP limits and
configuring a closed resolver. The resolver samples given here all
configure closed resolvers using a variety of techniques.
</div>
<section id="additional-zone-files">
<h3>3.3.1. Additional Zone Files<a class="headerlink" href="#additional-zone-files" title="Permalink to this headline"></a></h3>
<section id="root-servers-hint-zone-file">
<h4>3.3.1.1. Root Servers (Hint) Zone File<a class="headerlink" href="#root-servers-hint-zone-file" title="Permalink to this headline"></a></h4>
Resolvers (although not necessarily forwarding resolvers) need to access the
DNS hierarchy. To do this, they need to know the addresses (IPv4 and/or IPv6)
of the 13 <a class="reference internal" href="chapter1.html#root-servers">root servers</a>. This is done by the provision of a
root server zone file, which is contained in the standard BIND 9 distribution
as the file <code class="docutils literal notranslate">named.root</code> (normally found in /etc/namedb or
/usr/local/namedb). This file may also be obtained from the IANA website
(<a class="reference external" href="https://www.iana.org/domains/root/files">https://www.iana.org/domains/root/files</a>).
<blockquote>
<div><div class="admonition note">
Note
Many distributions rename this file for historical reasons.
Consult the appropriate distribution documentation for the actual file name.
</div>
</div></blockquote>
The hint zone file is referenced using the <a class="reference internal" href="reference.html#namedconf-statement-type hint" title="namedconf-statement-type hint"><code class="xref any namedconf namedconf-ref docutils literal notranslate">type hint</code></a> statement and
a zone (domain) name of “.” (the generally silent dot).
<blockquote>
<div><div class="admonition note">
Note
The root server IP addresses have been stable for a number of
years and are likely to remain stable for the near future. BIND 9 has a
root-server list in its executable such that even if this file is omitted,
out-of-date, or corrupt BIND 9 can still function. For this reason, many
sample configurations omit the hints file. All the samples given here
include the hints file primarily as a reminder of the functionality of the
configuration, rather than as an absolute necessity.
</div>
</div></blockquote>
</section>
<section id="private-ip-reverse-map-zone-files">
<h4>3.3.1.2. Private IP Reverse Map Zone Files<a class="headerlink" href="#private-ip-reverse-map-zone-files" title="Permalink to this headline"></a></h4>
Resolvers are configured to send <a class="reference internal" href="chapter1.html#iterative-query">iterative queries</a> to
the public DNS hierarchy when the information requested is not in their cache
or not defined in any local zone file. Many networks make extensive use of
private IP addresses (defined by <a class="rfc reference external" href="https://tools.ietf.org/html/rfc1918.html">RFC 1918</a>, <a class="rfc reference external" href="https://tools.ietf.org/html/rfc2193.html">RFC 2193</a>, <a class="rfc reference external" href="https://tools.ietf.org/html/rfc5737.html">RFC 5737</a>, and
<a class="rfc reference external" href="https://tools.ietf.org/html/rfc6598.html">RFC 6598</a>). By their nature these IP addresses are forward-mapped in various
user zone files. However, certain applications may issue reverse map
queries (mapping an IP address to a name). If the private IP addresses are not
defined in one or more reverse-mapped zone file(s), the resolver sends them to
the DNS hierarchy where they are simply useless traffic, slowing down DNS
responses for all users.
Private IP addresses may be defined using standard <a class="reference internal" href="#ipv4-reverse">reverse-mapping
techniques</a> or using the
<a class="reference internal" href="reference.html#namedconf-statement-empty-zones-enable" title="namedconf-statement-empty-zones-enable"><code class="xref any namedconf namedconf-ref docutils literal notranslate">empty-zones-enable</code></a> statement. By
default this statement is set to <code class="docutils literal notranslate">empty-zones-enable yes;</code> and thus automatically prevents
unnecessary DNS traffic by sending an NXDOMAIN error response (indicating the
name does not exist) to any request. However, some applications may require a
genuine answer to such reverse-mapped requests or they will fail to function.
Mail systems in particular perform reverse DNS queries as a first-line spam
check; in this case a reverse-mapped zone file is essential. The sample
configuration files given here for both the resolver and the forwarding
resolver provide a reverse-mapping zone file for the private IP address
192.168.254.4, which is the mail server address in the <a class="reference internal" href="#base-zone-file">base zone
file</a>, as an illustration of the reverse-map technique. The
file is named <code class="docutils literal notranslate">192.168.254.rev</code> and has a zone name of
254.168.192.in-addr.arpa.
<div class="highlight-none notranslate"><div class="highlight"><pre>; reverse map zone file for 192.168.254.4 only
$TTL 2d ; 172800 seconds
$ORIGIN 254.168.192.IN-ADDR.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. (
 2003080800 ; serial number
 3h ; refresh
 15m ; update retry
 3w ; expiry
 3h ; nx = nxdomain ttl
 )
; only one NS is required for this local file
; and is an out of zone name
 IN NS ns1.example.com.
; other IP addresses can be added as required
; this maps 192.168.254.4 as shown
4 IN PTR mail.example.com. ; fully qualified domain name (FQDN)
</pre></div>
</div>
</section>
</section>
<section id="resolver-configuration">
<h3>3.3.2. Resolver Configuration<a class="headerlink" href="#resolver-configuration" title="Permalink to this headline"></a></h3>
The resolver provides <a class="reference internal" href="chapter1.html#recursive-query">recursive query support</a> to a defined set of IP addresses.
It is therefore a closed resolver and cannot be used in wider network attacks.
<div class="highlight-c notranslate"><div class="highlight"><pre>// resolver named.conf file
// Two corporate subnets we wish to allow queries from
// defined in an acl clause
acl corpnets {
 192.168.4.0/24;
 192.168.7.0/24;
};

// options clause defining the server-wide properties
options {
 // all relative paths use this directory as a base
 directory &quot;/var&quot;;
 // version statement for security to avoid hacking known weaknesses
 // if the real version number is revealed
 version &quot;not currently available&quot;;
 // this is the default
 recursion yes;
 // recursive queries only allowed from these ips
 // and references the acl clause
 allow-query { corpnets; };
 // this ensures that any reverse map for private IPs
 // not defined in a zone file will *not* be passed to the public network
 // it is the default value
 empty-zones-enable yes;
};

// zone file for the root servers
// discretionary zone (see root server discussion above)
zone &quot;.&quot; {
 type hint;
 file &quot;named.root&quot;;
};

// zone file for the localhost forward map
// discretionary zone depending on hosts file (see discussion)
zone &quot;localhost&quot; {
 type primary;
 file &quot;masters/localhost-forward.db&quot;;
 notify no;
};

// zone file for the loopback address
// necessary zone
zone &quot;0.0.127.in-addr.arpa&quot; {
 type primary;
 file &quot;localhost.rev&quot;;
 notify no;
};

// hints zone file is not required

// forwarding is not global but selective by zone in this configuration
};

// zone file for local IP reverse map
// discretionary file depending on requirements
zone &quot;254.168.192.in-addr.arpa&quot; {
 type primary;
 file &quot;192.168.254.rev&quot;;
 notify no;
};
// zone file forwarded example.com
zone &quot;example.com&quot; {
 type forward;
 // this defines the addresses of the resolvers to
 // which queries for this zone will be forwarded
 forwarders {
 192.168.250.3;
 192.168.230.27;
 };
 // indicates all queries for this zone will be forwarded
 forward only;
};
</pre></div>
</div>
The <a class="reference internal" href="reference.html#namedconf-statement-zone" title="namedconf-statement-zone"><code class="xref any namedconf namedconf-ref docutils literal notranslate">zone</code></a> and <a class="reference internal" href="reference.html#namedconf-statement-acl" title="namedconf-statement-acl"><code class="xref any namedconf namedconf-ref docutils literal notranslate">acl</code></a> blocks, and the
<a class="reference internal" href="reference.html#namedconf-statement-allow-query" title="namedconf-statement-allow-query"><code class="xref any namedconf namedconf-ref docutils literal notranslate">allow-query</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-empty-zones-enable" title="namedconf-statement-empty-zones-enable"><code class="xref any namedconf namedconf-ref docutils literal notranslate">empty-zones-enable</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-file" title="namedconf-statement-file"><code class="xref any namedconf namedconf-ref docutils literal notranslate">file</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-forward" title="namedconf-statement-forward"><code class="xref any namedconf namedconf-ref docutils literal notranslate">forward</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-forwarders" title="namedconf-statement-forwarders"><code class="xref any namedconf namedconf-ref docutils literal notranslate">forwarders</code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-notify" title="namedconf-statement-notify"><code class="xref namedconf namedconf-ref docutils literal notranslate">notify</code></a>, <a class="reference internal" href="reference.html#namedconf-statement-recursion" title="namedconf-statement-recursion"><code class="xref any namedconf namedconf-ref docutils literal notranslate">recursion</code></a>, and <a class="reference internal" href="reference.html#namedconf-statement-type" title="namedconf-statement-type"><code class="xref any namedconf namedconf-ref docutils literal notranslate">type</code></a>
statements are described in detail in the appropriate sections.
As a reminder, the configuration of this resolver does not access the DNS
hierarchy (does not use the public network) for any recursive query for which:
<ol class="arabic simple">
<li>The answer is already in the cache.</li>
<li>The domain name is localhost (zone localhost).</li>
<li>Is a reverse-map query for 127.0.0.1 (zone 0.0.127.in-addr.arpa).</li>
<li>Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).</li>
<li>Is a reverse-map query for any local IP (empty-zones-enable statement).</li>
<li>Is a query for the domain name example.com, in which case it will be
forwarded to either 192.168.250.3 or 192.168.230.27 (zone example.com).</li>
</ol>
All other recursive queries will result in access to the DNS hierarchy to
resolve the query.
</section>
</section>
<section id="load-balancing">
<h2>3.4. Load Balancing<a class="headerlink" href="#load-balancing" title="Permalink to this headline"></a></h2>
A primitive form of load balancing can be achieved in the DNS by using multiple
resource records (RRs) in a <a class="reference internal" href="#zone-file">zone file</a> (such as multiple A
records) for one name.
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:
<table class="docutils align-default">
<colgroup>
<col style="width: 17%" />
<col style="width: 9%" />
<col style="width: 15%" />
<col style="width: 15%" />
<col style="width: 43%" />
</colgroup>
<tbody>
<tr class="row-odd"><td>Name</td>
<td>TTL</td>
<td>CLASS</td>
<td>TYPE</td>
<td>Resource Record (RR) Data</td>
</tr>
<tr class="row-even"><td>www</td>
<td>600</td>
<td>IN</td>
<td>A</td>
<td>10.0.0.1</td>
</tr>
<tr class="row-odd"><td></td>
<td>600</td>
<td>IN</td>
<td>A</td>
<td>10.0.0.2</td>
</tr>
<tr class="row-even"><td></td>
<td>600</td>
<td>IN</td>
<td>A</td>
<td>10.0.0.3</td>
</tr>
</tbody>
</table>
When a resolver queries for these records, BIND rotates them and
responds to the query with the records in a random 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.
For more detail on ordering responses, refer to the
<a class="reference internal" href="reference.html#rrset-ordering">rrset-order</a> statement in the
<a class="reference internal" href="reference.html#namedconf-statement-options" title="namedconf-statement-options"><code class="xref namedconf namedconf-ref docutils literal notranslate">options</code></a> block.
</section>
<section id="soa-rr">
<h2>3.5. Zone File<a class="headerlink" href="#soa-rr" title="Permalink to this headline"></a></h2>
This section, largely borrowed from <a class="rfc reference external" href="https://tools.ietf.org/html/rfc1034.html">RFC 1034</a>, describes the concept of a
Resource Record (RR) and explains how to use them.
<section id="resource-records">
<h3>3.5.1. Resource Records<a class="headerlink" href="#resource-records" title="Permalink to this headline"></a></h3>
A domain name identifies a node in the DNS tree namespace. 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
<a class="reference internal" href="reference.html#namedconf-statement-sortlist" title="namedconf-statement-sortlist"><code class="xref any namedconf namedconf-ref docutils literal notranslate">sortlist</code></a> and <a class="reference internal" href="reference.html#rrset-ordering">RRset Ordering</a>.
The components of a Resource Record are:
<dl class="glossary simple">
<dt id="term-owner-name">owner name<a class="headerlink" href="#term-owner-name" title="Permalink to this term"></a></dt><dd>The domain name where the RR is found.
</dd>
<dt id="term-RR-type">RR type<a class="headerlink" href="#term-RR-type" title="Permalink to this term"></a></dt><dd>An encoded 16-bit value that specifies the type of the resource record.
For a list of types of valid RRs, including those that have been obsoleted, please refer to
<cite>https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4</cite>.
</dd>
<dt id="term-TTL">TTL<a class="headerlink" href="#term-TTL" title="Permalink to this term"></a></dt><dd>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.
</dd>
<dt id="term-class">class<a class="headerlink" href="#term-class" title="Permalink to this term"></a></dt><dd>An encoded 16-bit value that identifies a protocol family or an instance of a protocol.
</dd>
<dt id="term-RDATA">RDATA<a class="headerlink" href="#term-RDATA" title="Permalink to this term"></a></dt><dd>The resource data. The format of the data is type- and sometimes class-specific.
</dd>
</dl>
The following classes of resource records are currently valid in the
DNS:
<dl class="glossary simple">
<dt id="term-IN">IN<a class="headerlink" href="#term-IN" title="Permalink to this term"></a></dt><dd>The Internet. The only widely <a class="reference internal" href="#term-class">class</a> used today.
</dd>
<dt id="term-CH">CH<a class="headerlink" href="#term-CH" title="Permalink to this term"></a></dt><dd>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., version.bind.
</dd>
<dt id="term-HS">HS<a class="headerlink" href="#term-HS" title="Permalink to this term"></a></dt><dd>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.
</dd>
</dl>
The <a class="reference internal" href="#term-owner-name">owner name</a> 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.
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 is anticipated, the TTL can be reduced prior to
the change to minimize inconsistency, and then
increased back to its former value following the change.
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.
<section id="textual-expression-of-rrs">
<h4>3.5.1.1. Textual Expression of RRs<a class="headerlink" href="#textual-expression-of-rrs" title="Permalink to this headline"></a></h4>
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 <a class="rfc reference external" href="https://tools.ietf.org/html/rfc1034.html">RFC 1034</a>, a style
similar to that used in primary 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.
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.
Following the owner are listed 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.
The resource data or RDATA section of the RR is given using knowledge
of the typical representation for the data.
For example, the RRs carried in a message might be shown as:
<blockquote>
<div><table class="docutils align-default">
<colgroup>
<col style="width: 31%" />
<col style="width: 22%" />
<col style="width: 47%" />
</colgroup>
<tbody>
<tr class="row-odd"><td>ISI.EDU.</td>
<td>MX</td>
<td>10 VENERA.ISI.EDU.</td>
</tr>
<tr class="row-even"><td></td>
<td>MX</td>
<td>10 VAXA.ISI.EDU</td>
</tr>
<tr class="row-odd"><td>VENERA.ISI.EDU</td>
<td>A</td>
<td>128.9.0.32</td>
</tr>
<tr class="row-even"><td></td>
<td>A</td>
<td>10.1.0.52</td>
</tr>
<tr class="row-odd"><td>VAXA.ISI.EDU</td>
<td>A</td>
<td>10.2.0.27</td>
</tr>
<tr class="row-even"><td></td>
<td>A</td>
<td>128.9.0.33</td>
</tr>
</tbody>
</table>
</div></blockquote>
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.
The above example shows six RRs, with two RRs at each of three domain
names.
Here is another possible example:
<blockquote>
<div><table class="docutils align-default">
<colgroup>
<col style="width: 32%" />
<col style="width: 22%" />
<col style="width: 46%" />
</colgroup>
<tbody>
<tr class="row-odd"><td>XX.LCS.MIT.EDU.</td>
<td>IN A</td>
<td>10.0.0.44</td>
</tr>
<tr class="row-even"><td></td>
<td>CH A</td>
<td>MIT.EDU. 2420</td>
</tr>
</tbody>
</table>
</div></blockquote>
This shows two addresses for XX.LCS.MIT.EDU, each of a
different class.
</section>
</section>
<section id="discussion-of-mx-records">
<h3>3.5.2. Discussion of MX Records<a class="headerlink" href="#discussion-of-mx-records" title="Permalink to this headline"></a></h3>
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 an 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.
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 must have an associated address
record (A or AAAA); CNAME is not sufficient.
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:
<blockquote>
<div><table class="docutils align-default">
<colgroup>
<col style="width: 31%" />
<col style="width: 10%" />
<col style="width: 10%" />
<col style="width: 18%" />
<col style="width: 31%" />
</colgroup>
<tbody>
<tr class="row-odd"><td>example.com.</td>
<td>IN</td>
<td>MX</td>
<td>10</td>
<td>mail.example.com.</td>
</tr>
<tr class="row-even"><td></td>
<td>IN</td>
<td>MX</td>
<td>10</td>
<td>mail2.example.com.</td>
</tr>
<tr class="row-odd"><td></td>
<td>IN</td>
<td>MX</td>
<td>20</td>
<td>mail.backup.org.</td>
</tr>
<tr class="row-even"><td>mail.example.com.</td>
<td>IN</td>
<td>A</td>
<td>10.0.0.1</td>
<td></td>
</tr>
<tr class="row-odd"><td>mail2.example.com.</td>
<td>IN</td>
<td>A</td>
<td>10.0.0.2</td>
<td></td>
</tr>
</tbody>
</table>
</div></blockquote>
Mail delivery is attempted to mail.example.com and
mail2.example.com (in any order); if neither of those succeeds,
delivery to mail.backup.org is attempted.
</section>
<section id="setting-ttls">
<h3>3.5.3. Setting TTLs<a class="headerlink" href="#setting-ttls" title="Permalink to this headline"></a></h3>
The time-to-live (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.
<dl class="glossary">
<dt id="term-SOA-minimum">SOA minimum<a class="headerlink" href="#term-SOA-minimum" title="Permalink to this term"></a></dt><dd>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. Further details can be found in <a class="rfc reference external" href="https://tools.ietf.org/html/rfc2308.html">RFC 2308</a>.
The maximum time for negative caching is 3 hours (3h).
</dd>
<dt id="term-0">$TTL<a class="headerlink" href="#term-0" title="Permalink to this term"></a></dt><dd>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.
</dd>
<dt id="term-RR-TTLs">RR TTLs<a class="headerlink" href="#term-RR-TTLs" title="Permalink to this term"></a></dt><dd>Each RR can have a TTL as the second field in the RR, which controls how long other servers can cache it.
</dd>
</dl>
All of these TTLs default to units of seconds, though units can be
explicitly specified: for example, 1h30m.
</section>
<section id="inverse-mapping-in-ipv4">
<h3>3.5.4. Inverse Mapping in IPv4<a class="headerlink" href="#inverse-mapping-in-ipv4" title="Permalink to this headline"></a></h3>
Reverse name resolution (that is, translation from IP address to name)
is achieved by means of the in-addr.arpa 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
example.com domain:
<blockquote>
<div><table class="docutils align-default">
<colgroup>
<col style="width: 20%" />
<col style="width: 80%" />
</colgroup>
<tbody>
<tr class="row-odd"><td>$ORIGIN</td>
<td>2.1.10.in-addr.arpa</td>
</tr>
<tr class="row-even"><td>3</td>
<td>IN PTR foo.example.com.</td>
</tr>
</tbody>
</table>
</div></blockquote>
<div class="admonition note">
Note
The $ORIGIN 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.
</div>
</section>
<section id="other-zone-file-directives">
<h3>3.5.5. Other Zone File Directives<a class="headerlink" href="#other-zone-file-directives" title="Permalink to this headline"></a></h3>
The DNS “master file” format was initially defined in <a class="rfc reference external" href="https://tools.ietf.org/html/rfc1035.html">RFC 1035</a> and has
subsequently been extended. While the format itself is class-independent,
all records in a zone file must be of the same class.
Master file directives include $ORIGIN, $INCLUDE, and $TTL.
<section id="the-at-sign">
<h4>3.5.5.1. The &#64; (at-sign)<a class="headerlink" href="#the-at-sign" title="Permalink to this headline"></a></h4>
When used in the label (or name) field, the asperand or at-sign (&#64;)
symbol represents the current origin. At the start of the zone file, it
is the &lt;zone_name&gt;, followed by a trailing dot (.).
</section>
<section id="the-origin-directive">
<h4>3.5.5.2. The $ORIGIN Directive<a class="headerlink" href="#the-origin-directive" title="Permalink to this headline"></a></h4>
Syntax: $ORIGIN domain-name [comment]
$ORIGIN sets the domain name that is appended to any
unqualified records. When a zone is first read, there is an implicit
<code class="docutils literal notranslate">$ORIGIN &lt;zone_name&gt;.</code>; note the trailing dot. The
current $ORIGIN is appended to the domain specified in the
$ORIGIN argument if it is not absolute.
<div class="highlight-none notranslate"><div class="highlight"><pre>$ORIGIN example.com.
WWW CNAME MAIN-SERVER
</pre></div>
</div>
is equivalent to
<div class="highlight-none notranslate"><div class="highlight"><pre>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
</pre></div>
</div>
</section>
<section id="the-include-directive">
<h4>3.5.5.3. The $INCLUDE Directive<a class="headerlink" href="#the-include-directive" title="Permalink to this headline"></a></h4>
Syntax: $INCLUDE filename [origin] [comment]
This reads and processes the file filename as if it were included in the
file at this point. The filename can be an absolute path, or a relative
path. In the latter case it is read from <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</code></a>’s working directory. If
origin is specified, the file is processed with $ORIGIN set to that
value; otherwise, the current $ORIGIN is used.
The origin and the current domain name revert to the values they had
prior to the $INCLUDE once the file has been read.
<div class="admonition note">
Note
<a class="rfc reference external" href="https://tools.ietf.org/html/rfc1035.html">RFC 1035</a> specifies that the current origin should be restored after
an $INCLUDE, 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 <a class="rfc reference external" href="https://tools.ietf.org/html/rfc1035.html">RFC 1035</a>, a feature, or both.
</div>
</section>
<section id="the-ttl-directive">
<h4>3.5.5.4. The $TTL Directive<a class="headerlink" href="#the-ttl-directive" title="Permalink to this headline"></a></h4>
Syntax: $TTL default-ttl [comment]
This sets the default Time-To-Live (TTL) for subsequent records with undefined
TTLs. Valid TTLs are of the range 0-2147483647 seconds.
$TTL is defined in <a class="rfc reference external" href="https://tools.ietf.org/html/rfc2308.html">RFC 2308</a>.
</section>
</section>
<section id="bind-primary-file-extension-the-generate-directive">
<h3>3.5.6. BIND Primary File Extension: the $GENERATE Directive<a class="headerlink" href="#bind-primary-file-extension-the-generate-directive" title="Permalink to this headline"></a></h3>
Syntax: $GENERATE range owner [ttl] [class] type rdata [comment]
$GENERATE is used to create a series of resource records that only
differ from each other by an iterator.
<dl>
<dt>range</dt><dd>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”.
</dd>
<dt>owner</dt><dd>This describes the owner name of the resource records to be created.
The owner string may include one or more $ (dollar sign)
symbols, which will be replaced with the iterator value when
generating records; see below for details.
</dd>
<dt>ttl</dt><dd>This specifies the time-to-live of the generated records. If
not specified, this is inherited using the normal TTL inheritance
rules.
class and ttl can be entered in either order.
</dd>
<dt>class</dt><dd>This specifies the class of the generated records. This must
match the zone class if it is specified.
class and ttl can be entered in either order.
</dd>
<dt>type</dt><dd>This can be any valid type.
</dd>
<dt>rdata</dt><dd>This is a string containing the RDATA of the resource record
to be created. As with owner, the rdata string may
include one or more $ symbols, which are replaced with the
iterator value. rdata may be quoted if there are spaces in
the string; the quotation marks do not appear in the generated
record.
Any single $ (dollar sign) symbols within the owner or
rdata strings are replaced by the iterator value. To get a $
in the output, escape the $ using a backslash \, e.g.,
<code class="docutils literal notranslate">\$</code>. (For compatibility with earlier versions, $$ is also
recognized as indicating a literal $ in the output.)
The $ may optionally be followed by modifiers which change
the offset from the iterator, field width, and base. Modifiers
are introduced by a { (left brace) immediately following
the $, as in ${offset[,width[,base]]}. For example,
${-20,3,d} 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 (d), octal (o),
hexadecimal (x or X for uppercase), and nibble (n
or N for uppercase). The modfiier cannot contain whitespace
or newlines.
The default modifier is ${0,0,d}. If the owner is not
absolute, the current $ORIGIN is appended to the name.
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.
</dd>
</dl>
Examples:
$GENERATE can be used to easily generate the sets of records required
to support sub-/24 reverse delegations described in <a class="rfc reference external" href="https://tools.ietf.org/html/rfc2317.html">RFC 2317</a>:
<div class="highlight-none notranslate"><div class="highlight"><pre>$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-2 @ NS SERVER$.EXAMPLE.
$GENERATE 1-127 $ CNAME $.0
</pre></div>
</div>
is equivalent to
<div class="highlight-none notranslate"><div class="highlight"><pre>0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE.
0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
...
127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
</pre></div>
</div>
This example creates a set of A and MX records. Note the MX’s rdata
is a quoted string; the quotes are stripped when $GENERATE is processed:
<div class="highlight-none notranslate"><div class="highlight"><pre>$ORIGIN EXAMPLE.
$GENERATE 1-127 HOST-$ A 1.2.3.$
$GENERATE 1-127 HOST-$ MX &quot;0 .&quot;
</pre></div>
</div>
is equivalent to
<div class="highlight-none notranslate"><div class="highlight"><pre>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 .
</pre></div>
</div>
This example generates A and AAAA records using modifiers; the AAAA
owner names are generated using nibble mode:
<div class="highlight-none notranslate"><div class="highlight"><pre>$ORIGIN EXAMPLE.
$GENERATE 0-2 HOST-${0,4,d} A 1.2.3.${1,0,d}
$GENERATE 1024-1026 ${0,3,n} AAAA 2001:db8::${0,4,x}
</pre></div>
</div>
is equivalent to:
<div class="highlight-none notranslate"><div class="highlight"><pre>HOST-0000.EXAMPLE. A 1.2.3.1
HOST-0001.EXAMPLE. A 1.2.3.2
HOST-0002.EXAMPLE. A 1.2.3.3
0.0.4.EXAMPLE. AAAA 2001:db8::400
1.0.4.EXAMPLE. AAAA 2001:db8::401
2.0.4.EXAMPLE. AAAA 2001:db8::402
</pre></div>
</div>
The $GENERATE directive is a BIND extension and not part of the
standard zone file format.
</section>
<section id="additional-file-formats">
<h3>3.5.7. Additional File Formats<a class="headerlink" href="#additional-file-formats" title="Permalink to this headline"></a></h3>
In addition to the standard text format, BIND 9 supports the ability
to read or dump to zone files in other formats.
The raw 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.
For a primary server, a zone file in raw format is expected
to be generated from a text zone file by the <a class="reference internal" href="manpages.html#std-iscman-named-compilezone"><code class="xref std std-iscman docutils literal notranslate">named-compilezone</code></a> command.
For a secondary server or a dynamic zone, the zone file is automatically
generated when <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</code></a> dumps the zone contents after zone transfer or
when applying prior updates, if one of these formats is specified by the
masterfile-format option.
If a zone file in raw format needs manual modification, it first must
be converted to text format by the <a class="reference internal" href="manpages.html#std-iscman-named-compilezone"><code class="xref std std-iscman docutils literal notranslate">named-compilezone</code></a> command,
then converted back after editing. For example:
<div class="highlight-none notranslate"><div class="highlight"><pre>named-compilezone -f raw -F text -o zonefile.text &lt;origin&gt; zonefile.raw
[edit zonefile.text]
named-compilezone -f text -F raw -o zonefile.raw &lt;origin&gt; zonefile.text
</pre></div>
</div>
</section>
</section>
</section>

</div>
 </div>
 <footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer">
 <a href="chapter2.html" class="btn btn-neutral float-left" title="2. Resource Requirements" accesskey="p" rel="prev"> Previous</a>
 <a href="chapter4.html" class="btn btn-neutral float-right" title="4. Name Server Operations" accesskey="n" rel="next">Next </a>
 </div>

<hr/>

<div role="contentinfo">
 &#169; Copyright 2025, Internet Systems Consortium.
 </div>

Built with <a href="https://www.sphinx-doc.org/">Sphinx</a> using a
 <a href="https://github.com/readthedocs/sphinx_rtd_theme">theme</a>
 provided by <a href="https://readthedocs.org">Read the Docs</a>.

</footer>
 </div>
 </div>
 </section>
 </div>
 <script>
 jQuery(function () {
 SphinxRtdTheme.Navigation.enable(true);
 });
 </script>

</body>
</html>

${this.title}

Code Editor : chapter3.html