Bv9ARM-book.xml 286 KB
Newer Older
1

2
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
3
               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd">
4

Brian Wellington's avatar
Brian Wellington committed
5
<!-- File: $Id: Bv9ARM-book.xml,v 1.151 2001/07/26 22:46:44 bwelling Exp $ -->
6

7
<book>
8 9 10 11 12 13 14 15 16
<title>BIND 9 Administrator Reference Manual</title>

<bookinfo>
<copyright>
<year>2000</year>
<year>2001</year>
<holder>Internet Software Consortium</holder>
</copyright>
</bookinfo>
17

18
  <chapter id="ch01">
19 20 21 22 23 24 25 26 27 28 29 30
  <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
31
    domain name server for a number of operating systems. This
32
    document provides basic information about the installation and
33 34 35 36
    care of the Internet Software Consortium (<acronym>ISC</acronym>)
    <acronym>BIND</acronym> version 9 software package for system
    administrators.</para>

Andreas Gustafsson's avatar
Andreas Gustafsson committed
37
    <para>This version of the manual corresponds to BIND version 9.2.</para>
38
    
39 40 41 42 43 44 45 46 47 48 49
  </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
50 51
    certain options. <emphasis>Section 5</emphasis>
    describes the <acronym>BIND</acronym> 9 lightweight
52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
    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>

68 69 70 71
<informaltable>
        <tgroup cols = "2">
          <colspec colname = "1" colnum = "1" colwidth = "3.000in"/>
          <colspec colname = "2" colnum = "2" colwidth = "2.625in"/>
72
          <tbody>
73 74
            <row>
              <entry colname = "1">
75 76
<para><emphasis>To
describe:</emphasis></para></entry>
77
              <entry colname = "2">
78 79
<para><emphasis>We use the style:</emphasis></para></entry>
            </row>
80 81
            <row>
              <entry colname = "1">
82 83
<para>a pathname, filename, URL, hostname,
mailing list name, or new term or concept</para></entry>
84
              <entry colname = "2"><para><filename>Fixed width</filename></para></entry>
85
            </row>
86 87
            <row>
              <entry colname = "1"><para>literal user
88
input</para></entry>
89
              <entry colname = "2"><para><userinput>Fixed Width Bold</userinput></para></entry>
90
            </row>
91 92
            <row>
              <entry colname = "1"><para>program output</para></entry>
93
              <entry colname = "2"><para><computeroutput>Fixed Width</computeroutput></para></entry>
94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112
            </row>
          </tbody>
        </tgroup>
</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>
113
              <entry colname = "2" rowsep = "1"><para><literal>Fixed Width</literal></para></entry>
114 115 116
            </row>
            <row rowsep = "0">
              <entry colname = "1" colsep = "1" rowsep = "1"><para>variables</para></entry>
117
              <entry colname = "2" rowsep = "1"><para><varname>Fixed Width</varname></para></entry>
118 119 120 121 122 123 124
            </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>
125
<sect1><title>The Domain Name System (<acronym>DNS</acronym>)</title>
126
<para>The purpose of this document is to explain the installation
127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167
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 9</acronym> software distribution contains both a 
name server and a resolver library.</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.net</literal>,
were <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
168
name of the host.</para>
169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192

<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>

193
<para>As we stated previously, a zone is a point of delegation in
194 195 196
the <acronym>DNS</acronym> tree. A zone consists of
those contiguous parts of the domain
tree for which a a name server has complete information and over which
197 198
it has authority. It contains all domain names from a certain point
downward in the domain tree except those which are delegated to
199 200
other zones. A delegation point is marked by one or more
<emphasis>NS records</emphasis> in the
201 202
parent zone, which should be matched by equivalent NS records at
the root of the delegated zone.</para>
203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226

<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
227
actually asking for slave service for some collection of zones.</para>
228 229 230 231 232 233 234 235 236 237 238
</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>

239
<para>Responses from authoritative servers have the "authoritative
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
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
273
records that are not in the parent's NS delegation, but you cannot
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
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,
326
and they are queried in turn until the list is exhausted or an answer
327 328
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
329 330 331 332 333 334
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
335
cache of information that all the clients can take advantage
336
of.</para>
337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360
</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>

361 362
    </sect2>
  </sect1>
363 364

</chapter>
365

366 367 368 369 370
<chapter id="ch02"><title><acronym>BIND</acronym> Resource Requirements</title>

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

371 372 373 374 375 376 377 378 379 380 381 382 383
<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 now 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>
384 385

<sect1><title>Memory Requirements</title>
386
<para>The memory of the server has to be large enough to fit the
387 388
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,
389 390 391 392 393 394 395 396
at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
traffic. 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 nameserver
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. Ideally, the resource limits should
be set higher than this stable size.</para></sect1>
397

398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418
<sect1><title>Nameserver Intensive Environment Issues</title>
<para>For nameserver intensive environments, there are two alternative
configurations that may be used. The first is where clients and
any second-level internal nameservers query a main nameserver, 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 nameservers 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 nameservers share their cached data.</para></sect1>
<sect1><title>Supported Operating Systems</title>
<para>ISC <acronym>BIND</acronym> 9 compiles and runs on the following operating
systems:</para>
    <itemizedlist>
      <listitem>
        <simpara>IBM AIX 4.3</simpara>
      </listitem>
      <listitem>
        <simpara>Compaq Digital/Tru64 UNIX 4.0D</simpara>
      </listitem>
419 420 421
      <listitem>
        <simpara>Compaq Digital/Tru64 UNIX 5 (with IPv6 EAK)</simpara>
      </listitem>
422 423 424 425 426 427 428
      <listitem>
        <simpara>HP HP-UX 11</simpara>
      </listitem>
      <listitem>
        <simpara>IRIX64 6.5</simpara>
      </listitem>
      <listitem>
429
        <simpara>Sun Solaris 2.6, 7, 8</simpara>
430 431
      </listitem>
      <listitem>
432
        <simpara>NetBSD 1.5 (with unproven-pthreads 0.17)</simpara>
433 434
      </listitem>
      <listitem>
435
        <simpara>FreeBSD 3.4-STABLE, 3.5, 4.0, 4.1</simpara>
436 437
      </listitem>
      <listitem>
438
        <simpara>Red Hat Linux 6.0, 6.1, 6.2, 7.0</simpara>
439 440 441 442 443
      </listitem>
    </itemizedlist>
  </sect1>
  </chapter>

444
  <chapter id="ch03">
445 446 447 448 449 450 451 452 453 454 455 456 457 458 459
  <title>Nameserver 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 Nameserver</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.</para>
      <programlisting>
// Two corporate subnets we wish to allow queries from.
acl "corpnets" { 192.168.4.0/24; 192.168.7.0/24; };
options {
460 461
     directory "/etc/namedb";           // Working directory
     pid-file "named.pid";              // Put pid file in working dir
462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480
     allow-query { "corpnets"; };
};
// Root server hints
zone "." { type hint; file "root.hint"; };
// 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>
    </sect2>
    <sect2>
      <title>An Authoritative-only Nameserver</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>
      <programlisting>
options {
481 482 483 484
     directory "/etc/namedb";           // Working directory
     pid-file "named.pid";              // Put pid file in working dir
     allow-query { any; };              // This is the default
     recursion no;                      // Do not provide recursive service
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
};
// Root server hints
zone "." { type hint; file "root.hint"; };

// 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>
    </sect2>
  </sect1>
  <sect1>
    <title>Load Balancing</title>
    <para>Primitive load balancing can be achieved in <acronym>DNS</acronym> 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></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></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
Andreas Gustafsson's avatar
Andreas Gustafsson committed
570 571 572
    <command>options</command> statement, see
    <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
    This substatement is not supported in
573 574 575 576 577 578 579 580 581 582 583 584 585
    <acronym>BIND</acronym> 9, and only the ordering scheme described above is
    available.</para>

  </sect1>
  <sect1 id="notify">
    <title>Notify</title>

    <para><acronym>DNS</acronym> Notify is a mechanism that allows master nameservers 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 transfer.</para> <para><acronym>DNS</acronym>
    Notify is fully documented in RFC 1996. See also the description
586 587
    of the zone option <command>also-notify</command>, see
    <xref linkend="zone_transfers"/>. For more information about
588
    <command>notify</command>, see <xref
589 590 591 592 593 594 595 596 597 598 599
    linkend="boolean_options"/>.</para>

  </sect1>
  <sect1>
    <title>Nameserver Operations</title>
    <sect2>
      <title>Tools for Use With the Nameserver Daemon</title>
      <para>There are several indispensable diagnostic, administrative
and monitoring tools available to the system administrator for controlling
and debugging the nameserver daemon. We describe several in this
section </para>
600
      <sect3 id="diagnostic_tools">
601 602 603
        <title>Diagnostic Tools</title>
        <variablelist>
          <varlistentry>
604
            <term id="dig"><command>dig</command></term>
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 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681
            <listitem>
              <para>The domain information groper (<command>dig</command>) is
a command line tool that can be used to gather information from
the Domain Name System servers. Dig 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>
                <!-- one of (SBR GROUP ARG COMMAND) -->
              </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
provides a simple <acronym>DNS</acronym> lookup using a command-line interface for
looking up Internet hostnames. By default, the utility converts
between host names and Internet addresses, but its functionality
can be extended with the use of options.</para>
              <cmdsynopsis label="Usage">
                <!-- one of (SBR GROUP ARG COMMAND) -->
                <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> is a program used to query Internet
domain nameservers. <command>nslookup</command> has two modes: interactive
and non-interactive. Interactive mode allows the user to query nameservers
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 nameserver will be used) or when the first argument is a
hyphen (`-') and the second argument is the host name or Internet address
of a nameserver.</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 nameserver.</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>
682 683 684 685 686 687 688
        </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>
689
          <varlistentry id="named-checkconf" xreflabel="Named Configuration Checking application">
690
            <term><command>named-checkconf</command></term>
Mark Andrews's avatar
Mark Andrews committed
691
            <listitem>
692 693
              <para>The <command>named-checkconf</command> program
              checks the syntax of a <filename>named.conf</filename> file.</para>
Mark Andrews's avatar
Mark Andrews committed
694
              <cmdsynopsis label="Usage">
695
                <command>named-checkconf</command>
696
                <arg>-t <replaceable>directory</replaceable></arg>
Mark Andrews's avatar
Mark Andrews committed
697 698 699
                <arg><replaceable>filename</replaceable></arg>
              </cmdsynopsis>
            </listitem>
700 701
          </varlistentry>
          <varlistentry id="named-checkzone" xreflabel="Zone Checking application">
702
            <term><command>named-checkzone</command></term>
Mark Andrews's avatar
Mark Andrews committed
703
            <listitem>
704 705
              <para>The <command>named-checkzone</command> program checks a master file for
              syntax and consistency.</para>
Mark Andrews's avatar
Mark Andrews committed
706
              <cmdsynopsis label="Usage">
707
                <command>check-zone</command>
Mark Andrews's avatar
Mark Andrews committed
708 709 710 711 712 713
                <arg>-dq</arg>
                <arg>-c <replaceable>class</replaceable></arg>
                <arg choice="plain"><replaceable>zone</replaceable></arg>
                <arg><replaceable>filename</replaceable></arg>
              </cmdsynopsis>
            </listitem>
714
          </varlistentry>
715 716
          <varlistentry id="rndc" xreflabel="Remote Name Daemon Control application">
            <term><command>rndc</command></term>
717 718 719 720 721 722 723 724 725 726 727 728 729 730 731
            <listitem>
              <para>The remote name daemon control
              (<command>rndc</command>) program allows the system
              administrator to control the operation of a nameserver.
              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>
732 733
              <para><command>command</command> is one of the following:</para>

734
<variablelist>
735

736
   <varlistentry><term><userinput>reload</userinput></term>
737 738
   <listitem><para>Reload configuration file and zones.</para></listitem>
   </varlistentry>
739

740 741
   <varlistentry><term><userinput>reload <replaceable>zone</replaceable>
       <optional><replaceable>class</replaceable>
742
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
743 744
   <listitem><para>Reload the given zone.</para></listitem>
   </varlistentry>
745

746 747 748
   <varlistentry><term><userinput>refresh <replaceable>zone</replaceable>
       <optional><replaceable>class</replaceable>
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
749 750 751 752 753 754 755 756 757 758 759
   <listitem><para>Schedule zone maintenance for the given 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>
760

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

765 766
   <varlistentry><term><userinput>querylog</userinput></term>
   <listitem><para>Toggle query logging.</para></listitem></varlistentry>
767

768 769
   <varlistentry><term><userinput>dumpdb</userinput></term>
   <listitem><para>Dump the server's caches to the dump file. </para></listitem></varlistentry>
770

771 772 773 774 775
   <varlistentry><term><userinput>stop</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.</para></listitem></varlistentry>
776

777 778 779 780 781
   <varlistentry><term><userinput>halt</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.</para></listitem></varlistentry>
782

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

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

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

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

796 797 798
   <varlistentry><term><userinput>status</userinput></term>
   <listitem><para>Display status of the server.</para></listitem></varlistentry>

799
</variablelist>
800

801
              <para>In <acronym>BIND</acronym> 9.2, <command>rndc</command>
802 803 804
              supports all the commands of the BIND 8 <command>ndc</command>
              utility except <command>ndc start</command>, which was also
              not supported in <command>ndc</command>'s channel mode.</para>
805 806 807 808 809 810 811 812 813

              <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>
814 815 816 817
              option.  If the configuration file is not found,
              <command>rndc</command> will also look in
              <filename>/var/run/named.key</filename> (or wherever
              <varname>localstatedir</varname> was defined when
Brian Wellington's avatar
typos  
Brian Wellington committed
818
              the <acronym>BIND</acronym> build was configured).
819 820
              The <filename>named.key</filename> file is generated by
              <command>named</command> as described in
Brian Wellington's avatar
typos  
Brian Wellington committed
821
              <xref linkend="controls_statement_definition_and_usage"/>.</para>
822 823 824

              <para>The format of the configuration file is similar to
              that of <filename>named.conf</filename>, but limited to
825 826 827
              only four statements, the <command>options</command>,
              <command>key</command>, <command>server</command> and
              <command>include</command>
828 829 830 831 832
              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>

833 834 835 836
<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
837 838
host name or address argument  and represents the server that will
be contacted if no <option>-s</option>
839 840
option is provided on the command line.  
<command>default-key</command> takes
841
the name of key as its argument, as defined by a <command>key</command> statement.
842 843 844 845 846
<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>

847
<para>The <command>key</command> statement names a key with its
848 849 850
string argument. The string is required by the server to be a valid
domain name, though it need not actually be hierarchical; thus,
a string like "<userinput>rndc_key</userinput>" is a valid name.
851 852 853
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
854 855 856
to algorithm, currently only the string "<userinput>hmac-md5</userinput>"
has any meaning.  The secret is a base-64 encoded string, typically
generated with either <command>dnssec-keygen</command> or <command>mmencode</command>.</para>
857

858 859
<para>The <command>server</command> statement uses the key clause
to associate a <command>key</command>-defined key with a server.
860
The argument to the <command>server</command> statement is a
861
host name or address (addresses must be double quoted).  The argument
862
to the key clause is the name of the key as defined by the <command>key</command> statement.
863 864
The <command>port</command> clause can be used to 
specify the port to which <command>rndc</command> should connect
865
on the given server.</para>
866

867
<para>A sample minimal configuration file is as follows:</para>
868
<programlisting>
869 870 871 872 873 874 875 876 877
key rndc_key {
     algorithm "hmac-md5";
     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
options {
     default-server localhost;
     default-key    rndc_key;
};
</programlisting>
878

879 880 881 882 883 884 885 886
<para>This file, if installed as <filename>/etc/rndc.conf</filename>,
would allow the command:</para>
              <para><prompt>$ </prompt><userinput>rndc reload</userinput></para>
<para>to connect to 127.0.0.1 port 953 and cause the nameserver
to reload, if a nameserver on the local machine were running with
following controls statements:</para>
              <programlisting>
controls {
887
                inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
888 889 890 891 892 893 894 895 896 897 898 899 900 901 902
};
</programlisting>
<para>and it had an identical key statement for
<literal>rndc_key</literal>.</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>
903
<informaltable frame = "all" ><tgroup cols = "2">
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
<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>
  </chapter>

929
  <chapter id="ch04">
930
  <title>Advanced Concepts</title>
931 932

<sect1 id="dynamic_update">
933 934 935 936 937 938 939 940 941 942 943 944
    <title>Dynamic Update</title>

    <para>Dynamic update is the term used for the ability under
    certain specified conditions to add, modify or delete records or
    RRsets in the master zone files. Dynamic update is fully described
    in RFC 2136.</para>

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

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

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
    <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 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.  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 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>
981 982 983 984 985

    <para>If you have to make changes to a dynamic zone
    manually, the following procedure will work: Shut down
    the server using <command>rndc stop</command> (sending a signal
    or using <command>rndc halt</command> is <emphasis>not</emphasis>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
986 987
    sufficient). Wait for the server to exit,
    then <emphasis>remove</emphasis> the zone's 
988 989
    <filename>.jnl</filename> file, edit the zone file,
    and restart the server.  Removing the <filename>.jnl</filename>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
990
    file is necessary because the manual edits will not be
991 992 993
    present in the journal, rendering it inconsistent with the
    contents of the zone file.</para>

994 995 996 997
  </sect2>
    
</sect1>
    
998 999 1000 1001 1002 1003
  <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 documented in RFC
1004
    1995. See <xref linkend="proposed_standards"/>.</para>
1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015

<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, but not manually maintained master
zones nor slave zones obtained by performing a full zone transfer
(AXFR).</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>
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
<sect1><title>Split DNS</title>
<para>Setting up different views, or visibility, of 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> (example.com)
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 nameservers. 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> </emphasis><filename>site1.internal</filename>,
and <filename>site2.internal</filename>.</para>
1053
<para>To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
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
the internal nameservers 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><literal>*   IN MX 10 external1.example.com.</literal></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
nameservers 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
nameservers 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>
1086 1087
        <simpara>Look up any hostnames in the <literal>site1</literal> and 
<literal>site2.example.com</literal> zones.</simpara></listitem>
1088
<listitem>
1089 1090
        <simpara>Look up any hostnames in the <literal>site1.internal</literal> and 
<literal>site2.internal</literal> domains.</simpara></listitem>
1091 1092 1093 1094 1095 1096
<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>
1097 1098
        <simpara>Look up any hostnames in the <literal>site1</literal> and 
<literal>site2.example.com</literal> zones.</simpara></listitem>
1099
<listitem>
1100 1101
        <simpara>Exchange mail with anyone in the <literal>site1</literal> and 
<literal>site2.example.com</literal> zones.</simpara></listitem></itemizedlist>
1102 1103 1104

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

<para>Internal DNS server config:</para>
<programlisting>
1110 1111 1112

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

1113
acl externals { <varname>bastion-ips-go-here</varname>; };
1114

1115 1116 1117 1118
options {
    ...
    ...
    forward only;
1119 1120
    forwarders {                                // forward to external servers
        <varname>bastion-ips-go-here</varname>; 
1121
    };
1122 1123 1124
    allow-transfer { none; };                   // sample allow-transfer (no one)
    allow-query { internals; externals; };      // restrict query access
    allow-recursion { internals; };             // restrict recursion
1125 1126 1127
    ...
    ...
};
1128

1129
zone "site1.example.com" {                      // sample slave zone
1130 1131
  type master;
  file "m/site1.example.com";
1132 1133
  forwarders { };                               // do normal iterative
                                                // resolution (do not forward)
1134 1135 1136
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
1137

1138 1139 1140 1141 1142 1143 1144 1145
zone "site2.example.com" {
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
1146

1147 1148 1149 1150 1151 1152 1153
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};
1154

1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165
zone "site2.internal" {
  type slave;
  file "s/site2.internal";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals };
  allow-transfer { internals; }
};
</programlisting>
    <para>External (bastion host) DNS server config:</para>
<programlisting>
1166 1167
acl internals { 172.16.72.0/24; 192.168.1.0/24; };

1168
acl externals { bastion-ips-go-here; };
1169

1170 1171 1172
options {
  ...
  ...
1173 1174 1175
  allow-transfer { none; };                     // sample allow-transfer (no one)
  allow-query { internals; externals; };        // restrict query access
  allow-recursion { internals; externals; };    // restrict recursion
1176 1177 1178
  ...
  ...
};
1179

1180
zone "site1.example.com" {                      // sample slave zone
1181 1182 1183 1184 1185
  type master;
  file "m/site1.foo.com";
  allow-query { any; };
  allow-transfer { internals; externals; };
};
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
zone "site2.example.com" {
  type slave;
  file "s/site2.foo.com";
  masters { another_bastion_host_maybe; };
  allow-query { any; };
  allow-transfer { internals; externals; }
};
</programlisting>
<para>In the <filename>resolv.conf</filename> (or equivalent) on
the bastion host(s):</para>
<programlisting>
search ...
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4
</programlisting>
</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. Key-based
1218
    access control is far superior, see <xref
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
    linkend="proposed_standards"/>. 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>
<programlisting>
key host1-host2. {
  algorithm hmac-md5;
  secret "La/E5CjG9O+os1jq0a2jdA==";
};
</programlisting>
<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 succeeds, 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>
<programlisting>
server 10.1.2.3 {
  keys { host1-host2. ;};
};
</programlisting>
<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>
1282
<para>If <emphasis>host1</emphasis> sends a message that is a request
1283 1284 1285 1286 1287
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
1288
sign request messages to <emphasis>host1</emphasis>.</para></sect2>
1289 1290 1291
<sect2><title>TSIG Key Based Access Control</title>
<para><acronym>BIND</acronym> allows IP addresses and ranges to be specified in ACL
definitions and
1292
<command>allow-{ query | transfer | update }</command> directives.
1293 1294 1295 1296 1297 1298 1299 1300 1301
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>
<programlisting>
allow-update { key host1-host2. ;};
</programlisting>

      <para>This allows dynamic updates to succeed only if the request
      was signed by a key named
1302 1303
      "<command>host1-host2.</command>".</para> <para>You may want to read about the more
      powerful <command>update-policy</command> statement in <xref
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
      linkend="dynamic_update_policies"/>.</para>

    </sect2>
    <sect2>
      <title>Errors</title>

      <para>The processing of TSIG signed messages can result in
      several errors. If a signed message is sent to a non-TSIG aware
      server, a FORMERR will be returned, since the server will not
      understand the record. This is a result of misconfiguration,
      since the server must be explicitly configured to send a TSIG
      signed message to a specific server.</para>

      <para>If a TSIG aware server receives a message signed by an
      unknown key, the response will be unsigned with the TSIG
      extended error code set to BADKEY. If a TSIG aware server
      receives a message with a signature that does not validate, the
      response will be unsigned with the TSIG extended error code set
      to BADSIG. If a TSIG aware server receives a message with a time
      outside of the allowed range, the response will be signed with
      the TSIG extended error code set to BADTIME, and the time values
      will be adjusted so that the response can be successfully
      verified. In any of these cases, the message's rcode is set to
      NOTAUTH.</para>

    </sect2>
  </sect1>
  <sect1>
    <title>TKEY</title>

    <para><command>TKEY</command> is a mechanism for automatically
    generating a shared secret between two hosts.  There are several
    "modes" of <command>TKEY</command> that specify how the key is
    generated or assigned.  <acronym>BIND</acronym> implements only one of these modes,
    the Diffie-Hellman key exchange.  Both hosts are required to have
    a Diffie-Hellman KEY record (although this record is not required
    to be present in a zone).  The <command>TKEY</command> process
    must use signed messages, signed either by TSIG or SIG(0).  The
    result of <command>TKEY</command> is a shared secret that can be
    used to sign messages with TSIG.  <command>TKEY</command> can also
    be used to delete shared secrets that it had previously
    generated.</para>

    <para>The <command>TKEY</command> process is initiated by a client
    or server by sending a signed <command>TKEY</command> query
    (including any appropriate KEYs) to a TKEY-aware server.  The
    server response, if it indicates success, will contain a
    <command>TKEY</command> record and any appropriate keys.  After
    this exchange, both participants have enough information to
    determine the shared secret; the exact process depends on the
    <command>TKEY</command> mode.  When using the Diffie-Hellman
    <command>TKEY</command> mode, Diffie-Hellman keys are exchanged,
    and the shared secret is derived by both participants.</para>
  
  </sect1>
  <sect1>
    <title>SIG(0)</title>

    <para><acronym>BIND</acronym> 9 partially supports DNSSEC SIG(0) transaction
    signatures as specified in RFC 2535.  SIG(0) uses public/private
    keys to authenticate messages.  Access control is performed in the
    same manner as TSIG keys; privileges can be granted or denied
    based on the key name.</para>

    <para>When a SIG(0) signed message is received, it will only be
    verified if the key is known and trusted by the server; the server
    will not attempt to locate and/or validate the key.</para>

1372
    <para>SIG(0) signing of multiple-message TCP streams is not
1373
    supported.</para>
1374

1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387
    <para><acronym>BIND</acronym> 9 does not ship with any tools that generate SIG(0)
    signed messages.</para>

  </sect1>
  <sect1 id="DNSSEC">
    <title>DNSSEC</title>

    <para>Cryptographic authentication of DNS information is possible
    through the DNS Security (<emphasis>DNSSEC</emphasis>) extensions,
    defined in RFC 2535. This section describes the creation and use
    of DNSSEC signed zones.</para>

    <para>In order to set up a DNSSEC secure zone, there are a series
1388 1389
    of steps which must be followed.  <acronym>BIND</acronym> 9 ships
    with several tools
1390 1391
    that are used in this process, which are explained in more detail
    below.  In all cases, the "<option>-h</option>" option prints a
1392
    full list of parameters.  Note that the DNSSEC tools require the
1393 1394 1395
    keyset and signedkey files to be in the working directory, and
    that the tools shipped with BIND 9.0.x are not fully compatible
    with the current ones.</para>
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

    <para>There must also be communication with the administrators of
    the parent and/or child zone to transmit keys and signatures.  A
    zone's security status must be indicated by the parent zone for a
    DNSSEC capable resolver to trust its data.</para>

    <para>For other servers to trust data in this zone, they must
    either be statically configured with this zone's zone key or the
    zone key of another zone above this one in the DNS tree.</para>

    <sect2>
      <title>Generating Keys</title>

      <para>The <command>dnssec-keygen</command> program is used to
      generate keys.</para>

      <para>A secure zone must contain one or more zone keys.  The
      zone keys will sign all other records in the zone, as well as
      the zone keys of any secure delegated zones.  Zone keys must
      have the same name as the zone, a name type of
      <command>ZONE</command>, and must be usable for authentication.
      It is recommended that zone keys be mandatory to implement a
      cryptographic algorithm; currently the only key mandatory to
      implement an algorithm is DSA.</para>

      <para>The following command will generate a 768 bit DSA key for
      the <filename>child.example</filename> zone:</para>

      <para><userinput>dnssec-keygen -a DSA -b 768 -n ZONE child.example.</userinput></para>

      <para>Two output files will be produced:
      <filename>Kchild.example.+003+12345.key</filename> and
      <filename>Kchild.example.+003+12345.private</filename> (where
      12345 is an example of a key tag).  The key file names contain
      the key name (<filename>child.example.</filename>), algorithm (3
      is DSA, 1 is RSA, etc.), and the key tag (12345 in this case).
      The private key (in the <filename>.private</filename> file) is
      used to generate signatures, and the public key (in the
      <filename>.key</filename> file) is used for signature
      verification.</para>

      <para>To generate another key with the same properties (but with
      a different key tag), repeat the above command.</para>

      <para>The public keys should be inserted into the zone file with
      <command>$INCLUDE</command> statements, including the
1442
      <filename>.key</filename> files.</para>
1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468

    </sect2>
    <sect2>
      <title>Creating a Keyset</title>

      <para>The <command>dnssec-makekeyset</command> program is used
      to create a key set from one or more keys.</para>

      <para>Once the zone keys have been generated, a key set must be
      built for transmission to the administrator of the parent zone,
      so that the parent zone can sign the keys with its own zone key
      and correctly indicate the security status of this zone.  When
      building a key set, the list of keys to be included and the TTL
      of the set must be specified, and the desired signature validity
      period of the parent's signature may also be specified.</para>

      <para>The list of keys to be inserted into the key set may also
      included non-zone keys present at the top of the zone.
      <command>dnssec-makekeyset</command> may also be used at other
      names in the zone.</para>

      <para>The following command generates a key set containing the
      above key and another key similarly generated, with a TTL of
      3600 and a signature validity period of 10 days starting from
      now.</para>

1469
<para><userinput>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para>
1470 1471

      <para>One output file is produced:
1472
      <filename>keyset-child.example.</filename>.  This file should be
1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494
      transmitted to the parent to be signed.  It includes the keys,
      as well as signatures over the key set generated by the zone
      keys themselves, which are used to prove ownership of the
      private keys and encode the desired validity period.</para>

    </sect2>
    <sect2>
      <title>Signing the Child's Keyset</title>

      <para>The <command>dnssec-signkey</command> program is used to
      sign one child's keyset.</para>

      <para>If the <filename>child.example</filename> zone has any
      delegations which are secure, for example,
      <filename>grand.child.example</filename>, the
      <filename>child.example</filename> administrator should receive
      keyset files for each secure subzone.  These keys must be signed
      by this zone's zone keys.</para>

      <para>The following command signs the child's key set with the
      zone keys:</para>

1495
<para><userinput>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para>
1496 1497

      <para>One output file is produced:
1498
      <filename>signedkey-grand.child.example.</filename>.  This file
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
      should be both transmitted back to the child and retained.  It
      includes all keys (the child's keys) from the keyset file and
      signatures generated by this zone's zone keys.</para>

    </sect2>
    <sect2>
      <title>Signing the Zone</title>

      <para>The <command>dnssec-signzone</command> program is used to
      sign a zone.</para>

      <para>Any <filename>signedkey</filename> files corresponding to
      secure subzones should be present, as well as a
      <filename>signedkey</filename> file for this zone generated by
      the parent (if there is one). The zone signer will generate
      <literal>NXT</literal> and <literal>SIG</literal> records for
      the zone, as well as incorporate the zone key signature from the
      parent and indicate the security status at all delegation
      points.</para>

      <para>The following command signs the zone, assuming it is in a
      file called <filename>zone.child.example</filename>.  By
      default, all zone keys which have an available private key are
      used to generate signatures.</para>

<para><userinput>dnssec-signzone -o child.example zone.child.example</userinput></para>

      <para>One output file is produced:
      <filename>zone.child.example.signed</filename>.  This file
      should be referenced by <filename>named.conf</filename> as the
      input file for the zone.</para>

    </sect2>
    <sect2><title>Configuring Servers</title>

      <para>Unlike in <acronym>BIND</acronym> 8, data is not verified on load in <acronym>BIND</acronym> 9,
      so zone keys for authoritative zones do not need to be specified
      in the configuration file.</para>

      <para>The public key for any security root must be present in
      the configuration file's <command>trusted-keys</command>
      statement, as described later in this document. </para>

    </sect2>
  </sect1>
  <sect1>
    <title>IPv6 Support in <acronym>BIND</acronym> 9</title>

    <para><acronym>BIND</acronym> 9 fully supports all currently defined forms of IPv6
    name to address and address to name lookups.  It will also use
    IPv6 addresses to make queries when running on an IPv6 capable
    system.</para>

    <para>For forward lookups, <acronym>BIND</acronym> 9 supports both A6 and AAAA
1553
    records.  The use of AAAA records is deprecated, but it is still
1554 1555 1556 1557 1558 1559 1560 1561 1562 1563