1.. 2 Copyright (C) Internet Systems Consortium, Inc. ("ISC") 3 4 This Source Code Form is subject to the terms of the Mozilla Public 5 License, v. 2.0. If a copy of the MPL was not distributed with this 6 file, you can obtain one at https://mozilla.org/MPL/2.0/. 7 8 See the COPYRIGHT file distributed with this work for additional 9 information regarding copyright ownership. 10 11.. _Introduction: 12 13Introduction 14============ 15 16The Internet Domain Name System (DNS) consists of the syntax to specify 17the names of entities in the Internet in a hierarchical manner, the 18rules used for delegating authority over names, and the system 19implementation that actually maps names to Internet addresses. DNS data 20is maintained in a group of distributed hierarchical databases. 21 22.. _doc_scope: 23 24Scope of Document 25----------------- 26 27The Berkeley Internet Name Domain (BIND) implements a domain name server 28for a number of operating systems. This document provides basic 29information about the installation and care of the Internet Systems 30Consortium (ISC) BIND version 9 software package for system 31administrators. 32 33This manual covers BIND version |release|. 34 35.. _organization: 36 37Organization of This Document 38----------------------------- 39 40In this document, *Chapter 1* introduces the basic DNS and BIND 41concepts. *Chapter 2* describes resource requirements for running BIND 42in various environments. Information in *Chapter 3* is *task-oriented* 43in its presentation and is organized functionally, to aid in the process 44of installing the BIND 9 software. The task-oriented section is followed 45by *Chapter 4*, which is organized as a reference manual to aid in the ongoing 46maintenance of the software. *Chapter 5* contains more advanced concepts that 47the system administrator may need for implementing certain options. *Chapter 6* 48addresses security considerations, and *Chapter 7* contains troubleshooting help. 49The main body of the document is followed by several *appendices* which contain 50useful reference information, such as a *bibliography* and historic 51information related to BIND and the Domain Name System. 52 53.. _conventions: 54 55Conventions Used in This Document 56--------------------------------- 57 58In this document, we generally use ``Fixed Width`` text to indicate the 59following types of information: 60 61- pathnames 62- filenames 63- URLs 64- hostnames 65- mailing list names 66- new terms or concepts 67- literal user input 68- program output 69- keywords 70- variables 71 72Text in "quotes," **bold**, or *italics* is also used for emphasis or clarity. 73 74.. _dns_overview: 75 76The Domain Name System (DNS) 77---------------------------- 78 79This document explains the installation and upkeep 80of the BIND (Berkeley Internet Name Domain) software package. We 81begin by reviewing the fundamentals of the Domain Name System (DNS) as 82they relate to BIND. 83 84.. _dns_fundamentals: 85 86DNS Fundamentals 87~~~~~~~~~~~~~~~~ 88 89The Domain Name System (DNS) is a hierarchical, distributed database. It 90stores information for mapping Internet host names to IP addresses and 91vice versa, mail routing information, and other data used by Internet 92applications. 93 94Clients look up information in the DNS by calling a *resolver* library, 95which sends queries to one or more *name servers* and interprets the 96responses. The BIND 9 software distribution contains a name server, 97``named``, and a set of associated tools. 98 99.. _domain_names: 100 101Domains and Domain Names 102~~~~~~~~~~~~~~~~~~~~~~~~ 103 104The data stored in the DNS is identified by *domain names* that are 105organized as a tree according to organizational or administrative 106boundaries. Each node of the tree, called a *domain*, is given a label. 107The domain name of the node is the concatenation of all the labels on 108the path from the node to the *root* node. This is represented in 109written form as a string of labels listed from right to left and 110separated by dots. A label need only be unique within its parent domain. 111 112For example, a domain name for a host at the company *Example, Inc.* 113could be ``ourhost.example.com``, where ``com`` is the top-level domain 114to which ``ourhost.example.com`` belongs, ``example`` is a subdomain of 115``com``, and ``ourhost`` is the name of the host. 116 117For administrative purposes, the name space is partitioned into areas 118called *zones*, each starting at a node and extending down to the "leaf" 119nodes or to nodes where other zones start. The data for each zone is 120stored in a *name server*, which answers queries about the zone using 121the *DNS protocol*. 122 123The data associated with each domain name is stored in the form of 124*resource records* (RRs). Some of the supported resource record types 125are described in :ref:`types_of_resource_records_and_when_to_use_them`. 126 127For more detailed information about the design of the DNS and the DNS 128protocol, please refer to the standards documents listed in :ref:`rfcs`. 129 130Zones 131~~~~~ 132 133To properly operate a name server, it is important to understand the 134difference between a *zone* and a *domain*. 135 136As stated previously, a zone is a point of delegation in the DNS tree. A 137zone consists of those contiguous parts of the domain tree for which a 138name server has complete information and over which it has authority. It 139contains all domain names from a certain point downward in the domain 140tree except those which are delegated to other zones. A delegation point 141is marked by one or more *NS records* in the parent zone, which should 142be matched by equivalent NS records at the root of the delegated zone. 143 144For instance, consider the ``example.com`` domain, which includes names 145such as ``host.aaa.example.com`` and ``host.bbb.example.com``, even 146though the ``example.com`` zone includes only delegations for the 147``aaa.example.com`` and ``bbb.example.com`` zones. A zone can map 148exactly to a single domain, but could also include only part of a 149domain, the rest of which could be delegated to other name servers. 150Every name in the DNS tree is a *domain*, even if it is *terminal*, that 151is, has no *subdomains*. Every subdomain is a domain and every domain 152except the root is also a subdomain. The terminology is not intuitive 153and we suggest reading :rfc:`1033`, :rfc:`1034`, and :rfc:`1035` to gain a complete 154understanding of this difficult and subtle topic. 155 156Though BIND 9 is called a "domain name server," it deals primarily in 157terms of zones. The ``primary`` and ``secondary`` declarations in the ``named.conf`` 158file specify zones, not domains. When BIND asks some other site if it is 159willing to be a secondary server for a *domain*, it is actually asking 160for secondary service for some collection of *zones*. 161 162.. _auth_servers: 163 164Authoritative Name Servers 165~~~~~~~~~~~~~~~~~~~~~~~~~~ 166 167Each zone is served by at least one *authoritative name server*, which 168contains the complete data for the zone. To make the DNS tolerant of 169server and network failures, most zones have two or more authoritative 170servers, on different networks. 171 172Responses from authoritative servers have the "authoritative answer" 173(AA) bit set in the response packets. This makes them easy to identify 174when debugging DNS configurations using tools like ``dig`` (:ref:`diagnostic_tools`). 175 176.. _primary_master: 177 178The Primary Server 179^^^^^^^^^^^^^^^^^^ 180 181The authoritative server, where the main copy of the zone data is 182maintained, is called the *primary* (formerly *master*) server, or simply the 183*primary*. Typically it loads the zone contents from some local file 184edited by humans or perhaps generated mechanically from some other local 185file which is edited by humans. This file is called the *zone file* or 186*master file*. 187 188In some cases, however, the master file may not be edited by humans at 189all, but may instead be the result of *dynamic update* operations. 190 191.. _secondary_server: 192 193Secondary Servers 194^^^^^^^^^^^^^^^^^ 195 196The other authoritative servers, the *secondary* servers (formerly known as 197*slave* servers) load the zone contents from another server using a 198replication process known as a *zone transfer*. Typically the data is 199transferred directly from the primary, but it is also possible to 200transfer it from another secondary. In other words, a secondary server may 201itself act as a primary to a subordinate secondary server. 202 203Periodically, the secondary server must send a refresh query to determine 204whether the zone contents have been updated. This is done by sending a 205query for the zone's Start of Authority (SOA) record and checking whether the SERIAL field 206has been updated; if so, a new transfer request is initiated. The timing 207of these refresh queries is controlled by the SOA REFRESH and RETRY 208fields, but can be overridden with the ``max-refresh-time``, 209``min-refresh-time``, ``max-retry-time``, and ``min-retry-time`` 210options. 211 212If the zone data cannot be updated within the time specified by the SOA 213EXPIRE option (up to a hard-coded maximum of 24 weeks), the secondary 214zone expires and no longer responds to queries. 215 216.. _stealth_server: 217 218Stealth Servers 219^^^^^^^^^^^^^^^ 220 221Usually, all of the zone's authoritative servers are listed in NS 222records in the parent zone. These NS records constitute a *delegation* 223of the zone from the parent. The authoritative servers are also listed 224in the zone file itself, at the *top level* or *apex* of the zone. 225Servers that are not in the parent's NS delegation can be listed in the 226zone's top-level NS records, but servers that are not present at the 227zone's top level cannot be listed in the parent's delegation. 228 229A *stealth server* is a server that is authoritative for a zone but is 230not listed in that zone's NS records. Stealth servers can be used for 231keeping a local copy of a zone, to speed up access to the zone's records 232or to make sure that the zone is available even if all the "official" 233servers for the zone are inaccessible. 234 235A configuration where the primary server itself is a stealth 236server is often referred to as a "hidden primary" configuration. One use 237for this configuration is when the primary is behind a firewall 238and is therefore unable to communicate directly with the outside world. 239 240.. _cache_servers: 241 242Caching Name Servers 243~~~~~~~~~~~~~~~~~~~~ 244 245The resolver libraries provided by most operating systems are *stub 246resolvers*, meaning that they are not capable of performing the full DNS 247resolution process by themselves by talking directly to the 248authoritative servers. Instead, they rely on a local name server to 249perform the resolution on their behalf. Such a server is called a 250*recursive* name server; it performs *recursive lookups* for local 251clients. 252 253To improve performance, recursive servers cache the results of the 254lookups they perform. Since the processes of recursion and caching are 255intimately connected, the terms *recursive server* and *caching server* 256are often used synonymously. 257 258The length of time for which a record may be retained in the cache of a 259caching name server is controlled by the Time-To-Live (TTL) field 260associated with each resource record. 261 262.. _forwarder: 263 264Forwarding 265^^^^^^^^^^ 266 267Even a caching name server does not necessarily perform the complete 268recursive lookup itself. Instead, it can *forward* some or all of the 269queries that it cannot satisfy from its cache to another caching name 270server, commonly referred to as a *forwarder*. 271 272Forwarders are typically used when an administrator does not wish for 273all the servers at a given site to interact directly with the rest of 274the Internet. For example, a common scenario is when multiple internal 275DNS servers are behind an Internet firewall. Servers behind the firewall 276forward their requests to the server with external access, which queries 277Internet DNS servers on the internal servers' behalf. 278 279Another scenario (largely now superseded by Response Policy Zones) is to 280send queries first to a custom server for RBL processing before 281forwarding them to the wider Internet. 282 283There may be one or more forwarders in a given setup. The order in which 284the forwarders are listed in ``named.conf`` does not determine the 285sequence in which they are queried; rather, ``named`` uses the response 286times from previous queries to select the server that is likely to 287respond the most quickly. A server that has not yet been queried is 288given an initial small random response time to ensure that it is tried 289at least once. Dynamic adjustment of the recorded response times ensures 290that all forwarders are queried, even those with slower response times. 291This permits changes in behavior based on server responsiveness. 292 293.. _multi_role: 294 295Name Servers in Multiple Roles 296~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 297 298The BIND name server can simultaneously act as a primary for some zones, 299a secondary for other zones, and as a caching (recursive) server for a set 300of local clients. 301 302However, since the functions of authoritative name service and 303caching/recursive name service are logically separate, it is often 304advantageous to run them on separate server machines. A server that only 305provides authoritative name service (an *authoritative-only* server) can 306run with recursion disabled, improving reliability and security. A 307server that is not authoritative for any zones and only provides 308recursive service to local clients (a *caching-only* server) does not 309need to be reachable from the Internet at large and can be placed inside 310a firewall. 311