Bv9ARM-book.xml 443 KB
Newer Older
1
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
	       [<!ENTITY mdash "&#8212;">]>
<!--
 - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 - Copyright (C) 2000-2003  Internet Software Consortium.
 -
 - Permission to use, copy, modify, and distribute this software for any
 - purpose with or without fee is hereby granted, provided that the above
 - copyright notice and this permission notice appear in all copies.
 -
 - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
 - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 - PERFORMANCE OF THIS SOFTWARE.
-->

<!-- File: $Id: Bv9ARM-book.xml,v 1.267 2005/05/11 05:55:33 sra Exp $ -->
<book>
  <title>BIND 9 Administrator Reference Manual</title>

  <bookinfo>
    <copyright>
      <year>2004</year>
      <year>2005</year>
      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
    </copyright>
    <copyright>
      <year>2000</year>
      <year>2001</year>
      <year>2002</year>
      <year>2003</year>
      <holder>Internet Software Consortium</holder>
    </copyright>
  </bookinfo>

  <chapter id="Bv9ARM.ch01">
    <title>Introduction</title>
    <para>
      The Internet Domain Name System (<acronym>DNS</acronym>)
      consists of the syntax
      to specify the names of entities in the Internet in a hierarchical
      manner, the rules used for delegating authority over names, and the
      system implementation that actually maps names to Internet
      addresses.  <acronym>DNS</acronym> data is maintained in a
      group of distributed
      hierarchical databases.
    </para>

    <sect1>
      <title>Scope of Document</title>

      <para>
        The Berkeley Internet Name Domain
        (<acronym>BIND</acronym>) implements an
        domain name server for a number of operating systems. This
        document provides basic information about the installation and
        care of the Internet Software Consortium (<acronym>ISC</acronym>)
        <acronym>BIND</acronym> version 9 software package for
        system
        administrators.
      </para>
66

67 68 69
      <para>
        This version of the manual corresponds to BIND version 9.3.
      </para>
70

71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
    </sect1>
    <sect1>
      <title>Organization of This Document</title>
      <para>
        In this document, <emphasis>Section 1</emphasis> introduces
        the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Section 2</emphasis>
        describes resource requirements for running <acronym>BIND</acronym> in various
        environments. Information in <emphasis>Section 3</emphasis> is
        <emphasis>task-oriented</emphasis> in its presentation and is
        organized functionally, to aid in the process of installing the
        <acronym>BIND</acronym> 9 software. The task-oriented
        section is followed by
        <emphasis>Section 4</emphasis>, which contains more advanced
        concepts that the system administrator may need for implementing
        certain options. <emphasis>Section 5</emphasis>
        describes the <acronym>BIND</acronym> 9 lightweight
        resolver.  The contents of <emphasis>Section 6</emphasis> are
        organized as in a reference manual to aid in the ongoing
        maintenance of the software. <emphasis>Section 7</emphasis> addresses
        security considerations, and
        <emphasis>Section 8</emphasis> contains troubleshooting help. The
        main body of the document is followed by several
        <emphasis>Appendices</emphasis> which contain useful reference
        information, such as a <emphasis>Bibliography</emphasis> and
        historic information related to <acronym>BIND</acronym>
        and the Domain Name
        System.
      </para>
    </sect1>
    <sect1>
      <title>Conventions Used in This Document</title>

      <para>
        In this document, we use the following general typographic
        conventions:
      </para>

      <informaltable>
        <tgroup cols="2">
          <colspec colname="1" colnum="1" colwidth="3.000in"/>
          <colspec colname="2" colnum="2" colwidth="2.625in"/>
112
          <tbody>
113
            <row>
114 115 116 117 118 119 120 121 122 123
              <entry colname="1">
                <para>
                  <emphasis>To describe:</emphasis>
                </para>
              </entry>
              <entry colname="2">
                <para>
                  <emphasis>We use the style:</emphasis>
                </para>
              </entry>
124
            </row>
125
            <row>
126 127 128 129 130 131 132 133 134 135 136
              <entry colname="1">
                <para>
                  a pathname, filename, URL, hostname,
                  mailing list name, or new term or concept
                </para>
              </entry>
              <entry colname="2">
                <para>
                  <filename>Fixed width</filename>
                </para>
              </entry>
137
            </row>
138
            <row>
139 140 141 142 143 144 145 146 147 148 149
              <entry colname="1">
                <para>
                  literal user
                  input
                </para>
              </entry>
              <entry colname="2">
                <para>
                  <userinput>Fixed Width Bold</userinput>
                </para>
              </entry>
150
            </row>
151
            <row>
152 153 154 155 156 157 158 159 160 161
              <entry colname="1">
                <para>
                  program output
                </para>
              </entry>
              <entry colname="2">
                <para>
                  <computeroutput>Fixed Width</computeroutput>
                </para>
              </entry>
162 163 164
            </row>
          </tbody>
        </tgroup>
165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658
      </informaltable>

      <para>
        The following conventions are used in descriptions of the
        <acronym>BIND</acronym> configuration file:<informaltable colsep="0" frame="all" rowsep="0">
                  <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
                      <colspec colname="1" colnum="1" colsep="0" colwidth="3.000in"/>
            <colspec colname="2" colnum="2" colsep="0" colwidth="2.625in"/>
            <tbody>
              <row rowsep="0">
                <entry colname="1" colsep="1" rowsep="1">
                  <para>
                    <emphasis>To describe:</emphasis>
                  </para>
                </entry>
                <entry colname="2" rowsep="1">
                  <para>
                    <emphasis>We use the style:</emphasis>
                  </para>
                </entry>
              </row>
              <row rowsep="0">
                <entry colname="1" colsep="1" rowsep="1">
                  <para>
                    keywords
                  </para>
                </entry>
                <entry colname="2" rowsep="1">
                  <para>
                    <literal>Fixed Width</literal>
                  </para>
                </entry>
              </row>
              <row rowsep="0">
                <entry colname="1" colsep="1" rowsep="1">
                  <para>
                    variables
                  </para>
                </entry>
                <entry colname="2" rowsep="1">
                  <para>
                    <varname>Fixed Width</varname>
                  </para>
                </entry>
              </row>
              <row rowsep="0">
                <entry colname="1" colsep="1">
                  <para>
                    Optional input
                  </para>
                </entry>
                <entry colname="2">
                  <para>
                    <optional>Text is enclosed in square brackets</optional>
                  </para>
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>
      </para>
    </sect1>
    <sect1>
      <title>The Domain Name System (<acronym>DNS</acronym>)</title>
      <para>
        The purpose of this document is to explain the installation
        and upkeep of the <acronym>BIND</acronym> software
        package, and we
        begin by reviewing the fundamentals of the Domain Name System
        (<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>.
      </para>

      <sect2>
        <title>DNS Fundamentals</title>

        <para>
          The Domain Name System (DNS) is the hierarchical, distributed
          database.  It stores information for mapping Internet host names to
          IP
          addresses and vice versa, mail routing information, and other data
          used by Internet applications.
        </para>

        <para>
          Clients look up information in the DNS by calling a
          <emphasis>resolver</emphasis> library, which sends queries to one or
          more <emphasis>name servers</emphasis> and interprets the responses.
          The <acronym>BIND</acronym> 9 software distribution
          contains a
          name server, <command>named</command>, and two resolver
          libraries, <command>liblwres</command> and <command>libbind</command>.
        </para>

        </sect2><sect2>
        <title>Domains and Domain Names</title>

        <para>
          The data stored in the DNS is identified by <emphasis>domain names</emphasis> that are organized as a tree according to
          organizational or administrative boundaries. Each node of the tree,
          called a <emphasis>domain</emphasis>, is given a label. The domain
          name of the
          node is the concatenation of all the labels on the path from the
          node to the <emphasis>root</emphasis> node.  This is represented
          in written form as a string of labels listed from right to left and
          separated by dots. A label need only be unique within its parent
          domain.
        </para>

        <para>
          For example, a domain name for a host at the
          company <emphasis>Example, Inc.</emphasis> could be
          <literal>mail.example.com</literal>,
          where <literal>com</literal> is the
          top level domain to which
          <literal>ourhost.example.com</literal> belongs,
          <literal>example</literal> is
          a subdomain of <literal>com</literal>, and
          <literal>ourhost</literal> is the
          name of the host.
        </para>

        <para>
          For administrative purposes, the name space is partitioned into
          areas called <emphasis>zones</emphasis>, each starting at a node and
          extending down to the leaf nodes or to nodes where other zones
          start.
          The data for each zone is stored in a <emphasis>name server</emphasis>, which answers queries about the zone using the
          <emphasis>DNS protocol</emphasis>.
        </para>

        <para>
          The data associated with each domain name is stored in the
          form of <emphasis>resource records</emphasis> (<acronym>RR</acronym>s).
          Some of the supported resource record types are described in
          <xref linkend="types_of_resource_records_and_when_to_use_them"/>.
        </para>

        <para>
          For more detailed information about the design of the DNS and
          the DNS protocol, please refer to the standards documents listed in
          <xref linkend="rfcs"/>.
        </para>
      </sect2>

      <sect2>
        <title>Zones</title>
        <para>
          To properly operate a name server, it is important to understand
          the difference between a <emphasis>zone</emphasis>
          and a <emphasis>domain</emphasis>.
        </para>

        <para>
          As we stated previously, a zone is a point of delegation in
          the <acronym>DNS</acronym> tree. A zone consists of
          those contiguous parts of the domain
          tree for which a name server has complete information and over which
          it has authority. It contains all domain names from a certain point
          downward in the domain tree except those which are delegated to
          other zones. A delegation point is marked by one or more
          <emphasis>NS records</emphasis> in the
          parent zone, which should be matched by equivalent NS records at
          the root of the delegated zone.
        </para>

        <para>
          For instance, consider the <literal>example.com</literal>
          domain which includes names
          such as <literal>host.aaa.example.com</literal> and
          <literal>host.bbb.example.com</literal> even though
          the <literal>example.com</literal> zone includes
          only delegations for the <literal>aaa.example.com</literal> and
          <literal>bbb.example.com</literal> zones.  A zone can
          map
          exactly to a single domain, but could also include only part of a
          domain, the rest of which could be delegated to other
          name servers. Every name in the <acronym>DNS</acronym>
          tree is a
          <emphasis>domain</emphasis>, even if it is
          <emphasis>terminal</emphasis>, that is, has no
          <emphasis>subdomains</emphasis>.  Every subdomain is a domain and
          every domain except the root is also a subdomain. The terminology is
          not intuitive and we suggest that you read RFCs 1033, 1034 and 1035
          to
          gain a complete understanding of this difficult and subtle
          topic.
        </para>

        <para>
          Though <acronym>BIND</acronym> is called a "domain name
          server",
          it deals primarily in terms of zones. The master and slave
          declarations in the <filename>named.conf</filename> file
          specify
          zones, not domains. When you ask some other site if it is willing to
          be a slave server for your <emphasis>domain</emphasis>, you are
          actually asking for slave service for some collection of zones.
        </para>
      </sect2>

      <sect2>
        <title>Authoritative Name Servers</title>

        <para>
          Each zone is served by at least
          one <emphasis>authoritative name server</emphasis>,
          which contains the complete data for the zone.
          To make the DNS tolerant of server and network failures,
          most zones have two or more authoritative servers.
        </para>

        <para>
          Responses from authoritative servers have the "authoritative
          answer" (AA) bit set in the response packets.  This makes them
          easy to identify when debugging DNS configurations using tools like
          <command>dig</command> (<xref linkend="diagnostic_tools"/>).
        </para>

        <sect3>
          <title>The Primary Master</title>

          <para>
            The authoritative server where the master copy of the zone data is
            maintained is
            called the <emphasis>primary master</emphasis> server, or simply
            the
            <emphasis>primary</emphasis>.  It loads the zone contents from
            some
            local file edited by humans or perhaps generated mechanically from
            some other local file which is edited by humans.  This file is
            called
            the <emphasis>zone file</emphasis> or <emphasis>master file</emphasis>.
          </para>
        </sect3>

        <sect3>
          <title>Slave Servers</title>
          <para>
            The other authoritative servers, the <emphasis>slave</emphasis>
            servers (also known as <emphasis>secondary</emphasis> servers)
            load
            the zone contents from another server using a replication process
            known as a <emphasis>zone transfer</emphasis>.  Typically the data
            are
            transferred directly from the primary master, but it is also
            possible
            to transfer it from another slave.  In other words, a slave server
            may itself act as a master to a subordinate slave server.
          </para>
        </sect3>

        <sect3>
          <title>Stealth Servers</title>

          <para>
            Usually all of the zone's authoritative servers are listed in
            NS records in the parent zone.  These NS records constitute
            a <emphasis>delegation</emphasis> of the zone from the parent.
            The authoritative servers are also listed in the zone file itself,
            at the <emphasis>top level</emphasis> or <emphasis>apex</emphasis>
            of the zone.  You can list servers in the zone's top-level NS
            records that are not in the parent's NS delegation, but you cannot
            list servers in the parent's delegation that are not present at
            the zone's top level.
          </para>

          <para>
            A <emphasis>stealth server</emphasis> is a server that is
            authoritative for a zone but is not listed in that zone's NS
            records.  Stealth servers can be used for keeping a local copy of
            a
            zone to speed up access to the zone's records or to make sure that
            the
            zone is available even if all the "official" servers for the zone
            are
            inaccessible.
          </para>

          <para>
            A configuration where the primary master server itself is a
            stealth server is often referred to as a "hidden primary"
            configuration.  One use for this configuration is when the primary
            master
            is behind a firewall and therefore unable to communicate directly
            with the outside world.
          </para>

        </sect3>

      </sect2>
      <sect2>

        <title>Caching Name Servers</title>

        <para>
          The resolver libraries provided by most operating systems are
          <emphasis>stub resolvers</emphasis>, meaning that they are not
          capable of
          performing the full DNS resolution process by themselves by talking
          directly to the authoritative servers.  Instead, they rely on a
          local
          name server to perform the resolution on their behalf.  Such a
          server
          is called a <emphasis>recursive</emphasis> name server; it performs
          <emphasis>recursive lookups</emphasis> for local clients.
        </para>

        <para>
          To improve performance, recursive servers cache the results of
          the lookups they perform.  Since the processes of recursion and
          caching are intimately connected, the terms
          <emphasis>recursive server</emphasis> and
          <emphasis>caching server</emphasis> are often used synonymously.
        </para>

        <para>
          The length of time for which a record may be retained in
          in the cache of a caching name server is controlled by the
          Time To Live (TTL) field associated with each resource record.
        </para>

        <sect3>
          <title>Forwarding</title>

          <para>
            Even a caching name server does not necessarily perform
            the complete recursive lookup itself.  Instead, it can
            <emphasis>forward</emphasis> some or all of the queries
            that it cannot satisfy from its cache to another caching name
            server,
            commonly referred to as a <emphasis>forwarder</emphasis>.
          </para>

          <para>
            There may be one or more forwarders,
            and they are queried in turn until the list is exhausted or an
            answer
            is found. Forwarders are typically used when you do not
            wish all the servers at a given site to interact directly with the
            rest of
            the Internet servers. A typical scenario would involve a number
            of internal <acronym>DNS</acronym> servers and an
            Internet firewall. Servers unable
            to pass packets through the firewall would forward to the server
            that can do it, and that server would query the Internet <acronym>DNS</acronym> servers
            on the internal server's behalf. An added benefit of using the
            forwarding
            feature is that the central machine develops a much more complete
            cache of information that all the clients can take advantage
            of.
          </para>
        </sect3>

      </sect2>

      <sect2>
        <title>Name Servers in Multiple Roles</title>

        <para>
          The <acronym>BIND</acronym> name server can
          simultaneously act as
          a master for some zones, a slave for other zones, and as a caching
          (recursive) server for a set of local clients.
        </para>

        <para>
          However, since the functions of authoritative name service
          and caching/recursive name service are logically separate, it is
          often advantageous to run them on separate server machines.

          A server that only provides authoritative name service
          (an <emphasis>authoritative-only</emphasis> server) can run with
          recursion disabled, improving reliability and security.

          A server that is not authoritative for any zones and only provides
          recursive service to local
          clients (a <emphasis>caching-only</emphasis> server)
          does not need to be reachable from the Internet at large and can
          be placed inside a firewall.
        </para>

      </sect2>
    </sect1>

  </chapter>

  <chapter id="Bv9ARM.ch02">
    <title><acronym>BIND</acronym> Resource Requirements</title>

    <sect1>
      <title>Hardware requirements</title>

      <para>
        <acronym>DNS</acronym> hardware requirements have
        traditionally been quite modest.
        For many installations, servers that have been pensioned off from
        active duty have performed admirably as <acronym>DNS</acronym> servers.
      </para>
      <para>
        The DNSSEC and IPv6 features of <acronym>BIND</acronym> 9
        may prove to be quite
        CPU intensive however, so organizations that make heavy use of these
        features may wish to consider larger systems for these applications.
        <acronym>BIND</acronym> 9 is fully multithreaded, allowing
        full utilization of
        multiprocessor systems for installations that need it.
      </para>
    </sect1>
    <sect1>
      <title>CPU Requirements</title>
      <para>
        CPU requirements for <acronym>BIND</acronym> 9 range from
        i486-class machines
        for serving of static zones without caching, to enterprise-class
        machines if you intend to process many dynamic updates and DNSSEC
        signed zones, serving many thousands of queries per second.
      </para>
    </sect1>

    <sect1>
      <title>Memory Requirements</title>
      <para>
        The memory of the server has to be large enough to fit the
        cache and zones loaded off disk.  The <command>max-cache-size</command>
        option can be used to limit the amount of memory used by the cache,
        at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
        traffic.
        Additionally, if additional section caching
        (<xref linkend="acache"/>) is enabled,
        the <command>max-acache-size</command> can be used to
        limit the amount
        of memory used by the mechanism.
        It is still good practice to have enough memory to load
        all zone and cache data into memory &mdash; unfortunately, the best
        way
        to determine this for a given installation is to watch the name server
        in operation. After a few weeks the server process should reach
        a relatively stable size where entries are expiring from the cache as
        fast as they are being inserted.
      </para>
    </sect1>

    <sect1>
      <title>Name Server Intensive Environment Issues</title>
      <para>
        For name server intensive environments, there are two alternative
        configurations that may be used. The first is where clients and
        any second-level internal name servers query a main name server, which
        has enough memory to build a large cache. This approach minimizes
        the bandwidth used by external name lookups. The second alternative
        is to set up second-level internal name servers to make queries
        independently.
        In this configuration, none of the individual machines needs to
        have as much memory or CPU power as in the first alternative, but
        this has the disadvantage of making many more external queries,
        as none of the name servers share their cached data.
      </para>
    </sect1>

    <sect1>
      <title>Supported Operating Systems</title>
      <para>
        ISC <acronym>BIND</acronym> 9 compiles and runs on a large
        number
        of Unix-like operating system and on Windows NT / 2000.  For an
        up-to-date
        list of supported systems, see the README file in the top level
        directory
        of the BIND 9 source distribution.
      </para>
    </sect1>
  </chapter>

  <chapter id="Bv9ARM.ch03">
    <title>Name Server Configuration</title>
    <para>
      In this section we provide some suggested configurations along
      with guidelines for their use. We also address the topic of reasonable
      option setting.
    </para>

    <sect1 id="sample_configuration">
      <title>Sample Configurations</title>
      <sect2>
        <title>A Caching-only Name Server</title>
        <para>
          The following sample configuration is appropriate for a caching-only
          name server for use by clients internal to a corporation.  All
          queries
          from outside clients are refused using the <command>allow-query</command>
          option.  Alternatively, the same effect could be achieved using
          suitable
          firewall rules.
        </para>
659 660

<programlisting>
661
// Two corporate subnets we wish to allow queries from.
662
acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
663
options {
664
     directory "/etc/namedb";           // Working directory
665
     allow-query { corpnets; };
666 667 668 669 670 671 672 673
};
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
     type master;
     file "localhost.rev";
     notify no;
};
</programlisting>
674

675 676 677 678 679 680 681 682 683
      </sect2>

      <sect2>
        <title>An Authoritative-only Name Server</title>
        <para>
          This sample configuration is for an authoritative-only server
          that is the master server for "<filename>example.com</filename>"
          and a slave for the subdomain "<filename>eng.example.com</filename>".
        </para>
684 685

<programlisting>
686
options {
687
     directory "/etc/namedb";           // Working directory
688
     allow-query-cache { none; };       // Do not allow access to cache
689 690
     allow-query { any; };              // This is the default
     recursion no;                      // Do not provide recursive service
691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716
};

// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
     type master;
     file "localhost.rev";
     notify no;
};
// We are the master server for example.com
zone "example.com" {
     type master;
     file "example.com.db";
     // IP addresses of slave servers allowed to transfer example.com
     allow-transfer {
          192.168.4.14;
          192.168.5.53;
     };
};
// We are a slave server for eng.example.com
zone "eng.example.com" {
     type slave;
     file "eng.example.com.bk";
     // IP address of eng.example.com master server
     masters { 192.168.4.12; };
};
</programlisting>
717

718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095
      </sect2>
    </sect1>

    <sect1>
      <title>Load Balancing</title>

      <para>
        A primitive form of load balancing can be achieved in
        the <acronym>DNS</acronym> by using multiple A records for
        one name.
      </para>

      <para>
        For example, if you have three WWW servers with network addresses
        of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the
        following means that clients will connect to each machine one third
        of the time:
      </para>

      <informaltable colsep="0" rowsep="0">
        <tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="2Level-table">
          <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
          <colspec colname="2" colnum="2" colsep="0" colwidth="0.500in"/>
          <colspec colname="3" colnum="3" colsep="0" colwidth="0.750in"/>
          <colspec colname="4" colnum="4" colsep="0" colwidth="0.750in"/>
          <colspec colname="5" colnum="5" colsep="0" colwidth="2.028in"/>
          <tbody>
            <row rowsep="0">
              <entry colname="1">
                <para>
                  Name
                </para>
              </entry>
              <entry colname="2">
                <para>
                  TTL
                </para>
              </entry>
              <entry colname="3">
                <para>
                  CLASS
                </para>
              </entry>
              <entry colname="4">
                <para>
                  TYPE
                </para>
              </entry>
              <entry colname="5">
                <para>
                  Resource Record (RR) Data
                </para>
              </entry>
            </row>
            <row rowsep="0">
              <entry colname="1">
                <para>
                  <literal>www</literal>
                </para>
              </entry>
              <entry colname="2">
                <para>
                  <literal>600</literal>
                </para>
              </entry>
              <entry colname="3">
                <para>
                  <literal>IN</literal>
                </para>
              </entry>
              <entry colname="4">
                <para>
                  <literal>A</literal>
                </para>
              </entry>
              <entry colname="5">
                <para>
                  <literal>10.0.0.1</literal>
                </para>
              </entry>
            </row>
            <row rowsep="0">
              <entry colname="1">
                <para/>
              </entry>
              <entry colname="2">
                <para>
                  <literal>600</literal>
                </para>
              </entry>
              <entry colname="3">
                <para>
                  <literal>IN</literal>
                </para>
              </entry>
              <entry colname="4">
                <para>
                  <literal>A</literal>
                </para>
              </entry>
              <entry colname="5">
                <para>
                  <literal>10.0.0.2</literal>
                </para>
              </entry>
            </row>
            <row rowsep="0">
              <entry colname="1">
                <para/>
              </entry>
              <entry colname="2">
                <para>
                  <literal>600</literal>
                </para>
              </entry>
              <entry colname="3">
                <para>
                  <literal>IN</literal>
                </para>
              </entry>
              <entry colname="4">
                <para>
                  <literal>A</literal>
                </para>
              </entry>
              <entry colname="5">
                <para>
                  <literal>10.0.0.3</literal>
                </para>
              </entry>
            </row>
          </tbody>
        </tgroup>
      </informaltable>
      <para>
        When a resolver queries for these records, <acronym>BIND</acronym> will rotate
        them and respond to the query with the records in a different
        order.  In the example above, clients will randomly receive
        records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
        will use the first record returned and discard the rest.
      </para>
      <para>
        For more detail on ordering responses, check the
        <command>rrset-order</command> substatement in the
        <command>options</command> statement, see
        <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
        This substatement is not supported in
        <acronym>BIND</acronym> 9, and only the ordering scheme
        described above is
        available.
      </para>

    </sect1>

    <sect1>
      <title>Name Server Operations</title>

      <sect2>
        <title>Tools for Use With the Name Server Daemon</title>
        <para>
          There are several indispensable diagnostic, administrative
          and monitoring tools available to the system administrator for
          controlling
          and debugging the name server daemon. We describe several in this
          section
        </para>
        <sect3 id="diagnostic_tools">
          <title>Diagnostic Tools</title>
          <para>
            The <command>dig</command>, <command>host</command>, and
            <command>nslookup</command> programs are all command
            line tools
            for manually querying name servers.  They differ in style and
            output format.
          </para>

          <variablelist>
            <varlistentry>
              <term id="dig"><command>dig</command></term>
              <listitem>
                <para>
                  The domain information groper (<command>dig</command>)
                  is the most versatile and complete of these lookup tools.
                  It has two modes: simple interactive
                  mode for a single query, and batch mode which executes a
                  query for
                  each in a list of several query lines. All query options are
                  accessible
                  from the command line.
                </para>
                <cmdsynopsis label="Usage">
                  <command>dig</command>
                  <arg>@<replaceable>server</replaceable></arg>
                  <arg choice="plain"><replaceable>domain</replaceable></arg>
                  <arg><replaceable>query-type</replaceable></arg>
                  <arg><replaceable>query-class</replaceable></arg>
                  <arg>+<replaceable>query-option</replaceable></arg>
                  <arg>-<replaceable>dig-option</replaceable></arg>
                  <arg>%<replaceable>comment</replaceable></arg>
                </cmdsynopsis>
                <para>
                  The usual simple use of dig will take the form
                </para>
                <simpara>
                  <command>dig @server domain query-type query-class</command>
                </simpara>
                <para>
                  For more information and a list of available commands and
                  options, see the <command>dig</command> man
                  page.
                </para>
              </listitem>
            </varlistentry>

            <varlistentry>
              <term><command>host</command></term>
              <listitem>
                <para>
                  The <command>host</command> utility emphasizes
                  simplicity
                  and ease of use.  By default, it converts
                  between host names and Internet addresses, but its
                  functionality
                  can be extended with the use of options.
                </para>
                <cmdsynopsis label="Usage">
                  <command>host</command>
                  <arg>-aCdlrTwv</arg>
                  <arg>-c <replaceable>class</replaceable></arg>
                  <arg>-N <replaceable>ndots</replaceable></arg>
                  <arg>-t <replaceable>type</replaceable></arg>
                  <arg>-W <replaceable>timeout</replaceable></arg>
                  <arg>-R <replaceable>retries</replaceable></arg>
                  <arg choice="plain"><replaceable>hostname</replaceable></arg>
                  <arg><replaceable>server</replaceable></arg>
                </cmdsynopsis>
                <para>
                  For more information and a list of available commands and
                  options, see the <command>host</command> man
                  page.
                </para>
              </listitem>
            </varlistentry>

            <varlistentry>
              <term><command>nslookup</command></term>
              <listitem>
                <para><command>nslookup</command>
		  has two modes: interactive and
                  non-interactive. Interactive mode allows the user to
                  query name servers for information about various
                  hosts and domains or to print a list of hosts in a
                  domain. Non-interactive mode is used to print just
                  the name and requested information for a host or
                  domain.
                </para>
                <cmdsynopsis label="Usage">
                  <command>nslookup</command>
                  <arg rep="repeat">-option</arg>
                  <group>
                    <arg><replaceable>host-to-find</replaceable></arg>
                    <arg>- <arg>server</arg></arg>
                  </group>
                </cmdsynopsis>
                <para>
                  Interactive mode is entered when no arguments are given (the
                  default name server will be used) or when the first argument
                  is a
                  hyphen (`-') and the second argument is the host name or
                  Internet address
                  of a name server.
                </para>
                <para>
                  Non-interactive mode is used when the name or Internet
                  address
                  of the host to be looked up is given as the first argument.
                  The
                  optional second argument specifies the host name or address
                  of a name server.
                </para>
                <para>
                  Due to its arcane user interface and frequently inconsistent
                  behavior, we do not recommend the use of <command>nslookup</command>.
                  Use <command>dig</command> instead.
                </para>
              </listitem>

            </varlistentry>
          </variablelist>
        </sect3>

        <sect3 id="admin_tools">
          <title>Administrative Tools</title>
          <para>
            Administrative tools play an integral part in the management
            of a server.
          </para>
          <variablelist>
            <varlistentry id="named-checkconf" xreflabel="Named Configuration Checking application">

              <term><command>named-checkconf</command></term>
              <listitem>
                <para>
                  The <command>named-checkconf</command> program
                  checks the syntax of a <filename>named.conf</filename> file.
                </para>
                <cmdsynopsis label="Usage">
                  <command>named-checkconf</command>
                  <arg>-jvz</arg>
                  <arg>-t <replaceable>directory</replaceable></arg>
                  <arg><replaceable>filename</replaceable></arg>
                </cmdsynopsis>
              </listitem>
            </varlistentry>
            <varlistentry id="named-checkzone" xreflabel="Zone Checking application">

              <term><command>named-checkzone</command></term>
              <listitem>
                <para>
                  The <command>named-checkzone</command> program
                  checks a master file for
                  syntax and consistency.
                </para>
                <cmdsynopsis label="Usage">
                  <command>named-checkzone</command>
                  <arg>-djqvD</arg>
                  <arg>-c <replaceable>class</replaceable></arg>
                  <arg>-o <replaceable>output</replaceable></arg>
                  <arg>-t <replaceable>directory</replaceable></arg>
                  <arg>-w <replaceable>directory</replaceable></arg>
                  <arg>-k <replaceable>(ignore|warn|fail)</replaceable></arg>
                  <arg>-n <replaceable>(ignore|warn|fail)</replaceable></arg>
                  <arg>-W <replaceable>(ignore|warn)</replaceable></arg>
                  <arg choice="plain"><replaceable>zone</replaceable></arg>
                  <arg><replaceable>filename</replaceable></arg>
                </cmdsynopsis>
              </listitem>
            </varlistentry>
            <varlistentry id="rndc" xreflabel="Remote Name Daemon Control application">

              <term><command>rndc</command></term>
              <listitem>
                <para>
                  The remote name daemon control
                  (<command>rndc</command>) program allows the
                  system
                  administrator to control the operation of a name server.
                  If you run <command>rndc</command> without any
                  options
                  it will display a usage message as follows:
                </para>
                <cmdsynopsis label="Usage">
                  <command>rndc</command>
                  <arg>-c <replaceable>config</replaceable></arg>
                  <arg>-s <replaceable>server</replaceable></arg>
                  <arg>-p <replaceable>port</replaceable></arg>
                  <arg>-y <replaceable>key</replaceable></arg>
                  <arg choice="plain"><replaceable>command</replaceable></arg>
                  <arg rep="repeat"><replaceable>command</replaceable></arg>
                </cmdsynopsis>
                <para><command>command</command>
		  is one of the following:
                </para>

                <variablelist>

                  <varlistentry>
                    <term><userinput>reload</userinput></term>
                    <listitem>
                      <para>
                        Reload configuration file and zones.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>reload <replaceable>zone</replaceable>
                        <optional><replaceable>class</replaceable>
1096
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113
                    <listitem>
                      <para>
                        Reload the given zone.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>refresh <replaceable>zone</replaceable>
                        <optional><replaceable>class</replaceable>
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
                    <listitem>
                      <para>
                        Schedule zone maintenance for the given zone.
                      </para>
                    </listitem>
                  </varlistentry>
1114

1115 1116 1117 1118
                  <varlistentry>
                    <term><userinput>retransfer <replaceable>zone</replaceable>

                        <optional><replaceable>class</replaceable>
1119
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
1120 1121 1122 1123 1124 1125 1126 1127
                    <listitem>
                      <para>
                        Retransfer the given zone from the master.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
1128

1129 1130
                    <term><userinput>freeze
                        <optional><replaceable>zone</replaceable>
1131
       <optional><replaceable>class</replaceable>
1132
           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151
                    <listitem>
                      <para>
                        Suspend updates to a dynamic zone.  If no zone is
                        specified
                        then all zones are suspended.  This allows manual
                        edits to be made to a zone normally updated by dynamic
                        update.  It
                        also causes changes in the journal file to be synced
                        into the master
                        and the journal file to be removed.  All dynamic
                        update attempts will
                        be refused while the zone is frozen.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>thaw
                        <optional><replaceable>zone</replaceable>
1152
       <optional><replaceable>class</replaceable>
1153
           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171
                    <listitem>
                      <para>
                        Enable updates to a frozen dynamic zone.  If no zone
                        is
                        specified then all frozen zones are enabled.  This
                        causes
                        the server to reload the zone from disk, and
                        re-enables dynamic updates
                        after the load has completed.  After a zone is thawed,
                        dynamic updates
                        will no longer be refused.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>notify <replaceable>zone</replaceable>
                        <optional><replaceable>class</replaceable>
1172
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458
                    <listitem>
                      <para>
                        Resend NOTIFY messages for the zone
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>reconfig</userinput></term>
                    <listitem>
                      <para>
                        Reload the configuration file and load new zones,
                        but do not reload existing zone files even if they
                        have changed.
                        This is faster than a full <command>reload</command> when there
                        is a large number of zones because it avoids the need
                        to examine the
                        modification times of the zones files.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>stats</userinput></term>
                    <listitem>
                      <para>
                        Write server statistics to the statistics file.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>querylog</userinput></term>
                    <listitem>
                      <para>
                        Toggle query logging. Query logging can also be
                        enabled
                        by explicitly directing the <command>queries</command>
                        <command>category</command> to a <command>channel</command> in the
                        <command>logging</command> section of
                        <filename>named.conf</filename>.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>dumpdb
                        <optional>-all|-cache|-zone</optional>
                        <optional><replaceable>view ...</replaceable></optional></userinput></term>
                    <listitem>
                      <para>
                        Dump the server's caches (default) and / or zones to
                        the
                        dump file for the specified views.  If no view is
                        specified all
                        views are dumped.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>stop <optional>-p</optional></userinput></term>
                    <listitem>
                      <para>
                        Stop the server, making sure any recent changes
                        made through dynamic update or IXFR are first saved to
                        the master files
                        of the updated zones.  If -p is specified named's
                        process id is returned.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>halt <optional>-p</optional></userinput></term>
                    <listitem>
                      <para>
                        Stop the server immediately.  Recent changes
                        made through dynamic update or IXFR are not saved to
                        the master files,
                        but will be rolled forward from the journal files when
                        the server
                        is restarted.  If -p is specified named's process id
                        is returned.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>trace</userinput></term>
                    <listitem>
                      <para>
                        Increment the servers debugging level by one.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>trace <replaceable>level</replaceable></userinput></term>
                    <listitem>
                      <para>
                        Sets the server's debugging level to an explicit
                        value.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>notrace</userinput></term>
                    <listitem>
                      <para>
                        Sets the server's debugging level to 0.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>flush</userinput></term>
                    <listitem>
                      <para>
                        Flushes the server's cache.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>flushname</userinput> <replaceable>name</replaceable></term>
                    <listitem>
                      <para>
                        Flushes the given name from the server's cache.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>flushname</userinput> <replaceable>name</replaceable></term>
                    <listitem>
                      <para>
                        Flushes the given name from the server's cache.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>status</userinput></term>
                    <listitem>
                      <para>
                        Display status of the server.
                        Note the number of zones includes the internal <command>bind/CH</command> zone
                        and the default <command>./IN</command>
                        hint zone if there is not a
                        explicit root zone configured.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>recursing</userinput></term>
                    <listitem>
                      <para>
                        Dump the list of queries named is currently recursing
                        on.
                      </para>
                    </listitem>
                  </varlistentry>

                  <varlistentry>
                    <term><userinput>recursing</userinput></term>
                    <listitem>
                      <para>
                        Dump the list of queries named is currently recursing
                        on.
                      </para>
                    </listitem>
                  </varlistentry>

                </variablelist>

                <para>
                  In <acronym>BIND</acronym> 9.2, <command>rndc</command>
                  supports all the commands of the BIND 8 <command>ndc</command>
                  utility except <command>ndc start</command> and
                  <command>ndc restart</command>, which were also
                  not supported in <command>ndc</command>'s
                  channel mode.
                </para>

                <para>
                  A configuration file is required, since all
                  communication with the server is authenticated with
                  digital signatures that rely on a shared secret, and
                  there is no way to provide that secret other than with a
                  configuration file.  The default location for the
                  <command>rndc</command> configuration file is
                  <filename>/etc/rndc.conf</filename>, but an
                  alternate
                  location can be specified with the <option>-c</option>
                  option.  If the configuration file is not found,
                  <command>rndc</command> will also look in
                  <filename>/etc/rndc.key</filename> (or whatever
                  <varname>sysconfdir</varname> was defined when
                  the <acronym>BIND</acronym> build was
                  configured).
                  The <filename>rndc.key</filename> file is
                  generated by
                  running <command>rndc-confgen -a</command> as
                  described in
                  <xref linkend="controls_statement_definition_and_usage"/>.
                </para>

                <para>
                  The format of the configuration file is similar to
                  that of <filename>named.conf</filename>, but
                  limited to
                  only four statements, the <command>options</command>,
                  <command>key</command>, <command>server</command> and
                  <command>include</command>
                  statements.  These statements are what associate the
                  secret keys to the servers with which they are meant to
                  be shared.  The order of statements is not
                  significant.
                </para>

                <para>
                  The <command>options</command> statement has
                  three clauses:
                  <command>default-server</command>, <command>default-key</command>,
                  and <command>default-port</command>.
                  <command>default-server</command> takes a
                  host name or address argument  and represents the server
                  that will
                  be contacted if no <option>-s</option>
                  option is provided on the command line.
                  <command>default-key</command> takes
                  the name of a key as its argument, as defined by a <command>key</command> statement.
                  <command>default-port</command> specifies the
                  port to which
                  <command>rndc</command> should connect if no
                  port is given on the command line or in a
                  <command>server</command> statement.
                </para>

                <para>
                  The <command>key</command> statement defines an
                  key to be used
                  by <command>rndc</command> when authenticating
                  with
                  <command>named</command>.  Its syntax is
                  identical to the
                  <command>key</command> statement in named.conf.
                  The keyword <userinput>key</userinput> is
                  followed by a key name, which must be a valid
                  domain name, though it need not actually be hierarchical;
                  thus,
                  a string like "<userinput>rndc_key</userinput>" is a valid
                  name.
                  The <command>key</command> statement has two
                  clauses:
                  <command>algorithm</command> and <command>secret</command>.
                  While the configuration parser will accept any string as the
                  argument
                  to algorithm, currently only the string "<userinput>hmac-md5</userinput>"
                  has any meaning.  The secret is a base-64 encoded string.
                </para>

                <para>
                  The <command>server</command> statement
                  associates a key
                  defined using the <command>key</command>
                  statement with a server.
                  The keyword <userinput>server</userinput> is followed by a
                  host name or address.  The <command>server</command> statement
                  has two clauses: <command>key</command> and <command>port</command>.
                  The <command>key</command> clause specifies the
                  name of the key
                  to be used when communicating with this server, and the
                  <command>port</command> clause can be used to
                  specify the port <command>rndc</command> should
                  connect
                  to on the server.
                </para>

                <para>
                  A sample minimal configuration file is as follows:
                </para>

1459
<programlisting>
1460 1461 1462 1463 1464
key rndc_key {
     algorithm "hmac-md5";
     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
options {
1465
     default-server 127.0.0.1;
1466 1467 1468
     default-key    rndc_key;
};
</programlisting>
1469

1470 1471 1472 1473
                <para>
                  This file, if installed as <filename>/etc/rndc.conf</filename>,
                  would allow the command:
                </para>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1474

1475 1476 1477 1478 1479 1480 1481 1482 1483 1484
                <para>
                  <prompt>$ </prompt><userinput>rndc reload</userinput>
                </para>

                <para>
                  to connect to 127.0.0.1 port 953 and cause the name server
                  to reload, if a name server on the local machine were
                  running with
                  following controls statements:
                </para>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1485 1486

<programlisting>
1487
controls {
1488
        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
1489 1490 1491
};
</programlisting>

1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567
                <para>
                  and it had an identical key statement for
                  <literal>rndc_key</literal>.
                </para>

                <para>
                  Running the <command>rndc-confgen</command>
                  program will
                  conveniently create a <filename>rndc.conf</filename>
                  file for you, and also display the
                  corresponding <command>controls</command>
                  statement that you need to
                  add to <filename>named.conf</filename>.
                  Alternatively,
                  you can run <command>rndc-confgen -a</command>
                  to set up
                  a <filename>rndc.key</filename> file and not
                  modify
                  <filename>named.conf</filename> at all.
                </para>

              </listitem>
            </varlistentry>
          </variablelist>

        </sect3>
      </sect2>
      <sect2>

        <title>Signals</title>
        <para>
          Certain UNIX signals cause the name server to take specific
          actions, as described in the following table.  These signals can
          be sent using the <command>kill</command> command.
        </para>
        <informaltable frame="all">
          <tgroup cols="2">
            <colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
            <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
            <tbody>
              <row rowsep="0">
                <entry colname="1">
                  <para><command>SIGHUP</command></para>
                </entry>
                <entry colname="2">
                  <para>
                    Causes the server to read <filename>named.conf</filename> and
                    reload the database.
                  </para>
                </entry>
              </row>
              <row rowsep="0">
                <entry colname="1">
                  <para><command>SIGTERM</command></para>
                </entry>
                <entry colname="2">
                  <para>
                    Causes the server to clean up and exit.
                  </para>
                </entry>
              </row>
              <row rowsep="0">
                <entry colname="1">
                  <para><command>SIGINT</command></para>
                </entry>
                <entry colname="2">
                  <para>
                    Causes the server to clean up and exit.
                  </para>
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>
      </sect2>
    </sect1>
1568 1569
  </chapter>

1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870
  <chapter id="Bv9ARM.ch04">
    <title>Advanced DNS Features</title>

    <sect1 id="notify">

      <title>Notify</title>
      <para>
        <acronym>DNS</acronym> NOTIFY is a mechanism that allows
        master
        servers to notify their slave servers of changes to a zone's data. In
        response to a <command>NOTIFY</command> from a master
        server, the
        slave will check to see that its version of the zone is the
        current version and, if not, initiate a zone transfer.
      </para>

      <para>
        <acronym>DNS</acronym>
        For more information about
        <command>NOTIFY</command>, see the description of the
        <command>notify</command> option in <xref linkend="boolean_options"/> and
        the description of the zone option <command>also-notify</command> in
        <xref linkend="zone_transfers"/>.  The <command>NOTIFY</command>
        protocol is specified in RFC 1996.
      </para>

    </sect1>

    <sect1 id="dynamic_update">
      <title>Dynamic Update</title>

      <para>
        Dynamic Update is a method for adding, replacing or deleting
        records in a master server by sending it a special form of DNS
        messages.  The format and meaning of these messages is specified
        in RFC 2136.
      </para>

      <para>
        Dynamic update is enabled by
        including an <command>allow-update</command> or
        <command>update-policy</command> clause in the
        <command>zone</command> statement.
      </para>

      <para>
        Updating of secure zones (zones using DNSSEC) follows
        RFC 3007: RRSIG and NSEC records affected by updates are automatically
            regenerated by the server using an online zone key.
        Update authorization is based
        on transaction signatures and an explicit server policy.
      </para>

      <sect2 id="journal">
        <title>The journal file</title>

        <para>
          All changes made to a zone using dynamic update are stored
          in the zone's journal file.  This file is automatically created
          by the server when the first dynamic update takes place.
          The name of the journal file is formed by appending the extension
          <filename>.jnl</filename> to the name of the
          corresponding zone
          file unless specifically overridden.  The journal file is in a
          binary format and should not be edited manually.
        </para>

        <para>
          The server will also occasionally write ("dump")
          the complete contents of the updated zone to its zone file.
          This is not done immediately after
          each dynamic update, because that would be too slow when a large
          zone is updated frequently.  Instead, the dump is delayed by
          up to 15 minutes, allowing additional updates to take place.
        </para>

        <para>
          When a server is restarted after a shutdown or crash, it will replay
              the journal file to incorporate into the zone any updates that
          took
          place after the last zone dump.
        </para>

        <para>
          Changes that result from incoming incremental zone transfers are
          also
          journalled in a similar way.
        </para>

        <para>
          The zone files of dynamic zones cannot normally be edited by
          hand because they are not guaranteed to contain the most recent
          dynamic changes - those are only in the journal file.
          The only way to ensure that the zone file of a dynamic zone
          is up to date is to run <command>rndc stop</command>.
        </para>

        <para>
          If you have to make changes to a dynamic zone
          manually, the following procedure will work: Disable dynamic updates
              to the zone using
          <command>rndc freeze <replaceable>zone</replaceable></command>.
          This will also remove the zone's <filename>.jnl</filename> file
          and update the master file.  Edit the zone file.  Run
          <command>rndc unfreeze <replaceable>zone</replaceable></command>
          to reload the changed zone and re-enable dynamic updates.
        </para>

      </sect2>

    </sect1>

    <sect1 id="incremental_zone_transfers">
      <title>Incremental Zone Transfers (IXFR)</title>

      <para>
        The incremental zone transfer (IXFR) protocol is a way for
        slave servers to transfer only changed data, instead of having to
        transfer the entire zone. The IXFR protocol is specified in RFC
        1995. See <xref linkend="proposed_standards"/>.
      </para>

      <para>
        When acting as a master, <acronym>BIND</acronym> 9
        supports IXFR for those zones
        where the necessary change history information is available. These
        include master zones maintained by dynamic update and slave zones
        whose data was obtained by IXFR.  For manually maintained master
        zones, and for slave zones obtained by performing a full zone
        transfer (AXFR), IXFR is supported only if the option
        <command>ixfr-from-differences</command> is set
        to <userinput>yes</userinput>.
      </para>

      <para>
        When acting as a slave, <acronym>BIND</acronym> 9 will
        attempt to use IXFR unless
        it is explicitly disabled. For more information about disabling
        IXFR, see the description of the <command>request-ixfr</command> clause
        of the <command>server</command> statement.
      </para>
    </sect1>

    <sect1>
      <title>Split DNS</title>
      <para>
        Setting up different views, or visibility, of the DNS space to
        internal and external resolvers is usually referred to as a <emphasis>Split DNS</emphasis> setup. There are several reasons an organization
        would want to set up its DNS this way.
      </para>
      <para>
        One common reason for setting up a DNS system this way is
        to hide "internal" DNS information from "external" clients on the
        Internet. There is some debate as to whether or not this is actually
        useful.
        Internal DNS information leaks out in many ways (via email headers,
        for example) and most savvy "attackers" can find the information
        they need using other means.
      </para>
      <para>
        Another common reason for setting up a Split DNS system is
        to allow internal networks that are behind filters or in RFC 1918
        space (reserved IP space, as documented in RFC 1918) to resolve DNS
        on the Internet. Split DNS can also be used to allow mail from outside
        back in to the internal network.
      </para>
      <para>
        Here is an example of a split DNS setup:
      </para>
      <para>
        Let's say a company named <emphasis>Example, Inc.</emphasis>
        (<literal>example.com</literal>)
        has several corporate sites that have an internal network with
        reserved
        Internet Protocol (IP) space and an external demilitarized zone (DMZ),
        or "outside" section of a network, that is available to the public.
      </para>
      <para>
        <emphasis>Example, Inc.</emphasis> wants its internal clients
        to be able to resolve external hostnames and to exchange mail with
        people on the outside. The company also wants its internal resolvers
        to have access to certain internal-only zones that are not available
        at all outside of the internal network.
      </para>
      <para>
        In order to accomplish this, the company will set up two sets
        of name servers. One set will be on the inside network (in the
        reserved
        IP space) and the other set will be on bastion hosts, which are
        "proxy"
        hosts that can talk to both sides of its network, in the DMZ.
      </para>
      <para>
        The internal servers will be configured to forward all queries,
        except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>,
        and <filename>site2.example.com</filename>, to the servers
        in the
        DMZ. These internal servers will have complete sets of information
        for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>,<emphasis/> <filename>site1.internal</filename>,
        and <filename>site2.internal</filename>.
      </para>
      <para>
        To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
        the internal name servers must be configured to disallow all queries
        to these domains from any external hosts, including the bastion
        hosts.
      </para>
      <para>
        The external servers, which are on the bastion hosts, will
        be configured to serve the "public" version of the <filename>site1</filename> and <filename>site2.example.com</filename> zones.
        This could include things such as the host records for public servers
        (<filename>www.example.com</filename> and <filename>ftp.example.com</filename>),
        and mail exchange (MX)  records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).
      </para>
      <para>
        In addition, the public <filename>site1</filename> and <filename>site2.example.com</filename> zones
        should have special MX records that contain wildcard (`*') records
        pointing to the bastion hosts. This is needed because external mail
        servers do not have any other way of looking up how to deliver mail
        to those internal hosts. With the wildcard records, the mail will
        be delivered to the bastion host, which can then forward it on to
        internal hosts.
      </para>
      <para>
        Here's an example of a wildcard MX record:
      </para>
      <programlisting>*   IN MX 10 external1.example.com.</programlisting>
      <para>
        Now that they accept mail on behalf of anything in the internal
        network, the bastion hosts will need to know how to deliver mail
        to internal hosts. In order for this to work properly, the resolvers
        on
        the bastion hosts will need to be configured to point to the internal
        name servers for DNS resolution.
      </para>
      <para>
        Queries for internal hostnames will be answered by the internal
        servers, and queries for external hostnames will be forwarded back
        out to the DNS servers on the bastion hosts.
      </para>
      <para>
        In order for all this to work properly, internal clients will
        need to be configured to query <emphasis>only</emphasis> the internal
        name servers for DNS queries. This could also be enforced via
        selective
        filtering on the network.
      </para>
      <para>
        If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s
        internal clients will now be able to:
      </para>
      <itemizedlist>
        <listitem>
          <simpara>
            Look up any hostnames in the <literal>site1</literal>
            and
            <literal>site2.example.com</literal> zones.
          </simpara>
        </listitem>
        <listitem>
          <simpara>
            Look up any hostnames in the <literal>site1.internal</literal> and
            <literal>site2.internal</literal> domains.
          </simpara>
        </listitem>
        <listitem>
          <simpara>Look up any hostnames on the Internet.</simpara>
        </listitem>
        <listitem>
          <simpara>Exchange mail with internal AND external people.</simpara>
        </listitem>
      </itemizedlist>
      <para>
        Hosts on the Internet will be able to:
      </para>
      <itemizedlist>
        <listitem>
          <simpara>
            Look up any hostnames in the <literal>site1</literal>
            and
            <literal>site2.example.com</literal> zones.
          </simpara>
        </listitem>
        <listitem>
          <simpara>
            Exchange mail with anyone in the <literal>site1</literal> and
            <literal>site2.example.com</literal> zones.
          </simpara>
        </listitem>
      </itemizedlist>

      <para>
        Here is an example configuration for the setup we just
        described above. Note that this is only configuration information;
        for information on how to configure your zone files, see <xref linkend="sample_configuration"/>
      </para>

      <para>
        Internal DNS server config:
      </para>

1871
<programlisting>
1872 1873 1874

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

1875
acl externals { <varname>bastion-ips-go-here</varname>; };
1876

1877 1878 1879 1880
options {
    ...
    ...
    forward only;
1881 1882
    forwarders {                                // forward to external servers
        <varname>bastion-ips-go-here</varname>; 
1883
    };
1884 1885 1886
    allow-transfer { none; };                   // sample allow-transfer (no one)
    allow-query { internals; externals; };      // restrict query access
    allow-recursion { internals; };             // restrict recursion
1887 1888 1889
    ...
    ...
};
1890

1891
zone "site1.example.com" {                      // sample master zone
1892 1893
  type master;
  file "m/site1.example.com";
1894 1895
  forwarders { };                               // do normal iterative
                                                // resolution (do not forward)
1896 1897 1898
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
1899

1900
zone "site2.example.com" {                      // sample slave zone
1901 1902 1903 1904 1905 1906 1907
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
1908

1909 1910 1911 1912 1913 1914 1915
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};
1916

1917 1918 1919 1920 1921 1922 1923 1924 1925
zone "site2.internal" {
  type slave;
  file "s/site2.internal";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals };
  allow-transfer { internals; }
};
</programlisting>
1926 1927 1928 1929 1930

      <para>
        External (bastion host) DNS server config:
      </para>

1931
<programlisting>
1932 1933
acl internals { 172.16.72.0/24; 192.168.1.0/24; };

1934
acl externals { bastion-ips-go-here; };
1935

1936 1937 1938
options {
  ...
  ...
1939
  allow-transfer { none; };                     // sample allow-transfer (no one)
1940 1941
  allow-query { any; };  			// default query access
  allow-query-cache { internals; externals; };  // restrict cache access
1942
  allow-recursion { internals; externals; };    // restrict recursion
1943 1944 1945
  ...
  ...
};
1946

1947
zone "site1.example.com" {                      // sample slave zone
1948 1949 1950 1951
  type master;
  file "m/site1.foo.com";
  allow-transfer { internals; externals; };
};
1952

1953 1954 1955 1956 1957 1958 1959
zone "site2.example.com" {
  type slave;
  file "s/site2.foo.com";
  masters { another_bastion_host_maybe; };
  allow-transfer { internals; externals; }
};
</programlisting>
1960 1961 1962 1963 1964 1965

      <para>
        In the <filename>resolv.conf</filename> (or equivalent) on
        the bastion host(s):
      </para>

1966 1967 1968 1969 1970 1971
<programlisting>
search ...
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4
</programlisting>
1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060

    </sect1>
    <sect1 id="tsig">
      <title>TSIG</title>
      <para>
        This is a short guide to setting up Transaction SIGnatures
        (TSIG) based transaction security in <acronym>BIND</acronym>. It describes changes
        to the configuration file as well as what changes are required for
        different features, including the process of creating transaction
        keys and using transaction signatures with <acronym>BIND</acronym>.
      </para>
      <para>
        <acronym>BIND</acronym> primarily supports TSIG for server
        to server communication.
        This includes zone transfer, notify, and recursive query messages.
        Resolvers based on newer versions of <acronym>BIND</acronym> 8 have limited support
        for TSIG.
      </para>

      <para>
        TSIG might be most useful for dynamic update. A primary
        server for a dynamic zone should use access control to control
        updates, but IP-based access control is insufficient.
        The cryptographic access control provided by TSIG
        is far superior. The <command>nsupdate</command>
        program supports TSIG via the <option>-k</option> and
        <option>-y</option> command line options.
      </para>

      <sect2>
        <title>Generate Shared Keys for Each Pair of Hosts</title>
        <para>
          A shared secret is generated to be shared between <emphasis>host1</emphasis> and <emphasis>host2</emphasis>.
          An arbitrary key name is chosen: "host1-host2.". The key name must
          be the same on both hosts.
        </para>
        <sect3>
          <title>Automatic Generation</title>
          <para>
            The following command will generate a 128 bit (16 byte) HMAC-MD5
            key as described above. Longer keys are better, but shorter keys
            are easier to read. Note that the maximum key length is 512 bits;
            keys longer than that will be digested with MD5 to produce a 128
            bit key.
          </para>
          <para>
            <userinput>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</userinput>
          </para>
          <para>
            The key is in the file <filename>Khost1-host2.+157+00000.private</filename>.
            Nothing directly uses this file, but the base-64 encoded string
            following "<literal>Key:</literal>"
            can be extracted from the file and used as a shared secret:
          </para>
          <programlisting>Key: La/E5CjG9O+os1jq0a2jdA==</programlisting>
          <para>
            The string "<literal>La/E5CjG9O+os1jq0a2jdA==</literal>" can
            be used as the shared secret.
          </para>
        </sect3>
        <sect3>
          <title>Manual Generation</title>
          <para>
            The shared secret is simply a random sequence of bits, encoded
            in base-64. Most ASCII strings are valid base-64 strings (assuming
            the length is a multiple of 4 and only valid characters are used),
            so the shared secret can be manually generated.
          </para>
          <para>
            Also, a known string can be run through <command>mmencode</command> or
            a similar program to generate base-64 encoded data.
          </para>
        </sect3>
      </sect2>
      <sect2>
        <title>Copying the Shared Secret to Both Machines</title>
        <para>
          This is beyond the scope of DNS. A secure transport mechanism
          should be used. This could be secure FTP, ssh, telephone, etc.
        </para>
      </sect2>
      <sect2>
        <title>Informing the Servers of the Key's Existence</title>
        <para>
          Imagine <emphasis>host1</emphasis> and <emphasis>host 2</emphasis>
          are
          both servers. The following is added to each server's <filename>named.conf</filename> file:
        </para>

2061 2062 2063 2064 2065 2066
<programlisting>
key host1-host2. {
  algorithm hmac-md5;
  secret "La/E5CjG9O+os1jq0a2jdA==";
};
</programlisting>
2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092

        <para>
          The algorithm, hmac-md5, is the only one supported by <acronym>BIND</acronym>.
          The secret is the one generated above. Since this is a secret, it
          is recommended that either <filename>named.conf</filename> be non-world
          readable, or the key directive be added to a non-world readable
          file that is included by
          <filename>named.conf</filename>.
        </para>
        <para>
          At this point, the key is recognized. This means that if the
          server receives a message signed by this key, it can verify the
          signature. If the signature is successfully verified, the
          response is signed by the same key.
        </para>
      </sect2>

      <sect2>
        <title>Instructing the Server to Use the Key</title>
        <para>
          Since keys are shared between two hosts only, the server must
          be told when keys are to be used. The following is added to the <filename>named.conf</filename> file
          for <emphasis>host1</emphasis>, if the IP address of <emphasis>host2</emphasis> is
          10.1.2.3:
        </para>

2093 2094 2095 2096 2097
<programlisting>
server 10.1.2.3 {
  keys { host1-host2. ;};
};
</programlisting>
2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131

        <para>
          Multiple keys may be present, but only the first is used.
          This directive does not contain any secrets, so it may be in a
          world-readable
          file.
        </para>
        <para>
          If <emphasis>host1</emphasis> sends a message that is a request
          to that address, the message will be signed with the specified key. <emphasis>host1</emphasis> will
          expect any responses to signed messages to be signed with the same
          key.
        </para>
        <para>
          A similar statement must be present in <emphasis>host2</emphasis>'s
          configuration file (with <emphasis>host1</emphasis>'s address) for <emphasis>host2</emphasis> to
          sign request messages to <emphasis>host1</emphasis>.
        </para>
      </sect2>
      <sect2>
        <title>TSIG Key Based Access Control</title>
        <para>
          <acronym>BIND</acronym> allows IP addresses and ranges
          to be specified in ACL
          definitions and
          <command>allow-{ query | transfer | update }</command>
          directives.
          This has been extended to allow TSIG keys also. The above key would
          be denoted <command>key host1-host2.</command>
        </para>
        <para>
          An example of an allow-update directive would be:
        </para>

2132 2133 2134 2135
<programlisting>
allow-update { key host1-host2. ;};
</programlisting>

2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420