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

   1 <!--
   2  - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
   3  - Copyright (C) 2000-2003 Internet Software Consortium.
   4  -
   5  - Permission to use, copy, modify, and 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: Bv9ARM.ch01.html,v 1.16.18.26 2008/05/24 01:31:10 tbox Exp $ -->
  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#id2563405">Scope of Document</a></span></dt>
  49 <dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564385">Organization of This Document</a></span></dt>
  50 <dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564524">Conventions Used in This Document</a></span></dt>
  51 <dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564637">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#id2564659">DNS Fundamentals</a></span></dt>
  54 <dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564693">Domains and Domain Names</a></span></dt>
  55 <dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564845">Zones</a></span></dt>
  56 <dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567243">Authoritative Name Servers</a></span></dt>
  57 <dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567416">Caching Name Servers</a></span></dt>
  58 <dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567546">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="id2563405"></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.4.
  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="id2564385"></a>Organization of This Document</h2></div></div></div>
  91 <p>
  92         In this document, <span class="emphasis"><em>Section 1</em></span> introduces
  93         the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Section 2</em></span>
  94         describes resource requirements for running <acronym class="acronym">BIND</acronym> in various
  95         environments. Information in <span class="emphasis"><em>Section 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>Section 4</em></span>, which contains more advanced
 101         concepts that the system administrator may need for implementing
 102         certain options. <span class="emphasis"><em>Section 5</em></span>
 103         describes the <acronym class="acronym">BIND</acronym> 9 lightweight
 104         resolver.  The contents of <span class="emphasis"><em>Section 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>Section 7</em></span> addresses
 107         security considerations, and
 108         <span class="emphasis"><em>Section 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="id2564524"></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="id2564637"></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="id2564659"></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 two resolver
 271           libraries, <span><strong class="command">liblwres</strong></span> and <span><strong class="command">libbind</strong></span>.
 272         </p>
 273 </div>
 274 <div class="sect2" lang="en">
 275 <div class="titlepage"><div><div><h3 class="title">
 276 <a name="id2564693"></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 &#8220;Types of Resource Records and When to Use Them&#8221;</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.ch09.html#rfcs" title="Request for Comments (RFCs)">the section called &#8220;Request for Comments (RFCs)&#8221;</a>.
 318         </p>
 319 </div>
 320 <div class="sect2" lang="en">
 321 <div class="titlepage"><div><div><h3 class="title">
 322 <a name="id2564845"></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="id2567243"></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 &#8220;Diagnostic Tools&#8221;</a>).
 389         </p>
 390 <div class="sect3" lang="en">
 391 <div class="titlepage"><div><div><h4 class="title">
 392 <a name="id2567267"></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="id2567297"></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="id2567386"></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="id2567416"></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="id2567520"></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="id2567546"></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 </body>
 560 </html>