Bv9ARM.ch04.html 39.6 KB
Newer Older
1 2 3 4 5 6
<HTML
><HEAD
><TITLE
>Advanced Concepts</TITLE
><META
NAME="GENERATOR"
7
CONTENT="Modular DocBook HTML Stylesheet Version 1.61
Andreas Gustafsson's avatar
Andreas Gustafsson committed
8
"><LINK
9
REL="HOME"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
10
TITLE="BIND 9 Administrator Reference Manual"
11 12 13 14 15 16 17 18
HREF="Bv9ARM.html"><LINK
REL="PREVIOUS"
TITLE="Nameserver Configuration"
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 28 29 30 31 32 33 34 35
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
36
>BIND 9 Administrator Reference Manual</TH
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
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch03.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch05.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="ch04"
>Chapter 4. Advanced Concepts</A
></H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>4.1. <A
HREF="Bv9ARM.ch04.html#dynamic_update"
>Dynamic Update</A
></DT
><DT
>4.2. <A
HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
>Incremental Zone Transfers (IXFR)</A
></DT
><DT
>4.3. <A
91
HREF="Bv9ARM.ch04.html#AEN714"
92 93 94 95 96 97 98 99 100
>Split DNS</A
></DT
><DT
>4.4. <A
HREF="Bv9ARM.ch04.html#tsig"
>TSIG</A
></DT
><DT
>4.5. <A
101
HREF="Bv9ARM.ch04.html#AEN874"
102 103 104 105
>TKEY</A
></DT
><DT
>4.6. <A
106
HREF="Bv9ARM.ch04.html#AEN889"
107 108 109 110 111 112 113 114 115
>SIG(0)</A
></DT
><DT
>4.7. <A
HREF="Bv9ARM.ch04.html#DNSSEC"
>DNSSEC</A
></DT
><DT
>4.8. <A
116
HREF="Bv9ARM.ch04.html#AEN974"
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 143 144 145 146 147 148 149 150 151
>IPv6 Support in <SPAN
CLASS="acronym"
>BIND</SPAN
> 9</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="dynamic_update"
>4.1. Dynamic Update</A
></H1
><P
>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.</P
><P
>Dynamic update is enabled on a zone-by-zone basis, by
    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
152 153 154 155
>Updating of secure zones (zones using DNSSEC) follows
    RFC 3007: SIG and NXT records affected by updates are automatically
    regenerated by the server using an online zone key.
    Update authorization is based
156
    on transaction signatures and an explicit server policy.</P
157 158 159 160 161 162 163 164
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="journal"
>4.1.1. The journal file</A
></H2
165
><P
166 167 168 169 170
>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
171 172
CLASS="filename"
>.jnl</TT
173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
> to the
    name of the corresponding zone file.  The journal file is in a
    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
    zone is updated frequently.  Instead, the dump is delayed by 15
    minutes, allowing additional updates to take place.</P
><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
199 200 201 202 203 204 205 206 207 208 209 210 211 212
><P
>If you have to make changes to a dynamic zone
    manually, the following procedure will work: Shut down
    the server using <B
CLASS="command"
>rndc stop</B
> (sending a signal
    or using <B
CLASS="command"
>rndc halt</B
> is <I
CLASS="emphasis"
>not</I
>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
213 214
    sufficient). Wait for the server to exit,
    then <I
215 216 217 218 219 220 221 222 223 224 225
CLASS="emphasis"
>remove</I
> the zone's 
    <TT
CLASS="filename"
>.jnl</TT
> file, edit the zone file,
    and restart the server.  Removing the <TT
CLASS="filename"
>.jnl</TT
>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
226
    file is necessary because the manual edits will not be
227 228
    present in the journal, rendering it inconsistent with the
    contents of the zone file.</P
229
></DIV
230
></DIV
231 232 233 234 235 236 237 238 239 240 241 242
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="incremental_zone_transfers"
>4.2. Incremental Zone Transfers (IXFR)</A
></H1
><P
>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
243 244
    1995. See <A
HREF="Bv9ARM.ch09.html#proposed_standards"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
245
>Proposed Standards</A
Brian Wellington's avatar
Brian Wellington committed
246
>.</P
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
><P
>When acting as a master, <SPAN
CLASS="acronym"
>BIND</SPAN
> 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).</P
><P
>When acting as a slave, <SPAN
CLASS="acronym"
>BIND</SPAN
> 9 will attempt to use IXFR unless
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
277
NAME="AEN714"
278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359
>4.3. Split DNS</A
></H1
><P
>Setting up different views, or visibility, of DNS space to
internal and external resolvers is usually referred to as a <I
CLASS="emphasis"
>Split
DNS</I
> 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
>Let's say a company named <I
CLASS="emphasis"
>Example, Inc.</I
> (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.</P
><P
><I
CLASS="emphasis"
>Example, Inc.</I
> 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
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.</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
>,<I
CLASS="emphasis"
> </I
><TT
CLASS="filename"
>site1.internal</TT
>,
and <TT
CLASS="filename"
>site2.internal</TT
>.</P
><P
360
>To protect the <TT
361
CLASS="filename"
362 363
>site1.internal</TT
> and <TT
364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444
CLASS="filename"
>site2.internal</TT
> domains,
the internal nameservers must be configured to disallow all queries
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"
><TT
CLASS="literal"
>*   IN MX 10 external1.example.com.</TT
></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
nameservers for DNS resolution.</P
><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
need to be configured to query <I
CLASS="emphasis"
>only</I
> the internal
nameservers for DNS queries. This could also be enforced via selective
filtering on the network.</P
><P
>If everything has been set properly, <I
CLASS="emphasis"
>Example, Inc.</I
>'s
internal clients will now be able to:</P
><P
></P
><UL
><LI
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
445 446 447
>Look up any hostnames in the <TT
CLASS="literal"
>site1</TT
448
> and 
Andreas Gustafsson's avatar
Andreas Gustafsson committed
449 450 451
<TT
CLASS="literal"
>site2.example.com</TT
452 453 454 455
> zones.</P
></LI
><LI
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
456 457 458
>Look up any hostnames in the <TT
CLASS="literal"
>site1.internal</TT
459
> and 
Andreas Gustafsson's avatar
Andreas Gustafsson committed
460 461 462
<TT
CLASS="literal"
>site2.internal</TT
463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480
> 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
Andreas Gustafsson's avatar
Andreas Gustafsson committed
481 482 483
>Look up any hostnames in the <TT
CLASS="literal"
>site1</TT
484
> and 
Andreas Gustafsson's avatar
Andreas Gustafsson committed
485 486 487
<TT
CLASS="literal"
>site2.example.com</TT
488
> zones.</P
489 490 491
></LI
><LI
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
492 493 494
>Exchange mail with anyone in the <TT
CLASS="literal"
>site1</TT
495
> and 
Andreas Gustafsson's avatar
Andreas Gustafsson committed
496 497 498
<TT
CLASS="literal"
>site2.example.com</TT
499 500 501 502 503 504
> zones.</P
></LI
></UL
><P
>Here is an example configuration for the setup we just
    described above. Note that this is only configuration information;
505
    for information on how to configure your zone files, see <A
506 507 508 509 510 511 512
HREF="Bv9ARM.ch03.html#sample_configuration"
>Section 3.1</A
></P
><P
>Internal DNS server config:</P
><PRE
CLASS="programlisting"
513 514 515
>&#13;
acl internals { 172.16.72.0/24; 192.168.1.0/24; };

516 517 518 519
acl externals { <TT
CLASS="varname"
>bastion-ips-go-here</TT
>; };
520

521 522 523 524
options {
    ...
    ...
    forward only;
Andreas Gustafsson's avatar
Andreas Gustafsson committed
525 526
    forwarders {                                // forward to external servers
        <TT
527 528
CLASS="varname"
>bastion-ips-go-here</TT
529 530
>; 
    };
Andreas Gustafsson's avatar
Andreas Gustafsson committed
531 532 533
    allow-transfer { none; };                   // sample allow-transfer (no one)
    allow-query { internals; externals; };      // restrict query access
    allow-recursion { internals; };             // restrict recursion
534 535 536
    ...
    ...
};
537

Andreas Gustafsson's avatar
Andreas Gustafsson committed
538
zone "site1.example.com" {                      // sample slave zone
539 540
  type master;
  file "m/site1.example.com";
Andreas Gustafsson's avatar
Andreas Gustafsson committed
541 542
  forwarders { };                               // do normal iterative
                                                // resolution (do not forward)
543 544 545
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
546

547 548 549 550 551 552 553 554
zone "site2.example.com" {
  type slave;
  file "s/site2.example.com";
  masters { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};
555

556 557 558 559 560 561 562
zone "site1.internal" {
  type master;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};
563

564 565 566 567 568 569 570 571 572 573 574 575 576
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"
577 578
>&#13;acl internals { 172.16.72.0/24; 192.168.1.0/24; };

579
acl externals { bastion-ips-go-here; };
580

581 582 583
options {
  ...
  ...
Andreas Gustafsson's avatar
Andreas Gustafsson committed
584 585 586
  allow-transfer { none; };                     // sample allow-transfer (no one)
  allow-query { internals; externals; };        // restrict query access
  allow-recursion { internals; externals; };    // restrict recursion
587 588 589
  ...
  ...
};
590

Andreas Gustafsson's avatar
Andreas Gustafsson committed
591
zone "site1.example.com" {                      // sample slave zone
592 593 594 595 596
  type master;
  file "m/site1.foo.com";
  allow-query { any; };
  allow-transfer { internals; externals; };
};
597

598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654
zone "site2.example.com" {
  type slave;
  file "s/site2.foo.com";
  masters { another_bastion_host_maybe; };
  allow-query { any; };
  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"
>4.4. TSIG</A
></H1
><P
>This is a short guide to setting up Transaction SIGnatures
(TSIG) based transaction security in <SPAN
CLASS="acronym"
>BIND</SPAN
>. It describes changes
to the configuration file as well as what changes are required for
different features, including the process of creating transaction
keys and using transaction signatures with <SPAN
CLASS="acronym"
>BIND</SPAN
>.</P
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> primarily supports TSIG for server to server communication.
This includes zone transfer, notify, and recursive query messages.
Resolvers based on newer versions of <SPAN
CLASS="acronym"
>BIND</SPAN
> 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
    updates, but IP-based access control is insufficient. Key-based
655 656
    access control is far superior, see <A
HREF="Bv9ARM.ch09.html#proposed_standards"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
657
>Proposed Standards</A
658
>. The <B
659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674
CLASS="command"
>nsupdate</B
>
    program supports TSIG via the <TT
CLASS="option"
>-k</TT
> and
    <TT
CLASS="option"
>-y</TT
> command line options.</P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
675
NAME="AEN805"
676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692
>4.4.1. Generate Shared Keys for Each Pair of Hosts</A
></H2
><P
>A shared secret is generated to be shared between <I
CLASS="emphasis"
>host1</I
> and <I
CLASS="emphasis"
>host2</I
>.
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
693
NAME="AEN810"
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
>4.4.1.1. Automatic Generation</A
></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
><TT
CLASS="userinput"
><B
>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</B
></TT
></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
following "<TT
CLASS="literal"
>Key:</TT
>"
can be extracted from the file and used as a shared secret:</P
><PRE
CLASS="programlisting"
>Key: La/E5CjG9O+os1jq0a2jdA==</PRE
><P
>The string "<TT
CLASS="literal"
>La/E5CjG9O+os1jq0a2jdA==</TT
>" can
be used as the shared secret.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
735
NAME="AEN821"
736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755
>4.4.1.2. Manual Generation</A
></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
756
NAME="AEN826"
757 758 759 760 761 762 763 764 765 766 767
>4.4.2. Copying the Shared Secret to Both Machines</A
></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
768
NAME="AEN829"
769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815
>4.4.3. Informing the Servers of the Key's Existence</A
></H2
><P
>Imagine <I
CLASS="emphasis"
>host1</I
> and <I
CLASS="emphasis"
>host 2</I
> 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
>The algorithm, hmac-md5, is the only one supported by <SPAN
CLASS="acronym"
>BIND</SPAN
>.
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
signature. If the signature succeeds, the response is signed by
the same key.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
816
NAME="AEN841"
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
>4.4.4. Instructing the Server to Use the Key</A
></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
for <I
CLASS="emphasis"
>host1</I
>, if the IP address of <I
CLASS="emphasis"
>host2</I
> 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
>If <I
CLASS="emphasis"
>host1</I
Andreas Gustafsson's avatar
Andreas Gustafsson committed
847
> sends a message that is a request
848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865
to that address, the message will be signed with the specified key. <I
CLASS="emphasis"
>host1</I
> will
expect any responses to signed messages to be signed with the same
key.</P
><P
>A similar statement must be present in <I
CLASS="emphasis"
>host2</I
>'s
configuration file (with <I
CLASS="emphasis"
>host1</I
>'s address) for <I
CLASS="emphasis"
>host2</I
> to
Andreas Gustafsson's avatar
Andreas Gustafsson committed
866
sign request messages to <I
867 868 869 870 871 872 873 874 875
CLASS="emphasis"
>host1</I
>.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
876
NAME="AEN857"
877 878 879 880 881 882 883 884 885 886
>4.4.5. TSIG Key Based Access Control</A
></H2
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> allows IP addresses and ranges to be specified in ACL
definitions and
<B
CLASS="command"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
887 888
>allow-{ query | transfer | update }</B
> directives.
889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907
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
908
>You may want to read about the more
909 910 911
      powerful <B
CLASS="command"
>update-policy</B
912
> statement in <A
913
HREF="Bv9ARM.ch06.html#dynamic_update_policies"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
914
>Section 6.2.22.4</A
915 916 917 918 919 920 921
>.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
922
NAME="AEN870"
923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950
>4.4.6. Errors</A
></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
951
NAME="AEN874"
952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016
>4.5. TKEY</A
></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
    generated or assigned.  <SPAN
CLASS="acronym"
>BIND</SPAN
> implements only one of these modes,
    the Diffie-Hellman key exchange.  Both hosts are required to have
    a Diffie-Hellman KEY record (although this record is not required
    to be present in a zone).  The <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
1017
NAME="AEN889"
1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033
>4.6. SIG(0)</A
></H1
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> 9 partially supports DNSSEC SIG(0) transaction
    signatures as specified in RFC 2535.  SIG(0) uses public/private
    keys to authenticate messages.  Access control is performed in the
    same manner as TSIG keys; privileges can be granted or denied
    based on the key name.</P
><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
1034 1035 1036
>SIG(0) signing of multiple-message TCP streams is not
    supported.</P
><P
1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063
><SPAN
CLASS="acronym"
>BIND</SPAN
> 9 does not ship with any tools that generate SIG(0)
    signed messages.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="DNSSEC"
>4.7. DNSSEC</A
></H1
><P
>Cryptographic authentication of DNS information is possible
    through the DNS Security (<I
CLASS="emphasis"
>DNSSEC</I
>) extensions,
    defined in RFC 2535. This section describes the creation and use
    of DNSSEC signed zones.</P
><P
>In order to set up a DNSSEC secure zone, there are a series
    of steps which must be followed.  <SPAN
CLASS="acronym"
>BIND</SPAN
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1064 1065
> 9 ships
    with several tools
1066 1067 1068 1069 1070
    that are used in this process, which are explained in more detail
    below.  In all cases, the "<TT
CLASS="option"
>-h</TT
>" option prints a
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1071
    full list of parameters.  Note that the DNSSEC tools require the
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1072 1073 1074
    keyset and signedkey files to be in the working directory, and
    that the tools shipped with BIND 9.0.x are not fully compatible
    with the current ones.</P
1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088
><P
>There must also be communication with the administrators of
    the parent and/or child zone to transmit keys and signatures.  A
    zone's security status must be indicated by the parent zone for a
    DNSSEC capable resolver to trust its data.</P
><P
>For other servers to trust data in this zone, they must
    either be statically configured with this zone's zone key or the
    zone key of another zone above this one in the DNS tree.</P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1089
NAME="AEN906"
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 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159
>4.7.1. Generating Keys</A
></H2
><P
>The <B
CLASS="command"
>dnssec-keygen</B
> program is used to
      generate keys.</P
><P
>A secure zone must contain one or more zone keys.  The
      zone keys will sign all other records in the zone, as well as
      the zone keys of any secure delegated zones.  Zone keys must
      have the same name as the zone, a name type of
      <B
CLASS="command"
>ZONE</B
>, and must be usable for authentication.
      It is recommended that zone keys be mandatory to implement a
      cryptographic algorithm; currently the only key mandatory to
      implement an algorithm is DSA.</P
><P
>The following command will generate a 768 bit DSA key for
      the <TT
CLASS="filename"
>child.example</TT
> zone:</P
><P
><TT
CLASS="userinput"
><B
>dnssec-keygen -a DSA -b 768 -n ZONE child.example.</B
></TT
></P
><P
>Two output files will be produced:
      <TT
CLASS="filename"
>Kchild.example.+003+12345.key</TT
> and
      <TT
CLASS="filename"
>Kchild.example.+003+12345.private</TT
> (where
      12345 is an example of a key tag).  The key file names contain
      the key name (<TT
CLASS="filename"
>child.example.</TT
>), algorithm (3
      is DSA, 1 is RSA, etc.), and the key tag (12345 in this case).
      The private key (in the <TT
CLASS="filename"
>.private</TT
> file) is
      used to generate signatures, and the public key (in the
      <TT
CLASS="filename"
>.key</TT
> file) is used for signature
      verification.</P
><P
>To generate another key with the same properties (but with
      a different key tag), repeat the above command.</P
><P
>The public keys should be inserted into the zone file with
      <B
CLASS="command"
>$INCLUDE</B
> statements, including the
      <TT
CLASS="filename"
1160 1161
>.key</TT
> files.</P
1162 1163 1164 1165 1166 1167
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1168
NAME="AEN926"
1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201
>4.7.2. Creating a Keyset</A
></H2
><P
>The <B
CLASS="command"
>dnssec-makekeyset</B
> program is used
      to create a key set from one or more keys.</P
><P
>Once the zone keys have been generated, a key set must be
      built for transmission to the administrator of the parent zone,
      so that the parent zone can sign the keys with its own zone key
      and correctly indicate the security status of this zone.  When
      building a key set, the list of keys to be included and the TTL
      of the set must be specified, and the desired signature validity
      period of the parent's signature may also be specified.</P
><P
>The list of keys to be inserted into the key set may also
      included non-zone keys present at the top of the zone.
      <B
CLASS="command"
>dnssec-makekeyset</B
> may also be used at other
      names in the zone.</P
><P
>The following command generates a key set containing the
      above key and another key similarly generated, with a TTL of
      3600 and a signature validity period of 10 days starting from
      now.</P
><P
><TT
CLASS="userinput"
><B
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1202
>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</B
1203 1204 1205 1206 1207 1208
></TT
></P
><P
>One output file is produced:
      <TT
CLASS="filename"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1209
>keyset-child.example.</TT
1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220
>.  This file should be
      transmitted to the parent to be signed.  It includes the keys,
      as well as signatures over the key set generated by the zone
      keys themselves, which are used to prove ownership of the
      private keys and encode the desired validity period.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1221
NAME="AEN938"
1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252
>4.7.3. Signing the Child's Keyset</A
></H2
><P
>The <B
CLASS="command"
>dnssec-signkey</B
> program is used to
      sign one child's keyset.</P
><P
>If the <TT
CLASS="filename"
>child.example</TT
> zone has any
      delegations which are secure, for example,
      <TT
CLASS="filename"
>grand.child.example</TT
>, the
      <TT
CLASS="filename"
>child.example</TT
> administrator should receive
      keyset files for each secure subzone.  These keys must be signed
      by this zone's zone keys.</P
><P
>The following command signs the child's key set with the
      zone keys:</P
><P
><TT
CLASS="userinput"
><B
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1253
>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</B
1254 1255 1256 1257 1258 1259
></TT
></P
><P
>One output file is produced:
      <TT
CLASS="filename"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1260
>signedkey-grand.child.example.</TT
1261 1262 1263 1264 1265 1266 1267 1268 1269 1270
>.  This file
      should be both transmitted back to the child and retained.  It
      includes all keys (the child's keys) from the keyset file and
      signatures generated by this zone's zone keys.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1271
NAME="AEN951"
1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332
>4.7.4. Signing the Zone</A
></H2
><P
>The <B
CLASS="command"
>dnssec-signzone</B
> program is used to
      sign a zone.</P
><P
>Any <TT
CLASS="filename"
>signedkey</TT
> files corresponding to
      secure subzones should be present, as well as a
      <TT
CLASS="filename"
>signedkey</TT
> file for this zone generated by
      the parent (if there is one). The zone signer will generate
      <TT
CLASS="literal"
>NXT</TT
> and <TT
CLASS="literal"
>SIG</TT
> records for
      the zone, as well as incorporate the zone key signature from the
      parent and indicate the security status at all delegation
      points.</P
><P
>The following command signs the zone, assuming it is in a
      file called <TT
CLASS="filename"
>zone.child.example</TT
>.  By
      default, all zone keys which have an available private key are
      used to generate signatures.</P
><P
><TT
CLASS="userinput"
><B
>dnssec-signzone -o child.example zone.child.example</B
></TT
></P
><P
>One output file is produced:
      <TT
CLASS="filename"
>zone.child.example.signed</TT
>.  This file
      should be referenced by <TT
CLASS="filename"
>named.conf</TT
> as the
      input file for the zone.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1333
NAME="AEN967"
1334 1335 1336 1337 1338 1339
>4.7.5. Configuring Servers</A
></H2
><P
>Unlike in <SPAN
CLASS="acronym"
>BIND</SPAN
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1340 1341
> 8, 
data is not verified on load in <SPAN
1342 1343 1344
CLASS="acronym"
>BIND</SPAN
> 9,
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1345 1346
so zone keys for authoritative zones do not need to be specified
in the configuration file.</P
1347 1348
><P
>The public key for any security root must be present in
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1349
the configuration file's <B
1350 1351 1352
CLASS="command"
>trusted-keys</B
>
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1353
statement, as described later in this document. </P
1354 1355 1356 1357 1358 1359 1360
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
1361
NAME="AEN974"
1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379
>4.8. IPv6 Support in <SPAN
CLASS="acronym"
>BIND</SPAN
> 9</A
></H1
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> 9 fully supports all currently defined forms of IPv6
    name to address and address to name lookups.  It will also use
    IPv6 addresses to make queries when running on an IPv6 capable
    system.</P
><P
>For forward lookups, <SPAN
CLASS="acronym"
>BIND</SPAN
> 9 supports both A6 and AAAA
1380
    records.  The use of AAAA records is deprecated, but it is still
1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405
    useful for hosts to have both AAAA and A6 records to maintain
    backward compatibility with installations where AAAA records are
    still used.  In fact, the stub resolvers currently shipped with
    most operating system support only AAAA lookups, because following
    A6 chains is much harder than doing A or AAAA lookups.</P
><P
>For IPv6 reverse lookups, <SPAN
CLASS="acronym"
>BIND</SPAN
> 9 supports the new
    "bitstring" format used in the <I
CLASS="emphasis"
>ip6.arpa</I
>
    domain, as well as the older, deprecated "nibble" format used in
    the <I
CLASS="emphasis"
>ip6.int</I
> domain.</P
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> 9 includes a new lightweight resolver library and
    resolver daemon which new applications may choose to use to avoid
1406
    the complexities of A6 chain following and bitstring labels, see <A
1407 1408 1409
HREF="Bv9ARM.ch05.html"
>Chapter 5</A
>.</P
1410 1411 1412 1413 1414 1415
><P
>For an overview of the format and structure of IPv6 addresses,
    see <A
HREF="Bv9ARM.ch09.html#ipv6addresses"
>Section A.3.1</A
>.</P
1416 1417 1418 1419 1420
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1421
NAME="AEN990"
1422 1423 1424 1425 1426 1427 1428 1429 1430
>4.8.1. Address Lookups Using AAAA Records</A
></H2
><P
>The AAAA record is a parallel to the IPv4 A record.  It
      specifies the entire address in a single record.  For
      example,</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN example.com.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1431
host            3600    IN      AAAA    3ffe:8050:201:1860:42::1
1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442
</PRE
><P
>While their use is deprecated, they are useful to support
      older IPv6 applications.  They should not be added where they
      are not absolutely necessary.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1443
NAME="AEN995"
1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455
>4.8.2. Address Lookups Using A6 Records</A
></H2
><P
>The A6 record is more flexible than the AAAA record, and
      is therefore more complicated.  The A6 record can be used to
      form a chain of A6 records, each specifying part of the IPv6
      address. It can also be used to specify the entire record as
      well.  For example, this record supplies the same data as the
      AAAA record in the previous example:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN example.com.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1456
host            3600    IN      A6      0 3ffe:8050:201:1860:42::1
1457 1458 1459 1460 1461 1462
</PRE
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
1463
NAME="AEN999"
1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476
>4.8.2.1. A6 Chains</A
></H3
><P
>A6 records are designed to allow network
        renumbering. This works when an A6 record only specifies the
        part of the address space the domain owner controls.  For
        example, a host may be at a company named "company."  It has
        two ISPs which provide IPv6 address space for it.  These two
        ISPs fully specify the IPv6 prefix they supply.</P
><P
>In the company's address space:</P
><PRE
CLASS="programlisting"
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1477 1478 1479
>&#13;$ORIGIN example.com.
host            3600    IN      A6      64 0:0:0:0:42::1 company.example1.net.
host            3600    IN      A6      64 0:0:0:0:42::1 company.example2.net.
1480 1481 1482 1483 1484 1485
</PRE
><P
>ISP1 will use:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN example1.net.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1486
company         3600    IN      A6      0 3ffe:8050:201:1860::
1487 1488 1489 1490 1491 1492
</PRE
><P
>ISP2 will use:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN example2.net.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1493
company         3600    IN      A6      0 1234:5678:90ab:fffa::
1494 1495
</PRE
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1496 1497 1498
>When <TT
CLASS="literal"
>host.example.com</TT
1499 1500 1501 1502 1503 1504 1505 1506 1507 1508
> is looked up,
        the resolver (in the resolver daemon or caching name server)
        will find two partial A6 records, and will use the additional
        name to find the remainder of the data.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
1509
NAME="AEN1010"
1510 1511 1512 1513 1514 1515 1516 1517 1518
>4.8.2.2. A6 Records for DNS Servers</A
></H3
><P
>When an A6 record specifies the address of a name
        server, it should use the full address rather than specifying
        a partial address.  For example:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN example.com.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1519 1520 1521 1522
@               14400           IN      NS              ns0
                14400           IN      NS              ns1
ns0             14400           IN      A6              0 3ffe:8050:201:1860:42::1
ns1             14400           IN      A               192.168.42.1
1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538
</PRE
><P
>It is recommended that IPv4-in-IPv6 mapped addresses not
        be used.  If a host has an IPv4 address, use an A record, not
        an A6, with <TT
CLASS="literal"
>::ffff:192.168.42.1</TT
> as the
        address.</P
></DIV
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1539
NAME="AEN1016"
1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561
>4.8.3. Address to Name Lookups Using Nibble Format</A
></H2
><P
>While the use of nibble format to look up names is
      deprecated, it is supported for backwards compatiblity with
      existing IPv6 applications.</P
><P
>When looking up an address in nibble format, the address
      components are simply reversed, just as in IPv4, and
      <TT
CLASS="literal"
>ip6.int.</TT
> is appended to the resulting name.
      For example, the following would provide reverse name lookup for
      a host with address
      <TT
CLASS="literal"
>3ffe:8050:201:1860:42::1</TT
>.</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1562
1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0   14400 IN      PTR     host.example.com.
1563 1564 1565 1566 1567 1568 1569
</PRE
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1570
NAME="AEN1023"
1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588
>4.8.4. Address to Name Lookups Using Bitstring Format</A
></H2
><P
>Bitstring labels can start and end on any bit boundary,
      rather than on a multiple of 4 bits as in the nibble
      format. They also use <I
CLASS="emphasis"
>ip6.arpa</I
> rather than
      <I
CLASS="emphasis"
>ip6.int</I
>.</P
><P
>To replicate the previous example using bitstrings:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN \[x3ffe805002011860/64].ip6.arpa.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1589
\[x0042000000000001/64]         14400   IN      PTR     host.example.com.
1590 1591 1592 1593 1594 1595 1596
</PRE
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
1597
NAME="AEN1030"
1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610
>4.8.5. Using DNAME for Delegation of IPv6 Reverse Addresses</A
></H2
><P
>In IPV6, the same host may have many addresses from many
      network providers.  Since the trailing portion of the address
      usually remains constant, <B
CLASS="command"
>DNAME</B
> can help
      reduce the number of zone files used for reverse mapping that
      need to be maintained.</P
><P
>For example, consider a host which has two providers
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1611 1612 1613
      (<TT
CLASS="literal"
>example.net</TT
1614
> and
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1615 1616 1617
      <TT
CLASS="literal"
>example2.net</TT
1618 1619 1620 1621 1622 1623 1624
>) and
      therefore two IPv6 addresses.  Since the host chooses its own 64
      bit host address portion, the provider address is the only part
      that changes:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN example.com.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1625 1626
host                    IN      A6      64      ::1234:5678:1212:5675 cust1.example.net.
                        IN      A6      64      ::1234:5678:1212:5675 subnet5.example2.net.
1627
$ORIGIN example.net.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1628 1629
cust1                   IN      A6      48      0:0:0:dddd:: ipv6net.example.net.
ipv6net                 IN      A6      0       aa:bb:cccc::
1630
$ORIGIN example2.net.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1631 1632
subnet5                 IN      A6      48      0:0:0:1:: ipv6net2.example2.net.
ipv6net2                IN      A6      0       6666:5555:4::
1633 1634 1635
</PRE
><P
>This sets up forward lookups.  To handle the reverse lookups,
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1636 1637 1638
the provider <TT
CLASS="literal"
>example.net</TT
1639 1640 1641 1642 1643
>
would have:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN \[x00aa00bbcccc/48].ip6.arpa.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1644
\[xdddd/16]             IN      DNAME           ipv6-rev.example.com.
1645 1646
</PRE
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1647 1648 1649
>and <TT
CLASS="literal"
>example2.net</TT
1650 1651 1652 1653
> would have:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN \[x666655550004/48].ip6.arpa.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1654
\[x0001/16]             IN      DNAME           ipv6-rev.example.com.
1655 1656
</PRE
><P
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1657 1658 1659
><TT
CLASS="literal"
>example.com</TT
1660 1661 1662 1663 1664 1665
>
      needs only one zone file to handle both of these reverse
      mappings:</P
><PRE
CLASS="programlisting"
>&#13;$ORIGIN ipv6-rev.example.com.
Andreas Gustafsson's avatar
Andreas Gustafsson committed
1666
\[x1234567812125675/64] IN      PTR             host.example.com. 
1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730
</PRE
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="Bv9ARM.ch03.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="Bv9ARM.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="Bv9ARM.ch05.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Nameserver Configuration</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>The <SPAN
CLASS="acronym"
>BIND</SPAN
> 9 Lightweight Resolver</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>