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 : chapter7.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"><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">Chroot</code> and <code class="docutils literal notranslate">Setuid</code></a><ul>
<li class="toctree-l3"><a class="reference internal" href="#the-chroot-environment">7.3.1. The <code class="docutils literal notranslate">chroot</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">setuid</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>
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>7. 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">
<h1>7. Security Configurations<a class="headerlink" href="#security-configurations" title="Permalink to this headline"></a></h1>
<section id="security-assumptions">
<h2>7.1. Security Assumptions<a class="headerlink" href="#security-assumptions" title="Permalink to this headline"></a></h2>
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.
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:
<ul class="simple">
<li>All files stored on disk - including zone files, configuration files, key
files, temporary files, etc.</li>
<li>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">controls</code></a> socket using configured keys</li>
<li>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">statistics-channels</code></a> from untrusted clients</li>
<li>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">update-policy</code></a> type <cite>external</cite></li>
</ul>
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.
<section id="authoritative-servers">
<h3>7.1.1. Authoritative Servers<a class="headerlink" href="#authoritative-servers" title="Permalink to this headline"></a></h3>
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.
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">Server Resource Limits</a> and
<a class="reference internal" href="reference.html#zone-transfers">Zone Transfers</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">Dynamic Update</a>.
</section>
<section id="dns-resolvers">
<h3>7.1.2. DNS Resolvers<a class="headerlink" href="#dns-resolvers" title="Permalink to this headline"></a></h3>
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.
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 in
BIND.
</section>
</section>
<section id="access-control-lists">
<h2>7.2. Access Control Lists<a class="headerlink" href="#access-control-lists" title="Permalink to this headline"></a></h2>
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">allow-notify</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">allow-query</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">allow-query-on</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">allow-recursion</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">blackhole</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-match-clients" title="namedconf-statement-match-clients"><code class="xref any namedconf namedconf-ref docutils literal notranslate">match-clients</code></a>, etc.
ACLs give users finer control over who can access the
name server, without cluttering up configuration files with huge lists of
IP addresses.
It is a good idea 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.
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.
Here is an example of ACLs based on client addresses:
<div class="highlight-default notranslate"><div class="highlight"><pre>// Set up an ACL named &quot;bogusnets&quot; that blocks
// RFC1918 space and some reserved space, which is
// commonly used in spoofing attacks.
acl bogusnets {
 0.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
};

// Set up an ACL called our-nets. Replace this with the
// real IP numbers.
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
options {
 ...
 ...
 allow-query { our-nets; };
 allow-recursion { our-nets; };
 ...
 blackhole { bogusnets; };
 ...
};

zone &quot;example.com&quot; {
 type primary;
 file &quot;m/example.com&quot;;
 allow-query { any; };
};
</pre></div>
</div>
This allows authoritative queries for <code class="docutils literal notranslate">example.com</code> from any address,
but recursive queries only from the networks specified in <code class="docutils literal notranslate">our-nets</code>,
and no queries at all from the networks specified in <code class="docutils literal notranslate">bogusnets</code>.
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">key</code>
elements, which specify the name of a TSIG key.
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">geoip db database field value</code>.
The <code class="docutils literal notranslate">field</code> parameter indicates which field to search for a match. Available fields
are <code class="docutils literal notranslate">country</code>, <code class="docutils literal notranslate">region</code>, <code class="docutils literal notranslate">city</code>, <code class="docutils literal notranslate">continent</code>, <code class="docutils literal notranslate">postal</code> (postal code),
<code class="docutils literal notranslate">metro</code> (metro code), <code class="docutils literal notranslate">area</code> (area code), <code class="docutils literal notranslate">tz</code> (timezone), <code class="docutils literal notranslate">isp</code>,
<code class="docutils literal notranslate">asnum</code>, and <code class="docutils literal notranslate">domain</code>.
<code class="docutils literal notranslate">value</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">asnum</code> search for
autonomous system number can be specified using the string “ASNNNN” or the
integer NNNN. If a <code class="docutils literal notranslate">country</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">region</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.
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">database</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">continent</code> or <code class="docutils literal notranslate">country</code> can be
answered from either the <code class="docutils literal notranslate">city</code> or <code class="docutils literal notranslate">country</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">database</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">database</code></a> is not specified, these queries
are first answered from the <code class="docutils literal notranslate">city</code> database if it is installed, and then from the <code class="docutils literal notranslate">country</code>
database if it is installed. Valid database names are <code class="docutils literal notranslate">country</code>,
<code class="docutils literal notranslate">city</code>, <code class="docutils literal notranslate">asnum</code>, <code class="docutils literal notranslate">isp</code>, and <code class="docutils literal notranslate">domain</code>.
Some example GeoIP ACLs:
<div class="highlight-default notranslate"><div class="highlight"><pre>geoip country US;
geoip country JP;
geoip db country country Canada;
geoip region WA;
geoip city &quot;San Francisco&quot;;
geoip region Oklahoma;
geoip postal 95062;
geoip tz &quot;America/Los_Angeles&quot;;
geoip org &quot;Internet Systems Consortium&quot;;
</pre></div>
</div>
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">{ 10/8; !10.0.0.1; }</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.
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 and only when it is
signed with a particular key, use:
<div class="highlight-default notranslate"><div class="highlight"><pre>allow-query { !{ !10/8; any; }; key example; };
</pre></div>
</div>
Within the nested ACL, any address that is not in the 10/8 network
prefix is rejected, which terminates the processing of the ACL.
Any address that is 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">example</code>, and rejected otherwise. The ACL, then, only
matches when both conditions are true.
</section>
<section id="chroot-and-setuid">
<h2>7.3. <code class="docutils literal notranslate">Chroot</code> and <code class="docutils literal notranslate">Setuid</code><a class="headerlink" href="#chroot-and-setuid" title="Permalink to this headline"></a></h2>
On Unix servers, it is possible to run BIND in a chrooted environment
(using the <code class="docutils literal notranslate">chroot()</code> function) by specifying the <a class="reference internal" href="manpages.html#cmdoption-named-t"><code class="xref std std-option docutils literal notranslate">-t</code></a> option for
<a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</code></a>. This can help improve system security by placing BIND in a
“sandbox,” which limits the damage done if a server is compromised.
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-1"><code class="xref std std-option docutils literal notranslate">-u</code></a> user). We suggest running
as an unprivileged user when using the <code class="docutils literal notranslate">chroot</code> feature.
Here is an example command line to load BIND in a <code class="docutils literal notranslate">chroot</code> sandbox,
<code class="docutils literal notranslate">/var/named</code>, and to run <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</code></a> <code class="docutils literal notranslate">setuid</code> to user 202:
<code class="docutils literal notranslate">/usr/local/sbin/named -u 202 -t /var/named</code>
<section id="the-chroot-environment">
<h3>7.3.1. The <code class="docutils literal notranslate">chroot</code> Environment<a class="headerlink" href="#the-chroot-environment" title="Permalink to this headline"></a></h3>
For a <code class="docutils literal notranslate">chroot</code> environment to work properly in a particular
directory (for example, <code class="docutils literal notranslate">/var/named</code>), the
environment must include everything BIND needs to run. From BIND’s
point of view, <code class="docutils literal notranslate">/var/named</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">directory</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">pid-file</code></a>
must be adjusted to account for this.
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">named</code></a> does not 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">/dev/zero</code>, <code class="docutils literal notranslate">/dev/random</code>, <code class="docutils literal notranslate">/dev/log</code>, and
<code class="docutils literal notranslate">/etc/localtime</code>.
</section>
<section id="using-the-setuid-function">
<h3>7.3.2. Using the <code class="docutils literal notranslate">setuid</code> Function<a class="headerlink" href="#using-the-setuid-function" title="Permalink to this headline"></a></h3>
Prior to running the <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</code></a> daemon, use the <code class="docutils literal notranslate">touch</code> utility (to
change file access and modification times) or the <code class="docutils literal notranslate">chown</code> utility (to
set the user id and/or group id) on files where BIND should
write.
<div class="admonition note">
Note
If the <a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</code></a> daemon is running as an unprivileged user, it
cannot bind to new restricted ports if the server is
reloaded.
</div>
</section>
</section>
<section id="dynamic-update-security">
<h2>7.4. Dynamic Update Security<a class="headerlink" href="#dynamic-update-security" title="Permalink to this headline"></a></h2>
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">allow-update</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">allow-update</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.
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">allow-update</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">update-policy</code></a> option can be used.
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.
</section>
<section id="tsig">
<h2>7.5. TSIG<a class="headerlink" href="#tsig" title="Permalink to this headline"></a></h2>
TSIG (Transaction SIGnatures) is a mechanism for authenticating DNS
messages, originally specified in <a class="rfc reference external" href="https://tools.ietf.org/html/rfc2845.html">RFC 2845</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.
This section is a guide to setting up TSIG in BIND. It describes the
configuration syntax and the process of creating TSIG keys.
<a class="reference internal" href="manpages.html#std-iscman-named"><code class="xref std std-iscman docutils literal notranslate">named</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">named</code></a>:
<blockquote>
<div><ul class="simple">
<li><a class="reference internal" href="manpages.html#man-nsupdate">nsupdate - dynamic DNS update utility</a> supports TSIG via the <a class="reference internal" href="manpages.html#cmdoption-nsupdate-k"><code class="xref std std-option docutils literal notranslate">-k</code></a>, <a class="reference internal" href="manpages.html#cmdoption-nsupdate-l"><code class="xref std std-option docutils literal notranslate">-l</code></a>, and <a class="reference internal" href="manpages.html#cmdoption-nsupdate-y"><code class="xref std std-option docutils literal notranslate">-y</code></a> command-line options, or via the <code class="docutils literal notranslate">key</code> command when running interactively.</li>
<li><a class="reference internal" href="manpages.html#man-dig">dig - DNS lookup utility</a> supports TSIG via the <a class="reference internal" href="manpages.html#cmdoption-dig-k"><code class="xref std std-option docutils literal notranslate">-k</code></a> and <a class="reference internal" href="manpages.html#cmdoption-dig-y"><code class="xref std std-option docutils literal notranslate">-y</code></a> command-line options.</li>
</ul>
</div></blockquote>
<section id="generating-a-shared-key">
<h3>7.5.1. Generating a Shared Key<a class="headerlink" href="#generating-a-shared-key" title="Permalink to this headline"></a></h3>
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">tsig-keygen</code></a> command; the output
of the command is a <code class="docutils literal notranslate">key</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">named.conf</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.
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">host1</code> and <code class="docutils literal notranslate">host2</code>
could be called “host1-host2.”, and this key can be generated using:
<div class="highlight-default notranslate"><div class="highlight"><pre>$ tsig-keygen host1-host2. &gt; host1-host2.key
</pre></div>
</div>
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.)
<a class="reference internal" href="manpages.html#std-iscman-tsig-keygen"><code class="xref std std-iscman docutils literal notranslate">tsig-keygen</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">ddns-confgen</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">named</code></a>. See <a class="reference internal" href="manpages.html#man-ddns-confgen">ddns-confgen - TSIG key generation tool</a> for details.
</section>
<section id="loading-a-new-key">
<h3>7.5.2. Loading a New Key<a class="headerlink" href="#loading-a-new-key" title="Permalink to this headline"></a></h3>
For a key shared between servers called <code class="docutils literal notranslate">host1</code> and <code class="docutils literal notranslate">host2</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">named.conf</code></a> file:
<div class="highlight-default notranslate"><div class="highlight"><pre>key &quot;host1-host2.&quot; {
 algorithm hmac-sha256;
 secret &quot;DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=&quot;;
};
</pre></div>
</div>
(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">tsig-keygen</code></a>.)
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">named.conf</code></a> not be world-readable, or that the <code class="docutils literal notranslate">key</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">named.conf</code></a> via the <code class="docutils literal notranslate">include</code> directive.
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">named.conf</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.
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">rndc tsig-list</code></a>.
</section>
<section id="instructing-the-server-to-use-a-key">
<h3>7.5.3. Instructing the Server to Use a Key<a class="headerlink" href="#instructing-the-server-to-use-a-key" title="Permalink to this headline"></a></h3>
A server sending a request to another server must be told whether to use
a key, and if so, which key to use.
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">primaries</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">also-notify</code></a> statement of a primary or secondary zone, causing NOTIFY
messages to be signed using the specified key.
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">server</code></a> directive. Adding the
following on <code class="docutils literal notranslate">host1</code>, if the IP address of <code class="docutils literal notranslate">host2</code> is 10.1.2.3, would
cause all requests from <code class="docutils literal notranslate">host1</code> to <code class="docutils literal notranslate">host2</code>, including normal DNS
queries, to be signed using the <code class="docutils literal notranslate">host1-host2.</code> key:
<div class="highlight-default notranslate"><div class="highlight"><pre>server 10.1.2.3 {
 keys { host1-host2. ;};
};
</pre></div>
</div>
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">keys</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.
Requests sent by <code class="docutils literal notranslate">host2</code> to <code class="docutils literal notranslate">host1</code> would not be signed, unless a
similar <code class="docutils literal notranslate">server</code> directive were in <code class="docutils literal notranslate">host2</code>’s configuration file.
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.
</section>
<section id="tsig-based-access-control">
<h3>7.5.4. TSIG-Based Access Control<a class="headerlink" href="#tsig-based-access-control" title="Permalink to this headline"></a></h3>
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">allow-query</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>, 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">allow-update</code></a>. The above key
would be denoted in an ACL element as <code class="docutils literal notranslate">key host1-host2.</code>
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">allow-update</code></a> directive using a TSIG key:
<div class="highlight-default notranslate"><div class="highlight"><pre>allow-update { !{ !localnets; any; }; key host1-host2. ;};
</pre></div>
</div>
This allows dynamic updates to succeed only if the UPDATE request comes
from an address in <code class="docutils literal notranslate">localnets</code>, and if it is signed using the
<code class="docutils literal notranslate">host1-host2.</code> key.
See <a class="reference internal" href="reference.html#dynamic-update-policies">Dynamic Update Policies</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">update-policy</code></a> statement.
</section>
<section id="errors">
<h3>7.5.5. Errors<a class="headerlink" href="#errors" title="Permalink to this headline"></a></h3>
Processing of TSIG-signed messages can result in several errors:
<ul class="simple">
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
In all of the above cases, the server returns a response code of
NOTAUTH (not authenticated).
</section>
</section>
<section id="tkey">
<h2>7.6. TKEY<a class="headerlink" href="#tkey" title="Permalink to this headline"></a></h2>
TKEY (Transaction KEY) is a mechanism for automatically negotiating a
shared secret between two hosts, originally specified in <a class="rfc reference external" href="https://tools.ietf.org/html/rfc2930.html">RFC 2930</a>.
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).
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.
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">rndc tsig-list</code></a>.
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">rndc tsig-delete</code></a>. This can also be done via the TKEY protocol
itself, by sending an authenticated TKEY query specifying the “key
deletion” mode.
</section>
<section id="sig-0">
<h2>7.7. SIG(0)<a class="headerlink" href="#sig-0" title="Permalink to this headline"></a></h2>
Support for DNSSEC SIG(0) transaction signatures has been removed.
This is a countermeasure for CVE-2024-1975.
</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"> Previous</a>
 <a href="reference.html" class="btn btn-neutral float-right" title="8. Configuration Reference" 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 : chapter7.html