Bv9ARM.ch04.html 34.4 KB
Newer Older
Mark Andrews's avatar
regen  
Mark Andrews committed
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 3 4
<HTML
><HEAD
><TITLE
Andreas Gustafsson's avatar
Andreas Gustafsson committed
5
>Advanced DNS Features</TITLE
6 7
><META
NAME="GENERATOR"
Mark Andrews's avatar
regen  
Mark Andrews committed
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
9
REL="HOME"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
10
TITLE="BIND 9 Administrator Reference Manual"
11 12
HREF="Bv9ARM.html"><LINK
REL="PREVIOUS"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
13
TITLE="Name Server Configuration"
14 15 16 17 18
HREF="Bv9ARM.ch03.html"><LINK
REL="NEXT"
TITLE="The BIND 9 Lightweight Resolver"
HREF="Bv9ARM.ch05.html"></HEAD
><BODY
Andreas Gustafsson's avatar
Andreas Gustafsson committed
19
CLASS="chapter"
20 21 22 23 24 25 26 27
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
Mark Andrews's avatar
Mark Andrews committed
28
SUMMARY="Header navigation table"
29 30 31 32 33 34 35 36
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
37
>BIND 9 Administrator Reference Manual</TH
38 39 40 41 42 43 44 45
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch03.html"
Mark Andrews's avatar
Mark Andrews committed
46
ACCESSKEY="P"
47 48 49 50 51 52 53 54 55 56 57 58 59
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch05.html"
Mark Andrews's avatar
Mark Andrews committed
60
ACCESSKEY="N"
61 62 63 64 65 66 67 68 69 70 71 72
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="ch04"
Mark Andrews's avatar
regen  
Mark Andrews committed
73 74
></A
>Chapter 4. Advanced DNS Features</H1
75 76 77 78 79 80 81 82 83
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>4.1. <A
Andreas Gustafsson's avatar
Andreas Gustafsson committed
84 85 86 87 88
HREF="Bv9ARM.ch04.html#notify"
>Notify</A
></DT
><DT
>4.2. <A
89 90 91 92
HREF="Bv9ARM.ch04.html#dynamic_update"
>Dynamic Update</A
></DT
><DT
Andreas Gustafsson's avatar
Andreas Gustafsson committed
93
>4.3. <A
94 95 96 97
HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
>Incremental Zone Transfers (IXFR)</A
></DT
><DT
Andreas Gustafsson's avatar
Andreas Gustafsson committed
98
>4.4. <A
Mark Andrews's avatar
regen  
Mark Andrews committed
99
HREF="Bv9ARM.ch04.html#AEN769"
100 101 102
>Split DNS</A
></DT
><DT
Andreas Gustafsson's avatar
Andreas Gustafsson committed
103
>4.5. <A
104 105 106 107
HREF="Bv9ARM.ch04.html#tsig"
>TSIG</A
></DT
><DT
Andreas Gustafsson's avatar
Andreas Gustafsson committed
108
>4.6. <A
Mark Andrews's avatar
regen  
Mark Andrews committed
109
HREF="Bv9ARM.ch04.html#AEN929"
110 111 112
>TKEY</A
></DT
><DT
Andreas Gustafsson's avatar
Andreas Gustafsson committed
113
>4.7. <A
Mark Andrews's avatar
regen  
Mark Andrews committed
114
HREF="Bv9ARM.ch04.html#AEN944"
115 116 117
>SIG(0)</A
></DT
><DT
Andreas Gustafsson's avatar
Andreas Gustafsson committed
118
>4.8. <A
119 120 121 122
HREF="Bv9ARM.ch04.html#DNSSEC"
>DNSSEC</A
></DT
><DT
Andreas Gustafsson's avatar
Andreas Gustafsson committed
123
>4.9. <A
Mark Andrews's avatar
regen  
Mark Andrews committed
124
HREF="Bv9ARM.ch04.html#AEN1013"
Mark Andrews's avatar
regen  
Mark Andrews committed
125
>IPv6 Support in <ACRONYM
126
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
127
>BIND</ACRONYM
128 129 130 131 132 133 134 135 136
> 9</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
Andreas Gustafsson's avatar
Andreas Gustafsson committed
137 138 139 140
NAME="notify"
>4.1. Notify</A
></H1
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
141
><ACRONYM
Andreas Gustafsson's avatar
Andreas Gustafsson committed
142
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
143
>DNS</ACRONYM
Andreas Gustafsson's avatar
Andreas Gustafsson committed
144 145 146 147 148 149 150 151 152
> NOTIFY is a mechanism that allows master
servers to notify their slave servers of changes to a zone's data. In
response to a <B
CLASS="command"
>NOTIFY</B
> 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.</P
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
153
><ACRONYM
Andreas Gustafsson's avatar
Andreas Gustafsson committed
154
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
155
>DNS</ACRONYM
Andreas Gustafsson's avatar
Andreas Gustafsson committed
156 157 158 159 160 161 162 163 164 165 166
>
For more information about
<B
CLASS="command"
>NOTIFY</B
>, see the description of the
<B
CLASS="command"
>notify</B
> option in <A
HREF="Bv9ARM.ch06.html#boolean_options"
Mark Andrews's avatar
Mark Andrews committed
167
>Section 6.2.16.1</A
Andreas Gustafsson's avatar
Andreas Gustafsson committed
168 169 170 171 172 173 174
> and
the description of the zone option <B
CLASS="command"
>also-notify</B
> in
<A
HREF="Bv9ARM.ch06.html#zone_transfers"
Mark Andrews's avatar
Mark Andrews committed
175
>Section 6.2.16.7</A
Andreas Gustafsson's avatar
Andreas Gustafsson committed
176 177 178 179 180 181 182 183 184 185 186 187
>.  The <B
CLASS="command"
>NOTIFY</B
>
protocol is specified in RFC 1996.
</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
188
NAME="dynamic_update"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
189
>4.2. Dynamic Update</A
190 191
></H1
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
192 193 194
>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
195 196
    in RFC 2136.</P
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
197
>Dynamic update is enabled by
198 199 200 201 202 203 204 205 206 207 208 209 210
    including an <B
CLASS="command"
>allow-update</B
> or
    <B
CLASS="command"
>update-policy</B
> clause in the
    <B
CLASS="command"
>zone</B
> statement.</P
><P
211
>Updating of secure zones (zones using DNSSEC) follows
Mark Andrews's avatar
regen  
Mark Andrews committed
212
    RFC 3007: RRSIG and NSEC records affected by updates are automatically
213 214
    regenerated by the server using an online zone key.
    Update authorization is based
215
    on transaction signatures and an explicit server policy.</P
216 217 218 219 220 221
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="journal"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
222
>4.2.1. The journal file</A
223
></H2
224
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
225 226 227 228 229
>All changes made to a zone using dynamic update are stored
    in the zone's journal file.  This file is automatically created
    by the server when when the first dynamic update takes place.
    The name of the journal file is formed by appending the extension
    <TT
230 231
CLASS="filename"
>.jnl</TT
Mark Andrews's avatar
regen  
Mark Andrews committed
232 233
> to the name of the corresponding zone
    file unless specifically overridden.  The journal file is in a
234 235 236 237 238 239
    binary format and should not be edited manually.</P
><P
>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
Andreas Gustafsson's avatar
Andreas Gustafsson committed
240 241
    zone is updated frequently.  Instead, the dump is delayed by
    up to 15 minutes, allowing additional updates to take place.</P
242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257
><P
>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.</P
><P
>Changes that result from incoming incremental zone transfers are also
    journalled in a similar way.</P
><P
>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 <B
CLASS="command"
>rndc stop</B
>.</P
258 259
><P
>If you have to make changes to a dynamic zone
Brian Wellington's avatar
regen  
Brian Wellington committed
260 261 262
    manually, the following procedure will work: Disable dynamic updates
    to the zone using
    <B
263
CLASS="command"
Mark Andrews's avatar
regen  
Mark Andrews committed
264
>rndc freeze <VAR
Brian Wellington's avatar
regen  
Brian Wellington committed
265
CLASS="replaceable"
Mark Andrews's avatar
regen  
Mark Andrews committed
266
>zone</VAR
Brian Wellington's avatar
regen  
Brian Wellington committed
267 268 269
></B
>.
    This will also remove the zone's <TT
270 271
CLASS="filename"
>.jnl</TT
Brian Wellington's avatar
regen  
Brian Wellington committed
272 273 274 275
> file
    and update the master file.  Edit the zone file.  Run
    <B
CLASS="command"
Mark Andrews's avatar
regen  
Mark Andrews committed
276
>rndc unfreeze <VAR
Brian Wellington's avatar
regen  
Brian Wellington committed
277
CLASS="replaceable"
Mark Andrews's avatar
regen  
Mark Andrews committed
278
>zone</VAR
Brian Wellington's avatar
regen  
Brian Wellington committed
279
></B
280
>
Brian Wellington's avatar
regen  
Brian Wellington committed
281
    to reload the changed zone and re-enable dynamic updates.</P
282
></DIV
283
></DIV
284 285 286 287 288 289
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="incremental_zone_transfers"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
290
>4.3. Incremental Zone Transfers (IXFR)</A
291 292 293
></H1
><P
>The incremental zone transfer (IXFR) protocol is a way for
Andreas Gustafsson's avatar
Andreas Gustafsson committed
294
slave servers to transfer only changed data, instead of having to
Andreas Gustafsson's avatar
Andreas Gustafsson committed
295
transfer the entire zone. The IXFR protocol is specified in RFC
Andreas Gustafsson's avatar
Andreas Gustafsson committed
296
1995. See <A
297
HREF="Bv9ARM.ch09.html#proposed_standards"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
298
>Proposed Standards</A
Brian Wellington's avatar
Brian Wellington committed
299
>.</P
300
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
301
>When acting as a master, <ACRONYM
302
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
303
>BIND</ACRONYM
Andreas Gustafsson's avatar
Andreas Gustafsson committed
304 305
> 9
supports IXFR for those zones
306 307
where the necessary change history information is available. These
include master zones maintained by dynamic update and slave zones
Andreas Gustafsson's avatar
Andreas Gustafsson committed
308 309 310 311 312 313 314
whose data was obtained by IXFR.  For manually maintained master
zones, and for slave zones obtained by performing a full zone 
transfer (AXFR), IXFR is supported only if the option
<B
CLASS="command"
>ixfr-from-differences</B
> is set
Mark Andrews's avatar
regen  
Mark Andrews committed
315
to <KBD
Andreas Gustafsson's avatar
Andreas Gustafsson committed
316
CLASS="userinput"
Mark Andrews's avatar
regen  
Mark Andrews committed
317
>yes</KBD
Andreas Gustafsson's avatar
Andreas Gustafsson committed
318 319
>.
</P
320
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
321
>When acting as a slave, <ACRONYM
322
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
323
>BIND</ACRONYM
Andreas Gustafsson's avatar
Andreas Gustafsson committed
324 325
> 9 will 
attempt to use IXFR unless
326 327 328 329 330 331 332 333 334 335 336 337 338 339 340
it is explicitly disabled. For more information about disabling
IXFR, see the description of the <B
CLASS="command"
>request-ixfr</B
> clause
of the <B
CLASS="command"
>server</B
> statement.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
341
NAME="AEN769"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
342
>4.4. Split DNS</A
343 344
></H1
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
345
>Setting up different views, or visibility, of the DNS space to
Mark Andrews's avatar
Mark Andrews committed
346 347 348
internal and external resolvers is usually referred to as a <SPAN
CLASS="emphasis"
><I
349 350 351
CLASS="emphasis"
>Split
DNS</I
Mark Andrews's avatar
Mark Andrews committed
352
></SPAN
353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370
> setup. There are several reasons an organization
would want to set up its DNS this way.</P
><P
>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.</P
><P
>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.</P
><P
>Here is an example of a split DNS setup:</P
><P
Mark Andrews's avatar
Mark Andrews committed
371 372 373
>Let's say a company named <SPAN
CLASS="emphasis"
><I
374 375
CLASS="emphasis"
>Example, Inc.</I
Mark Andrews's avatar
Mark Andrews committed
376
></SPAN
Andreas Gustafsson's avatar
Andreas Gustafsson committed
377
>
Mark Andrews's avatar
regen  
Mark Andrews committed
378
(<VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
379
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
380
>example.com</VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
381
>)
382 383 384 385
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.</P
><P
Mark Andrews's avatar
Mark Andrews committed
386 387
><SPAN
CLASS="emphasis"
388 389 390
><I
CLASS="emphasis"
>Example, Inc.</I
Mark Andrews's avatar
Mark Andrews committed
391
></SPAN
392 393 394 395 396 397 398
> 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.</P
><P
>In order to accomplish this, the company will set up two sets
Andreas Gustafsson's avatar
Andreas Gustafsson committed
399
of name servers. One set will be on the inside network (in the reserved
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
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.</P
><P
>The internal servers will be configured to forward all queries,
except queries for <TT
CLASS="filename"
>site1.internal</TT
>, <TT
CLASS="filename"
>site2.internal</TT
>, <TT
CLASS="filename"
>site1.example.com</TT
>,
and <TT
CLASS="filename"
>site2.example.com</TT
>, to the servers in the
DMZ. These internal servers will have complete sets of information
for <TT
CLASS="filename"
>site1.example.com</TT
>, <TT
CLASS="filename"
>site2.example.com</TT
Mark Andrews's avatar
Mark Andrews committed
425 426 427
>,<SPAN
CLASS="emphasis"
><I
428 429
CLASS="emphasis"
> </I
Mark Andrews's avatar
Mark Andrews committed
430
></SPAN
431 432 433 434 435 436 437 438 439
><TT
CLASS="filename"
>site1.internal</TT
>,
and <TT
CLASS="filename"
>site2.internal</TT
>.</P
><P
440
>To protect the <TT
441
CLASS="filename"
442 443
>site1.internal</TT
> and <TT
444 445 446
CLASS="filename"
>site2.internal</TT
> domains,
Andreas Gustafsson's avatar
Andreas Gustafsson committed
447
the internal name servers must be configured to disallow all queries
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
to these domains from any external hosts, including the bastion
hosts.</P
><P
>The external servers, which are on the bastion hosts, will
be configured to serve the "public" version of the <TT
CLASS="filename"
>site1</TT
> and <TT
CLASS="filename"
>site2.example.com</TT
> zones.
This could include things such as the host records for public servers
(<TT
CLASS="filename"
>www.example.com</TT
> and <TT
CLASS="filename"
>ftp.example.com</TT
>),
and mail exchange (MX)  records (<TT
CLASS="filename"
>a.mx.example.com</TT
> and <TT
CLASS="filename"
>b.mx.example.com</TT
>).</P
><P
>In addition, the public <TT
CLASS="filename"
>site1</TT
> and <TT
CLASS="filename"
>site2.example.com</TT
> 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.</P
><P
>Here's an example of a wildcard MX record:</P
><PRE
CLASS="programlisting"
Mark Andrews's avatar
regen  
Mark Andrews committed
492
><VAR
493
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
494
>*   IN MX 10 external1.example.com.</VAR
495 496 497 498 499 500
></PRE
><P
>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
Andreas Gustafsson's avatar
Andreas Gustafsson committed
501
name servers for DNS resolution.</P
502 503 504 505 506 507
><P
>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.</P
><P
>In order for all this to work properly, internal clients will
Mark Andrews's avatar
Mark Andrews committed
508 509 510
need to be configured to query <SPAN
CLASS="emphasis"
><I
511 512
CLASS="emphasis"
>only</I
Mark Andrews's avatar
Mark Andrews committed
513
></SPAN
514
> the internal
Andreas Gustafsson's avatar
Andreas Gustafsson committed
515
name servers for DNS queries. This could also be enforced via selective
516 517
filtering on the network.</P
><P
Mark Andrews's avatar
Mark Andrews committed
518 519 520
>If everything has been set properly, <SPAN
CLASS="emphasis"
><I
521 522
CLASS="emphasis"
>Example, Inc.</I
Mark Andrews's avatar
Mark Andrews committed
523
></SPAN
524 525 526 527 528 529 530
>'s
internal clients will now be able to:</P
><P
></P
><UL
><LI
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
531
>Look up any hostnames in the <VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
532
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
533
>site1</VAR
534
> and 
Mark Andrews's avatar
regen  
Mark Andrews committed
535
<VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
536
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
537
>site2.example.com</VAR
538 539 540 541
> zones.</P
></LI
><LI
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
542
>Look up any hostnames in the <VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
543
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
544
>site1.internal</VAR
545
> and 
Mark Andrews's avatar
regen  
Mark Andrews committed
546
<VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
547
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
548
>site2.internal</VAR
549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566
> domains.</P
></LI
><LI
><P
>Look up any hostnames on the Internet.</P
></LI
><LI
><P
>Exchange mail with internal AND external people.</P
></LI
></UL
><P
>Hosts on the Internet will be able to:</P
><P
></P
><UL
><LI
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
567
>Look up any hostnames in the <VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
568
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
569
>site1</VAR
570
> and 
Mark Andrews's avatar
regen  
Mark Andrews committed
571
<VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
572
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
573
>site2.example.com</VAR
574
> zones.</P
575 576 577
></LI
><LI
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
578
>Exchange mail with anyone in the <VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
579
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
580
>site1</VAR
581
> and 
Mark Andrews's avatar
regen  
Mark Andrews committed
582
<VAR
Andreas Gustafsson's avatar
Andreas Gustafsson committed
583
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
584
>site2.example.com</VAR
585 586 587 588 589 590
> zones.</P
></LI
></UL
><P
>Here is an example configuration for the setup we just
    described above. Note that this is only configuration information;
591
    for information on how to configure your zone files, see <A
592 593 594 595 596 597 598
HREF="Bv9ARM.ch03.html#sample_configuration"
>Section 3.1</A
></P
><P
>Internal DNS server config:</P
><PRE
CLASS="programlisting"
599 600 601
>&#13;
acl internals { 172.16.72.0/24; 192.168.1.0/24; };

Mark Andrews's avatar
regen  
Mark Andrews committed
602
acl externals { <VAR
603
CLASS="varname"
Mark Andrews's avatar
regen  
Mark Andrews committed
604
>bastion-ips-go-here</VAR
605
>; };
606

607 608 609 610
options {
    ...
    ...
    forward only;
Andreas Gustafsson's avatar
Andreas Gustafsson committed
611
    forwarders {                                // forward to external servers
Mark Andrews's avatar
regen  
Mark Andrews committed
612
        <VAR
613
CLASS="varname"
Mark Andrews's avatar
regen  
Mark Andrews committed
614
>bastion-ips-go-here</VAR
615 616
>; 
    };
Andreas Gustafsson's avatar
Andreas Gustafsson committed
617 618 619
    allow-transfer { none; };                   // sample allow-transfer (no one)
    allow-query { internals; externals; };      // restrict query access
    allow-recursion { internals; };             // restrict recursion
620 621 622
    ...
    ...
};
623

Andreas Gustafsson's avatar
Andreas Gustafsson committed
624
zone "site1.example.com" {                      // sample master zone
625 626
  type master;
  file "m/site1.example.com";
Andreas Gustafsson's avatar
Andreas Gustafsson committed
627 628
  forwarders { };                               // do normal iterative
                                                // resolution (do not forward)
629 630 631
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
632

Andreas Gustafsson's avatar
Andreas Gustafsson committed
633
zone "site2.example.com" {                      // sample slave zone
634 635 636 637 638 639 640
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
641

642 643 644 645 646 647 648
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};
649

650 651 652 653 654 655 656 657 658 659 660 661 662
zone "site2.internal" {
  type slave;
  file "s/site2.internal";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals };
  allow-transfer { internals; }
};
</PRE
><P
>External (bastion host) DNS server config:</P
><PRE
CLASS="programlisting"
663 664
>&#13;acl internals { 172.16.72.0/24; 192.168.1.0/24; };

665
acl externals { bastion-ips-go-here; };
666

667 668 669
options {
  ...
  ...
Andreas Gustafsson's avatar
Andreas Gustafsson committed
670
  allow-transfer { none; };                     // sample allow-transfer (no one)
Mark Andrews's avatar
regen  
Mark Andrews committed
671 672
  allow-query { any; };  			// default query access
  allow-query-cache { internals; externals; };  // restrict cache access
Andreas Gustafsson's avatar
Andreas Gustafsson committed
673
  allow-recursion { internals; externals; };    // restrict recursion
674 675 676
  ...
  ...
};
677

Andreas Gustafsson's avatar
Andreas Gustafsson committed
678
zone "site1.example.com" {                      // sample slave zone
679 680 681 682
  type master;
  file "m/site1.foo.com";
  allow-transfer { internals; externals; };
};
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
zone "site2.example.com" {
  type slave;
  file "s/site2.foo.com";
  masters { another_bastion_host_maybe; };
  allow-transfer { internals; externals; }
};
</PRE
><P
>In the <TT
CLASS="filename"
>resolv.conf</TT
> (or equivalent) on
the bastion host(s):</P
><PRE
CLASS="programlisting"
>&#13;search ...
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4
</PRE
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="tsig"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
711
>4.5. TSIG</A
712 713 714
></H1
><P
>This is a short guide to setting up Transaction SIGnatures
Mark Andrews's avatar
regen  
Mark Andrews committed
715
(TSIG) based transaction security in <ACRONYM
716
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
717
>BIND</ACRONYM
718 719 720
>. It describes changes
to the configuration file as well as what changes are required for
different features, including the process of creating transaction
Mark Andrews's avatar
regen  
Mark Andrews committed
721
keys and using transaction signatures with <ACRONYM
722
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
723
>BIND</ACRONYM
724 725
>.</P
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
726
><ACRONYM
727
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
728
>BIND</ACRONYM
729 730
> primarily supports TSIG for server to server communication.
This includes zone transfer, notify, and recursive query messages.
Mark Andrews's avatar
regen  
Mark Andrews committed
731
Resolvers based on newer versions of <ACRONYM
732
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
733
>BIND</ACRONYM
734 735 736 737 738
> 8 have limited support
for TSIG.</P
><P
>TSIG might be most useful for dynamic update. A primary
    server for a dynamic zone should use access control to control
Andreas Gustafsson's avatar
Andreas Gustafsson committed
739 740 741
    updates, but IP-based access control is insufficient.
    The cryptographic access control provided by TSIG
    is far superior. The <B
742 743 744
CLASS="command"
>nsupdate</B
>
Mark Andrews's avatar
regen  
Mark Andrews committed
745
    program supports TSIG via the <VAR
746
CLASS="option"
Mark Andrews's avatar
regen  
Mark Andrews committed
747
>-k</VAR
748
> and
Mark Andrews's avatar
regen  
Mark Andrews committed
749
    <VAR
750
CLASS="option"
Mark Andrews's avatar
regen  
Mark Andrews committed
751
>-y</VAR
752 753 754 755 756 757
> command line options.</P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
758
NAME="AEN860"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
759
>4.5.1. Generate Shared Keys for Each Pair of Hosts</A
760 761
></H2
><P
Mark Andrews's avatar
Mark Andrews committed
762 763 764
>A shared secret is generated to be shared between <SPAN
CLASS="emphasis"
><I
765 766
CLASS="emphasis"
>host1</I
Mark Andrews's avatar
Mark Andrews committed
767 768 769 770
></SPAN
> and <SPAN
CLASS="emphasis"
><I
771 772
CLASS="emphasis"
>host2</I
Mark Andrews's avatar
Mark Andrews committed
773
></SPAN
774 775 776 777 778 779 780 781
>.
An arbitrary key name is chosen: "host1-host2.". The key name must
be the same on both hosts.</P
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
782
NAME="AEN865"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
783
>4.5.1.1. Automatic Generation</A
784 785 786 787 788 789 790 791
></H3
><P
>The following command will generate a 128 bit (16 byte) HMAC-MD5
key as described above. Longer keys are better, but shorter keys
are easier to read. Note that the maximum key length is 512 bits;
keys longer than that will be digested with MD5 to produce a 128
bit key.</P
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
792
><KBD
793
CLASS="userinput"
Mark Andrews's avatar
regen  
Mark Andrews committed
794
>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</KBD
795 796 797 798 799 800 801
></P
><P
>The key is in the file <TT
CLASS="filename"
>Khost1-host2.+157+00000.private</TT
>.
Nothing directly uses this file, but the base-64 encoded string
Mark Andrews's avatar
regen  
Mark Andrews committed
802
following "<VAR
803
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
804
>Key:</VAR
805 806 807 808 809 810
>"
can be extracted from the file and used as a shared secret:</P
><PRE
CLASS="programlisting"
>Key: La/E5CjG9O+os1jq0a2jdA==</PRE
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
811
>The string "<VAR
812
CLASS="literal"
Mark Andrews's avatar
regen  
Mark Andrews committed
813
>La/E5CjG9O+os1jq0a2jdA==</VAR
814 815 816 817 818 819 820 821
>" can
be used as the shared secret.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
822
NAME="AEN876"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
823
>4.5.1.2. Manual Generation</A
824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842
></H3
><P
>The shared secret is simply a random sequence of bits, encoded
in base-64. Most ASCII strings are valid base-64 strings (assuming
the length is a multiple of 4 and only valid characters are used),
so the shared secret can be manually generated.</P
><P
>Also, a known string can be run through <B
CLASS="command"
>mmencode</B
> or
a similar program to generate base-64 encoded data.</P
></DIV
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
843
NAME="AEN881"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
844
>4.5.2. Copying the Shared Secret to Both Machines</A
845 846 847 848 849 850 851 852 853 854
></H2
><P
>This is beyond the scope of DNS. A secure transport mechanism
should be used. This could be secure FTP, ssh, telephone, etc.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
855
NAME="AEN884"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
856
>4.5.3. Informing the Servers of the Key's Existence</A
857 858
></H2
><P
Mark Andrews's avatar
Mark Andrews committed
859 860 861
>Imagine <SPAN
CLASS="emphasis"
><I
862 863
CLASS="emphasis"
>host1</I
Mark Andrews's avatar
Mark Andrews committed
864 865 866 867
></SPAN
> and <SPAN
CLASS="emphasis"
><I
868 869
CLASS="emphasis"
>host 2</I
Mark Andrews's avatar
Mark Andrews committed
870
></SPAN
871 872 873 874 875 876 877 878 879 880 881 882 883
> are
both servers. The following is added to each server's <TT
CLASS="filename"
>named.conf</TT
> file:</P
><PRE
CLASS="programlisting"
>&#13;key host1-host2. {
  algorithm hmac-md5;
  secret "La/E5CjG9O+os1jq0a2jdA==";
};
</PRE
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
884
>The algorithm, hmac-md5, is the only one supported by <ACRONYM
885
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
886
>BIND</ACRONYM
887 888 889 890 891 892 893 894 895 896 897 898 899 900
>.
The secret is the one generated above. Since this is a secret, it
is recommended that either <TT
CLASS="filename"
>named.conf</TT
> be non-world
readable, or the key directive be added to a non-world readable
file that is included by <TT
CLASS="filename"
>named.conf</TT
>.</P
><P
>At this point, the key is recognized. This means that if the
server receives a message signed by this key, it can verify the
Andreas Gustafsson's avatar
Andreas Gustafsson committed
901 902
signature. If the signature is successfully verified, the
response is signed by the same key.</P
903 904 905 906 907 908
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
909
NAME="AEN896"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
910
>4.5.4. Instructing the Server to Use the Key</A
911 912 913 914 915 916 917
></H2
><P
>Since keys are shared between two hosts only, the server must
be told when keys are to be used. The following is added to the <TT
CLASS="filename"
>named.conf</TT
> file
Mark Andrews's avatar
Mark Andrews committed
918 919 920
for <SPAN
CLASS="emphasis"
><I
921 922
CLASS="emphasis"
>host1</I
Mark Andrews's avatar
Mark Andrews committed
923 924 925 926
></SPAN
>, if the IP address of <SPAN
CLASS="emphasis"
><I
927 928
CLASS="emphasis"
>host2</I
Mark Andrews's avatar
Mark Andrews committed
929
></SPAN
930 931 932 933 934 935 936 937 938 939 940 941 942
> is
10.1.2.3:</P
><PRE
CLASS="programlisting"
>&#13;server 10.1.2.3 {
  keys { host1-host2. ;};
};
</PRE
><P
>Multiple keys may be present, but only the first is used.
This directive does not contain any secrets, so it may be in a world-readable
file.</P
><P
Mark Andrews's avatar
Mark Andrews committed
943 944 945
>If <SPAN
CLASS="emphasis"
><I
946 947
CLASS="emphasis"
>host1</I
Mark Andrews's avatar
Mark Andrews committed
948
></SPAN
Andreas Gustafsson's avatar
Andreas Gustafsson committed
949
> sends a message that is a request
Mark Andrews's avatar
Mark Andrews committed
950 951 952
to that address, the message will be signed with the specified key. <SPAN
CLASS="emphasis"
><I
953 954
CLASS="emphasis"
>host1</I
Mark Andrews's avatar
Mark Andrews committed
955
></SPAN
956 957 958 959
> will
expect any responses to signed messages to be signed with the same
key.</P
><P
Mark Andrews's avatar
Mark Andrews committed
960 961 962
>A similar statement must be present in <SPAN
CLASS="emphasis"
><I
963 964
CLASS="emphasis"
>host2</I
Mark Andrews's avatar
Mark Andrews committed
965
></SPAN
966
>'s
Mark Andrews's avatar
Mark Andrews committed
967 968 969
configuration file (with <SPAN
CLASS="emphasis"
><I
970 971
CLASS="emphasis"
>host1</I
Mark Andrews's avatar
Mark Andrews committed
972 973 974 975
></SPAN
>'s address) for <SPAN
CLASS="emphasis"
><I
976 977
CLASS="emphasis"
>host2</I
Mark Andrews's avatar
Mark Andrews committed
978
></SPAN
979
> to
Mark Andrews's avatar
Mark Andrews committed
980 981 982
sign request messages to <SPAN
CLASS="emphasis"
><I
983 984
CLASS="emphasis"
>host1</I
Mark Andrews's avatar
Mark Andrews committed
985
></SPAN
986 987 988 989 990 991 992
>.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
993
NAME="AEN912"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
994
>4.5.5. TSIG Key Based Access Control</A
995 996
></H2
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
997
><ACRONYM
998
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
999
>BIND</ACRONYM
1000 1001 1002 1003
> allows IP addresses and ranges to be specified in ACL
definitions and
<B
CLASS="command"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1004 1005
>allow-{ query | transfer | update }</B
> directives.
1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024
This has been extended to allow TSIG keys also. The above key would
be denoted <B
CLASS="command"
>key host1-host2.</B
></P
><P
>An example of an allow-update directive would be:</P
><PRE
CLASS="programlisting"
>&#13;allow-update { key host1-host2. ;};
</PRE
><P
>This allows dynamic updates to succeed only if the request
      was signed by a key named
      "<B
CLASS="command"
>host1-host2.</B
>".</P
><P
1025
>You may want to read about the more
1026 1027 1028
      powerful <B
CLASS="command"
>update-policy</B
1029
> statement in <A
1030
HREF="Bv9ARM.ch06.html#dynamic_update_policies"
Mark Andrews's avatar
Mark Andrews committed
1031
>Section 6.2.24.4</A
1032 1033 1034 1035 1036 1037 1038
>.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
1039
NAME="AEN925"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1040
>4.5.6. Errors</A
1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067
></H2
><P
>The processing of TSIG signed messages can result in
      several errors. If a signed message is sent to a non-TSIG aware
      server, a FORMERR will be returned, since the server will not
      understand the record. This is a result of misconfiguration,
      since the server must be explicitly configured to send a TSIG
      signed message to a specific server.</P
><P
>If a TSIG aware server receives a message signed by an
      unknown key, the response will be unsigned with the TSIG
      extended error code set to BADKEY. If a TSIG aware server
      receives a message with a signature that does not validate, the
      response will be unsigned with the TSIG extended error code set
      to BADSIG. If a TSIG aware server receives a message with a time
      outside of the allowed range, the response will be signed with
      the TSIG extended error code set to BADTIME, and the time values
      will be adjusted so that the response can be successfully
      verified. In any of these cases, the message's rcode is set to
      NOTAUTH.</P
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
1068
NAME="AEN929"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1069
>4.6. TKEY</A
1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080
></H1
><P
><B
CLASS="command"
>TKEY</B
> is a mechanism for automatically
    generating a shared secret between two hosts.  There are several
    "modes" of <B
CLASS="command"
>TKEY</B
> that specify how the key is
Mark Andrews's avatar
regen  
Mark Andrews committed
1081
    generated or assigned.  <ACRONYM
1082
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
1083
>BIND</ACRONYM
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1084 1085
> 9
    implements only one of these modes,
1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134
    the Diffie-Hellman key exchange.  Both hosts are required to have
    a Diffie-Hellman KEY record (although this record is not required
    to be present in a zone).  The <B
CLASS="command"
>TKEY</B
> process
    must use signed messages, signed either by TSIG or SIG(0).  The
    result of <B
CLASS="command"
>TKEY</B
> is a shared secret that can be
    used to sign messages with TSIG.  <B
CLASS="command"
>TKEY</B
> can also
    be used to delete shared secrets that it had previously
    generated.</P
><P
>The <B
CLASS="command"
>TKEY</B
> process is initiated by a client
    or server by sending a signed <B
CLASS="command"
>TKEY</B
> query
    (including any appropriate KEYs) to a TKEY-aware server.  The
    server response, if it indicates success, will contain a
    <B
CLASS="command"
>TKEY</B
> record and any appropriate keys.  After
    this exchange, both participants have enough information to
    determine the shared secret; the exact process depends on the
    <B
CLASS="command"
>TKEY</B
> mode.  When using the Diffie-Hellman
    <B
CLASS="command"
>TKEY</B
> mode, Diffie-Hellman keys are exchanged,
    and the shared secret is derived by both participants.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
Mark Andrews's avatar
regen  
Mark Andrews committed
1135
NAME="AEN944"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1136
>4.7. SIG(0)</A
1137 1138
></H1
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
1139
><ACRONYM
1140
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
1141
>BIND</ACRONYM
Brian Wellington's avatar
regen  
Brian Wellington committed
1142 1143 1144 1145 1146
> 9 partially supports DNSSEC SIG(0)
    transaction signatures as specified in RFC 2535 and RFC2931.  SIG(0)
    uses public/private keys to authenticate messages.  Access control
    is performed in the same manner as TSIG keys; privileges can be
    granted or denied based on the key name.</P
1147 1148 1149 1150 1151
><P
>When a SIG(0) signed message is received, it will only be
    verified if the key is known and trusted by the server; the server
    will not attempt to locate and/or validate the key.</P
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1152 1153 1154
>SIG(0) signing of multiple-message TCP streams is not
    supported.</P
><P
Mark Andrews's avatar
regen  
Mark Andrews committed
1155
>The only tool shipped with <ACRONYM
1156
CLASS="acronym"
Mark Andrews's avatar
regen  
Mark Andrews committed
1157
>BIND</ACRONYM
Brian Wellington's avatar
regen  
Brian Wellington committed
1158 1159 1160 1161 1162
> 9 that
    generates SIG(0) signed messages is <B
CLASS="command"
>nsupdate</B
>.</P
1163 1164 1165 1166 1167 1168 1169
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="DNSSEC"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1170
>4.8. DNSSEC</A
1171 1172 1173
></H1
><P
>Cryptographic authentication of DNS information is possible
Mark Andrews's avatar
Mark Andrews committed
1174 1175