--- /dev/null
+.. 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<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<config_auth_samples>` and
+:ref:`resolvers and forwarding resolvers<config_resolver_samples>`, as
+well as :ref:`advanced configurations<Advanced>` and :ref:`secure configurations<Security>`, are provided.
--- /dev/null
+.. 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<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 <file_permissions>`, running
+BIND 9 in a :ref:`jail <chroot_and_setuid>`, and the use of :ref:`Access_Control_Lists`.
+
+2. The remote name daemon control (:ref:`rndc<ops_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 <dynamic_update_security>`.
+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<sec_file_transfer>`.
+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 <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.
.. 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.
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<sample_primary>` and
+:ref:`secondary<sample_secondary>`), as well as a simple :ref:`config_resolver_samples` and
+a :ref:`sample_forwarding`. Some reference material on the :ref:`Zone File<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
- 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.
projects / thirdparty / bind9.git / commitdiff
