1<!-- 2 - Copyright (C) 2004-2015 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#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> 52<dd><dl> 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> 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="id2563509"></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>This version of the manual corresponds to BIND version 9.10.</p> 85</div> 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> 89<p> 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> 111 and the Domain Name 112 System. 113 </p> 114</div> 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> 118<p> 119 In this document, we use the following general typographic 120 conventions: 121 </p> 122<div class="informaltable"><table border="1"> 123<colgroup> 124<col> 125<col> 126</colgroup> 127<tbody> 128<tr> 129<td> 130 <p> 131 <span class="emphasis"><em>To describe:</em></span> 132 </p> 133 </td> 134<td> 135 <p> 136 <span class="emphasis"><em>We use the style:</em></span> 137 </p> 138 </td> 139</tr> 140<tr> 141<td> 142 <p> 143 a pathname, filename, URL, hostname, 144 mailing list name, or new term or concept 145 </p> 146 </td> 147<td> 148 <p> 149 <code class="filename">Fixed width</code> 150 </p> 151 </td> 152</tr> 153<tr> 154<td> 155 <p> 156 literal user 157 input 158 </p> 159 </td> 160<td> 161 <p> 162 <strong class="userinput"><code>Fixed Width Bold</code></strong> 163 </p> 164 </td> 165</tr> 166<tr> 167<td> 168 <p> 169 program output 170 </p> 171 </td> 172<td> 173 <p> 174 <code class="computeroutput">Fixed Width</code> 175 </p> 176 </td> 177</tr> 178</tbody> 179</table></div> 180<p> 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"> 184<colgroup> 185<col> 186<col> 187</colgroup> 188<tbody> 189<tr> 190<td> 191 <p> 192 <span class="emphasis"><em>To describe:</em></span> 193 </p> 194 </td> 195<td> 196 <p> 197 <span class="emphasis"><em>We use the style:</em></span> 198 </p> 199 </td> 200</tr> 201<tr> 202<td> 203 <p> 204 keywords 205 </p> 206 </td> 207<td> 208 <p> 209 <code class="literal">Fixed Width</code> 210 </p> 211 </td> 212</tr> 213<tr> 214<td> 215 <p> 216 variables 217 </p> 218 </td> 219<td> 220 <p> 221 <code class="varname">Fixed Width</code> 222 </p> 223 </td> 224</tr> 225<tr> 226<td> 227 <p> 228 Optional input 229 </p> 230 </td> 231<td> 232 <p> 233 [<span class="optional">Text is enclosed in square brackets</span>] 234 </p> 235 </td> 236</tr> 237</tbody> 238</table></div> 239<p> 240 </p> 241</div> 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> 245<p> 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>. 251 </p> 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> 255<p> 256 The Domain Name System (DNS) is a hierarchical, distributed 257 database. It stores information for mapping Internet host names to 258 IP 259 addresses and vice versa, mail routing information, and other data 260 used by Internet applications. 261 </p> 262<p> 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 267 contains a 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. 272 </p> 273</div> 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> 277<p> 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 281 name of the 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 286 domain. 287 </p> 288<p> 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 298 name of the host. 299 </p> 300<p> 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 304 start. 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>. 307 </p> 308<p> 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>. 313 </p> 314<p> 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>. 318 </p> 319</div> 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> 323<p> 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>. 327 </p> 328<p> 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. 339 </p> 340<p> 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 348 map 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> 352 tree is a 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 358 to 359 gain a complete understanding of this difficult and subtle 360 topic. 361 </p> 362<p> 363 Though <acronym class="acronym">BIND</acronym> is called a "domain name 364 server", 365 it deals primarily in terms of zones. The master and slave 366 declarations in the <code class="filename">named.conf</code> file 367 specify 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. 371 </p> 372</div> 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> 376<p> 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 382 different networks. 383 </p> 384<p> 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>). 389 </p> 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> 393<p> 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>. 403 </p> 404<p> 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. 408 </p> 409</div> 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> 413<p> 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) 416 load 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 419 are 420 transferred directly from the primary master, but it is also 421 possible 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. 424 </p> 425</div> 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> 429<p> 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. 439 </p> 440<p> 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 444 a 445 zone to speed up access to the zone's records or to make sure that 446 the 447 zone is available even if all the "official" servers for the zone 448 are 449 inaccessible. 450 </p> 451<p> 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 455 master 456 is behind a firewall and therefore unable to communicate directly 457 with the outside world. 458 </p> 459</div> 460</div> 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> 464<p> 465 The resolver libraries provided by most operating systems are 466 <span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not 467 capable of 468 performing the full DNS resolution process by themselves by talking 469 directly to the authoritative servers. Instead, they rely on a 470 local 471 name server to perform the resolution on their behalf. Such a 472 server 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. 475 </p> 476<p> 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. 482 </p> 483<p> 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. 487 </p> 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> 491<p> 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 496 server, 497 commonly referred to as a <span class="emphasis"><em>forwarder</em></span>. 498 </p> 499<p> 500 There may be one or more forwarders, 501 and they are queried in turn until the list is exhausted or an 502 answer 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 505 rest of 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. 512 </p> 513</div> 514</div> 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> 518<p> 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. 523 </p> 524<p> 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. 528 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. 532 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. 538 </p> 539</div> 540</div> 541</div> 542<div class="navfooter"> 543<hr> 544<table width="100%" summary="Navigation footer"> 545<tr> 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> 550</td> 551</tr> 552<tr> 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> 556</tr> 557</table> 558</div> 559<p style="text-align: center;">BIND 9.10.2-P4</p> 560</body> 561</html> 562