Linux ns1.utparral.edu.mx 6.8.0-79-generic #79~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 15 16:54:53 UTC 2 x86_64
Apache/2.4.58 (Unix) OpenSSL/1.1.1w PHP/8.2.12 mod_perl/2.0.12 Perl/v5.34.1
: 10.10.1.9 | : 10.10.1.254
Cant Read [ /etc/named.conf ]
daemon
Terminal
AUTO ROOT
Adminer
Backdoor Destroyer
Linux Exploit
Lock Shell
Lock File
Create User
README
+ Create Folder
+ Create File
/
usr /
share /
doc /
bind9-doc /
arm /
[ HOME SHELL ]
Name
Size
Permission
Action
_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--
Delete
Unzip
Zip
${this.title}
Close
Code Editor : chapter1.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/" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>1. Introduction to DNS and BIND 9 — BIND 9 9.18.39-0ubuntu0.22.04.2-Ubuntu documentation</title> <link rel="stylesheet" href="_static/pygments.css" type="text/css" /> <link rel="stylesheet" href="_static/css/theme.css" type="text/css" /> <link rel="stylesheet" href="_static/custom.css" type="text/css" /> <script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script> <script src="_static/jquery.js"></script> <script src="_static/underscore.js"></script> <script src="_static/doctools.js"></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="2. Resource Requirements" href="chapter2.html" /> <link rel="prev" title="BIND 9 Administrator Reference Manual" href="index.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.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 current"><a class="current reference internal" href="#">1. Introduction to DNS and BIND 9</a><ul> <li class="toctree-l2"><a class="reference internal" href="#scope-of-document">1.1. Scope of Document</a></li> <li class="toctree-l2"><a class="reference internal" href="#organization-of-this-document">1.2. Organization of This Document</a></li> <li class="toctree-l2"><a class="reference internal" href="#conventions-used-in-this-document">1.3. Conventions Used in This Document</a></li> <li class="toctree-l2"><a class="reference internal" href="#the-domain-name-system-dns">1.4. The Domain Name System (DNS)</a><ul> <li class="toctree-l3"><a class="reference internal" href="#dns-fundamentals">1.4.1. DNS Fundamentals</a></li> <li class="toctree-l3"><a class="reference internal" href="#authority-and-delegation">1.4.2. Authority and Delegation</a></li> <li class="toctree-l3"><a class="reference internal" href="#root-servers">1.4.3. Root Servers</a></li> <li class="toctree-l3"><a class="reference internal" href="#name-resolution">1.4.4. Name Resolution</a></li> <li class="toctree-l3"><a class="reference internal" href="#dns-protocol-and-queries">1.4.5. DNS Protocol and Queries</a></li> <li class="toctree-l3"><a class="reference internal" href="#dns-and-bind-9">1.4.6. DNS and BIND 9</a></li> </ul> </li> <li class="toctree-l2"><a class="reference internal" href="#dns-security-overview">1.5. DNS Security Overview</a></li> </ul> </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"><a class="reference internal" href="chapter7.html">7. Security Configurations</a></li> <li class="toctree-l1"><a class="reference internal" href="reference.html">8. Configuration Reference</a></li> <li class="toctree-l1"><a class="reference internal" href="chapter9.html">9. Troubleshooting</a></li> <li class="toctree-l1"><a class="reference internal" href="chapter10.html">10. Building BIND 9</a></li> </ul> <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"></a> »</li> <li><span class="section-number">1. </span>Introduction to DNS and BIND 9</li> <li class="wy-breadcrumbs-aside"> <a href="_sources/chapter1.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="introduction-to-dns-and-bind-9"> <span id="introduction"></span><h1><span class="section-number">1. </span>Introduction to DNS and BIND 9<a class="headerlink" href="#introduction-to-dns-and-bind-9" title="Permalink to this headline"></a></h1> <p>The Internet Domain Name System (DNS) consists of:</p> <ul class="simple"> <li><p>the syntax to specify the names of entities in the Internet in a hierarchical manner,</p></li> <li><p>the rules used for delegating authority over names, and</p></li> <li><p>the system implementation that actually maps names to Internet addresses.</p></li> </ul> <p>DNS data is maintained in a group of distributed hierarchical databases.</p> <section id="scope-of-document"> <span id="doc-scope"></span><h2><span class="section-number">1.1. </span>Scope of Document<a class="headerlink" href="#scope-of-document" title="Permalink to this headline"></a></h2> <p>The Berkeley Internet Name Domain (BIND) software implements a domain name server for a number of operating systems. This document provides basic information about the installation and maintenance of Internet Systems Consortium (ISC) BIND version 9 software package for system administrators.</p> <p>This manual covers BIND version 9.18.39-0ubuntu0.22.04.2-Ubuntu.</p> </section> <section id="organization-of-this-document"> <span id="organization"></span><h2><span class="section-number">1.2. </span>Organization of This Document<a class="headerlink" href="#organization-of-this-document" title="Permalink to this headline"></a></h2> <p><a class="reference internal" href="#introduction"><span class="std std-ref">Introduction to DNS and BIND 9</span></a> introduces the basic DNS and BIND concepts. Some tutorial material on <a class="reference internal" href="#dns-overview"><span class="std std-ref">The Domain Name System (DNS)</span></a> is presented for those unfamiliar with DNS. A <a class="reference internal" href="#intro-dns-security"><span class="std std-ref">DNS Security Overview</span></a> is provided to allow BIND operators to implement appropriate security for their operational environment.</p> <p><a class="reference internal" href="chapter2.html#requirements"><span class="std std-ref">Resource Requirements</span></a> describes the hardware and environment requirements for BIND 9 and lists both the supported and unsupported platforms.</p> <p><a class="reference internal" href="chapter3.html#configuration"><span class="std std-ref">Configurations and Zone Files</span></a> is intended as a quickstart guide for newer users. Sample files are included for <a class="reference internal" href="chapter3.html#config-auth-samples"><span class="std std-ref">Authoritative Name Servers</span></a> (both <a class="reference internal" href="chapter3.html#sample-primary"><span class="std std-ref">primary</span></a> and <a class="reference internal" href="chapter3.html#sample-secondary"><span class="std std-ref">secondary</span></a>), as well as a simple <a class="reference internal" href="chapter3.html#config-resolver-samples"><span class="std std-ref">Resolver (Caching Name Servers)</span></a> and a <a class="reference internal" href="chapter3.html#sample-forwarding"><span class="std std-ref">Forwarding Resolver Configuration</span></a>. Some reference material on the <a class="reference internal" href="chapter3.html#zone-file"><span class="std std-ref">Zone File</span></a> is included.</p> <p><a class="reference internal" href="chapter4.html#ns-operations"><span class="std std-ref">Name Server Operations</span></a> covers basic BIND 9 software and DNS operations, including some useful tools, Unix signals, and plugins.</p> <p><a class="reference internal" href="chapter6.html#advanced"><span class="std std-ref">Advanced Configurations</span></a> builds on the configurations of <a class="reference internal" href="chapter3.html#configuration"><span class="std std-ref">Configurations and Zone Files</span></a>, adding functions and features the system administrator may need.</p> <p><a class="reference internal" href="chapter7.html#security"><span class="std std-ref">Security Configurations</span></a> covers most aspects of BIND 9 security, including file permissions, running BIND 9 in a “jail,” and securing file transfers and dynamic updates.</p> <p><a class="reference internal" href="chapter5.html#dnssec"><span class="std std-ref">DNSSEC</span></a> describes the theory and practice of cryptographic authentication of DNS information. The <a class="reference internal" href="dnssec-guide.html#dnssec-guide"><span class="std std-ref">DNSSEC Guide</span></a> is a practical guide to implementing DNSSEC.</p> <p><a class="reference internal" href="reference.html#reference"><span class="std std-ref">Configuration Reference</span></a> gives exhaustive descriptions of all supported blocks, statements, and grammars used in BIND 9’s <code class="docutils literal notranslate"><span class="pre">named.conf</span></code> configuration file.</p> <p><a class="reference internal" href="chapter9.html#troubleshooting"><span class="std std-ref">Troubleshooting</span></a> provides information on identifying and solving BIND 9 and DNS problems. Information about bug-reporting procedures is also provided.</p> <p><a class="reference internal" href="chapter10.html#build-bind"><span class="std std-ref">Building BIND 9</span></a> is a definitive guide for those occasions where the user requires special options not provided in the standard Linux or Unix distributions.</p> <p>The <strong>Appendices</strong> contain useful reference information, such as a bibliography and historic information related to BIND and the Domain Name System, as well as the current <em>man</em> pages for all the published tools.</p> </section> <section id="conventions-used-in-this-document"> <span id="conventions"></span><h2><span class="section-number">1.3. </span>Conventions Used in This Document<a class="headerlink" href="#conventions-used-in-this-document" title="Permalink to this headline"></a></h2> <p>In this document, we generally use <code class="docutils literal notranslate"><span class="pre">fixed-width</span></code> text to indicate the following types of information:</p> <ul class="simple"> <li><p>pathnames</p></li> <li><p>filenames</p></li> <li><p>URLs</p></li> <li><p>hostnames</p></li> <li><p>mailing list names</p></li> <li><p>new terms or concepts</p></li> <li><p>literal user input</p></li> <li><p>program output</p></li> <li><p>keywords</p></li> <li><p>variables</p></li> </ul> <p>Text in “quotes,” <strong>bold text</strong>, or <em>italics</em> is also used for emphasis or clarity.</p> </section> <section id="the-domain-name-system-dns"> <span id="dns-overview"></span><h2><span class="section-number">1.4. </span>The Domain Name System (DNS)<a class="headerlink" href="#the-domain-name-system-dns" title="Permalink to this headline"></a></h2> <p>This is a brief description of the functionality and organization of the Domain Name System (DNS). It is provided to familiarize users with the concepts involved, the (often confusing) terminology used, and how all the parts fit together to form an operational system.</p> <p>All network systems operate with network addresses, such as IPv4 and IPv6. The vast majority of humans find it easier to work with names rather than seemingly endless strings of network address digits. The earliest ARPANET systems (from which the Internet evolved) mapped names to addresses using a <strong>hosts</strong> file that was distributed to all entities whenever changes occurred. Operationally, such a system became rapidly unsustainable once there were more than 100 networked entities, which led to the specification and implementation of the Domain Name System that we use today.</p> <section id="dns-fundamentals"> <span id="id1"></span><h3><span class="section-number">1.4.1. </span>DNS Fundamentals<a class="headerlink" href="#dns-fundamentals" title="Permalink to this headline"></a></h3> <p>The DNS naming system is organized as a tree structure comprised of multiple levels and thus it naturally creates a distributed system. Each node in the tree is given a label which defines its <strong>Domain</strong> (its area or zone) of <strong>Authority</strong>. The topmost node in the tree is the <strong>Root Domain</strong>; it delegates to <strong>Domains</strong> at the next level which are generically known as the <strong>Top-Level Domains (TLDs)</strong>. They in turn delegate to <strong>Second-Level Domains (SLDs)</strong>, and so on. The Top-Level Domains (TLDs) include a special group of TLDs called the <strong>Country Code Top-Level Domains (ccTLDs)</strong>, in which every country is assigned a unique two-character country code from ISO 3166 as its domain.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>The Domain Name System is controlled by ICANN (<a class="reference external" href="https://www.icann.org">https://www.icann.org</a>) (a 501c non-profit entity); their current policy is that any new TLD, consisting of three or more characters, may be proposed by any group of commercial sponsors and if it meets ICANN’s criteria will be added to the TLDs.</p> </div> <p>The concept of delegation and authority flows down the DNS tree (the DNS hierarchy) as shown:</p> <figure class="align-center" id="id3"> <img alt="_images/dns-tree.png" src="_images/dns-tree.png" /> <figcaption> <p><span class="caption-text">Delegation and Authority in the DNS Name Space</span><a class="headerlink" href="#id3" title="Permalink to this image"></a></p> </figcaption> </figure> <p>A domain is the label of a node in the tree. A <strong>domain name</strong> uniquely identifies any node in the DNS tree and is written, left to right, by combining all the domain labels (each of which are unique within their parent’s zone or domain of authority), with a dot separating each component, up to the root domain. In the above diagram the following are all domain names:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">example</span><span class="o">.</span><span class="n">com</span> <span class="n">b</span><span class="o">.</span><span class="n">com</span> <span class="n">ac</span><span class="o">.</span><span class="n">uk</span> <span class="n">us</span> <span class="n">org</span> </pre></div> </div> <p>The root has a unique label of “.” (dot), which is normally omitted when it is written as a domain name, but when it is written as a <strong>Fully Qualified Domain Name (FQDN)</strong> the dot must be present. Thus:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">example</span><span class="o">.</span><span class="n">com</span> <span class="c1"># domain name</span> <span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">.</span> <span class="c1"># FQDN</span> </pre></div> </div> </section> <section id="authority-and-delegation"> <h3><span class="section-number">1.4.2. </span>Authority and Delegation<a class="headerlink" href="#authority-and-delegation" title="Permalink to this headline"></a></h3> <p>Each domain (node) has been <strong>delegated</strong> the authority from its parent domain. The delegated authority includes specific responsibilities to ensure that every domain it delegates has a unique name or label within its zone or domain of authority, and that it maintains an <strong>authoritative</strong> list of its delegated domains. The responsibilities further include an operational requirement to operate two (or more) name servers (which may be contracted to a third party) which will contain the authoritative data for all the domain labels within its zone of authority in a <a class="reference internal" href="chapter3.html#zone-file"><span class="std std-ref">zone file</span></a>. Again, the tree structure ensures that the DNS name space is naturally distributed.</p> <p>The following diagram illustrates that <strong>Authoritative Name Servers</strong> exist for every level and every domain in the DNS name space:</p> <figure class="align-center" id="id4"> <img alt="_images/dns-servers.png" src="_images/dns-servers.png" /> <figcaption> <p><span class="caption-text">Authoritative Name Servers in the DNS Name Space</span><a class="headerlink" href="#id4" title="Permalink to this image"></a></p> </figcaption> </figure> <div class="admonition note"> <p class="admonition-title">Note</p> <p>The difference between a domain and a zone can appear confusing. Practically, the terms are generally used synonymously in the DNS. If, however, you are into directed graphs and tree structure theory or similar exotica, a zone can be considered as an arc through any node (or domain) with the domain at its apex. The zone therefore encompasses all the name space below the domain. This can, however, lead to the concept of subzones and these were indeed defined in the original DNS specifications. Thankfully the term subzone has been lost in the mists of time.</p> </div> </section> <section id="root-servers"> <span id="id2"></span><h3><span class="section-number">1.4.3. </span>Root Servers<a class="headerlink" href="#root-servers" title="Permalink to this headline"></a></h3> <p>The <strong>root servers</strong> are a critical part of the DNS authoritative infrastructure. There are 13 root servers (<em>a.root-servers.net</em> to <em>m.root-servers.net</em>). The number 13 is historically based on the maximum amount of name and IPv4 data that could be packed into a 512-byte UDP message, and not a perverse affinity for a number that certain cultures treat as unlucky. The 512-byte UDP data limit is no longer a limiting factor and all root servers now support both IPv4 and IPv6. In addition, almost all the root servers use <strong>anycast</strong>, with well over 300 instances of the root servers now providing service worldwide (see further information at <a class="reference external" href="https://root-servers.org">https://root-servers.org</a>). The root servers are the starting point for all <strong>name resolution</strong> within the DNS.</p> </section> <section id="name-resolution"> <h3><span class="section-number">1.4.4. </span>Name Resolution<a class="headerlink" href="#name-resolution" title="Permalink to this headline"></a></h3> <p>So far all the emphasis has been on how the DNS stores its authoritative domain (zone) data. End-user systems use names (an email address or a web address) and need to access this authoritative data to obtain an IP address, which they use to contact the required network resources such as web, FTP, or mail servers. The process of converting a domain name to a result (typically an IP address, though other types of data may be obtained) is generically called <strong>name resolution</strong>, and is handled by <strong>resolvers</strong> (also known as <strong>caching name servers</strong> and many other terms). The following diagram shows the typical name resolution process:</p> <figure class="align-center" id="id5"> <img alt="_images/name-resolution.png" src="_images/name-resolution.png" /> <figcaption> <p><span class="caption-text">Authoritative Name Servers and Name Resolution</span><a class="headerlink" href="#id5" title="Permalink to this image"></a></p> </figcaption> </figure> <p>An end-user application, such as a browser (1), when needing to resolve a name such as <strong>www.example.com</strong>, makes an internal system call to a minimal function resolution entity called a <strong>stub resolver</strong> (2). The stub resolver (using stored IP addresses) contacts a resolver (a caching name server or full-service resolver) (3), which in turn contacts all the necessary authoritative name servers (4, 5, and 6) to provide the answer that it then returns to the user (2, 1). To improve performance, all resolvers (including most stub resolvers) cache (store) their results such that a subsequent request for the same data is taken from the resolver’s cache, removing the need to repeat the name resolution process and use time-consuming resources. All communication between the stub resolver, the resolver, and the authoritative name servers uses the DNS protocol’s query and response message pair.</p> </section> <section id="dns-protocol-and-queries"> <span id="iterative-query"></span><span id="recursive-query"></span><span id="referral"></span><h3><span class="section-number">1.4.5. </span>DNS Protocol and Queries<a class="headerlink" href="#dns-protocol-and-queries" title="Permalink to this headline"></a></h3> <p>DNS <strong>queries</strong> use the UDP protocol over the reserved port 53 (but both TCP and TLS can optionally be used in some parts of the network).</p> <p>The following diagram shows the name resolution process expressed in terms of DNS queries and responses.</p> <figure class="align-center" id="id6"> <img alt="_images/recursive-query.png" src="_images/recursive-query.png" /> <figcaption> <p><span class="caption-text">Resolvers and Queries</span><a class="headerlink" href="#id6" title="Permalink to this image"></a></p> </figcaption> </figure> <p>The stub resolver sends a <strong>recursive query</strong> message (with the required domain name in the QUESTION section of the query) (2) to the resolver. A <strong>recursive</strong> query simply requests the resolver to find the complete answer. A stub resolver only ever sends recursive queries and always needs the service of a resolver. The response to a recursive query can be:</p> <ol class="arabic simple"> <li><p>The answer to the user’s QUESTION in the ANSWER section of the query response.</p></li> <li><p>An error (such as NXDOMAIN - the name does not exist).</p></li> </ol> <p>The resolver, on receipt of the user’s recursive query, either responds immediately, if the ANSWER is in its cache, or accesses the DNS hierarchy to obtain the answer. The resolver always starts with root servers and sends an <strong>iterative query</strong> (4, 5, and 6). The response to an iterative query can be:</p> <ol class="arabic simple"> <li><p>The answer to the resolver’s QUESTION in the ANSWER section of the query response.</p></li> </ol> <p>2. A <strong>referral</strong> (indicated by an empty ANSWER section but data in the AUTHORITY section, and typically IP addresses in the ADDITIONAL section of the response).</p> <ol class="arabic simple" start="3"> <li><p>An error (such as NXDOMAIN - the name does not exist).</p></li> </ol> <p>If the response is either an answer or an error, these are returned immediately to the user (and cached for future use). If the response is a referral, the resolver needs to take additional action to respond to the user’s recursive query.</p> <p>A referral, in essence, indicates that the queried server does not know the answer (the ANSWER section of the response is empty), but it refers the resolver to the authoritative name servers (in the AUTHORITY section of the response) which it knows about in the domain name supplied in the QUESTION section of the query. Thus, if the QUESTION is for the domain name <strong>www.example.com</strong>, the root server to which the iterative query was sent adds a list of the <strong>.com authoritative name servers</strong> in the AUTHORITY section. The resolver selects one of the servers from the AUTHORITY section and sends an iterative query to it. Similarly, the .com authoritative name servers send a referral containing a list of the <strong>example.com</strong> authoritative name servers. This process continues down the DNS hierarchy until either an ANSWER or an error is received, at which point the user’s original recursive query is sent a response.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>The DNS hierarchy is always accessed starting at the root servers and working down; there is no concept of “up” in the DNS hierarchy. Clearly, if the resolver has already cached the list of .com authoritative name servers and the user’s recursive query QUESTION contains a domain name ending in .com, it can omit access to the root servers. However, that is simply an artifact (in this case a performance benefit) of caching and does not change the concept of top-down access within the DNS hierarchy.</p> </div> <p>The insatiably curious may find reading <span class="target" id="index-0"></span><a class="rfc reference external" href="https://tools.ietf.org/html/rfc1034.html"><strong>RFC 1034</strong></a> and <span class="target" id="index-1"></span><a class="rfc reference external" href="https://tools.ietf.org/html/rfc1035.html"><strong>RFC 1035</strong></a> a useful starting point for further information.</p> </section> <section id="dns-and-bind-9"> <h3><span class="section-number">1.4.6. </span>DNS and BIND 9<a class="headerlink" href="#dns-and-bind-9" title="Permalink to this headline"></a></h3> <p>BIND 9 is a complete implementation of the DNS protocol. BIND 9 can be configured (using its <code class="docutils literal notranslate"><span class="pre">named.conf</span></code> file) as an authoritative name server, a resolver, and, on supported hosts, a stub resolver. While large operators usually dedicate DNS servers to a single function per system, smaller operators will find that BIND 9’s flexible configuration features support multiple functions, such as a single DNS server acting as both an authoritative name server and a resolver.</p> <p>Example configurations of basic <a class="reference internal" href="chapter3.html#config-auth-samples"><span class="std std-ref">authoritative name servers</span></a> and <a class="reference internal" href="chapter3.html#config-resolver-samples"><span class="std std-ref">resolvers and forwarding resolvers</span></a>, as well as <a class="reference internal" href="chapter6.html#advanced"><span class="std std-ref">advanced configurations</span></a> and <a class="reference internal" href="chapter7.html#security"><span class="std std-ref">secure configurations</span></a>, are provided.</p> </section> </section> <section id="dns-security-overview"> <span id="intro-dns-security"></span><h2><span class="section-number">1.5. </span>DNS Security Overview<a class="headerlink" href="#dns-security-overview" title="Permalink to this headline"></a></h2> <p>DNS is a communications protocol. All communications protocols are potentially vulnerable to both subversion and eavesdropping. It is important for users to audit their exposure to the various threats within their operational environment and implement the appropriate solutions. BIND 9, a specific implementation of the DNS protocol, provides an extensive set of security features. The purpose of this section is to help users to select from the range of available security features those required for their specific user environment.</p> <p>A generic DNS network is shown below, followed by text descriptions. In general, the further one goes from the left-hand side of the diagram, the more complex the implementation.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>Historically, DNS data was regarded as public and security was concerned, primarily, with ensuring the integrity of DNS data. DNS data privacy is increasingly regarded as an important dimension of overall security, specifically <a class="reference internal" href="chapter7.html#dns-over-tls"><span class="std std-ref">DNS over TLS</span></a>.</p> </div> <figure class="align-center" id="id7"> <img alt="_images/dns-security-overview.png" src="_images/dns-security-overview.png" /> <figcaption> <p><span class="caption-text">BIND 9 Security Overview</span><a class="headerlink" href="#id7" title="Permalink to this image"></a></p> </figcaption> </figure> <p>The following notes refer to the numbered elements in the above diagram.</p> <p>1. A variety of system administration techniques and methods may be used to secure BIND 9’s local environment, including <a class="reference internal" href="chapter7.html#file-permissions"><span class="std std-ref">file permissions</span></a>, running BIND 9 in a <a class="reference internal" href="chapter7.html#chroot-and-setuid"><span class="std std-ref">jail</span></a>, and the use of <a class="reference internal" href="chapter7.html#access-control-lists"><span class="std std-ref">Access Control Lists</span></a>.</p> <p>2. The remote name daemon control (<a class="reference internal" href="chapter4.html#ops-rndc"><span class="std std-ref">rndc</span></a>) program allows the system administrator to control the operation of a name server. The majority of BIND 9 packages or ports come preconfigured with local (loopback address) security preconfigured. If <code class="docutils literal notranslate"><span class="pre">rndc</span></code> is being invoked from a remote host, further configuration is required. The <code class="docutils literal notranslate"><span class="pre">nsupdate</span></code> tool uses <strong>Dynamic DNS (DDNS)</strong> features and allows users to dynamically change the contents of the zone file(s). <code class="docutils literal notranslate"><span class="pre">nsupdate</span></code> access and security may be controlled using <code class="docutils literal notranslate"><span class="pre">named.conf</span></code> <a class="reference internal" href="chapter7.html#dynamic-update-security"><span class="std std-ref">statements or via the TSIG cryptographic method</span></a>. Clearly, if the remote hosts used for either <code class="docutils literal notranslate"><span class="pre">rndc</span></code> or DDNS lie within a network entirely under the user’s control, the security threat may be regarded as non-existent. Any implementation requirements, therefore, depend on the site’s security policy.</p> <p>3. Zone transfer from a <strong>primary</strong> to one or more <strong>secondary</strong> authoritative name servers across a public network carries risk. The zone transfer may be secured using <code class="docutils literal notranslate"><span class="pre">named.conf</span></code> <a class="reference internal" href="chapter7.html#sec-file-transfer"><span class="std std-ref">statements, TSIG cryptographic methods, or TLS</span></a>. Clearly, if the secondary authoritative name server(s) all lie within a network entirely under the user’s control, the security threat may be regarded as non-existent. Any implementation requirements again depend on the site’s security policy.</p> <p>4. If the operator of an authoritative name server (primary or secondary) wishes to ensure that DNS responses to user-initiated queries about the zone(s) for which they are responsible can only have come from their server, that the data received by the user is the same as that sent, and that non-existent names are genuine, then <a class="reference internal" href="chapter5.html#dnssec"><span class="std std-ref">DNSSEC</span></a> is the only solution. DNSSEC requires configuration and operational changes both to the authoritative name servers and to any resolver which accesses those servers.</p> <p>5. The typical Internet-connected end-user device (PCs, laptops, and even mobile phones) either has a stub resolver or operates via a DNS proxy. A stub resolver requires the services of an area or full-service resolver to completely answer user queries. Stub resolvers on the majority of PCs and laptops typically have a caching capability to increase performance. At this time there are no standard stub resolvers or proxy DNS tools that implement DNSSEC. BIND 9 may be configured to provide such capability on supported Linux or Unix platforms. <a class="reference internal" href="chapter7.html#dns-over-tls"><span class="std std-ref">DNS over TLS</span></a> may be configured to verify the integrity of the data between the stub resolver and area (or full-service) resolver. However, unless the resolver and the authoritative name server implements DNSSEC, end-to-end integrity (from authoritative name server to stub resolver) cannot be guaranteed.</p> </section> </section> </div> </div> <footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer"> <a href="index.html" class="btn btn-neutral float-left" title="BIND 9 Administrator Reference Manual" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a> <a href="chapter2.html" class="btn btn-neutral float-right" title="2. Resource Requirements" 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>
Close