1<!-- 2 - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC") 3 - Copyright (C) 2000-2003 Internet Software Consortium. 4 - 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. 8 - 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. 16--> 17<!-- $Id$ --> 18<html> 19<head> 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"> 27</head> 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> 32<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> 37</td> 38</tr> 39</table> 40<hr> 41</div> 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> 45<div class="toc"> 46<p><b>Table of Contents</b></p> 47<dl> 48<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564375">Scope of Document</a></span></dt> 49<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564398">Organization of This Document</a></span></dt> 50<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564538">Conventions Used in This Document</a></span></dt> 51<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564720">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt> 52<dd><dl> 53<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564741">DNS Fundamentals</a></span></dt> 54<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564775">Domains and Domain Names</a></span></dt> 55<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567180">Zones</a></span></dt> 56<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567257">Authoritative Name Servers</a></span></dt> 57<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567430">Caching Name Servers</a></span></dt> 58<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567560">Name Servers in Multiple Roles</a></span></dt> 59</dl></dd> 60</dl> 61</div> 62<p> 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 69 group of distributed 70 hierarchical databases. 71 </p> 72<div class="sect1" lang="en"> 73<div class="titlepage"><div><div><h2 class="title" style="clear: both"> 74<a name="id2564375"></a>Scope of Document</h2></div></div></div> 75<p> 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. 83 </p> 84<p> 85 This version of the manual corresponds to BIND version 9.8. 86 </p> 87</div> 88<div class="sect1" lang="en"> 89<div class="titlepage"><div><div><h2 class="title" style="clear: both"> 90<a name="id2564398"></a>Organization of This Document</h2></div></div></div> 91<p> 92 In this document, <span class="emphasis"><em>Chapter 1</em></span> introduces 93 the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Chapter 2</em></span> 94 describes resource requirements for running <acronym class="acronym">BIND</acronym> in various 95 environments. Information in <span class="emphasis"><em>Chapter 3</em></span> is 96 <span class="emphasis"><em>task-oriented</em></span> in its presentation and is 97 organized functionally, to aid in the process of installing the 98 <acronym class="acronym">BIND</acronym> 9 software. The task-oriented 99 section is followed by 100 <span class="emphasis"><em>Chapter 4</em></span>, which contains more advanced 101 concepts that the system administrator may need for implementing 102 certain options. <span class="emphasis"><em>Chapter 5</em></span> 103 describes the <acronym class="acronym">BIND</acronym> 9 lightweight 104 resolver. The contents of <span class="emphasis"><em>Chapter 6</em></span> are 105 organized as in a reference manual to aid in the ongoing 106 maintenance of the software. <span class="emphasis"><em>Chapter 7</em></span> addresses 107 security considerations, and 108 <span class="emphasis"><em>Chapter 8</em></span> contains troubleshooting help. The 109 main body of the document is followed by several 110 <span class="emphasis"><em>appendices</em></span> which contain useful reference 111 information, such as a <span class="emphasis"><em>bibliography</em></span> and 112 historic information related to <acronym class="acronym">BIND</acronym> 113 and the Domain Name 114 System. 115 </p> 116</div> 117<div class="sect1" lang="en"> 118<div class="titlepage"><div><div><h2 class="title" style="clear: both"> 119<a name="id2564538"></a>Conventions Used in This Document</h2></div></div></div> 120<p> 121 In this document, we use the following general typographic 122 conventions: 123 </p> 124<div class="informaltable"><table border="1"> 125<colgroup> 126<col> 127<col> 128</colgroup> 129<tbody> 130<tr> 131<td> 132 <p> 133 <span class="emphasis"><em>To describe:</em></span> 134 </p> 135 </td> 136<td> 137 <p> 138 <span class="emphasis"><em>We use the style:</em></span> 139 </p> 140 </td> 141</tr> 142<tr> 143<td> 144 <p> 145 a pathname, filename, URL, hostname, 146 mailing list name, or new term or concept 147 </p> 148 </td> 149<td> 150 <p> 151 <code class="filename">Fixed width</code> 152 </p> 153 </td> 154</tr> 155<tr> 156<td> 157 <p> 158 literal user 159 input 160 </p> 161 </td> 162<td> 163 <p> 164 <strong class="userinput"><code>Fixed Width Bold</code></strong> 165 </p> 166 </td> 167</tr> 168<tr> 169<td> 170 <p> 171 program output 172 </p> 173 </td> 174<td> 175 <p> 176 <code class="computeroutput">Fixed Width</code> 177 </p> 178 </td> 179</tr> 180</tbody> 181</table></div> 182<p> 183 The following conventions are used in descriptions of the 184 <acronym class="acronym">BIND</acronym> configuration file:</p> 185<div class="informaltable"><table border="1"> 186<colgroup> 187<col> 188<col> 189</colgroup> 190<tbody> 191<tr> 192<td> 193 <p> 194 <span class="emphasis"><em>To describe:</em></span> 195 </p> 196 </td> 197<td> 198 <p> 199 <span class="emphasis"><em>We use the style:</em></span> 200 </p> 201 </td> 202</tr> 203<tr> 204<td> 205 <p> 206 keywords 207 </p> 208 </td> 209<td> 210 <p> 211 <code class="literal">Fixed Width</code> 212 </p> 213 </td> 214</tr> 215<tr> 216<td> 217 <p> 218 variables 219 </p> 220 </td> 221<td> 222 <p> 223 <code class="varname">Fixed Width</code> 224 </p> 225 </td> 226</tr> 227<tr> 228<td> 229 <p> 230 Optional input 231 </p> 232 </td> 233<td> 234 <p> 235 [<span class="optional">Text is enclosed in square brackets</span>] 236 </p> 237 </td> 238</tr> 239</tbody> 240</table></div> 241<p> 242 </p> 243</div> 244<div class="sect1" lang="en"> 245<div class="titlepage"><div><div><h2 class="title" style="clear: both"> 246<a name="id2564720"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div> 247<p> 248 The purpose of this document is to explain the installation 249 and upkeep of the <acronym class="acronym">BIND</acronym> (Berkeley Internet 250 Name Domain) software package, and we 251 begin by reviewing the fundamentals of the Domain Name System 252 (<acronym class="acronym">DNS</acronym>) as they relate to <acronym class="acronym">BIND</acronym>. 253 </p> 254<div class="sect2" lang="en"> 255<div class="titlepage"><div><div><h3 class="title"> 256<a name="id2564741"></a>DNS Fundamentals</h3></div></div></div> 257<p> 258 The Domain Name System (DNS) is a hierarchical, distributed 259 database. It stores information for mapping Internet host names to 260 IP 261 addresses and vice versa, mail routing information, and other data 262 used by Internet applications. 263 </p> 264<p> 265 Clients look up information in the DNS by calling a 266 <span class="emphasis"><em>resolver</em></span> library, which sends queries to one or 267 more <span class="emphasis"><em>name servers</em></span> and interprets the responses. 268 The <acronym class="acronym">BIND</acronym> 9 software distribution 269 contains a 270 name server, <span><strong class="command">named</strong></span>, and a resolver 271 library, <span><strong class="command">liblwres</strong></span>. The older 272 <span><strong class="command">libbind</strong></span> resolver library is also available 273 from ISC as a separate download. 274 </p> 275</div> 276<div class="sect2" lang="en"> 277<div class="titlepage"><div><div><h3 class="title"> 278<a name="id2564775"></a>Domains and Domain Names</h3></div></div></div> 279<p> 280 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 281 organizational or administrative boundaries. Each node of the tree, 282 called a <span class="emphasis"><em>domain</em></span>, is given a label. The domain 283 name of the 284 node is the concatenation of all the labels on the path from the 285 node to the <span class="emphasis"><em>root</em></span> node. This is represented 286 in written form as a string of labels listed from right to left and 287 separated by dots. A label need only be unique within its parent 288 domain. 289 </p> 290<p> 291 For example, a domain name for a host at the 292 company <span class="emphasis"><em>Example, Inc.</em></span> could be 293 <code class="literal">ourhost.example.com</code>, 294 where <code class="literal">com</code> is the 295 top level domain to which 296 <code class="literal">ourhost.example.com</code> belongs, 297 <code class="literal">example</code> is 298 a subdomain of <code class="literal">com</code>, and 299 <code class="literal">ourhost</code> is the 300 name of the host. 301 </p> 302<p> 303 For administrative purposes, the name space is partitioned into 304 areas called <span class="emphasis"><em>zones</em></span>, each starting at a node and 305 extending down to the leaf nodes or to nodes where other zones 306 start. 307 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 308 <span class="emphasis"><em>DNS protocol</em></span>. 309 </p> 310<p> 311 The data associated with each domain name is stored in the 312 form of <span class="emphasis"><em>resource records</em></span> (<acronym class="acronym">RR</acronym>s). 313 Some of the supported resource record types are described in 314 <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 </p> 316<p> 317 For more detailed information about the design of the DNS and 318 the DNS protocol, please refer to the standards documents listed in 319 <a href="Bv9ARM.ch09.html#rfcs" title="Request for Comments (RFCs)">the section called “Request for Comments (RFCs)”</a>. 320 </p> 321</div> 322<div class="sect2" lang="en"> 323<div class="titlepage"><div><div><h3 class="title"> 324<a name="id2567180"></a>Zones</h3></div></div></div> 325<p> 326 To properly operate a name server, it is important to understand 327 the difference between a <span class="emphasis"><em>zone</em></span> 328 and a <span class="emphasis"><em>domain</em></span>. 329 </p> 330<p> 331 As stated previously, a zone is a point of delegation in 332 the <acronym class="acronym">DNS</acronym> tree. A zone consists of 333 those contiguous parts of the domain 334 tree for which a name server has complete information and over which 335 it has authority. It contains all domain names from a certain point 336 downward in the domain tree except those which are delegated to 337 other zones. A delegation point is marked by one or more 338 <span class="emphasis"><em>NS records</em></span> in the 339 parent zone, which should be matched by equivalent NS records at 340 the root of the delegated zone. 341 </p> 342<p> 343 For instance, consider the <code class="literal">example.com</code> 344 domain which includes names 345 such as <code class="literal">host.aaa.example.com</code> and 346 <code class="literal">host.bbb.example.com</code> even though 347 the <code class="literal">example.com</code> zone includes 348 only delegations for the <code class="literal">aaa.example.com</code> and 349 <code class="literal">bbb.example.com</code> zones. A zone can 350 map 351 exactly to a single domain, but could also include only part of a 352 domain, the rest of which could be delegated to other 353 name servers. Every name in the <acronym class="acronym">DNS</acronym> 354 tree is a 355 <span class="emphasis"><em>domain</em></span>, even if it is 356 <span class="emphasis"><em>terminal</em></span>, that is, has no 357 <span class="emphasis"><em>subdomains</em></span>. Every subdomain is a domain and 358 every domain except the root is also a subdomain. The terminology is 359 not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 360 to 361 gain a complete understanding of this difficult and subtle 362 topic. 363 </p> 364<p> 365 Though <acronym class="acronym">BIND</acronym> is called a "domain name 366 server", 367 it deals primarily in terms of zones. The master and slave 368 declarations in the <code class="filename">named.conf</code> file 369 specify 370 zones, not domains. When you ask some other site if it is willing to 371 be a slave server for your <span class="emphasis"><em>domain</em></span>, you are 372 actually asking for slave service for some collection of zones. 373 </p> 374</div> 375<div class="sect2" lang="en"> 376<div class="titlepage"><div><div><h3 class="title"> 377<a name="id2567257"></a>Authoritative Name Servers</h3></div></div></div> 378<p> 379 Each zone is served by at least 380 one <span class="emphasis"><em>authoritative name server</em></span>, 381 which contains the complete data for the zone. 382 To make the DNS tolerant of server and network failures, 383 most zones have two or more authoritative servers, on 384 different networks. 385 </p> 386<p> 387 Responses from authoritative servers have the "authoritative 388 answer" (AA) bit set in the response packets. This makes them 389 easy to identify when debugging DNS configurations using tools like 390 <span><strong class="command">dig</strong></span> (<a href="Bv9ARM.ch03.html#diagnostic_tools" title="Diagnostic Tools">the section called “Diagnostic Tools”</a>). 391 </p> 392<div class="sect3" lang="en"> 393<div class="titlepage"><div><div><h4 class="title"> 394<a name="id2567281"></a>The Primary Master</h4></div></div></div> 395<p> 396 The authoritative server where the master copy of the zone 397 data is maintained is called the 398 <span class="emphasis"><em>primary master</em></span> server, or simply the 399 <span class="emphasis"><em>primary</em></span>. Typically it loads the zone 400 contents from some local file edited by humans or perhaps 401 generated mechanically from some other local file which is 402 edited by humans. This file is called the 403 <span class="emphasis"><em>zone file</em></span> or 404 <span class="emphasis"><em>master file</em></span>. 405 </p> 406<p> 407 In some cases, however, the master file may not be edited 408 by humans at all, but may instead be the result of 409 <span class="emphasis"><em>dynamic update</em></span> operations. 410 </p> 411</div> 412<div class="sect3" lang="en"> 413<div class="titlepage"><div><div><h4 class="title"> 414<a name="id2567379"></a>Slave Servers</h4></div></div></div> 415<p> 416 The other authoritative servers, the <span class="emphasis"><em>slave</em></span> 417 servers (also known as <span class="emphasis"><em>secondary</em></span> servers) 418 load 419 the zone contents from another server using a replication process 420 known as a <span class="emphasis"><em>zone transfer</em></span>. Typically the data 421 are 422 transferred directly from the primary master, but it is also 423 possible 424 to transfer it from another slave. In other words, a slave server 425 may itself act as a master to a subordinate slave server. 426 </p> 427</div> 428<div class="sect3" lang="en"> 429<div class="titlepage"><div><div><h4 class="title"> 430<a name="id2567400"></a>Stealth Servers</h4></div></div></div> 431<p> 432 Usually all of the zone's authoritative servers are listed in 433 NS records in the parent zone. These NS records constitute 434 a <span class="emphasis"><em>delegation</em></span> of the zone from the parent. 435 The authoritative servers are also listed in the zone file itself, 436 at the <span class="emphasis"><em>top level</em></span> or <span class="emphasis"><em>apex</em></span> 437 of the zone. You can list servers in the zone's top-level NS 438 records that are not in the parent's NS delegation, but you cannot 439 list servers in the parent's delegation that are not present at 440 the zone's top level. 441 </p> 442<p> 443 A <span class="emphasis"><em>stealth server</em></span> is a server that is 444 authoritative for a zone but is not listed in that zone's NS 445 records. Stealth servers can be used for keeping a local copy of 446 a 447 zone to speed up access to the zone's records or to make sure that 448 the 449 zone is available even if all the "official" servers for the zone 450 are 451 inaccessible. 452 </p> 453<p> 454 A configuration where the primary master server itself is a 455 stealth server is often referred to as a "hidden primary" 456 configuration. One use for this configuration is when the primary 457 master 458 is behind a firewall and therefore unable to communicate directly 459 with the outside world. 460 </p> 461</div> 462</div> 463<div class="sect2" lang="en"> 464<div class="titlepage"><div><div><h3 class="title"> 465<a name="id2567430"></a>Caching Name Servers</h3></div></div></div> 466<p> 467 The resolver libraries provided by most operating systems are 468 <span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not 469 capable of 470 performing the full DNS resolution process by themselves by talking 471 directly to the authoritative servers. Instead, they rely on a 472 local 473 name server to perform the resolution on their behalf. Such a 474 server 475 is called a <span class="emphasis"><em>recursive</em></span> name server; it performs 476 <span class="emphasis"><em>recursive lookups</em></span> for local clients. 477 </p> 478<p> 479 To improve performance, recursive servers cache the results of 480 the lookups they perform. Since the processes of recursion and 481 caching are intimately connected, the terms 482 <span class="emphasis"><em>recursive server</em></span> and 483 <span class="emphasis"><em>caching server</em></span> are often used synonymously. 484 </p> 485<p> 486 The length of time for which a record may be retained in 487 the cache of a caching name server is controlled by the 488 Time To Live (TTL) field associated with each resource record. 489 </p> 490<div class="sect3" lang="en"> 491<div class="titlepage"><div><div><h4 class="title"> 492<a name="id2567533"></a>Forwarding</h4></div></div></div> 493<p> 494 Even a caching name server does not necessarily perform 495 the complete recursive lookup itself. Instead, it can 496 <span class="emphasis"><em>forward</em></span> some or all of the queries 497 that it cannot satisfy from its cache to another caching name 498 server, 499 commonly referred to as a <span class="emphasis"><em>forwarder</em></span>. 500 </p> 501<p> 502 There may be one or more forwarders, 503 and they are queried in turn until the list is exhausted or an 504 answer 505 is found. Forwarders are typically used when you do not 506 wish all the servers at a given site to interact directly with the 507 rest of 508 the Internet servers. A typical scenario would involve a number 509 of internal <acronym class="acronym">DNS</acronym> servers and an 510 Internet firewall. Servers unable 511 to pass packets through the firewall would forward to the server 512 that can do it, and that server would query the Internet <acronym class="acronym">DNS</acronym> servers 513 on the internal server's behalf. 514 </p> 515</div> 516</div> 517<div class="sect2" lang="en"> 518<div class="titlepage"><div><div><h3 class="title"> 519<a name="id2567560"></a>Name Servers in Multiple Roles</h3></div></div></div> 520<p> 521 The <acronym class="acronym">BIND</acronym> name server can 522 simultaneously act as 523 a master for some zones, a slave for other zones, and as a caching 524 (recursive) server for a set of local clients. 525 </p> 526<p> 527 However, since the functions of authoritative name service 528 and caching/recursive name service are logically separate, it is 529 often advantageous to run them on separate server machines. 530 531 A server that only provides authoritative name service 532 (an <span class="emphasis"><em>authoritative-only</em></span> server) can run with 533 recursion disabled, improving reliability and security. 534 535 A server that is not authoritative for any zones and only provides 536 recursive service to local 537 clients (a <span class="emphasis"><em>caching-only</em></span> server) 538 does not need to be reachable from the Internet at large and can 539 be placed inside a firewall. 540 </p> 541</div> 542</div> 543</div> 544<div class="navfooter"> 545<hr> 546<table width="100%" summary="Navigation footer"> 547<tr> 548<td width="40%" align="left"> 549<a accesskey="p" href="Bv9ARM.html">Prev</a>�</td> 550<td width="20%" align="center">�</td> 551<td width="40%" align="right">�<a accesskey="n" href="Bv9ARM.ch02.html">Next</a> 552</td> 553</tr> 554<tr> 555<td width="40%" align="left" valign="top">BIND 9 Administrator Reference Manual�</td> 556<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td> 557<td width="40%" align="right" valign="top">�Chapter�2.�<acronym class="acronym">BIND</acronym> Resource Requirements</td> 558</tr> 559</table> 560</div> 561</body> 562</html> 563