contrib/bind9/doc/arm/Bv9ARM.ch01.html

   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 &#8220;Types of Resource Records and When to Use Them&#8221;</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 &#8220;Request for Comments (RFCs)&#8221;</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 &#8220;Diagnostic Tools&#8221;</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>