File: //proc/self/root/usr/share/doc/bind9-doc/arm/chapter7.html
<!DOCTYPE html>
<html class="writer-html5" lang="en" data-content_root="./">
<head>
<meta charset="utf-8" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>7. Security Configurations — BIND 9 9.18.39-0ubuntu0.24.04.2-Ubuntu documentation</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=80d5e7a1" />
<link rel="stylesheet" type="text/css" href="_static/css/theme.css?v=86f27845" />
<link rel="stylesheet" type="text/css" href="_static/custom.css?v=9ab34431" />
<script src="_static/jquery.js?v=8dae8fb0"></script>
<script src="_static/_sphinx_javascript_frameworks_compat.js?v=2cd50e6c"></script>
<script src="_static/documentation_options.js?v=9d4ae9d2"></script>
<script src="_static/doctools.js?v=888ff710"></script>
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
<script src="_static/js/theme.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="8. Configuration Reference" href="reference.html" />
<link rel="prev" title="6. Advanced Configurations" href="chapter6.html" />
</head>
<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.24.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" aria-label="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"><a class="reference internal" href="chapter3.html">3. Configurations and Zone Files</a></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 current"><a class="current reference internal" href="#">7. Security Configurations</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#security-assumptions">7.1. Security Assumptions</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#authoritative-servers">7.1.1. Authoritative Servers</a></li>
<li class="toctree-l3"><a class="reference internal" href="#dns-resolvers">7.1.2. DNS Resolvers</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#access-control-lists">7.2. Access Control Lists</a></li>
<li class="toctree-l2"><a class="reference internal" href="#chroot-and-setuid">7.3. <code class="docutils literal notranslate"><span class="pre">Chroot</span></code> and <code class="docutils literal notranslate"><span class="pre">Setuid</span></code></a><ul>
<li class="toctree-l3"><a class="reference internal" href="#the-chroot-environment">7.3.1. The <code class="docutils literal notranslate"><span class="pre">chroot</span></code> Environment</a></li>
<li class="toctree-l3"><a class="reference internal" href="#using-the-setuid-function">7.3.2. Using the <code class="docutils literal notranslate"><span class="pre">setuid</span></code> Function</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#dynamic-update-security">7.4. Dynamic Update Security</a></li>
<li class="toctree-l2"><a class="reference internal" href="#tsig">7.5. TSIG</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#generating-a-shared-key">7.5.1. Generating a Shared Key</a></li>
<li class="toctree-l3"><a class="reference internal" href="#loading-a-new-key">7.5.2. Loading a New Key</a></li>
<li class="toctree-l3"><a class="reference internal" href="#instructing-the-server-to-use-a-key">7.5.3. Instructing the Server to Use a Key</a></li>
<li class="toctree-l3"><a class="reference internal" href="#tsig-based-access-control">7.5.4. TSIG-Based Access Control</a></li>
<li class="toctree-l3"><a class="reference internal" href="#errors">7.5.5. Errors</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#tkey">7.6. TKEY</a></li>
<li class="toctree-l2"><a class="reference internal" href="#sig-0">7.7. SIG(0)</a></li>
</ul>
</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>
<p class="caption" role="heading"><span class="caption-text">Appendices</span></p>
<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>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap"><nav class="wy-nav-top" aria-label="Mobile navigation menu" >
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">BIND 9</a>
</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" aria-label="Home"></a></li>
<li class="breadcrumb-item active"><span class="section-number">7. </span>Security Configurations</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/chapter7.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="security-configurations">
<span id="security"></span><h1><span class="section-number">7. </span>Security Configurations<a class="headerlink" href="#security-configurations" title="Link to this heading"></a></h1>
<section id="security-assumptions">
<h2><span class="section-number">7.1. </span>Security Assumptions<a class="headerlink" href="#security-assumptions" title="Link to this heading"></a></h2>
<p>BIND 9’s design assumes that access to the objects listed below is limited only to
trusted parties. An incorrect deployment, which does not follow rules set by this
section, cannot be the basis for CVE assignment or special security-sensitive
handling of issues.</p>
<p>Unauthorized access can potentially disclose sensitive data, slow down server
operation, etc. Unauthorized, unexpected, or incorrect writes to any of the following listed objects
can potentially cause crashes, incorrect data handling, or corruption:</p>
<ul class="simple">
<li><p>All files stored on disk - including zone files, configuration files, key
files, temporary files, etc.</p></li>
<li><p>Clients communicating via the <a class="reference internal" href="reference.html#namedconf-statement-controls" title="namedconf-statement-controls"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">controls</span></code></a> socket using configured keys</p></li>
<li><p>Access to <a class="reference internal" href="reference.html#namedconf-statement-statistics-channels" title="namedconf-statement-statistics-channels"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">statistics-channels</span></code></a> from untrusted clients</p></li>
<li><p>Sockets used for <a class="reference internal" href="reference.html#namedconf-statement-update-policy" title="namedconf-statement-update-policy"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">update-policy</span></code></a> type <cite>external</cite></p></li>
</ul>
<p>Certain aspects of the DNS protocol are left unspecified, such as the handling of
responses from DNS servers which do not fully conform to the DNS protocol. For
such a situation, BIND implements its own safety checks and limits which are
subject to change as the protocol and deployment evolve.</p>
<section id="authoritative-servers">
<h3><span class="section-number">7.1.1. </span>Authoritative Servers<a class="headerlink" href="#authoritative-servers" title="Link to this heading"></a></h3>
<p>By default, zones use intentionally lenient limits (unlimited size, long
transfer timeouts, etc.). These defaults can be misused by the source of data
(zone transfers or UPDATEs) to exhaust resources on the receiving side.</p>
<p>The impact of malicious zone changes can be limited, to an extent, using
configuration options listed in sections <a class="reference internal" href="reference.html#server-resource-limits"><span class="std std-ref">Server Resource Limits</span></a> and
<a class="reference internal" href="reference.html#zone-transfers"><span class="std std-ref">Zone Transfers</span></a>. Limits should also be applied to zones where malicious clients may potentially be authorized to use <a class="reference internal" href="chapter6.html#dynamic-update"><span class="std std-ref">Dynamic Update</span></a>.</p>
</section>
<section id="dns-resolvers">
<h3><span class="section-number">7.1.2. </span>DNS Resolvers<a class="headerlink" href="#dns-resolvers" title="Link to this heading"></a></h3>
<p>By definition, DNS resolvers act as traffic amplifiers;
during normal operation, a DNS resolver can legitimately generate more outgoing
traffic (counted in packets or bytes) than the incoming client traffic that
triggered it. The DNS protocol specification does not currently specify limits
for this amplification, but BIND implements its own limits to balance
interoperability and safety. As a general rule, if a traffic amplification factor
for any given scenario is lower than 100 packets, ISC does not handle the given
scenario as a security issue. These limits are subject to change as DNS
deployment evolves.</p>
<p>All DNS answers received by the DNS resolver are treated as untrusted input and are
subject to safety and correctness checks. However, protocol non-conformity
might cause unexpected behavior. If such unexpected behavior is limited to DNS
domains hosted on non-conformant servers, it is not deemed a security issue <em>in
BIND</em>.</p>
</section>
</section>
<section id="access-control-lists">
<span id="file-permissions"></span><span id="id1"></span><h2><span class="section-number">7.2. </span>Access Control Lists<a class="headerlink" href="#access-control-lists" title="Link to this heading"></a></h2>
<p>Access Control Lists (ACLs) are address match lists that can be set up
and nicknamed for future use in <a class="reference internal" href="reference.html#namedconf-statement-allow-notify" title="namedconf-statement-allow-notify"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">allow-notify</span></code></a>, <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"><span class="pre">allow-query</span></code></a>,
<a class="reference internal" href="reference.html#namedconf-statement-allow-query-on" title="namedconf-statement-allow-query-on"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">allow-query-on</span></code></a>, <a class="reference internal" href="reference.html#namedconf-statement-allow-recursion" title="namedconf-statement-allow-recursion"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">allow-recursion</span></code></a>, <a class="reference internal" href="reference.html#namedconf-statement-blackhole" title="namedconf-statement-blackhole"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">blackhole</span></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"><span class="pre">allow-transfer</span></code></a>, <a class="reference internal" href="reference.html#namedconf-statement-match-clients" title="namedconf-statement-match-clients"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">match-clients</span></code></a>, etc.</p>
<p>ACLs give users finer control over who can access the
name server, without cluttering up configuration files with huge lists of
IP addresses.</p>
<p>It is a <em>good idea</em> 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.</p>
<p>ACLs match clients on the basis of up to three characteristics: 1) The
client’s IP address; 2) the TSIG key that was used to sign the
request, if any; and 3) an address prefix encoded in an EDNS
Client-Subnet option, if any.</p>
<p>Here is an example of ACLs based on client addresses:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">//</span> <span class="n">Set</span> <span class="n">up</span> <span class="n">an</span> <span class="n">ACL</span> <span class="n">named</span> <span class="s2">"bogusnets"</span> <span class="n">that</span> <span class="n">blocks</span>
<span class="o">//</span> <span class="n">RFC1918</span> <span class="n">space</span> <span class="ow">and</span> <span class="n">some</span> <span class="n">reserved</span> <span class="n">space</span><span class="p">,</span> <span class="n">which</span> <span class="ow">is</span>
<span class="o">//</span> <span class="n">commonly</span> <span class="n">used</span> <span class="ow">in</span> <span class="n">spoofing</span> <span class="n">attacks</span><span class="o">.</span>
<span class="n">acl</span> <span class="n">bogusnets</span> <span class="p">{</span>
<span class="mf">0.0.0.0</span><span class="o">/</span><span class="mi">8</span><span class="p">;</span> <span class="mf">192.0.2.0</span><span class="o">/</span><span class="mi">24</span><span class="p">;</span> <span class="mf">224.0.0.0</span><span class="o">/</span><span class="mi">3</span><span class="p">;</span>
<span class="mf">10.0.0.0</span><span class="o">/</span><span class="mi">8</span><span class="p">;</span> <span class="mf">172.16.0.0</span><span class="o">/</span><span class="mi">12</span><span class="p">;</span> <span class="mf">192.168.0.0</span><span class="o">/</span><span class="mi">16</span><span class="p">;</span>
<span class="p">};</span>
<span class="o">//</span> <span class="n">Set</span> <span class="n">up</span> <span class="n">an</span> <span class="n">ACL</span> <span class="n">called</span> <span class="n">our</span><span class="o">-</span><span class="n">nets</span><span class="o">.</span> <span class="n">Replace</span> <span class="n">this</span> <span class="k">with</span> <span class="n">the</span>
<span class="o">//</span> <span class="n">real</span> <span class="n">IP</span> <span class="n">numbers</span><span class="o">.</span>
<span class="n">acl</span> <span class="n">our</span><span class="o">-</span><span class="n">nets</span> <span class="p">{</span> <span class="n">x</span><span class="o">.</span><span class="n">x</span><span class="o">.</span><span class="n">x</span><span class="o">.</span><span class="n">x</span><span class="o">/</span><span class="mi">24</span><span class="p">;</span> <span class="n">x</span><span class="o">.</span><span class="n">x</span><span class="o">.</span><span class="n">x</span><span class="o">.</span><span class="n">x</span><span class="o">/</span><span class="mi">21</span><span class="p">;</span> <span class="p">};</span>
<span class="n">options</span> <span class="p">{</span>
<span class="o">...</span>
<span class="o">...</span>
<span class="n">allow</span><span class="o">-</span><span class="n">query</span> <span class="p">{</span> <span class="n">our</span><span class="o">-</span><span class="n">nets</span><span class="p">;</span> <span class="p">};</span>
<span class="n">allow</span><span class="o">-</span><span class="n">recursion</span> <span class="p">{</span> <span class="n">our</span><span class="o">-</span><span class="n">nets</span><span class="p">;</span> <span class="p">};</span>
<span class="o">...</span>
<span class="n">blackhole</span> <span class="p">{</span> <span class="n">bogusnets</span><span class="p">;</span> <span class="p">};</span>
<span class="o">...</span>
<span class="p">};</span>
<span class="n">zone</span> <span class="s2">"example.com"</span> <span class="p">{</span>
<span class="nb">type</span> <span class="n">primary</span><span class="p">;</span>
<span class="n">file</span> <span class="s2">"m/example.com"</span><span class="p">;</span>
<span class="n">allow</span><span class="o">-</span><span class="n">query</span> <span class="p">{</span> <span class="nb">any</span><span class="p">;</span> <span class="p">};</span>
<span class="p">};</span>
</pre></div>
</div>
<p>This allows authoritative queries for <code class="docutils literal notranslate"><span class="pre">example.com</span></code> from any address,
but recursive queries only from the networks specified in <code class="docutils literal notranslate"><span class="pre">our-nets</span></code>,
and no queries at all from the networks specified in <code class="docutils literal notranslate"><span class="pre">bogusnets</span></code>.</p>
<p>In addition to network addresses and prefixes, which are matched against
the source address of the DNS request, ACLs may include <code class="docutils literal notranslate"><span class="pre">key</span></code>
elements, which specify the name of a TSIG key.</p>
<p>When BIND 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: <code class="docutils literal notranslate"><span class="pre">geoip</span> <span class="pre">db</span> <span class="pre">database</span> <span class="pre">field</span> <span class="pre">value</span></code>.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">field</span></code> parameter indicates which field to search for a match. Available fields
are <code class="docutils literal notranslate"><span class="pre">country</span></code>, <code class="docutils literal notranslate"><span class="pre">region</span></code>, <code class="docutils literal notranslate"><span class="pre">city</span></code>, <code class="docutils literal notranslate"><span class="pre">continent</span></code>, <code class="docutils literal notranslate"><span class="pre">postal</span></code> (postal code),
<code class="docutils literal notranslate"><span class="pre">metro</span></code> (metro code), <code class="docutils literal notranslate"><span class="pre">area</span></code> (area code), <code class="docutils literal notranslate"><span class="pre">tz</span></code> (timezone), <code class="docutils literal notranslate"><span class="pre">isp</span></code>,
<code class="docutils literal notranslate"><span class="pre">asnum</span></code>, and <code class="docutils literal notranslate"><span class="pre">domain</span></code>.</p>
<p><code class="docutils literal notranslate"><span class="pre">value</span></code> is the value to search for within the database. A string may be quoted
if it contains spaces or other special characters. An <code class="docutils literal notranslate"><span class="pre">asnum</span></code> search for
autonomous system number can be specified using the string “ASNNNN” or the
integer NNNN. If a <code class="docutils literal notranslate"><span class="pre">country</span></code> 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
<code class="docutils literal notranslate"><span class="pre">region</span></code> 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.</p>
<p>The <a class="reference internal" href="reference.html#namedconf-statement-database" title="namedconf-statement-database"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">database</span></code></a> 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 <code class="docutils literal notranslate"><span class="pre">continent</span></code> or <code class="docutils literal notranslate"><span class="pre">country</span></code> can be
answered from either the <code class="docutils literal notranslate"><span class="pre">city</span></code> or <code class="docutils literal notranslate"><span class="pre">country</span></code> databases, so for these search
types, specifying a <a class="reference internal" href="reference.html#namedconf-statement-database" title="namedconf-statement-database"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">database</span></code></a> forces the query to be answered from that
database and no other. If a <a class="reference internal" href="reference.html#namedconf-statement-database" title="namedconf-statement-database"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">database</span></code></a> is not specified, these queries
are first answered from the <code class="docutils literal notranslate"><span class="pre">city</span></code> database if it is installed, and then from the <code class="docutils literal notranslate"><span class="pre">country</span></code>
database if it is installed. Valid database names are <code class="docutils literal notranslate"><span class="pre">country</span></code>,
<code class="docutils literal notranslate"><span class="pre">city</span></code>, <code class="docutils literal notranslate"><span class="pre">asnum</span></code>, <code class="docutils literal notranslate"><span class="pre">isp</span></code>, and <code class="docutils literal notranslate"><span class="pre">domain</span></code>.</p>
<p>Some example GeoIP ACLs:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">geoip</span> <span class="n">country</span> <span class="n">US</span><span class="p">;</span>
<span class="n">geoip</span> <span class="n">country</span> <span class="n">JP</span><span class="p">;</span>
<span class="n">geoip</span> <span class="n">db</span> <span class="n">country</span> <span class="n">country</span> <span class="n">Canada</span><span class="p">;</span>
<span class="n">geoip</span> <span class="n">region</span> <span class="n">WA</span><span class="p">;</span>
<span class="n">geoip</span> <span class="n">city</span> <span class="s2">"San Francisco"</span><span class="p">;</span>
<span class="n">geoip</span> <span class="n">region</span> <span class="n">Oklahoma</span><span class="p">;</span>
<span class="n">geoip</span> <span class="n">postal</span> <span class="mi">95062</span><span class="p">;</span>
<span class="n">geoip</span> <span class="n">tz</span> <span class="s2">"America/Los_Angeles"</span><span class="p">;</span>
<span class="n">geoip</span> <span class="n">org</span> <span class="s2">"Internet Systems Consortium"</span><span class="p">;</span>
</pre></div>
</div>
<p>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 <code class="docutils literal notranslate"><span class="pre">{</span> <span class="pre">10/8;</span> <span class="pre">!10.0.0.1;</span> <span class="pre">}</span></code> 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.</p>
<p>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 <em>and</em> only when it is
signed with a particular key, use:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>allow-query { !{ !10/8; any; }; key example; };
</pre></div>
</div>
<p>Within the nested ACL, any address that is <em>not</em> in the 10/8 network
prefix is rejected, which terminates the processing of the ACL.
Any address that <em>is</em> 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 <code class="docutils literal notranslate"><span class="pre">example</span></code>, and rejected otherwise. The ACL, then, only
matches when <em>both</em> conditions are true.</p>
</section>
<section id="chroot-and-setuid">
<span id="id2"></span><h2><span class="section-number">7.3. </span><code class="docutils literal notranslate"><span class="pre">Chroot</span></code> and <code class="docutils literal notranslate"><span class="pre">Setuid</span></code><a class="headerlink" href="#chroot-and-setuid" title="Link to this heading"></a></h2>
<p>On Unix servers, it is possible to run BIND in a <em>chrooted</em> environment
(using the <code class="docutils literal notranslate"><span class="pre">chroot()</span></code> function) by specifying the <a class="reference internal" href="manpages.html#cmdoption-named-t"><code class="xref std std-option docutils literal notranslate"><span class="pre">-t</span></code></a> option for
<a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named</span></code></a>. This can help improve system security by placing BIND in a
“sandbox,” which limits the damage done if a server is compromised.</p>
<p>Another useful feature in the Unix version of BIND is the ability to run
the daemon as an unprivileged user (<a class="reference internal" href="manpages.html#cmdoption-named-u"><code class="xref std std-option docutils literal notranslate"><span class="pre">-u</span></code></a> user). We suggest running
as an unprivileged user when using the <code class="docutils literal notranslate"><span class="pre">chroot</span></code> feature.</p>
<p>Here is an example command line to load BIND in a <code class="docutils literal notranslate"><span class="pre">chroot</span></code> sandbox,
<code class="docutils literal notranslate"><span class="pre">/var/named</span></code>, and to run <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named</span></code></a> <code class="docutils literal notranslate"><span class="pre">setuid</span></code> to user 202:</p>
<p><code class="docutils literal notranslate"><span class="pre">/usr/local/sbin/named</span> <span class="pre">-u</span> <span class="pre">202</span> <span class="pre">-t</span> <span class="pre">/var/named</span></code></p>
<section id="the-chroot-environment">
<span id="chroot"></span><h3><span class="section-number">7.3.1. </span>The <code class="docutils literal notranslate"><span class="pre">chroot</span></code> Environment<a class="headerlink" href="#the-chroot-environment" title="Link to this heading"></a></h3>
<p>For a <code class="docutils literal notranslate"><span class="pre">chroot</span></code> environment to work properly in a particular
directory (for example, <code class="docutils literal notranslate"><span class="pre">/var/named</span></code>), the
environment must include everything BIND needs to run. From BIND’s
point of view, <code class="docutils literal notranslate"><span class="pre">/var/named</span></code> is the root of the filesystem;
the values of options like <a class="reference internal" href="reference.html#namedconf-statement-directory" title="namedconf-statement-directory"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">directory</span></code></a> and <a class="reference internal" href="reference.html#namedconf-statement-pid-file" title="namedconf-statement-pid-file"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">pid-file</span></code></a>
must be adjusted to account for this.</p>
<p>Unlike with earlier versions of BIND,
<a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named</span></code></a> does <em>not</em> 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 <code class="docutils literal notranslate"><span class="pre">/dev/zero</span></code>, <code class="docutils literal notranslate"><span class="pre">/dev/random</span></code>, <code class="docutils literal notranslate"><span class="pre">/dev/log</span></code>, and
<code class="docutils literal notranslate"><span class="pre">/etc/localtime</span></code>.</p>
</section>
<section id="using-the-setuid-function">
<span id="setuid"></span><h3><span class="section-number">7.3.2. </span>Using the <code class="docutils literal notranslate"><span class="pre">setuid</span></code> Function<a class="headerlink" href="#using-the-setuid-function" title="Link to this heading"></a></h3>
<p>Prior to running the <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named</span></code></a> daemon, use the <code class="docutils literal notranslate"><span class="pre">touch</span></code> utility (to
change file access and modification times) or the <code class="docutils literal notranslate"><span class="pre">chown</span></code> utility (to
set the user id and/or group id) on files where BIND should
write.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>If the <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named</span></code></a> daemon is running as an unprivileged user, it
cannot bind to new restricted ports if the server is
reloaded.</p>
</div>
</section>
</section>
<section id="dynamic-update-security">
<span id="id3"></span><h2><span class="section-number">7.4. </span>Dynamic Update Security<a class="headerlink" href="#dynamic-update-security" title="Link to this heading"></a></h2>
<p>Access to the dynamic update facility should be strictly limited. In
earlier versions of BIND, 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 <a class="reference internal" href="reference.html#namedconf-statement-allow-update" title="namedconf-statement-allow-update"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">allow-update</span></code></a> 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
<a class="reference internal" href="reference.html#namedconf-statement-allow-update" title="namedconf-statement-allow-update"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">allow-update</span></code></a> 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.</p>
<p>For these reasons, we strongly recommend that updates be
cryptographically authenticated by means of transaction signatures
(TSIG). That is, the <a class="reference internal" href="reference.html#namedconf-statement-allow-update" title="namedconf-statement-allow-update"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">allow-update</span></code></a> option should list only TSIG key
names, not IP addresses or network prefixes. Alternatively, the
<a class="reference internal" href="reference.html#namedconf-statement-update-policy" title="namedconf-statement-update-policy"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">update-policy</span></code></a> option can be used.</p>
<p>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 updates at all.</p>
<span class="target" id="dns-over-tls"><span id="sec-file-transfer"></span></span></section>
<section id="tsig">
<span id="id4"></span><h2><span class="section-number">7.5. </span>TSIG<a class="headerlink" href="#tsig" title="Link to this heading"></a></h2>
<p>TSIG (Transaction SIGnatures) is a mechanism for authenticating DNS
messages, originally specified in <span class="target" id="index-0"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc2845.html"><strong>RFC 2845</strong></a>. 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.</p>
<p>This section is a guide to setting up TSIG in BIND. It describes the
configuration syntax and the process of creating TSIG keys.</p>
<p><a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named</span></code></a> supports TSIG for server-to-server communication, and some of
the tools included with BIND support it for sending messages to
<a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named</span></code></a>:</p>
<blockquote>
<div><ul class="simple">
<li><p><a class="reference internal" href="manpages.html#man-nsupdate"><span class="std std-ref">nsupdate - dynamic DNS update utility</span></a> supports TSIG via the <a class="reference internal" href="manpages.html#cmdoption-nsupdate-k"><code class="xref std std-option docutils literal notranslate"><span class="pre">-k</span></code></a>, <a class="reference internal" href="manpages.html#cmdoption-nsupdate-l"><code class="xref std std-option docutils literal notranslate"><span class="pre">-l</span></code></a>, and <a class="reference internal" href="manpages.html#cmdoption-nsupdate-y"><code class="xref std std-option docutils literal notranslate"><span class="pre">-y</span></code></a> command-line options, or via the <code class="docutils literal notranslate"><span class="pre">key</span></code> command when running interactively.</p></li>
<li><p><a class="reference internal" href="manpages.html#man-dig"><span class="std std-ref">dig - DNS lookup utility</span></a> supports TSIG via the <a class="reference internal" href="manpages.html#cmdoption-dig-k"><code class="xref std std-option docutils literal notranslate"><span class="pre">-k</span></code></a> and <a class="reference internal" href="manpages.html#cmdoption-dig-y"><code class="xref std std-option docutils literal notranslate"><span class="pre">-y</span></code></a> command-line options.</p></li>
</ul>
</div></blockquote>
<section id="generating-a-shared-key">
<h3><span class="section-number">7.5.1. </span>Generating a Shared Key<a class="headerlink" href="#generating-a-shared-key" title="Link to this heading"></a></h3>
<p>TSIG keys can be generated using the <a class="reference internal" href="manpages.html#std-iscman-tsig-keygen"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">tsig-keygen</span></code></a> command; the output
of the command is a <code class="docutils literal notranslate"><span class="pre">key</span></code> directive suitable for inclusion in
<a class="reference internal" href="manpages.html#std-iscman-named.conf"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named.conf</span></code></a>. The key name, algorithm, and size can be specified by
command-line parameters; the defaults are “tsig-key”, HMAC-SHA256, and
256 bits, respectively.</p>
<p>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 <code class="docutils literal notranslate"><span class="pre">host1</span></code> and <code class="docutils literal notranslate"><span class="pre">host2</span></code>
could be called “host1-host2.”, and this key can be generated using:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ tsig-keygen host1-host2. > host1-host2.key
</pre></div>
</div>
<p>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.)</p>
<p><a class="reference internal" href="manpages.html#std-iscman-tsig-keygen"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">tsig-keygen</span></code></a> can also be run as <a class="reference internal" href="manpages.html#std-iscman-ddns-confgen"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">ddns-confgen</span></code></a>, in which case its
output includes additional configuration text for setting up dynamic DNS
in <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named</span></code></a>. See <a class="reference internal" href="manpages.html#man-ddns-confgen"><span class="std std-ref">ddns-confgen - TSIG key generation tool</span></a> for details.</p>
</section>
<section id="loading-a-new-key">
<h3><span class="section-number">7.5.2. </span>Loading a New Key<a class="headerlink" href="#loading-a-new-key" title="Link to this heading"></a></h3>
<p>For a key shared between servers called <code class="docutils literal notranslate"><span class="pre">host1</span></code> and <code class="docutils literal notranslate"><span class="pre">host2</span></code>, the
following could be added to each server’s <a class="reference internal" href="manpages.html#std-iscman-named.conf"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named.conf</span></code></a> file:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">key</span> <span class="s2">"host1-host2."</span> <span class="p">{</span>
<span class="n">algorithm</span> <span class="n">hmac</span><span class="o">-</span><span class="n">sha256</span><span class="p">;</span>
<span class="n">secret</span> <span class="s2">"DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY="</span><span class="p">;</span>
<span class="p">};</span>
</pre></div>
</div>
<p>(This is the same key generated above using <a class="reference internal" href="manpages.html#std-iscman-tsig-keygen"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">tsig-keygen</span></code></a>.)</p>
<p>Since this text contains a secret, it is recommended that either
<a class="reference internal" href="manpages.html#std-iscman-named.conf"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named.conf</span></code></a> not be world-readable, or that the <code class="docutils literal notranslate"><span class="pre">key</span></code> directive be
stored in a file which is not world-readable and which is included in
<a class="reference internal" href="manpages.html#std-iscman-named.conf"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named.conf</span></code></a> via the <code class="docutils literal notranslate"><span class="pre">include</span></code> directive.</p>
<p>Once a key has been added to <a class="reference internal" href="manpages.html#std-iscman-named.conf"><code class="xref std std-iscman docutils literal notranslate"><span class="pre">named.conf</span></code></a> 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.</p>
<p>TSIG keys that are known to a server can be listed using the command
<a class="reference internal" href="manpages.html#cmdoption-rndc-arg-tsig-list"><code class="xref std std-option docutils literal notranslate"><span class="pre">rndc</span> <span class="pre">tsig-list</span></code></a>.</p>
</section>
<section id="instructing-the-server-to-use-a-key">
<h3><span class="section-number">7.5.3. </span>Instructing the Server to Use a Key<a class="headerlink" href="#instructing-the-server-to-use-a-key" title="Link to this heading"></a></h3>
<p>A server sending a request to another server must be told whether to use
a key, and if so, which key to use.</p>
<p>For example, a key may be specified for each server in the <a class="reference internal" href="reference.html#namedconf-statement-primaries" title="namedconf-statement-primaries"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">primaries</span></code></a>
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 <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"><span class="pre">also-notify</span></code></a> statement of a primary or secondary zone, causing NOTIFY
messages to be signed using the specified key.</p>
<p>Keys can also be specified in a <a class="reference internal" href="reference.html#namedconf-statement-server" title="namedconf-statement-server"><code class="xref namedconf namedconf-ref docutils literal notranslate"><span class="pre">server</span></code></a> directive. Adding the
following on <code class="docutils literal notranslate"><span class="pre">host1</span></code>, if the IP address of <code class="docutils literal notranslate"><span class="pre">host2</span></code> is 10.1.2.3, would
cause <em>all</em> requests from <code class="docutils literal notranslate"><span class="pre">host1</span></code> to <code class="docutils literal notranslate"><span class="pre">host2</span></code>, including normal DNS
queries, to be signed using the <code class="docutils literal notranslate"><span class="pre">host1-host2.</span></code> key:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">server</span> <span class="mf">10.1.2.3</span> <span class="p">{</span>
<span class="n">keys</span> <span class="p">{</span> <span class="n">host1</span><span class="o">-</span><span class="n">host2</span><span class="o">.</span> <span class="p">;};</span>
<span class="p">};</span>
</pre></div>
</div>
<p>Multiple keys may be present in the <a class="reference internal" href="reference.html#namedconf-statement-keys" title="namedconf-statement-keys"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">keys</span></code></a> statement, but only the
first one is used. As this directive does not contain secrets, it can be
used in a world-readable file.</p>
<p>Requests sent by <code class="docutils literal notranslate"><span class="pre">host2</span></code> to <code class="docutils literal notranslate"><span class="pre">host1</span></code> would <em>not</em> be signed, unless a
similar <code class="docutils literal notranslate"><span class="pre">server</span></code> directive were in <code class="docutils literal notranslate"><span class="pre">host2</span></code>’s configuration file.</p>
<p>When 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.</p>
</section>
<section id="tsig-based-access-control">
<h3><span class="section-number">7.5.4. </span>TSIG-Based Access Control<a class="headerlink" href="#tsig-based-access-control" title="Link to this heading"></a></h3>
<p>TSIG keys may be specified in ACL definitions and ACL directives such as
<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"><span class="pre">allow-query</span></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"><span class="pre">allow-transfer</span></code></a>, and <a class="reference internal" href="reference.html#namedconf-statement-allow-update" title="namedconf-statement-allow-update"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">allow-update</span></code></a>. The above key
would be denoted in an ACL element as <code class="docutils literal notranslate"><span class="pre">key</span> <span class="pre">host1-host2.</span></code></p>
<p>Here is an example of an <a class="reference internal" href="reference.html#namedconf-statement-allow-update" title="namedconf-statement-allow-update"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">allow-update</span></code></a> directive using a TSIG key:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>allow-update { !{ !localnets; any; }; key host1-host2. ;};
</pre></div>
</div>
<p>This allows dynamic updates to succeed only if the UPDATE request comes
from an address in <code class="docutils literal notranslate"><span class="pre">localnets</span></code>, <em>and</em> if it is signed using the
<code class="docutils literal notranslate"><span class="pre">host1-host2.</span></code> key.</p>
<p>See <a class="reference internal" href="reference.html#dynamic-update-policies"><span class="std std-ref">Dynamic Update Policies</span></a> for a
discussion of the more flexible <a class="reference internal" href="reference.html#namedconf-statement-update-policy" title="namedconf-statement-update-policy"><code class="xref any namedconf namedconf-ref docutils literal notranslate"><span class="pre">update-policy</span></code></a> statement.</p>
</section>
<section id="errors">
<h3><span class="section-number">7.5.5. </span>Errors<a class="headerlink" href="#errors" title="Link to this heading"></a></h3>
<p>Processing of TSIG-signed messages can result in several errors:</p>
<ul class="simple">
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ul>
<p>In all of the above cases, the server returns a response code of
NOTAUTH (not authenticated).</p>
</section>
</section>
<section id="tkey">
<h2><span class="section-number">7.6. </span>TKEY<a class="headerlink" href="#tkey" title="Link to this heading"></a></h2>
<p>TKEY (Transaction KEY) is a mechanism for automatically negotiating a
shared secret between two hosts, originally specified in <span class="target" id="index-1"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc2930.html"><strong>RFC 2930</strong></a>.</p>
<p>There are several TKEY “modes” that specify how a key is to be generated
or assigned. BIND 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).</p>
<p>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 to sign subsequent
transactions between the two servers.</p>
<p>TSIG keys known by the server, including TKEY-negotiated keys, can be
listed using <a class="reference internal" href="manpages.html#cmdoption-rndc-arg-tsig-list"><code class="xref std std-option docutils literal notranslate"><span class="pre">rndc</span> <span class="pre">tsig-list</span></code></a>.</p>
<p>TKEY-negotiated keys can be deleted from a server using
<a class="reference internal" href="manpages.html#cmdoption-rndc-arg-tsig-delete"><code class="xref std std-option docutils literal notranslate"><span class="pre">rndc</span> <span class="pre">tsig-delete</span></code></a>. This can also be done via the TKEY protocol
itself, by sending an authenticated TKEY query specifying the “key
deletion” mode.</p>
</section>
<section id="sig-0">
<h2><span class="section-number">7.7. </span>SIG(0)<a class="headerlink" href="#sig-0" title="Link to this heading"></a></h2>
<p>Support for DNSSEC SIG(0) transaction signatures has been removed.
This is a countermeasure for CVE-2024-1975.</p>
</section>
</section>
</div>
</div>
<footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer">
<a href="chapter6.html" class="btn btn-neutral float-left" title="6. Advanced Configurations" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a>
<a href="reference.html" class="btn btn-neutral float-right" title="8. Configuration Reference" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right" aria-hidden="true"></span></a>
</div>
<hr/>
<div role="contentinfo">
<p>© Copyright 2025, Internet Systems Consortium.</p>
</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>