2 - Copyright (C) 2004-2015 Internet Systems Consortium, Inc. ("ISC")
3 - Copyright (C) 2000-2003 Internet Software Consortium.
5 - Permission to use, copy, modify, and/or distribute this software for any
6 - purpose with or without fee is hereby granted, provided that the above
7 - copyright notice and this permission notice appear in all copies.
9 - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
10 - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
11 - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
12 - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
13 - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
14 - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
15 - PERFORMANCE OF THIS SOFTWARE.
20 <meta http-equiv=
"Content-Type" content=
"text/html; charset=ISO-8859-1">
21 <title>Chapter
1. Introduction
</title>
22 <meta name=
"generator" content=
"DocBook XSL Stylesheets V1.71.1">
23 <link rel=
"start" href=
"Bv9ARM.html" title=
"BIND 9 Administrator Reference Manual">
24 <link rel=
"up" href=
"Bv9ARM.html" title=
"BIND 9 Administrator Reference Manual">
25 <link rel=
"prev" href=
"Bv9ARM.html" title=
"BIND 9 Administrator Reference Manual">
26 <link rel=
"next" href=
"Bv9ARM.ch02.html" title=
"Chapter 2. BIND Resource Requirements">
28 <body bgcolor=
"white" text=
"black" link=
"#0000FF" vlink=
"#840084" alink=
"#0000FF">
29 <div class=
"navheader">
30 <table width=
"100%" summary=
"Navigation header">
31 <tr><th colspan=
"3" align=
"center">Chapter
1. Introduction
</th></tr>
33 <td width=
"20%" align=
"left">
34 <a accesskey=
"p" href=
"Bv9ARM.html">Prev
</a> </td>
35 <th width=
"60%" align=
"center"> </th>
36 <td width=
"20%" align=
"right"> <a accesskey=
"n" href=
"Bv9ARM.ch02.html">Next
</a>
42 <div class=
"chapter" lang=
"en">
43 <div class=
"titlepage"><div><div><h2 class=
"title">
44 <a name=
"Bv9ARM.ch01"></a>Chapter
1. Introduction
</h2></div></div></div>
46 <p><b>Table of Contents
</b></p>
48 <dt><span class=
"sect1"><a href=
"Bv9ARM.ch01.html#id2563509">Scope of Document
</a></span></dt>
49 <dt><span class=
"sect1"><a href=
"Bv9ARM.ch01.html#id2563533">Organization of This Document
</a></span></dt>
50 <dt><span class=
"sect1"><a href=
"Bv9ARM.ch01.html#id2564629">Conventions Used in This Document
</a></span></dt>
51 <dt><span class=
"sect1"><a href=
"Bv9ARM.ch01.html#id2564810">The Domain Name System (
<acronym class=
"acronym">DNS
</acronym>)
</a></span></dt>
53 <dt><span class=
"sect2"><a href=
"Bv9ARM.ch01.html#id2564832">DNS Fundamentals
</a></span></dt>
54 <dt><span class=
"sect2"><a href=
"Bv9ARM.ch01.html#id2564934">Domains and Domain Names
</a></span></dt>
55 <dt><span class=
"sect2"><a href=
"Bv9ARM.ch01.html#id2567271">Zones
</a></span></dt>
56 <dt><span class=
"sect2"><a href=
"Bv9ARM.ch01.html#id2567348">Authoritative Name Servers
</a></span></dt>
57 <dt><span class=
"sect2"><a href=
"Bv9ARM.ch01.html#id2567589">Caching Name Servers
</a></span></dt>
58 <dt><span class=
"sect2"><a href=
"Bv9ARM.ch01.html#id2567651">Name Servers in Multiple Roles
</a></span></dt>
63 The Internet Domain Name System (
<acronym class=
"acronym">DNS
</acronym>)
64 consists of the syntax
65 to specify the names of entities in the Internet in a hierarchical
66 manner, the rules used for delegating authority over names, and the
67 system implementation that actually maps names to Internet
68 addresses.
<acronym class=
"acronym">DNS
</acronym> data is maintained in a
70 hierarchical databases.
72 <div class=
"sect1" lang=
"en">
73 <div class=
"titlepage"><div><div><h2 class=
"title" style=
"clear: both">
74 <a name=
"id2563509"></a>Scope of Document
</h2></div></div></div>
76 The Berkeley Internet Name Domain
77 (
<acronym class=
"acronym">BIND
</acronym>) implements a
78 domain name server for a number of operating systems. This
79 document provides basic information about the installation and
80 care of the Internet Systems Consortium (
<acronym class=
"acronym">ISC
</acronym>)
81 <acronym class=
"acronym">BIND
</acronym> version
9 software package for
82 system administrators.
84 <p>This version of the manual corresponds to BIND version
9.10.
</p>
86 <div class=
"sect1" lang=
"en">
87 <div class=
"titlepage"><div><div><h2 class=
"title" style=
"clear: both">
88 <a name=
"id2563533"></a>Organization of This Document
</h2></div></div></div>
90 In this document,
<span class=
"emphasis"><em>Chapter
1</em></span> introduces
91 the basic
<acronym class=
"acronym">DNS
</acronym> and
<acronym class=
"acronym">BIND
</acronym> concepts.
<span class=
"emphasis"><em>Chapter
2</em></span>
92 describes resource requirements for running
<acronym class=
"acronym">BIND
</acronym> in various
93 environments. Information in
<span class=
"emphasis"><em>Chapter
3</em></span> is
94 <span class=
"emphasis"><em>task-oriented
</em></span> in its presentation and is
95 organized functionally, to aid in the process of installing the
96 <acronym class=
"acronym">BIND
</acronym> 9 software. The task-oriented
97 section is followed by
98 <span class=
"emphasis"><em>Chapter
4</em></span>, which contains more advanced
99 concepts that the system administrator may need for implementing
100 certain options.
<span class=
"emphasis"><em>Chapter
5</em></span>
101 describes the
<acronym class=
"acronym">BIND
</acronym> 9 lightweight
102 resolver. The contents of
<span class=
"emphasis"><em>Chapter
6</em></span> are
103 organized as in a reference manual to aid in the ongoing
104 maintenance of the software.
<span class=
"emphasis"><em>Chapter
7</em></span> addresses
105 security considerations, and
106 <span class=
"emphasis"><em>Chapter
8</em></span> contains troubleshooting help. The
107 main body of the document is followed by several
108 <span class=
"emphasis"><em>appendices
</em></span> which contain useful reference
109 information, such as a
<span class=
"emphasis"><em>bibliography
</em></span> and
110 historic information related to
<acronym class=
"acronym">BIND
</acronym>
115 <div class=
"sect1" lang=
"en">
116 <div class=
"titlepage"><div><div><h2 class=
"title" style=
"clear: both">
117 <a name=
"id2564629"></a>Conventions Used in This Document
</h2></div></div></div>
119 In this document, we use the following general typographic
122 <div class=
"informaltable"><table border=
"1">
131 <span class=
"emphasis"><em>To describe:
</em></span>
136 <span class=
"emphasis"><em>We use the style:
</em></span>
143 a pathname, filename, URL, hostname,
144 mailing list name, or new term or concept
149 <code class=
"filename">Fixed width
</code>
162 <strong class=
"userinput"><code>Fixed Width Bold
</code></strong>
174 <code class=
"computeroutput">Fixed Width
</code>
181 The following conventions are used in descriptions of the
182 <acronym class=
"acronym">BIND
</acronym> configuration file:
</p>
183 <div class=
"informaltable"><table border=
"1">
192 <span class=
"emphasis"><em>To describe:
</em></span>
197 <span class=
"emphasis"><em>We use the style:
</em></span>
209 <code class=
"literal">Fixed Width
</code>
221 <code class=
"varname">Fixed Width
</code>
233 [
<span class=
"optional">Text is enclosed in square brackets
</span>]
242 <div class=
"sect1" lang=
"en">
243 <div class=
"titlepage"><div><div><h2 class=
"title" style=
"clear: both">
244 <a name=
"id2564810"></a>The Domain Name System (
<acronym class=
"acronym">DNS
</acronym>)
</h2></div></div></div>
246 The purpose of this document is to explain the installation
247 and upkeep of the
<acronym class=
"acronym">BIND
</acronym> (Berkeley Internet
248 Name Domain) software package, and we
249 begin by reviewing the fundamentals of the Domain Name System
250 (
<acronym class=
"acronym">DNS
</acronym>) as they relate to
<acronym class=
"acronym">BIND
</acronym>.
252 <div class=
"sect2" lang=
"en">
253 <div class=
"titlepage"><div><div><h3 class=
"title">
254 <a name=
"id2564832"></a>DNS Fundamentals
</h3></div></div></div>
256 The Domain Name System (DNS) is a hierarchical, distributed
257 database. It stores information for mapping Internet host names to
259 addresses and vice versa, mail routing information, and other data
260 used by Internet applications.
263 Clients look up information in the DNS by calling a
264 <span class=
"emphasis"><em>resolver
</em></span> library, which sends queries to one or
265 more
<span class=
"emphasis"><em>name servers
</em></span> and interprets the responses.
266 The
<acronym class=
"acronym">BIND
</acronym> 9 software distribution
268 name server,
<span><strong class=
"command">named
</strong></span>, and a resolver
269 library,
<span><strong class=
"command">liblwres
</strong></span>. The older
270 <span><strong class=
"command">libbind
</strong></span> resolver library is also available
271 from ISC as a separate download.
274 <div class=
"sect2" lang=
"en">
275 <div class=
"titlepage"><div><div><h3 class=
"title">
276 <a name=
"id2564934"></a>Domains and Domain Names
</h3></div></div></div>
278 The data stored in the DNS is identified by
<span class=
"emphasis"><em>domain names
</em></span> that are organized as a tree according to
279 organizational or administrative boundaries. Each node of the tree,
280 called a
<span class=
"emphasis"><em>domain
</em></span>, is given a label. The domain
282 node is the concatenation of all the labels on the path from the
283 node to the
<span class=
"emphasis"><em>root
</em></span> node. This is represented
284 in written form as a string of labels listed from right to left and
285 separated by dots. A label need only be unique within its parent
289 For example, a domain name for a host at the
290 company
<span class=
"emphasis"><em>Example, Inc.
</em></span> could be
291 <code class=
"literal">ourhost.example.com
</code>,
292 where
<code class=
"literal">com
</code> is the
293 top level domain to which
294 <code class=
"literal">ourhost.example.com
</code> belongs,
295 <code class=
"literal">example
</code> is
296 a subdomain of
<code class=
"literal">com
</code>, and
297 <code class=
"literal">ourhost
</code> is the
301 For administrative purposes, the name space is partitioned into
302 areas called
<span class=
"emphasis"><em>zones
</em></span>, each starting at a node and
303 extending down to the leaf nodes or to nodes where other zones
305 The data for each zone is stored in a
<span class=
"emphasis"><em>name server
</em></span>, which answers queries about the zone using the
306 <span class=
"emphasis"><em>DNS protocol
</em></span>.
309 The data associated with each domain name is stored in the
310 form of
<span class=
"emphasis"><em>resource records
</em></span> (
<acronym class=
"acronym">RR
</acronym>s).
311 Some of the supported resource record types are described in
312 <a href=
"Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them" title=
"Types of Resource Records and When to Use Them">the section called
“Types of Resource Records and When to Use Them
”</a>.
315 For more detailed information about the design of the DNS and
316 the DNS protocol, please refer to the standards documents listed in
317 <a href=
"Bv9ARM.ch11.html#rfcs" title=
"Request for Comments (RFCs)">the section called
“Request for Comments (RFCs)
”</a>.
320 <div class=
"sect2" lang=
"en">
321 <div class=
"titlepage"><div><div><h3 class=
"title">
322 <a name=
"id2567271"></a>Zones
</h3></div></div></div>
324 To properly operate a name server, it is important to understand
325 the difference between a
<span class=
"emphasis"><em>zone
</em></span>
326 and a
<span class=
"emphasis"><em>domain
</em></span>.
329 As stated previously, a zone is a point of delegation in
330 the
<acronym class=
"acronym">DNS
</acronym> tree. A zone consists of
331 those contiguous parts of the domain
332 tree for which a name server has complete information and over which
333 it has authority. It contains all domain names from a certain point
334 downward in the domain tree except those which are delegated to
335 other zones. A delegation point is marked by one or more
336 <span class=
"emphasis"><em>NS records
</em></span> in the
337 parent zone, which should be matched by equivalent NS records at
338 the root of the delegated zone.
341 For instance, consider the
<code class=
"literal">example.com
</code>
342 domain which includes names
343 such as
<code class=
"literal">host.aaa.example.com
</code> and
344 <code class=
"literal">host.bbb.example.com
</code> even though
345 the
<code class=
"literal">example.com
</code> zone includes
346 only delegations for the
<code class=
"literal">aaa.example.com
</code> and
347 <code class=
"literal">bbb.example.com
</code> zones. A zone can
349 exactly to a single domain, but could also include only part of a
350 domain, the rest of which could be delegated to other
351 name servers. Every name in the
<acronym class=
"acronym">DNS
</acronym>
353 <span class=
"emphasis"><em>domain
</em></span>, even if it is
354 <span class=
"emphasis"><em>terminal
</em></span>, that is, has no
355 <span class=
"emphasis"><em>subdomains
</em></span>. Every subdomain is a domain and
356 every domain except the root is also a subdomain. The terminology is
357 not intuitive and we suggest that you read RFCs
1033,
1034 and
1035
359 gain a complete understanding of this difficult and subtle
363 Though
<acronym class=
"acronym">BIND
</acronym> is called a
"domain name
365 it deals primarily in terms of zones. The master and slave
366 declarations in the
<code class=
"filename">named.conf
</code> file
368 zones, not domains. When you ask some other site if it is willing to
369 be a slave server for your
<span class=
"emphasis"><em>domain
</em></span>, you are
370 actually asking for slave service for some collection of zones.
373 <div class=
"sect2" lang=
"en">
374 <div class=
"titlepage"><div><div><h3 class=
"title">
375 <a name=
"id2567348"></a>Authoritative Name Servers
</h3></div></div></div>
377 Each zone is served by at least
378 one
<span class=
"emphasis"><em>authoritative name server
</em></span>,
379 which contains the complete data for the zone.
380 To make the DNS tolerant of server and network failures,
381 most zones have two or more authoritative servers, on
385 Responses from authoritative servers have the
"authoritative
386 answer" (AA) bit set in the response packets. This makes them
387 easy to identify when debugging DNS configurations using tools like
388 <span><strong class=
"command">dig
</strong></span> (
<a href=
"Bv9ARM.ch03.html#diagnostic_tools" title=
"Diagnostic Tools">the section called
“Diagnostic Tools
”</a>).
390 <div class=
"sect3" lang=
"en">
391 <div class=
"titlepage"><div><div><h4 class=
"title">
392 <a name=
"id2567371"></a>The Primary Master
</h4></div></div></div>
394 The authoritative server where the master copy of the zone
395 data is maintained is called the
396 <span class=
"emphasis"><em>primary master
</em></span> server, or simply the
397 <span class=
"emphasis"><em>primary
</em></span>. Typically it loads the zone
398 contents from some local file edited by humans or perhaps
399 generated mechanically from some other local file which is
400 edited by humans. This file is called the
401 <span class=
"emphasis"><em>zone file
</em></span> or
402 <span class=
"emphasis"><em>master file
</em></span>.
405 In some cases, however, the master file may not be edited
406 by humans at all, but may instead be the result of
407 <span class=
"emphasis"><em>dynamic update
</em></span> operations.
410 <div class=
"sect3" lang=
"en">
411 <div class=
"titlepage"><div><div><h4 class=
"title">
412 <a name=
"id2567401"></a>Slave Servers
</h4></div></div></div>
414 The other authoritative servers, the
<span class=
"emphasis"><em>slave
</em></span>
415 servers (also known as
<span class=
"emphasis"><em>secondary
</em></span> servers)
417 the zone contents from another server using a replication process
418 known as a
<span class=
"emphasis"><em>zone transfer
</em></span>. Typically the data
420 transferred directly from the primary master, but it is also
422 to transfer it from another slave. In other words, a slave server
423 may itself act as a master to a subordinate slave server.
426 <div class=
"sect3" lang=
"en">
427 <div class=
"titlepage"><div><div><h4 class=
"title">
428 <a name=
"id2567422"></a>Stealth Servers
</h4></div></div></div>
430 Usually all of the zone's authoritative servers are listed in
431 NS records in the parent zone. These NS records constitute
432 a
<span class=
"emphasis"><em>delegation
</em></span> of the zone from the parent.
433 The authoritative servers are also listed in the zone file itself,
434 at the
<span class=
"emphasis"><em>top level
</em></span> or
<span class=
"emphasis"><em>apex
</em></span>
435 of the zone. You can list servers in the zone's top-level NS
436 records that are not in the parent's NS delegation, but you cannot
437 list servers in the parent's delegation that are not present at
438 the zone's top level.
441 A
<span class=
"emphasis"><em>stealth server
</em></span> is a server that is
442 authoritative for a zone but is not listed in that zone's NS
443 records. Stealth servers can be used for keeping a local copy of
445 zone to speed up access to the zone's records or to make sure that
447 zone is available even if all the
"official" servers for the zone
452 A configuration where the primary master server itself is a
453 stealth server is often referred to as a
"hidden primary"
454 configuration. One use for this configuration is when the primary
456 is behind a firewall and therefore unable to communicate directly
457 with the outside world.
461 <div class=
"sect2" lang=
"en">
462 <div class=
"titlepage"><div><div><h3 class=
"title">
463 <a name=
"id2567589"></a>Caching Name Servers
</h3></div></div></div>
465 The resolver libraries provided by most operating systems are
466 <span class=
"emphasis"><em>stub resolvers
</em></span>, meaning that they are not
468 performing the full DNS resolution process by themselves by talking
469 directly to the authoritative servers. Instead, they rely on a
471 name server to perform the resolution on their behalf. Such a
473 is called a
<span class=
"emphasis"><em>recursive
</em></span> name server; it performs
474 <span class=
"emphasis"><em>recursive lookups
</em></span> for local clients.
477 To improve performance, recursive servers cache the results of
478 the lookups they perform. Since the processes of recursion and
479 caching are intimately connected, the terms
480 <span class=
"emphasis"><em>recursive server
</em></span> and
481 <span class=
"emphasis"><em>caching server
</em></span> are often used synonymously.
484 The length of time for which a record may be retained in
485 the cache of a caching name server is controlled by the
486 Time To Live (TTL) field associated with each resource record.
488 <div class=
"sect3" lang=
"en">
489 <div class=
"titlepage"><div><div><h4 class=
"title">
490 <a name=
"id2567624"></a>Forwarding
</h4></div></div></div>
492 Even a caching name server does not necessarily perform
493 the complete recursive lookup itself. Instead, it can
494 <span class=
"emphasis"><em>forward
</em></span> some or all of the queries
495 that it cannot satisfy from its cache to another caching name
497 commonly referred to as a
<span class=
"emphasis"><em>forwarder
</em></span>.
500 There may be one or more forwarders,
501 and they are queried in turn until the list is exhausted or an
503 is found. Forwarders are typically used when you do not
504 wish all the servers at a given site to interact directly with the
506 the Internet servers. A typical scenario would involve a number
507 of internal
<acronym class=
"acronym">DNS
</acronym> servers and an
508 Internet firewall. Servers unable
509 to pass packets through the firewall would forward to the server
510 that can do it, and that server would query the Internet
<acronym class=
"acronym">DNS
</acronym> servers
511 on the internal server's behalf.
515 <div class=
"sect2" lang=
"en">
516 <div class=
"titlepage"><div><div><h3 class=
"title">
517 <a name=
"id2567651"></a>Name Servers in Multiple Roles
</h3></div></div></div>
519 The
<acronym class=
"acronym">BIND
</acronym> name server can
520 simultaneously act as
521 a master for some zones, a slave for other zones, and as a caching
522 (recursive) server for a set of local clients.
525 However, since the functions of authoritative name service
526 and caching/recursive name service are logically separate, it is
527 often advantageous to run them on separate server machines.
529 A server that only provides authoritative name service
530 (an
<span class=
"emphasis"><em>authoritative-only
</em></span> server) can run with
531 recursion disabled, improving reliability and security.
533 A server that is not authoritative for any zones and only provides
534 recursive service to local
535 clients (a
<span class=
"emphasis"><em>caching-only
</em></span> server)
536 does not need to be reachable from the Internet at large and can
537 be placed inside a firewall.
542 <div class=
"navfooter">
544 <table width=
"100%" summary=
"Navigation footer">
546 <td width=
"40%" align=
"left">
547 <a accesskey=
"p" href=
"Bv9ARM.html">Prev
</a> </td>
548 <td width=
"20%" align=
"center"> </td>
549 <td width=
"40%" align=
"right"> <a accesskey=
"n" href=
"Bv9ARM.ch02.html">Next
</a>
553 <td width=
"40%" align=
"left" valign=
"top">BIND
9 Administrator Reference Manual
</td>
554 <td width=
"20%" align=
"center"><a accesskey=
"h" href=
"Bv9ARM.html">Home
</a></td>
555 <td width=
"40%" align=
"right" valign=
"top"> Chapter
2.
<acronym class=
"acronym">BIND
</acronym> Resource Requirements
</td>
559 <p style=
"text-align: center;">BIND
9.10.2-P4
</p>