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