diff --git a/doc/arm/Makefile.am b/doc/arm/Makefile.am index 57612a6fcc..52bc19b9fb 100644 --- a/doc/arm/Makefile.am +++ b/doc/arm/Makefile.am @@ -13,19 +13,31 @@ EXTRA_DIST = \ dlz.inc.rst \ dnssec-guide.rst \ dnssec.inc.rst \ + dns-security-overview.dia \ + dns-security-overview.png \ + dns-servers.dia \ + dns-servers.png \ + dns-tree.dia \ + dns-tree.png \ dyndb.inc.rst \ general.rst \ history.rst \ index.rst \ + intro-dns-bind.inc.rst \ introduction.inc.rst \ + intro-security.inc.rst \ isc-logo.pdf \ logging-categories.inc.rst \ managed-keys.inc.rst \ manpages.rst \ + name-resolution.dia \ + name-resolution.png \ notes.rst \ pkcs11.inc.rst \ platforms.inc.rst \ plugins.inc.rst \ + recursive-query.dia \ + recursive-query.png \ reference.rst \ requirements.inc.rst \ requirements.txt \ diff --git a/doc/arm/chapter1.rst b/doc/arm/chapter1.rst index a392637fdf..d3d0c708c7 100644 --- a/doc/arm/chapter1.rst +++ b/doc/arm/chapter1.rst @@ -10,3 +10,5 @@ .. information regarding copyright ownership. .. include:: introduction.inc.rst +.. include:: intro-dns-bind.inc.rst +.. include:: intro-security.inc.rst diff --git a/doc/arm/dns-security-overview.dia b/doc/arm/dns-security-overview.dia new file mode 100644 index 0000000000..77f00f34a5 Binary files /dev/null and b/doc/arm/dns-security-overview.dia differ diff --git a/doc/arm/dns-security-overview.png b/doc/arm/dns-security-overview.png new file mode 100644 index 0000000000..28e92202dc Binary files /dev/null and b/doc/arm/dns-security-overview.png differ diff --git a/doc/arm/dns-servers.dia b/doc/arm/dns-servers.dia new file mode 100644 index 0000000000..caabefe133 Binary files /dev/null and b/doc/arm/dns-servers.dia differ diff --git a/doc/arm/dns-servers.png b/doc/arm/dns-servers.png new file mode 100644 index 0000000000..14a7bea765 Binary files /dev/null and b/doc/arm/dns-servers.png differ diff --git a/doc/arm/dns-tree.dia b/doc/arm/dns-tree.dia new file mode 100644 index 0000000000..052e7ee766 Binary files /dev/null and b/doc/arm/dns-tree.dia differ diff --git a/doc/arm/dns-tree.png b/doc/arm/dns-tree.png new file mode 100644 index 0000000000..c76ae1bbf7 Binary files /dev/null and b/doc/arm/dns-tree.png differ diff --git a/doc/arm/intro-dns-bind.inc.rst b/doc/arm/intro-dns-bind.inc.rst new file mode 100644 index 0000000000..f8a61c4c43 --- /dev/null +++ b/doc/arm/intro-dns-bind.inc.rst @@ -0,0 +1,197 @@ +.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") +.. +.. SPDX-License-Identifier: MPL-2.0 +.. +.. This Source Code Form is subject to the terms of the Mozilla Public +.. License, v. 2.0. If a copy of the MPL was not distributed with this +.. file, you can obtain one at https://mozilla.org/MPL/2.0/. +.. +.. See the COPYRIGHT file distributed with this work for additional +.. information regarding copyright ownership. + +.. _dns_overview: + +The Domain Name System (DNS) +---------------------------- + +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. + +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 **hosts** 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. + +.. _dns_fundamentals: + +DNS Fundamentals +~~~~~~~~~~~~~~~~ + +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 **Domain** (its area or zone) of **Authority**. +The topmost node in the tree is the **Root Domain**; it delegates to **Domains** at the next level which are generically +known as the **Top-Level Domains (TLDs)**. They in turn delegate to **Second-Level Domains (SLDs)**, and so on. +The Top-Level Domains (TLDs) include a special group of TLDs called the **Country Code Top-Level Domains (ccTLDs)**, +in which every country is assigned a unique two-character country code from ISO 3166 as its domain. + +.. Note:: The Domain Name System is controlled by ICANN (https://www.icann.org) (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. + +The concept of delegation and authority flows down the DNS tree (the DNS hierarchy) as shown: + +.. figure:: dns-tree.png + :align: center + + Delegation and Authority in the DNS Name Space + +A domain is the label of a node in the tree. A **domain name** 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: + +.. code-block:: + + example.com + b.com + ac.uk + us + org + +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 **Fully Qualified Domain Name (FQDN)** the dot must be present. Thus: + +.. code-block:: + + example.com # domain name + example.com. # FQDN + +Authority and Delegation +~~~~~~~~~~~~~~~~~~~~~~~~ + +Each domain (node) has been **delegated** 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 **authoritative** 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 :ref:`zone file`. Again, the +tree structure ensures that the DNS name space is naturally distributed. + +The following diagram illustrates that **Authoritative Name Servers** exist for every level and every domain in the DNS name space: + +.. figure:: dns-servers.png + :align: center + + Authoritative Name Servers in the DNS Name Space + +.. Note:: 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. + +.. _root_servers: + +Root Servers +~~~~~~~~~~~~ + +The **root servers** are a critical part of the DNS authoritative infrastructure. There are 13 root servers (*a.root-servers.net* +to *m.root-servers.net*). 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 **anycast**, with well over +300 instances of the root servers now providing service worldwide (see further information at https://www.root-servers.org). +The root servers are the starting point for all **name resolution** within the DNS. + +Name Resolution +~~~~~~~~~~~~~~~ + +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 **name resolution**, and is handled by +**resolvers** (also known as **caching name servers** and many other terms). The following diagram shows the typical name resolution process: + +.. figure:: name-resolution.png + :align: center + + Authoritative Name Servers and Name Resolution + +An end-user application, such as a browser (1), when needing to resolve a name such as **www.example.com**, makes an +internal system call to a minimal function resolution entity called a **stub resolver** (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. + +.. _referral: + +.. _recursive_query: + +.. _iterative_query: + +DNS Protocol and Queries +~~~~~~~~~~~~~~~~~~~~~~~~ + +DNS **queries** use the UDP protocol over the reserved port 53 (but both TCP and TLS can optionally be used in some parts of the network). + +The following diagram shows the name resolution process expressed in terms of DNS queries and responses. + +.. figure:: recursive-query.png + :align: center + + Resolvers and Queries + +The stub resolver sends a **recursive query** message (with the required domain name in the QUESTION section of the query) (2) to the resolver. +A **recursive** 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: + +1. The answer to the user's QUESTION in the ANSWER section of the query response. + +2. An error (such as NXDOMAIN - the name does not exist). + +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 **iterative query** (4, 5, and 6). The +response to an iterative query can be: + +1. The answer to the resolver's QUESTION in the ANSWER section of the query response. + +2. A **referral** (indicated by an empty ANSWER section but data in the AUTHORITY section, +and typically IP addresses in the ADDITIONAL section of the response). + +3. An error (such as NXDOMAIN - the name does not exist). + +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. + +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 **www.example.com**, the root +server to which the iterative query was sent adds a list of the **.com authoritative name servers** 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 **example.com** 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. + +.. Note:: 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. + +The insatiably curious may find reading :rfc:`1034` and :rfc:`1035` a useful starting point for further information. + +DNS and BIND 9 +~~~~~~~~~~~~~~ + +BIND 9 is a complete implementation of the DNS protocol. BIND 9 can be configured (using its ``named.conf`` 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. + +Example configurations of basic :ref:`authoritative name servers` and +:ref:`resolvers and forwarding resolvers`, as +well as :ref:`advanced configurations` and :ref:`secure configurations`, are provided. diff --git a/doc/arm/intro-security.inc.rst b/doc/arm/intro-security.inc.rst new file mode 100644 index 0000000000..40abef87c2 --- /dev/null +++ b/doc/arm/intro-security.inc.rst @@ -0,0 +1,76 @@ +.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") +.. +.. SPDX-License-Identifier: MPL-2.0 +.. +.. This Source Code Form is subject to the terms of the Mozilla Public +.. License, v. 2.0. If a copy of the MPL was not distributed with this +.. file, you can obtain one at https://mozilla.org/MPL/2.0/. +.. +.. See the COPYRIGHT file distributed with this work for additional +.. information regarding copyright ownership. + +.. _intro_dns_security: + +DNS Security Overview +--------------------- + +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. + +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. + +.. Note:: 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 :ref:`DNS over TLS`. + +.. figure:: dns-security-overview.png + :align: center + + BIND 9 Security Overview + +The following notes refer to the numbered elements in the above diagram. + +1. A variety of system administration techniques and methods may be used to secure +BIND 9's local environment, including :ref:`file permissions `, running +BIND 9 in a :ref:`jail `, and the use of :ref:`Access_Control_Lists`. + +2. The remote name daemon control (:ref:`rndc`) 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 ``rndc`` is being invoked from a remote host, further configuration is required. +The ``nsupdate`` tool uses **Dynamic DNS (DDNS)** features and allows users to dynamically +change the contents of the zone file(s). ``nsupdate`` access and security may be controlled +using ``named.conf`` :ref:`statements or using TSIG or SIG(0) cryptographic methods `. +Clearly, if the remote hosts used for either ``rndc`` 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. + +3. Zone transfer from a **primary** to one or more **secondary** authoritative name servers across a +public network carries risk. The zone transfer may be secured using +``named.conf`` :ref:`statements, TSIG cryptographic methods or TLS`. +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. + +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 :ref:`DNSSEC` is the only solution. DNSSEC requires configuration +and operational changes both to the authoritative name servers and to any resolver which accesses +those servers. + +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. +:ref:`DNS over TLS ` 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. diff --git a/doc/arm/introduction.inc.rst b/doc/arm/introduction.inc.rst index fc80fb8119..009a702347 100644 --- a/doc/arm/introduction.inc.rst +++ b/doc/arm/introduction.inc.rst @@ -9,25 +9,27 @@ .. See the COPYRIGHT file distributed with this work for additional .. information regarding copyright ownership. -.. _Introduction: +.. _introduction: -Introduction -============ +Introduction to DNS and BIND 9 +============================== -The Internet Domain Name System (DNS) consists of the syntax to specify -the names of entities in the Internet in a hierarchical manner, the -rules used for delegating authority over names, and the system -implementation that actually maps names to Internet addresses. DNS data -is maintained in a group of distributed hierarchical databases. +The Internet Domain Name System (DNS) consists of: + +- the syntax to specify the names of entities in the Internet in a hierarchical manner, +- the rules used for delegating authority over names, and +- the system implementation that actually maps names to Internet addresses. + +DNS data is maintained in a group of distributed hierarchical databases. .. _doc_scope: Scope of Document ----------------- -The Berkeley Internet Name Domain (BIND) implements a domain name server +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 care of the Internet Systems +information about the installation and maintenance of Internet Systems Consortium (ISC) BIND version 9 software package for system administrators. @@ -38,25 +40,50 @@ This manual covers BIND version |release|. Organization of This Document ----------------------------- -In this document, *Chapter 1* introduces the basic DNS and BIND -concepts. *Chapter 2* describes resource requirements for running BIND -in various environments. Information in *Chapter 3* is *task-oriented* -in its presentation and is organized functionally, to aid in the process -of installing the BIND 9 software. The task-oriented section is followed -by *Chapter 4*, which is organized as a reference manual to aid in the ongoing -maintenance of the software. *Chapter 5* contains more advanced concepts that -the system administrator may need for implementing certain options. *Chapter 6* -addresses security considerations, and *Chapter 7* contains troubleshooting help. -The main body of the document is followed by several *appendices* which contain -useful reference information, such as a *bibliography* and historic -information related to BIND and the Domain Name System. +:ref:`introduction` introduces the basic DNS and BIND concepts. Some tutorial material on +:ref:`dns_overview` is presented for those unfamiliar with DNS. A +:ref:`intro_dns_security` is provided to allow BIND operators to implement +appropriate security for their operational environment. + +:ref:`requirements` describes the hardware and environment requirements for BIND 9 +and lists both the supported and unsupported platforms. + +:ref:`configuration` is intended as a quickstart guide for newer users. Sample files +are included for :ref:`config_auth_samples` (both :ref:`primary` and +:ref:`secondary`), as well as a simple :ref:`config_resolver_samples` and +a :ref:`sample_forwarding`. Some reference material on the :ref:`Zone File` is included. + +:ref:`ns_operations` covers basic BIND 9 software and DNS operations, including some +useful tools, Unix signals, and plugins. + +:ref:`advanced` builds on the configurations of :ref:`configuration`, adding +functions and features the system administrator may need. + +:ref:`security` covers most aspects of BIND 9 security, including file permissions, +running BIND 9 in a "jail," and securing file transfers and dynamic updates. + +:ref:`dnssec` describes the theory and practice of cryptographic authentication of DNS +information. The :ref:`dnssec_guide` is a practical guide to implementing DNSSEC. + +:ref:`Reference` gives exhaustive descriptions of all supported clauses, statements, +and grammars used in BIND 9's ``named.conf`` configuration file. + +:ref:`troubleshooting` provides information on identifying and solving BIND 9 and DNS +problems. Information about bug-reporting procedures is also provided. + +:ref:`build_bind` is a definitive guide for those occasions where the user requires +special options not provided in the standard Linux or Unix distributions. + +The **Appendices** contain useful reference information, such as a bibliography and historic +information related to BIND and the Domain Name System, as well as the current *man* +pages for all the published tools. .. _conventions: Conventions Used in This Document --------------------------------- -In this document, we generally use ``Fixed Width`` text to indicate the +In this document, we generally use ``fixed-width`` text to indicate the following types of information: - pathnames @@ -70,242 +97,4 @@ following types of information: - keywords - variables -Text in "quotes," **bold**, or *italics* is also used for emphasis or clarity. - -.. _dns_overview: - -The Domain Name System (DNS) ----------------------------- - -This document explains the installation and upkeep -of the BIND (Berkeley Internet Name Domain) software package. We -begin by reviewing the fundamentals of the Domain Name System (DNS) as -they relate to BIND. - -.. _dns_fundamentals: - -DNS Fundamentals -~~~~~~~~~~~~~~~~ - -The Domain Name System (DNS) is a hierarchical, distributed database. It -stores information for mapping Internet host names to IP addresses and -vice versa, mail routing information, and other data used by Internet -applications. - -Clients look up information in the DNS by calling a *resolver* library, -which sends queries to one or more *name servers* and interprets the -responses. The BIND 9 software distribution contains a name server, -:iscman:`named`, and a set of associated tools. - -.. _domain_names: - -Domains and Domain Names -~~~~~~~~~~~~~~~~~~~~~~~~ - -The data stored in the DNS is identified by *domain names* that are -organized as a tree according to organizational or administrative -boundaries. Each node of the tree, called a *domain*, is given a label. -The domain name of the node is the concatenation of all the labels on -the path from the node to the *root* node. This is represented in -written form as a string of labels listed from right to left and -separated by dots. A label need only be unique within its parent domain. - -For example, a domain name for a host at the company *Example, Inc.* -could be ``ourhost.example.com``, where ``com`` is the top-level domain -to which ``ourhost.example.com`` belongs, ``example`` is a subdomain of -``com``, and ``ourhost`` is the name of the host. - -For administrative purposes, the name space is partitioned into areas -called *zones*, each starting at a node and extending down to the "leaf" -nodes or to nodes where other zones start. The data for each zone is -stored in a *name server*, which answers queries about the zone using -the *DNS protocol*. - -The data associated with each domain name is stored in the form of -*resource records* (RRs). Some of the supported resource record types -are described in :ref:`types_of_resource_records_and_when_to_use_them`. - -For more detailed information about the design of the DNS and the DNS -protocol, please refer to the standards documents listed in :ref:`rfcs`. - -Zones -~~~~~ - -To properly operate a name server, it is important to understand the -difference between a *zone* and a *domain*. - -As stated previously, a zone is a point of delegation in the DNS tree. A -zone consists of those contiguous parts of the domain tree for which a -name server has complete information and over which it has authority. It -contains all domain names from a certain point downward in the domain -tree except those which are delegated to other zones. A delegation point -is marked by one or more *NS records* in the parent zone, which should -be matched by equivalent NS records at the root of the delegated zone. - -For instance, consider the ``example.com`` domain, which includes names -such as ``host.aaa.example.com`` and ``host.bbb.example.com``, even -though the ``example.com`` zone includes only delegations for the -``aaa.example.com`` and ``bbb.example.com`` zones. A zone can map -exactly to a single domain, but could also include only part of a -domain, the rest of which could be delegated to other name servers. -Every name in the DNS tree is a *domain*, even if it is *terminal*, that -is, has no *subdomains*. Every subdomain is a domain and every domain -except the root is also a subdomain. The terminology is not intuitive -and we suggest reading :rfc:`1033`, :rfc:`1034`, and :rfc:`1035` to gain a complete -understanding of this difficult and subtle topic. - -Though BIND 9 is called a "domain name server," it deals primarily in -terms of zones. The ``primary`` and ``secondary`` declarations in the :iscman:`named.conf` -file specify zones, not domains. When BIND asks some other site if it is -willing to be a secondary server for a *domain*, it is actually asking -for secondary service for some collection of *zones*. - -.. _auth_servers: - -Authoritative Name Servers -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Each zone is served by at least one *authoritative name server*, which -contains the complete data for the zone. To make the DNS tolerant of -server and network failures, most zones have two or more authoritative -servers, on different networks. - -Responses from authoritative servers have the "authoritative answer" -(AA) bit set in the response packets. This makes them easy to identify -when debugging DNS configurations using tools like :iscman:`dig` (:ref:`diagnostic_tools`). - -.. _primary_master: - -The Primary Server -^^^^^^^^^^^^^^^^^^ - -The authoritative server, where the main copy of the zone data is -maintained, is called the *primary* (formerly *master*) server, or simply the -*primary*. Typically it loads the zone contents from some local file -edited by humans or perhaps generated mechanically from some other local -file which is edited by humans. This file is called the *zone file* or -*master file*. - -In some cases, however, the master file may not be edited by humans at -all, but may instead be the result of *dynamic update* operations. - -.. _secondary_server: - -Secondary Servers -^^^^^^^^^^^^^^^^^ - -The other authoritative servers, the *secondary* servers (formerly known as -*slave* servers) load the zone contents from another server using a -replication process known as a *zone transfer*. Typically the data is -transferred directly from the primary, but it is also possible to -transfer it from another secondary. In other words, a secondary server may -itself act as a primary to a subordinate secondary server. - -Periodically, the secondary server must send a refresh query to determine -whether the zone contents have been updated. This is done by sending a -query for the zone's Start of Authority (SOA) record and checking whether the SERIAL field -has been updated; if so, a new transfer request is initiated. The timing -of these refresh queries is controlled by the SOA REFRESH and RETRY -fields, but can be overridden with the ``max-refresh-time``, -``min-refresh-time``, ``max-retry-time``, and ``min-retry-time`` -options. - -If the zone data cannot be updated within the time specified by the SOA -EXPIRE option (up to a hard-coded maximum of 24 weeks), the secondary -zone expires and no longer responds to queries. - -.. _stealth_server: - -Stealth Servers -^^^^^^^^^^^^^^^ - -Usually, all of the zone's authoritative servers are listed in NS -records in the parent zone. These NS records constitute a *delegation* -of the zone from the parent. The authoritative servers are also listed -in the zone file itself, at the *top level* or *apex* of the zone. -Servers that are not in the parent's NS delegation can be listed in the -zone's top-level NS records, but servers that are not present at the -zone's top level cannot be listed in the parent's delegation. - -A *stealth server* is a server that is authoritative for a zone but is -not listed in that zone's NS records. Stealth servers can be used for -keeping a local copy of a zone, to speed up access to the zone's records -or to make sure that the zone is available even if all the "official" -servers for the zone are inaccessible. - -A configuration where the primary server itself is a stealth -server is often referred to as a "hidden primary" configuration. One use -for this configuration is when the primary is behind a firewall -and is therefore unable to communicate directly with the outside world. - -.. _cache_servers: - -Caching Name Servers -~~~~~~~~~~~~~~~~~~~~ - -The resolver libraries provided by most operating systems are *stub -resolvers*, meaning that they are not capable of performing the full DNS -resolution process by themselves by talking directly to the -authoritative servers. Instead, they rely on a local name server to -perform the resolution on their behalf. Such a server is called a -*recursive* name server; it performs *recursive lookups* for local -clients. - -To improve performance, recursive servers cache the results of the -lookups they perform. Since the processes of recursion and caching are -intimately connected, the terms *recursive server* and *caching server* -are often used synonymously. - -The length of time for which a record may be retained in the cache of a -caching name server is controlled by the Time-To-Live (TTL) field -associated with each resource record. - -.. _forwarder: - -Forwarding -^^^^^^^^^^ - -Even a caching name server does not necessarily perform the complete -recursive lookup itself. Instead, it can *forward* some or all of the -queries that it cannot satisfy from its cache to another caching name -server, commonly referred to as a *forwarder*. - -Forwarders are typically used when an administrator does not wish for -all the servers at a given site to interact directly with the rest of -the Internet. For example, a common scenario is when multiple internal -DNS servers are behind an Internet firewall. Servers behind the firewall -forward their requests to the server with external access, which queries -Internet DNS servers on the internal servers' behalf. - -Another scenario (largely now superseded by Response Policy Zones) is to -send queries first to a custom server for RBL processing before -forwarding them to the wider Internet. - -There may be one or more forwarders in a given setup. The order in which -the forwarders are listed in :iscman:`named.conf` does not determine the -sequence in which they are queried; rather, :iscman:`named` uses the response -times from previous queries to select the server that is likely to -respond the most quickly. A server that has not yet been queried is -given an initial small random response time to ensure that it is tried -at least once. Dynamic adjustment of the recorded response times ensures -that all forwarders are queried, even those with slower response times. -This permits changes in behavior based on server responsiveness. - -.. _multi_role: - -Name Servers in Multiple Roles -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The BIND name server can simultaneously act as a primary for some zones, -a secondary for other zones, and as a caching (recursive) server for a set -of local clients. - -However, since the functions of authoritative name service and -caching/recursive name service are logically separate, it is often -advantageous to run them on separate server machines. A server that only -provides authoritative name service (an *authoritative-only* server) can -run with recursion disabled, improving reliability and security. A -server that is not authoritative for any zones and only provides -recursive service to local clients (a *caching-only* server) does not -need to be reachable from the Internet at large and can be placed inside -a firewall. +Text in "quotes," **bold text**, or *italics* is also used for emphasis or clarity. diff --git a/doc/arm/name-resolution.dia b/doc/arm/name-resolution.dia new file mode 100644 index 0000000000..272169f5ad Binary files /dev/null and b/doc/arm/name-resolution.dia differ diff --git a/doc/arm/name-resolution.png b/doc/arm/name-resolution.png new file mode 100644 index 0000000000..178428480e Binary files /dev/null and b/doc/arm/name-resolution.png differ diff --git a/doc/arm/recursive-query.dia b/doc/arm/recursive-query.dia new file mode 100644 index 0000000000..6b16e01fba Binary files /dev/null and b/doc/arm/recursive-query.dia differ diff --git a/doc/arm/recursive-query.png b/doc/arm/recursive-query.png new file mode 100644 index 0000000000..0c9b20ea47 Binary files /dev/null and b/doc/arm/recursive-query.png differ