Bv9ARM-book.xml 269 KB
Newer Older
1
2
<?xml version='1.0'?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
3
               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd">
4

5
<!-- File: $Id: Bv9ARM-book.xml,v 1.42 2000/11/20 17:37:54 gson Exp $ -->
6

7
8
<book>

9
  <chapter id="ch01">
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
  <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
    Internet nameserver for a number of operating systems. This
    document provides basic information about the installation and
    care of the Internet Software Consortium (<acronym>ISC</acronym>) <acronym>BIND</acronym> version 9
    software package for system administrators.</para>
  </sect1>
  <sect1><title>Organization of This Document</title>
    <para>In this document, <emphasis>Section 1</emphasis> introduces
    the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Section 2</emphasis>
    describes resource requirements for running <acronym>BIND</acronym> in various
    environments. Information in <emphasis>Section 3</emphasis> is
    <emphasis>task-oriented</emphasis> in its presentation and is
    organized functionally, to aid in the process of installing the
    <acronym>BIND</acronym> 9 software. The task-oriented section is followed by
    <emphasis>Section 4</emphasis>, which contains more advanced
    concepts that the system administrator may need for implementing
    certain options. Section 5 describes the <acronym>BIND</acronym> 9 lightweight
    resolver.  The contents of <emphasis>Section 6</emphasis> are
    organized as in a reference manual to aid in the ongoing
    maintenance of the software. <emphasis>Section 7
    </emphasis>addresses security considerations, and
    <emphasis>Section 8</emphasis> contains troubleshooting help. The
    main body of the document is followed by several
    <emphasis>Appendices</emphasis> which contain useful reference
    information, such as a <emphasis>Bibliography</emphasis> and
    historic information related to <acronym>BIND</acronym> and the Domain Name
    System.</para>
  </sect1>
  <sect1><title>Conventions Used in This Document</title>

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

<informaltable 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>a pathname, filename, URL, hostname,
mailing list name, or new term or concept</para></entry>
              <entry colname = "2" rowsep = "1"><para><filename>Italic</filename></para></entry>
            </row>
            <row rowsep = "0">
              <entry colname = "1" colsep = "1" rowsep = "1"><para>literal user
input</para></entry>
              <entry colname = "2" rowsep = "1"><para><userinput>Fixed Width Bold</userinput></para></entry>
            </row>
            <row rowsep = "0">
              <entry colname = "1" colsep = "1" rowsep = "1"><para>variable user
input</para></entry>
              <entry colname = "2" rowsep = "1"><para><optional>Fixed Width Italic</optional></para></entry>
            </row>
            <row rowsep = "0">
              <entry colname = "1" colsep = "1"><para>program output</para></entry>
              <entry colname = "2"><para><computeroutput>Fixed Width Bold</computeroutput></para></entry>
            </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>
              <entry colname = "2" rowsep = "1"><para><literal>Sans Serif Bold</literal></para></entry>
            </row>
            <row rowsep = "0">
              <entry colname = "1" colsep = "1" rowsep = "1"><para>variables</para></entry>
              <entry colname = "2" rowsep = "1"><para><varname>Sans Serif Italic</varname></para></entry>
            </row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>"meta-syntactic"
information (within brackets when optional)</para></entry>
<entry colname = "2" rowsep = "1"><para><optional>Fixed Width Italic</optional></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>Command line
input</para></entry>
<entry colname = "2" rowsep = "1"><para><userinput>Fixed Width Bold</userinput></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>Program output</para></entry>
                <entry colname = "2" rowsep = "1"><para><computeroutput>Fixed Width</computeroutput></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1"><para>Optional input</para></entry>
                <entry colname = "2"><para><optional>Text is enclosed in square brackets</optional></para></entry>
</row>
</tbody>
</tgroup></informaltable></para></sect1>
<sect1><title>Discussion of Domain Name System (<acronym>DNS</acronym>) Basics and
<acronym>BIND</acronym></title>
<para>The purpose of this document is to explain the installation
and basic upkeep of the <acronym>BIND</acronym> software package, and we begin by reviewing
the fundamentals of the domain naming system as they relate to <acronym>BIND</acronym>.
<acronym>BIND</acronym> consists of a <emphasis>nameserver</emphasis> (or "daemon")
called <command>named</command> and a <command>resolver</command> library.
The <acronym>BIND</acronym> server runs in the background, servicing queries on a well
known network port. The standard port for the User Datagram Protocol
(UDP) and Transmission Control Protocol (TCP), usually port 53,
143
is specified in <filename>/etc/services</filename>.
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
The <emphasis>resolver</emphasis> is a set of routines residing
in a system library that provides the interface that programs can
use to access the domain name services.</para>
<sect2><title>Nameservers</title>
<para>A nameserver (NS) is a program that stores information about
named resources and responds to queries from programs called <emphasis>resolvers</emphasis> which
act as client processes. The basic function of an NS is to provide
information about network objects by answering queries.</para>
<para>With the nameserver, the network can be broken into a hierarchy
of domains. The name space is organized as a tree according to organizational
or administrative boundaries. Each node of the tree, called a domain,
is given a label. The name of the domain is the concatenation of
all the labels of the domains from the root to the current domain.
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 domain. The whole name space is partitioned into areas
called <emphasis>zones</emphasis>, each starting at a domain and
extending down to the leaf domains or to domains where other zones
start. Zones usually represent administrative boundaries. For example,
a domain name for a host at the company <emphasis>Example, Inc.</emphasis> would
be:</para>
<para><systemitem class="systemname">ourhost.example.com</systemitem></para>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
166
167
168
169
170
<para>where <systemitem class="systemname">com</systemitem> is the top level domain to which
<systemitem class="systemname">ourhost.example.com</systemitem> belongs, 
<systemitem class="systemname">example</systemitem> is
a subdomain of <systemitem class="systemname">com</systemitem>, and
<systemitem class="systemname">ourhost</systemitem> is the
171
172
173
174
175
176
name of the host.</para>
<para>The specifications for the domain nameserver are defined in
the RFC 1034, RFC 1035 and RFC 974. These documents can be found
in
<filename>/usr/src/etc/named/doc</filename> in 4.4BSD or are available
via File Transfer Protocol (FTP) from
Andreas Gustafsson's avatar
Andreas Gustafsson committed
177
178
<ulink url="ftp://www.isi.edu/in-notes/">ftp://www.isi.edu/in-notes/</ulink>
or via the Web at <ulink url="http://www.ietf.org/rfc/">http://www.ietf.org/rfc/</ulink>.
179
(See Appendix C for complete information on finding and retrieving
Andreas Gustafsson's avatar
Andreas Gustafsson committed
180
181
RFCs.) It is also recommended that you read the related man pages:
<command>named</command> and <command>resolver</command>.</para></sect2>
182
183
184
185
186
187
188
189
190
191
192
193
<sect2><title>Types of Zones</title>
<para>As we stated previously, a zone is a point of delegation in
the <acronym>DNS</acronym> tree. A zone consists of those contiguous parts of the domain
tree for which a domain server has complete information and over which
it has authority. It contains all domain names from a certain point
downward in the domain tree except those which are delegated to
other zones. A delegation point has one or more NS records in the
parent zone, which should be matched by equivalent NS records at
the root of the delegated zone.</para>
<para>To properly operate a nameserver, it is important to understand
the difference between a <emphasis>zone</emphasis> and a <emphasis>domain</emphasis>.</para>
<para>For instance, consider the <systemitem class="systemname">example.com</systemitem> domain
Andreas Gustafsson's avatar
Andreas Gustafsson committed
194
195
196
197
198
199
which includes names such as <systemitem class="systemname">host.aaa.example.com</systemitem>
and <systemitem class="systemname">host.bbb.example.com</systemitem> even
though the <systemitem class="systemname">example.com</systemitem>
zone includes only delegations for the
<systemitem class="systemname">aaa.example.com</systemitem>
and <systemitem class="systemname">bbb.example.com</systemitem> zones.
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
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
nameservers. 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 a Domain Nameserver, it deals primarily in
terms of zones. The master and slave declarations in the <filename>named.conf</filename> file
specify zones, not domains. When you ask some other site if it is willing
to be a slave server for your <emphasis>domain</emphasis>, you are
actually asking for slave service for some collection of zones.</para>
<para>Each zone will have one <emphasis>primary master</emphasis> (also
called <emphasis>primary</emphasis>) server which 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.
There there will be some number of <emphasis>slave</emphasis> (also
called <emphasis>secondary) </emphasis>servers, which load the zone
contents using the <acronym>DNS</acronym> protocol (that is, the secondary servers
will contact the primary and fetch the zone data using TCP). This
set of servers &mdash; the primary and all of its secondaries &mdash; should be
listed in the NS records in the parent zone and will constitute a <emphasis>delegation</emphasis>.
This set of servers must also be listed in the zone file itself,
usually under the <command>@</command> name which indicates the <emphasis>top
level</emphasis> or <emphasis>root</emphasis> of the current zone.
You can list servers in the zone's top-level <command>@</command> NS
records that are not in the parent's NS delegation, but you cannot
list servers in the parent's delegation that are not present in
the zone's <command>@</command>.</para>
<para>Any servers listed in the NS records must be configured as <emphasis>authoritative</emphasis> for
the zone. A server is authoritative for a zone when it has been
configured to answer questions for that zone with authority, which
it does by setting the "authoritative answer" (AA) bit in reply
packets. A server may be authoritative for more than one zone. The
authoritative data for a zone is composed of all of the Resource
Records (RRs) &mdash; the data associated with names in a tree-structured
name space &mdash; attached to all of the nodes from the top node of the
zone down to leaf nodes or nodes above cuts around the bottom edge
of the zone.</para>
<para>Adding a zone as a type master or type slave will tell the
server to answer questions for the zone authoritatively. If the
server is able to load the zone into memory without any errors it
will set the AA bit when it replies to queries for the zone. See
RFCs 1034 and 1035 for more information about the AA bit.</para></sect2>
<sect2><title>Servers</title>
<para>A <acronym>DNS</acronym> server can be master for some zones and slave for others
or can be only a master, or only a slave, or can serve no zones
and just answer queries via its <emphasis>cache</emphasis>. Master
servers are often also called <emphasis>primaries</emphasis> and
slave servers are often also called <emphasis>secondaries</emphasis>.
Both master/primary and slave/secondary servers are authoritative
for a zone.</para>
<para>All servers keep data in their cache until the data expires,
based on a Time To Live (TTL) field which is maintained for all
resource records.</para>
<sect3><title>Master Server</title>
<para>The <emphasis>primary master server</emphasis> is the ultimate
source of information about a domain. The primary master is an authoritative
server configured to be the source of zone transfer for one or more
secondary servers. The primary master server obtains data for the
zone from a file on disk.</para></sect3>
<sect3><title>Slave Server </title>
<para>A <emphasis>slave server</emphasis>, also called a <emphasis>secondary
server</emphasis>, is an authoritative server that uses zone transfers from
the primary master server to retrieve the zone data. Optionally,
the slave server obtains zone data from a cache on disk. Slave servers
provide necessary redundancy. All secondary/slave servers are named
in the NS RRs for the zone.</para></sect3>
<sect3><title>Caching Only Server</title>
<para>Some servers are <emphasis>caching only servers</emphasis>.
This means that the server caches the information that it receives
and uses it until the data expires. A caching only server is a server
that is not authoritative for any zone. This server services queries
and asks other servers, who have the authority, for the information
it needs.</para></sect3>
<sect3><title>Forwarding Server</title>
<para>Instead of interacting with the nameservers for the root and
other domains, a <emphasis>forwarding server</emphasis> always forwards
queries it cannot satisfy from its authoritative data or cache to
a fixed list of other servers. The forwarded queries are also known
as <emphasis>recursive queries</emphasis>, the same type as a client would
send to a server. There may be one or more servers forwarded to,
and they are queried in turn until the list is exhausted or an answer
is found. A forwarding server is typically used when you do not
wish all the servers at a given site to interact with the rest of
the Internet servers. A typical scenario would involve a number
of internal <acronym>DNS</acronym> servers and an Internet firewall. Servers unable
to pass packets through the firewall would forward to the server
that can do it, and that server would query the Internet <acronym>DNS</acronym> servers
on the internal server's behalf. An added benefit of using the forwarding
feature is that the central machine develops a much more complete
cache of information that all the workstations can take advantage
of.</para>
<para>There is no prohibition against declaring a server to be a
forwarder even though it has master and/or slave zones as well;
the effect will still be that anything in the local server's cache
or zones will be answered, and anything else will be forwarded using
the forwarders list.</para></sect3>
<sect3><title>Stealth Server</title>
<para>A <emphasis>stealth server</emphasis> is a server that answers
authoritatively for a zone, but is not listed in that zone's NS
records. Stealth servers can be used as a way to centralize distribution
of a zone, without having to edit the zone on a remote nameserver.
Where the master file for a zone resides on a stealth server in
this way, it is often referred to as a "hidden primary" configuration.
Stealth servers can also be a way to keep a local copy of a zone
for rapid access to the zone's records, even if all "official" nameservers
for the zone are inaccessible.</para>
      </sect3>
    </sect2>
  </sect1>
  </chapter>

314
  <chapter id="ch02"><title><acronym>BIND</acronym> Resource Requirements</title>
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
<sect1><title>Hardware requirements</title>
<para><acronym>DNS</acronym> hardware requirements have traditionally been quite modest.
For many installations, servers that have been pensioned off from
active duty have performed admirably as <acronym>DNS</acronym> servers.</para>
<para>The DNSSEC and IPv6 features of <acronym>BIND</acronym> 9 may prove to be quite
CPU intensive however, so organizations that make heavy use of these
features may wish to consider larger systems for these applications.
<acronym>BIND</acronym> 9 is 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>
<sect1><title>Memory Requirements </title>
<para>The memory of the server has to be large enough to fit the
cache and zones loaded off disk. Future releases of <acronym>BIND</acronym> 9 will
provide methods to limit the amount of memory used by the cache,
at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
traffic. 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>
<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>
      <listitem>
        <simpara>HP HP-UX 11</simpara>
      </listitem>
      <listitem>
        <simpara>IRIX64 6.5</simpara>
      </listitem>
      <listitem>
        <simpara>Red Hat Linux 6.0, 6.1</simpara>
      </listitem>
      <listitem>
        <simpara>Sun Solaris 2.6, 7, 8 (beta)</simpara>
      </listitem>
      <listitem>
        <simpara>FreeBSD 3.4-STABLE</simpara>
      </listitem>
      <listitem>
        <simpara>NetBSD-current with "unproven" pthreads</simpara>
      </listitem>
    </itemizedlist>
  </sect1>
  </chapter>

384
  <chapter id="ch03">
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
  <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 {
     directory "/etc/namedb";		// Working directory
     pid-file "named.pid";		// Put pid file in working dir
     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 {
     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
};
// 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
510
511
512
    <command>options</command> statement, see
    <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
    This substatement is not supported in
513
514
515
516
517
518
519
520
521
522
523
524
525
    <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
526
    of the zone option <command>also-notify</command>, see <xref
527
    linkend="zone_transfers"/>. For more information about
528
    <command>notify</command>, see <xref
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
    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>
      <sect3>
        <title>Diagnostic Tools</title>
        <variablelist>
          <varlistentry>
            <term><command>dig</command></term>
            <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>
        </variablelist>
      </sect3>
624
      <sect3 id="admin_tools">
625
626
627
628
        <title>Administrative Tools</title>
        <para>Administrative tools play an integral part in the management
of a server.</para>
        <variablelist>
629
630
          <varlistentry id="rndc" xreflabel="Remote Name Daemon Control application">
            <term><command>rndc</command></term>
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
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
            <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>
              <para><command>command</command> is one of the following
              for <command>named</command>:</para>
              <informaltable colsep = "0" rowsep = "0">
                <tgroup cols = "2"
                        colsep = "0" rowsep = "0" tgroupstyle = "4Level-table">
                  <colspec colname = "1" colnum = "1"
                           colsep = "0" colwidth = "1.500in"/>
                  <colspec colname = "2" colnum = "2" colsep = "0"
                           colwidth = "3.000in"/>
                  <tbody>
                    <row rowsep = "0">
                      <entry colname = "1">
<para><userinput>status</userinput><footnote id="nyi1">
                            <para>not yet implemented</para>
                          </footnote></para></entry>
<entry colname = "2"><para>Display ps(1) status of named.</para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><userinput>dumpdb</userinput><footnoteref linkend="nyi1"/></para></entry>
<entry colname = "2"><para>Dump database and cache to /var/tmp/named_dump.db.</para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><userinput>reload</userinput></para></entry>
<entry colname = "2"><para>Reload configuration file and zones.</para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><userinput>stats</userinput><footnoteref linkend="nyi1"/></para></entry>
<entry colname = "2"><para>Dump statistics to /var/tmp/named.stats.</para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><userinput>trace</userinput><footnoteref linkend="nyi1"/></para></entry>
<entry colname = "2"><para>Increment debugging level by one.</para></entry>
</row>
<row rowsep = "0">
                      <entry colname = "1">
<para><userinput>notrace</userinput><footnoteref linkend="nyi1"/>
</para></entry>
<entry colname = "2"><para>Set debugging level to 0.</para></entry>
</row>
<row rowsep = "0">
                      <entry colname =
                             "1"><para><userinput>querylog</userinput><footnoteref linkend="nyi1"/></para></entry>
<entry colname = "2"><para>Toggle query logging.</para></entry>
</row>
<row rowsep = "0">
                      <entry colname =
                             "1"><para><userinput>stop</userinput><footnoteref linkend="nyi1"/></para></entry>
<entry colname = "2"><para>Stop the server.</para></entry>
</row>
<row rowsep = "0">
                      <entry colname =
                             "1"><para><userinput>restart</userinput><footnoteref linkend="nyi1"/></para></entry>
<entry colname = "2"><para>Restart the server.</para></entry>
                    </row>
                  </tbody>
                </tgroup>
              </informaltable>
              <para>As noted above, <command>reload</command> is the
              only command available for <acronym>BIND</acronym> 9.0.0. The other
              commands, and more, are planned to be implemented for
              future releases.</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.</para>

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

<para>The <command>options{}</command> statement has two clauses: <command>default-server</command> and <command>default-key</command>. <command>default-server</command> takes a
host name or address argument  and represents the server that will
be contacted if no <option>-s</option>
option is provided on the command line.  <command>default-key</command> takes
the name of key as its argument, as defined by a <command>key{}</command> statement.
 In the future a <command>default-port</command> clause will be
added to specify the port to which <command>rndc</command> should
connect.</para>
<para>The <command>key{}</command> statement names a key with its
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.
The <command>key{}</command> statement has two clauses: <command>algorithm</command> and <command>secret</command>.
 While the configuration parser will accept any string as the argument
to algorithm, currently only the string "<userinput>hmac-md5</userinput>"
has any meaning.  The secret is a base-64 encoded string, typically
generated with either <command>dnssec-keygen</command> or <command>mmencode</command>.</para>
<para>The <command>server{}</command> statement uses the key clause
to associate a <command>key{}</command>-defined key with a server.
 The argument to the <command>server{}</command> statement is a
host name or address (addresses must be double quoted).  The argument
to the key clause is the name of the key as defined by the <command>key{}</command> statement.
 A <command>port</command> clause will be added to a future release
to specify the port to which <command>rndc</command> should connect
on the given server.</para>
<para>A sample minimal configuration file is as follows:</para>
              <programlisting>
key rndc_key {
     algorithm "hmac-md5";
     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
options {
     default-server localhost;
     default-key    rndc_key;
};
</programlisting>
<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 {
		inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};
</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>
<informaltable colsep = "0" rowsep = "0"><tgroup cols = "2"
    colsep = "0" rowsep = "0" tgroupstyle = "3Level-table">
<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>

814
  <chapter id="ch04">
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
  <title>Advanced Concepts</title>
  <sect1 id="dynamic_update">
    <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>

    <para>Updating of secure zones (zones using DNSSEC) is modelled
    after the <emphasis>simple-secure-update</emphasis> proposal, a
    work in progress in the DNS Extensions working group of the IETF.
    (See <ulink
    url="http://www.ietf.org/html.charters/dnsext-charter.html">http://www.ietf.org/html.charters/dnsext-charter.html</ulink>
    for information about the DNS Extensions working group.) SIG and
    NXT records affected by updates are automatically regenerated by
    the server using an online zone key. Update authorization is based
    on transaction signatures and an explicit server policy.</para>

    <para>The zone files of dynamic zones must not be edited by hand.
    The zone file on disk at any given time may not contain the latest
    changes performed by dynamic update. The zone file is written to
    disk only periodically, and changes that have occurred since the
    zone file was last written to disk are stored only in the zone's
    journal (<filename>.jnl</filename>) file. <acronym>BIND</acronym> 9 currently does
    not update the zone file when it exits as <acronym>BIND</acronym> 8 does, so editing
    the zone file manually is unsafe even when the server has been
    shut down. </para>
  </sect1>
  <sect1 id="incremental_zone_transfers">
    <title>Incremental Zone Transfers (IXFR)</title>

    <para>The incremental zone transfer (IXFR) protocol is a way for
    slave servers to transfer only changed data, instead of having to
    transfer the entire zone. The IXFR protocol is documented in RFC
855
    1995. See <xref linkend="proposed_standards"/></para>
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902

<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>
<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>
903
<para>To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
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>
        <simpara>Look up any hostnames in the <systemitem class="systemname">site1</systemitem> and 
<systemitem class="systemname">site2.example.com</systemitem> zones.</simpara></listitem>
<listitem>
        <simpara>Look up any hostnames in the <systemitem class="systemname">site1.internal</systemitem> and 
<systemitem class="systemname">site2.internal</systemitem> domains.</simpara></listitem>
<listitem>
        <simpara>Look up any hostnames on the Internet.</simpara></listitem>
<listitem>
        <simpara>Exchange mail with internal AND external people.</simpara></listitem></itemizedlist>
<para>Hosts on the Internet will be able to:</para>
<itemizedlist><listitem>
        <simpara>Look up any hostnames in the <systemitem class="systemname">site1</systemitem> and 
948
<systemitem class="systemname">site2.example.com</systemitem> zones.</simpara></listitem>
949
950
951
952
953
954
<listitem>
        <simpara>Exchange mail with anyone in the <systemitem class="systemname">site1</systemitem> and 
<systemitem class="systemname">site2.example.com</systemitem> zones.</simpara></listitem></itemizedlist>

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

<para>Internal DNS server config:</para>
<programlisting>
960
961
962

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

963
acl externals { <varname>bastion-ips-go-here</varname>; };
964

965
966
967
968
options {
    ...
    ...
    forward only;
969
970
971
972
973
974
    forwarders { 				// forward to external servers
    	<varname>bastion-ips-go-here</varname>; 
    };
    allow-transfer { none; };			// sample allow-transfer (no one)
    allow-query { internals; externals; };	// restrict query access
    allow-recursion { internals; };		// restrict recursion
975
976
977
    ...
    ...
};
978
979

zone "site1.example.com" { 			// sample slave zone
980
981
  type master;
  file "m/site1.example.com";
982
983
  forwarders { }; 				// do normal iterative
						// resolution (do not forward)
984
985
986
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
987

988
989
990
991
992
993
994
995
zone "site2.example.com" {
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
996

997
998
999
1000
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
For faster browsing, not all history is shown. View entire blame