Bv9ARM-book.xml 313 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

Mark Andrews's avatar
Mark Andrews committed
5
<!-- File: $Id: Bv9ARM-book.xml,v 1.266 2005/04/08 04:51:21 marka Exp $ -->
6

7
<book>
8 9 10 11
<title>BIND 9 Administrator Reference Manual</title>

<bookinfo>
<copyright>
Mark Andrews's avatar
Mark Andrews committed
12 13 14
<year>2004</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
Mark Andrews's avatar
Mark Andrews committed
15 16 17 18
<copyright>
<year>2000-2003</year>
<holder>Internet Software Consortium</holder>
</copyright>
19
</bookinfo>
20

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

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

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

</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
166 167
<literal>mail.example.com</literal>,
where <literal>com</literal> is the
168 169 170 171 172
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
173
name of the host.</para>
174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197

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

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

<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
232
actually asking for slave service for some collection of zones.</para>
233 234 235 236 237 238 239 240 241 242 243
</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>

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

366 367
    </sect2>
  </sect1>
368 369

</chapter>
370

371 372 373 374 375
<chapter id="ch02"><title><acronym>BIND</acronym> Resource Requirements</title>

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

376 377 378 379 380 381
<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.
382
<acronym>BIND</acronym> 9 is fully multithreaded, allowing full utilization of
383 384 385 386 387 388
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>
389 390

<sect1><title>Memory Requirements</title>
391
<para>The memory of the server has to be large enough to fit the
392 393
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,
394
at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
395 396 397 398 399 400
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
401
all zone and cache data into memory &mdash; unfortunately, the best way
402
to determine this for a given installation is to watch the name server
403 404
in operation. After a few weeks the server process should reach
a relatively stable size where entries are expiring from the cache as
405
fast as they are being inserted.</para></sect1>
406

407 408
<sect1><title>Name Server Intensive Environment Issues</title>
<para>For name server intensive environments, there are two alternative
409
configurations that may be used. The first is where clients and
410
any second-level internal name servers query a main name server, which
411 412
has enough memory to build a large cache. This approach minimizes
the bandwidth used by external name lookups. The second alternative
413
is to set up second-level internal name servers to make queries independently.
414 415 416
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,
417 418
as none of the name servers share their cached data.</para></sect1>

419
<sect1><title>Supported Operating Systems</title>
420 421 422 423 424 425
<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>
426

427 428
<chapter id="ch03">
<title>Name Server Configuration</title>
429 430 431
<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>
432 433 434 435 436 437

<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
438
name server for use by clients internal to a corporation.  All queries
439 440 441 442 443
from outside clients are refused using the <command>allow-query</command>
option.  Alternatively, the same effect could be achieved using suitable
firewall rules.</para>

<programlisting>
444
// Two corporate subnets we wish to allow queries from.
445
acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
446
options {
447
     directory "/etc/namedb";           // Working directory
448
     allow-query { corpnets; };
449 450 451 452 453 454 455 456
};
// 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>
457 458 459 460 461
</sect2>

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

<programlisting>
466
options {
467
     directory "/etc/namedb";           // Working directory
468
     allow-query-cache { none; };       // Do not allow access to cache
469 470
     allow-query { any; };              // This is the default
     recursion no;                      // Do not provide recursive service
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
};

// 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>
497 498 499 500 501 502 503 504 505
</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>

506 507 508 509
<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>
510 511 512

<informaltable colsep = "0" rowsep = "0">
<tgroup cols = "5" colsep = "0" rowsep = "0" tgroupstyle = "2Level-table">
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
<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
557 558 559
    <command>options</command> statement, see
    <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
    This substatement is not supported in
560 561 562
    <acronym>BIND</acronym> 9, and only the ordering scheme described above is
    available.</para>

563
</sect1>
564

565 566 567 568 569 570
<sect1>
<title>Name Server Operations</title>

<sect2>
<title>Tools for Use With the Name Server Daemon</title>
<para>There are several indispensable diagnostic, administrative
571
and monitoring tools available to the system administrator for controlling
572
and debugging the name server daemon. We describe several in this
573
section </para>
574 575 576 577 578 579 580 581 582 583 584 585 586 587 588
<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
589 590 591
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>
592 593 594 595 596 597 598 599 600 601 602 603 604
<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
605
options, see the <command>dig</command> man page.</para>
606 607 608 609 610 611 612 613
</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
614 615
between host names and Internet addresses, but its functionality
can be extended with the use of options.</para>
616 617 618 619 620 621 622 623 624 625 626 627
<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
628
options, see the <command>host</command> man page.</para>
629 630 631 632 633 634 635 636
</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
637 638 639
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>
640 641 642 643 644 645 646 647
<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>
648
<para>Interactive mode is entered when no arguments are given (the
649
default name server will be used) or when the first argument is a
650
hyphen (`-') and the second argument is the host name or Internet address
651
of a name server.</para>
652 653
<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
654
optional second argument specifies the host name or address of a name server.</para>
655 656 657
<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>
658 659 660 661
</listitem>

</varlistentry>
</variablelist>
662 663 664
</sect3>

<sect3 id="admin_tools">
665 666 667 668
        <title>Administrative Tools</title>
        <para>Administrative tools play an integral part in the management
of a server.</para>
        <variablelist>
669
          <varlistentry id="named-checkconf" xreflabel="Named Configuration Checking application">
670
            <term><command>named-checkconf</command></term>
Mark Andrews's avatar
Mark Andrews committed
671
            <listitem>
672 673
              <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
674
              <cmdsynopsis label="Usage">
675
                <command>named-checkconf</command>
676
		<arg>-jvz</arg>
677
                <arg>-t <replaceable>directory</replaceable></arg>
Mark Andrews's avatar
Mark Andrews committed
678 679 680
                <arg><replaceable>filename</replaceable></arg>
              </cmdsynopsis>
            </listitem>
681 682
          </varlistentry>
          <varlistentry id="named-checkzone" xreflabel="Zone Checking application">
683
            <term><command>named-checkzone</command></term>
Mark Andrews's avatar
Mark Andrews committed
684
            <listitem>
685 686
              <para>The <command>named-checkzone</command> program checks a master file for
              syntax and consistency.</para>
Mark Andrews's avatar
Mark Andrews committed
687
              <cmdsynopsis label="Usage">
688
                <command>named-checkzone</command>
689
                <arg>-djqvD</arg>
Mark Andrews's avatar
Mark Andrews committed
690
                <arg>-c <replaceable>class</replaceable></arg>
691 692 693 694 695
                <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>
Mark Andrews's avatar
Mark Andrews committed
696
                <arg>-W <replaceable>(ignore|warn)</replaceable></arg>
Mark Andrews's avatar
Mark Andrews committed
697 698 699 700
                <arg choice="plain"><replaceable>zone</replaceable></arg>
                <arg><replaceable>filename</replaceable></arg>
              </cmdsynopsis>
            </listitem>
701
          </varlistentry>
702 703
          <varlistentry id="rndc" xreflabel="Remote Name Daemon Control application">
            <term><command>rndc</command></term>
704 705 706
            <listitem>
              <para>The remote name daemon control
              (<command>rndc</command>) program allows the system
707
              administrator to control the operation of a name server.
708 709 710 711 712 713 714 715 716 717 718
              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>
719 720
              <para><command>command</command> is one of the following:</para>

721
<variablelist>
722

723
   <varlistentry><term><userinput>reload</userinput></term>
724 725
   <listitem><para>Reload configuration file and zones.</para></listitem>
   </varlistentry>
726

727 728
   <varlistentry><term><userinput>reload <replaceable>zone</replaceable>
       <optional><replaceable>class</replaceable>
729
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
730 731
   <listitem><para>Reload the given zone.</para></listitem>
   </varlistentry>
732

733 734 735
   <varlistentry><term><userinput>refresh <replaceable>zone</replaceable>
       <optional><replaceable>class</replaceable>
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
736 737 738
   <listitem><para>Schedule zone maintenance for the given zone.</para></listitem>
   </varlistentry>

739 740 741 742 743 744
   <varlistentry><term><userinput>retransfer <replaceable>zone</replaceable>
       <optional><replaceable>class</replaceable>
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
   <listitem><para>Retransfer the given zone from the master.</para></listitem>
   </varlistentry>

745
   <varlistentry> <term><userinput>freeze <optional><replaceable>zone</replaceable>
746
       <optional><replaceable>class</replaceable>
747 748 749
           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
   <listitem><para>Suspend updates to a dynamic zone.  If no zone is specified
	then all zones are suspended.  This allows manual
750 751 752 753 754 755
    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>

756
   <varlistentry><term><userinput>thaw <optional><replaceable>zone</replaceable>
757
       <optional><replaceable>class</replaceable>
758 759 760
           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
   <listitem><para>Enable updates to a frozen dynamic zone.  If no zone is
    specified then all frozen zones are enabled.  This causes
761
    the server to reload the zone from disk, and re-enables dynamic updates
762
    after the load has completed.  After a zone is thawed, dynamic updates
763 764 765
    will no longer be refused.</para></listitem>
   </varlistentry>

766 767 768 769 770
   <varlistentry><term><userinput>notify <replaceable>zone</replaceable>
       <optional><replaceable>class</replaceable>
           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
   <listitem><para>Resend NOTIFY messages for the zone</para></listitem></varlistentry>

771 772 773 774 775 776 777 778
   <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>
779

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

784
   <varlistentry><term><userinput>querylog</userinput></term>
785
   <listitem><para>Toggle query logging. Query logging can also be enabled
Mark Andrews's avatar
Mark Andrews committed
786
   by explicitly directing the <command>queries</command>
787 788 789
   <command>category</command> to a <command>channel</command> in the
   <command>logging</command> section of
   <filename>named.conf</filename>.</para></listitem></varlistentry>
790

791 792 793 794
   <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>
795

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

801
   <varlistentry><term><userinput>halt <optional>-p</optional></userinput></term>
802 803 804
   <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
805
   is restarted.  If -p is specified named's process id is returned.</para></listitem></varlistentry>
806

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

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

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

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

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

823
   <varlistentry><term><userinput>status</userinput></term>
824 825 826 827
   <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>
828

829 830 831 832 833
   <varlistentry><term><userinput>recursing</userinput></term>
   <listitem><para>Dump the list of queries named is currently recursing
   on.
   </para></listitem></varlistentry>

834
</variablelist>
835

Andreas Gustafsson's avatar
Andreas Gustafsson committed
836 837
<para>In <acronym>BIND</acronym> 9.2, <command>rndc</command>
supports all the commands of the BIND 8 <command>ndc</command>
838 839
utility except <command>ndc start</command> and
<command>ndc restart</command>, which were also
Andreas Gustafsson's avatar
Andreas Gustafsson committed
840 841 842 843 844 845 846 847 848 849 850 851
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
852 853 854 855 856
<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
Andreas Gustafsson's avatar
Andreas Gustafsson committed
857 858 859 860 861 862 863 864 865 866 867
<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>
868

869 870 871 872
<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
873 874
host name or address argument  and represents the server that will
be contacted if no <option>-s</option>
875 876
option is provided on the command line.  
<command>default-key</command> takes
877
the name of a key as its argument, as defined by a <command>key</command> statement.
878 879 880 881 882
<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>

883 884 885 886 887 888
<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
889 890
domain name, though it need not actually be hierarchical; thus,
a string like "<userinput>rndc_key</userinput>" is a valid name.
891 892 893
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
894
to algorithm, currently only the string "<userinput>hmac-md5</userinput>"
895
has any meaning.  The secret is a base-64 encoded string.</para>
896

897 898 899 900 901 902 903 904 905 906
<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>
907

908
<para>A sample minimal configuration file is as follows:</para>
909
<programlisting>
910 911 912 913 914
key rndc_key {
     algorithm "hmac-md5";
     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
options {
915
     default-server 127.0.0.1;
916 917 918
     default-key    rndc_key;
};
</programlisting>
919

920 921
<para>This file, if installed as <filename>/etc/rndc.conf</filename>,
would allow the command:</para>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
922 923 924

<para><prompt>$ </prompt><userinput>rndc reload</userinput></para>

925 926
<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
927
following controls statements:</para>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
928
<programlisting>
929
controls {
930
        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
931 932 933 934
};
</programlisting>
<para>and it had an identical key statement for
<literal>rndc_key</literal>.</para>
935 936 937 938 939 940 941 942 943 944 945

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

946 947 948 949 950 951
            </listitem>
          </varlistentry>
        </variablelist>

      </sect3>
    </sect2>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
952 953 954
<sect2>

<title>Signals</title>
955 956 957
<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>
958
<informaltable frame = "all" ><tgroup cols = "2">
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
<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>

984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005
<chapter id="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>
1006 1007

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

1010 1011 1012
    <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
1013 1014
    in RFC 2136.</para>

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

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

1026 1027 1028
    <sect2 id="journal">
    <title>The journal file</title>

1029 1030
    <para>All changes made to a zone using dynamic update are stored
    in the zone's journal file.  This file is automatically created
Mark Andrews's avatar
Mark Andrews committed
1031
    by the server when the first dynamic update takes place.
1032 1033 1034
    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
1035 1036 1037 1038 1039 1040
    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
1041 1042
    zone is updated frequently.  Instead, the dump is delayed by
    up to 15 minutes, allowing additional updates to take place.</para>
1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055

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

    <para>If you have to make changes to a dynamic zone
1058 1059 1060 1061 1062 1063 1064
    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>
1065

1066 1067 1068 1069
  </sect2>
    
</sect1>
    
1070 1071
<sect1 id="incremental_zone_transfers">
<title>Incremental Zone Transfers (IXFR)</title>
1072

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

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

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

1096
<sect1><title>Split DNS</title>
1097
<para>Setting up different views, or visibility, of the DNS space to
1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112
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>
1113 1114
<para>Let's say a company named <emphasis>Example, Inc.</emphasis>
(<literal>example.com</literal>)
1115 1116 1117 1118 1119 1120 1121 1122 1123
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
1124
of name servers. One set will be on the inside network (in the reserved
1125 1126 1127 1128 1129 1130 1131 1132
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>
1133
<para>To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
1134
the internal name servers must be configured to disallow all queries
1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154
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
1155
name servers for DNS resolution.</para>
1156 1157 1158 1159 1160
<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
1161
name servers for DNS queries. This could also be enforced via selective
1162 1163 1164 1165
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>
1166 1167
        <simpara>Look up any hostnames in the <literal>site1</literal> and 
<literal>site2.example.com</literal> zones.</simpara></listitem>
1168
<listitem>
1169 1170
        <simpara>Look up any hostnames in the <literal>site1.internal</literal> and 
<literal>site2.internal</literal> domains.</simpara></listitem>
1171 1172 1173 1174 1175 1176
<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>
1177 1178
        <simpara>Look up any hostnames in the <literal>site1</literal> and 
<literal>site2.example.com</literal> zones.</simpara></listitem>
1179
<listitem>
1180 1181
        <simpara>Exchange mail with anyone in the <literal>site1</literal> and 
<literal>site2.example.com</literal> zones.</simpara></listitem></itemizedlist>
1182 1183 1184

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

<para>Internal DNS server config:</para>
<programlisting>
1190 1191 1192

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

1193
acl externals { <varname>bastion-ips-go-here</varname>; };
1194

1195 1196 1197 1198
options {
    ...
    ...
    forward only;
1199 1200
    forwarders {                                // forward to external servers
        <varname>bastion-ips-go-here</varname>; 
1201
    };
1202 1203 1204
    allow-transfer { none; };                   // sample allow-transfer (no one)
    allow-query { internals; externals; };      // restrict query access
    allow-recursion { internals; };             // restrict recursion
1205 1206 1207
    ...
    ...
};
1208

1209
zone "site1.example.com" {                      // sample master zone
1210 1211
  type master;
  file "m/site1.example.com";
1212 1213
  forwarders { };                               // do normal iterative
                                                // resolution (do not forward)
1214 1215 1216
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
1217

1218
zone "site2.example.com" {                      // sample slave zone
1219 1220 1221 1222 1223 1224 1225
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
1226

1227 1228 1229 1230 1231 1232 1233
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};
1234

1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245
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>
1246 1247
acl internals { 172.16.72.0/24; 192.168.1.0/24; };

Eric Luce's avatar