From b1e4bd53e00e9694dd378a884abd3f2dd790190d Mon Sep 17 00:00:00 2001 From: Tom Rhodes Date: Sun, 19 Sep 2004 01:30:24 +0000 Subject: Vender import of BIND 9.3.0rc4. --- contrib/bind9/CHANGES | 5479 ++++ contrib/bind9/COPYRIGHT | 30 + contrib/bind9/FAQ | 454 + contrib/bind9/Makefile.in | 59 + contrib/bind9/README | 344 + contrib/bind9/acconfig.h | 141 + contrib/bind9/bin/Makefile.in | 25 + contrib/bind9/bin/check/Makefile.in | 95 + contrib/bind9/bin/check/check-tool.c | 159 + contrib/bind9/bin/check/check-tool.h | 46 + contrib/bind9/bin/check/named-checkconf.8 | 59 + contrib/bind9/bin/check/named-checkconf.c | 286 + contrib/bind9/bin/check/named-checkconf.docbook | 146 + contrib/bind9/bin/check/named-checkconf.html | 216 + contrib/bind9/bin/check/named-checkzone.8 | 94 + contrib/bind9/bin/check/named-checkzone.c | 200 + contrib/bind9/bin/check/named-checkzone.docbook | 236 + contrib/bind9/bin/check/named-checkzone.html | 367 + contrib/bind9/bin/dig/Makefile.in | 101 + contrib/bind9/bin/dig/dig.1 | 401 + contrib/bind9/bin/dig/dig.c | 1671 + contrib/bind9/bin/dig/dig.docbook | 611 + contrib/bind9/bin/dig/dig.html | 1174 + contrib/bind9/bin/dig/dighost.c | 5074 +++ contrib/bind9/bin/dig/host.1 | 136 + contrib/bind9/bin/dig/host.c | 754 + contrib/bind9/bin/dig/host.docbook | 212 + contrib/bind9/bin/dig/host.html | 434 + contrib/bind9/bin/dig/include/dig/dig.h | 343 + contrib/bind9/bin/dig/nslookup.1 | 192 + contrib/bind9/bin/dig/nslookup.c | 887 + contrib/bind9/bin/dig/nslookup.docbook | 320 + contrib/bind9/bin/dig/nslookup.html | 617 + contrib/bind9/bin/dnssec/Makefile.in | 82 + contrib/bind9/bin/dnssec/dnssec-keygen.8 | 174 + contrib/bind9/bin/dnssec/dnssec-keygen.c | 415 + contrib/bind9/bin/dnssec/dnssec-keygen.docbook | 342 + contrib/bind9/bin/dnssec/dnssec-keygen.html | 544 + contrib/bind9/bin/dnssec/dnssec-makekeyset.8 | 113 + contrib/bind9/bin/dnssec/dnssec-makekeyset.c | 401 + contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook | 233 + contrib/bind9/bin/dnssec/dnssec-makekeyset.html | 407 + contrib/bind9/bin/dnssec/dnssec-signkey.8 | 108 + contrib/bind9/bin/dnssec/dnssec-signkey.c | 448 + contrib/bind9/bin/dnssec/dnssec-signkey.docbook | 237 + contrib/bind9/bin/dnssec/dnssec-signkey.html | 407 + contrib/bind9/bin/dnssec/dnssec-signzone.8 | 167 + contrib/bind9/bin/dnssec/dnssec-signzone.c | 2102 ++ contrib/bind9/bin/dnssec/dnssec-signzone.docbook | 362 + contrib/bind9/bin/dnssec/dnssec-signzone.html | 553 + contrib/bind9/bin/dnssec/dnssectool.c | 305 + contrib/bind9/bin/dnssec/dnssectool.h | 76 + contrib/bind9/bin/named/Makefile.in | 131 + contrib/bind9/bin/named/aclconf.c | 233 + contrib/bind9/bin/named/builtin.c | 228 + contrib/bind9/bin/named/client.c | 2361 ++ contrib/bind9/bin/named/config.c | 723 + contrib/bind9/bin/named/control.c | 140 + contrib/bind9/bin/named/controlconf.c | 1323 + contrib/bind9/bin/named/include/named/aclconf.h | 72 + contrib/bind9/bin/named/include/named/builtin.h | 29 + contrib/bind9/bin/named/include/named/client.h | 337 + contrib/bind9/bin/named/include/named/config.h | 75 + contrib/bind9/bin/named/include/named/control.h | 87 + contrib/bind9/bin/named/include/named/globals.h | 118 + .../bind9/bin/named/include/named/interfacemgr.h | 173 + contrib/bind9/bin/named/include/named/listenlist.h | 104 + contrib/bind9/bin/named/include/named/log.h | 96 + contrib/bind9/bin/named/include/named/logconf.h | 32 + contrib/bind9/bin/named/include/named/lwaddr.h | 34 + contrib/bind9/bin/named/include/named/lwdclient.h | 230 + contrib/bind9/bin/named/include/named/lwresd.h | 111 + contrib/bind9/bin/named/include/named/lwsearch.h | 110 + contrib/bind9/bin/named/include/named/main.h | 32 + contrib/bind9/bin/named/include/named/notify.h | 54 + contrib/bind9/bin/named/include/named/query.h | 83 + contrib/bind9/bin/named/include/named/server.h | 213 + contrib/bind9/bin/named/include/named/sortlist.h | 84 + contrib/bind9/bin/named/include/named/tkeyconf.h | 51 + contrib/bind9/bin/named/include/named/tsigconf.h | 47 + contrib/bind9/bin/named/include/named/types.h | 41 + contrib/bind9/bin/named/include/named/update.h | 49 + contrib/bind9/bin/named/include/named/xfrout.h | 38 + contrib/bind9/bin/named/include/named/zoneconf.h | 61 + contrib/bind9/bin/named/interfacemgr.c | 911 + contrib/bind9/bin/named/listenlist.c | 136 + contrib/bind9/bin/named/log.c | 217 + contrib/bind9/bin/named/logconf.c | 295 + contrib/bind9/bin/named/lwaddr.c | 92 + contrib/bind9/bin/named/lwdclient.c | 465 + contrib/bind9/bin/named/lwderror.c | 78 + contrib/bind9/bin/named/lwdgabn.c | 655 + contrib/bind9/bin/named/lwdgnba.c | 270 + contrib/bind9/bin/named/lwdgrbn.c | 513 + contrib/bind9/bin/named/lwdnoop.c | 86 + contrib/bind9/bin/named/lwresd.8 | 140 + contrib/bind9/bin/named/lwresd.c | 861 + contrib/bind9/bin/named/lwresd.docbook | 300 + contrib/bind9/bin/named/lwresd.html | 497 + contrib/bind9/bin/named/lwsearch.c | 199 + contrib/bind9/bin/named/main.c | 884 + contrib/bind9/bin/named/named.8 | 177 + contrib/bind9/bin/named/named.conf.5 | 474 + contrib/bind9/bin/named/named.conf.docbook | 532 + contrib/bind9/bin/named/named.conf.html | 1893 ++ contrib/bind9/bin/named/named.docbook | 370 + contrib/bind9/bin/named/named.html | 625 + contrib/bind9/bin/named/notify.c | 162 + contrib/bind9/bin/named/query.c | 3539 +++ contrib/bind9/bin/named/server.c | 4089 +++ contrib/bind9/bin/named/sortlist.c | 162 + contrib/bind9/bin/named/tkeyconf.c | 118 + contrib/bind9/bin/named/tsigconf.c | 170 + contrib/bind9/bin/named/unix/Makefile.in | 36 + contrib/bind9/bin/named/unix/include/named/os.h | 64 + contrib/bind9/bin/named/unix/os.c | 630 + contrib/bind9/bin/named/update.c | 2811 ++ contrib/bind9/bin/named/xfrout.c | 1718 + contrib/bind9/bin/named/zoneconf.c | 729 + contrib/bind9/bin/nsupdate/Makefile.in | 83 + contrib/bind9/bin/nsupdate/nsupdate.8 | 369 + contrib/bind9/bin/nsupdate/nsupdate.c | 1983 ++ contrib/bind9/bin/nsupdate/nsupdate.docbook | 629 + contrib/bind9/bin/nsupdate/nsupdate.html | 962 + contrib/bind9/bin/rndc/Makefile.in | 102 + contrib/bind9/bin/rndc/include/rndc/os.h | 44 + contrib/bind9/bin/rndc/rndc-confgen.8 | 140 + contrib/bind9/bin/rndc/rndc-confgen.c | 323 + contrib/bind9/bin/rndc/rndc-confgen.docbook | 273 + contrib/bind9/bin/rndc/rndc-confgen.html | 538 + contrib/bind9/bin/rndc/rndc.8 | 118 + contrib/bind9/bin/rndc/rndc.c | 687 + contrib/bind9/bin/rndc/rndc.conf | 36 + contrib/bind9/bin/rndc/rndc.conf.5 | 142 + contrib/bind9/bin/rndc/rndc.conf.docbook | 210 + contrib/bind9/bin/rndc/rndc.conf.html | 377 + contrib/bind9/bin/rndc/rndc.docbook | 228 + contrib/bind9/bin/rndc/rndc.html | 388 + contrib/bind9/bin/rndc/unix/Makefile.in | 36 + contrib/bind9/bin/rndc/unix/os.c | 68 + contrib/bind9/bin/rndc/util.c | 55 + contrib/bind9/bin/rndc/util.h | 49 + contrib/bind9/config.guess | 1435 + contrib/bind9/config.sub | 1537 + contrib/bind9/configure.in | 2180 ++ contrib/bind9/doc/Makefile.in | 29 + contrib/bind9/doc/arm/Bv9ARM-book.xml | 6571 ++++ contrib/bind9/doc/arm/Bv9ARM.ch01.html | 1131 + contrib/bind9/doc/arm/Bv9ARM.ch02.html | 284 + contrib/bind9/doc/arm/Bv9ARM.ch03.html | 1458 + contrib/bind9/doc/arm/Bv9ARM.ch04.html | 1602 + contrib/bind9/doc/arm/Bv9ARM.ch05.html | 265 + contrib/bind9/doc/arm/Bv9ARM.ch06.html | 11479 +++++++ contrib/bind9/doc/arm/Bv9ARM.ch07.html | 500 + contrib/bind9/doc/arm/Bv9ARM.ch08.html | 272 + contrib/bind9/doc/arm/Bv9ARM.ch09.html | 1587 + contrib/bind9/doc/arm/Bv9ARM.html | 851 + contrib/bind9/doc/arm/Makefile.in | 69 + contrib/bind9/doc/arm/README-SGML | 329 + contrib/bind9/doc/arm/isc.color.gif | Bin 0 -> 6384 bytes contrib/bind9/doc/arm/nominum-docbook-html.dsl.in | 148 + contrib/bind9/doc/arm/nominum-docbook-print.dsl.in | 42 + contrib/bind9/doc/arm/validate.sh.in | 21 + .../doc/draft/draft-baba-dnsext-acl-reqts-01.txt | 336 + contrib/bind9/doc/draft/draft-daigle-napstr-04.txt | 1232 + .../doc/draft/draft-danisch-dns-rr-smtp-03.txt | 1960 ++ .../doc/draft/draft-dnsext-opcode-discover-02.txt | 241 + .../doc/draft/draft-durand-dnsop-dynreverse-00.txt | 240 + .../draft/draft-ietf-dnsext-axfr-clarify-05.txt | 393 + .../doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt | 561 + ...t-ietf-dnsext-dnssec-2535typecode-change-06.txt | 442 + .../draft/draft-ietf-dnsext-dnssec-intro-11.txt | 1457 + .../draft/draft-ietf-dnsext-dnssec-protocol-07.txt | 3193 ++ .../draft/draft-ietf-dnsext-dnssec-records-09.txt | 1849 ++ .../doc/draft/draft-ietf-dnsext-insensitive-04.txt | 639 + .../doc/draft/draft-ietf-dnsext-interop3597-01.txt | 335 + ...draft-ietf-dnsext-keyrr-key-signing-flag-12.txt | 560 + .../bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt | 1559 + .../draft-ietf-dnsext-tkey-renewal-mode-04.txt | 1235 + .../doc/draft/draft-ietf-dnsext-tsig-sha-00.txt | 466 + .../draft/draft-ietf-dnsext-wcard-clarify-02.txt | 1010 + .../doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt | 1120 + ...-ietf-dnsop-dnssec-operational-practices-01.txt | 1344 + .../draft-ietf-dnsop-ipv6-dns-configuration-02.txt | 1321 + .../draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt | 1969 ++ ...aft-ietf-dnsop-ipv6-transport-guidelines-01.txt | 300 + ...aft-ietf-dnsop-key-rollover-requirements-01.txt | 391 + ...raft-ietf-dnsop-misbehavior-against-aaaa-00.txt | 505 + .../doc/draft/draft-ietf-dnsop-respsize-01.txt | 485 + .../doc/draft/draft-ietf-dnsop-serverid-02.txt | 617 + .../doc/draft/draft-ietf-enum-e164-gstn-np-05.txt | 1588 + .../bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt | 951 + .../draft/draft-ietf-ipv6-node-requirements-08.txt | 1200 + .../bind9/doc/draft/draft-ietf-secsh-dns-05.txt | 614 + .../draft-ihren-dnsext-threshold-validation-00.txt | 519 + .../doc/draft/draft-kato-dnsop-local-zones-00.txt | 295 + .../draft-park-ipv6-extensions-dns-pnp-00.txt | 1830 ++ contrib/bind9/doc/draft/update | 46 + contrib/bind9/doc/misc/Makefile.in | 36 + contrib/bind9/doc/misc/dnssec | 84 + contrib/bind9/doc/misc/format-options.pl | 36 + contrib/bind9/doc/misc/ipv6 | 113 + contrib/bind9/doc/misc/migration | 246 + contrib/bind9/doc/misc/migration-4to9 | 57 + contrib/bind9/doc/misc/options | 384 + contrib/bind9/doc/misc/rfc-compliance | 62 + contrib/bind9/doc/misc/roadmap | 47 + contrib/bind9/doc/misc/sdb | 169 + contrib/bind9/doc/rfc/index | 94 + contrib/bind9/doc/rfc/rfc1032.txt | 781 + contrib/bind9/doc/rfc/rfc1033.txt | 1229 + contrib/bind9/doc/rfc/rfc1034.txt | 3077 ++ contrib/bind9/doc/rfc/rfc1035.txt | 3077 ++ contrib/bind9/doc/rfc/rfc1101.txt | 787 + contrib/bind9/doc/rfc/rfc1122.txt | 6844 ++++ contrib/bind9/doc/rfc/rfc1123.txt | 5782 ++++ contrib/bind9/doc/rfc/rfc1183.txt | 619 + contrib/bind9/doc/rfc/rfc1348.txt | 227 + contrib/bind9/doc/rfc/rfc1535.txt | 283 + contrib/bind9/doc/rfc/rfc1536.txt | 675 + contrib/bind9/doc/rfc/rfc1537.txt | 507 + contrib/bind9/doc/rfc/rfc1591.txt | 395 + contrib/bind9/doc/rfc/rfc1611.txt | 1683 + contrib/bind9/doc/rfc/rfc1612.txt | 1795 ++ contrib/bind9/doc/rfc/rfc1706.txt | 563 + contrib/bind9/doc/rfc/rfc1712.txt | 395 + contrib/bind9/doc/rfc/rfc1750.txt | 1683 + contrib/bind9/doc/rfc/rfc1876.txt | 1011 + contrib/bind9/doc/rfc/rfc1886.txt | 268 + contrib/bind9/doc/rfc/rfc1982.txt | 394 + contrib/bind9/doc/rfc/rfc1995.txt | 451 + contrib/bind9/doc/rfc/rfc1996.txt | 395 + contrib/bind9/doc/rfc/rfc2052.txt | 563 + contrib/bind9/doc/rfc/rfc2104.txt | 620 + contrib/bind9/doc/rfc/rfc2119.txt | 171 + contrib/bind9/doc/rfc/rfc2133.txt | 1795 ++ contrib/bind9/doc/rfc/rfc2136.txt | 1460 + contrib/bind9/doc/rfc/rfc2137.txt | 619 + contrib/bind9/doc/rfc/rfc2163.txt | 1459 + contrib/bind9/doc/rfc/rfc2168.txt | 1123 + contrib/bind9/doc/rfc/rfc2181.txt | 842 + contrib/bind9/doc/rfc/rfc2230.txt | 619 + contrib/bind9/doc/rfc/rfc2308.txt | 1067 + contrib/bind9/doc/rfc/rfc2317.txt | 563 + contrib/bind9/doc/rfc/rfc2373.txt | 1459 + contrib/bind9/doc/rfc/rfc2374.txt | 675 + contrib/bind9/doc/rfc/rfc2375.txt | 451 + contrib/bind9/doc/rfc/rfc2418.txt | 1459 + contrib/bind9/doc/rfc/rfc2535.txt | 2635 ++ contrib/bind9/doc/rfc/rfc2536.txt | 339 + contrib/bind9/doc/rfc/rfc2537.txt | 339 + contrib/bind9/doc/rfc/rfc2538.txt | 563 + contrib/bind9/doc/rfc/rfc2539.txt | 395 + contrib/bind9/doc/rfc/rfc2540.txt | 339 + contrib/bind9/doc/rfc/rfc2541.txt | 395 + contrib/bind9/doc/rfc/rfc2553.txt | 2299 ++ contrib/bind9/doc/rfc/rfc2671.txt | 395 + contrib/bind9/doc/rfc/rfc2672.txt | 507 + contrib/bind9/doc/rfc/rfc2673.txt | 395 + contrib/bind9/doc/rfc/rfc2782.txt | 675 + contrib/bind9/doc/rfc/rfc2825.txt | 395 + contrib/bind9/doc/rfc/rfc2826.txt | 339 + contrib/bind9/doc/rfc/rfc2845.txt | 843 + contrib/bind9/doc/rfc/rfc2874.txt | 1123 + contrib/bind9/doc/rfc/rfc2915.txt | 1011 + contrib/bind9/doc/rfc/rfc2929.txt | 675 + contrib/bind9/doc/rfc/rfc2930.txt | 899 + contrib/bind9/doc/rfc/rfc2931.txt | 563 + contrib/bind9/doc/rfc/rfc3007.txt | 507 + contrib/bind9/doc/rfc/rfc3008.txt | 395 + contrib/bind9/doc/rfc/rfc3071.txt | 563 + contrib/bind9/doc/rfc/rfc3090.txt | 619 + contrib/bind9/doc/rfc/rfc3110.txt | 395 + contrib/bind9/doc/rfc/rfc3123.txt | 451 + contrib/bind9/doc/rfc/rfc3152.txt | 227 + contrib/bind9/doc/rfc/rfc3197.txt | 283 + contrib/bind9/doc/rfc/rfc3225.txt | 339 + contrib/bind9/doc/rfc/rfc3226.txt | 339 + contrib/bind9/doc/rfc/rfc3258.txt | 619 + contrib/bind9/doc/rfc/rfc3363.txt | 339 + contrib/bind9/doc/rfc/rfc3364.txt | 619 + contrib/bind9/doc/rfc/rfc3425.txt | 283 + contrib/bind9/doc/rfc/rfc3445.txt | 563 + contrib/bind9/doc/rfc/rfc3467.txt | 1739 + contrib/bind9/doc/rfc/rfc3490.txt | 1235 + contrib/bind9/doc/rfc/rfc3491.txt | 395 + contrib/bind9/doc/rfc/rfc3492.txt | 1963 ++ contrib/bind9/doc/rfc/rfc3493.txt | 2187 ++ contrib/bind9/doc/rfc/rfc3513.txt | 1459 + contrib/bind9/doc/rfc/rfc3596.txt | 451 + contrib/bind9/doc/rfc/rfc3597.txt | 451 + contrib/bind9/doc/rfc/rfc3645.txt | 1459 + contrib/bind9/doc/rfc/rfc3655.txt | 451 + contrib/bind9/doc/rfc/rfc3658.txt | 1067 + contrib/bind9/doc/rfc/rfc3833.txt | 899 + contrib/bind9/doc/rfc/rfc3845.txt | 395 + contrib/bind9/doc/rfc/rfc952.txt | 340 + contrib/bind9/install-sh | 250 + contrib/bind9/isc-config.sh.in | 149 + contrib/bind9/lib/Makefile.in | 29 + contrib/bind9/lib/bind/Makefile.in | 127 + contrib/bind9/lib/bind/README | 4 + contrib/bind9/lib/bind/aclocal.m4 | 2 + contrib/bind9/lib/bind/api | 3 + contrib/bind9/lib/bind/bsd/Makefile.in | 39 + contrib/bind9/lib/bind/bsd/daemon.c | 79 + contrib/bind9/lib/bind/bsd/ftruncate.c | 63 + contrib/bind9/lib/bind/bsd/gettimeofday.c | 62 + contrib/bind9/lib/bind/bsd/mktemp.c | 154 + contrib/bind9/lib/bind/bsd/putenv.c | 25 + contrib/bind9/lib/bind/bsd/readv.c | 38 + contrib/bind9/lib/bind/bsd/setenv.c | 149 + contrib/bind9/lib/bind/bsd/setitimer.c | 27 + contrib/bind9/lib/bind/bsd/strcasecmp.c | 122 + contrib/bind9/lib/bind/bsd/strdup.c | 18 + contrib/bind9/lib/bind/bsd/strerror.c | 90 + contrib/bind9/lib/bind/bsd/strpbrk.c | 68 + contrib/bind9/lib/bind/bsd/strsep.c | 86 + contrib/bind9/lib/bind/bsd/strtoul.c | 117 + contrib/bind9/lib/bind/bsd/utimes.c | 39 + contrib/bind9/lib/bind/bsd/writev.c | 87 + contrib/bind9/lib/bind/config.h.in | 45 + contrib/bind9/lib/bind/configure | 31829 +++++++++++++++++++ contrib/bind9/lib/bind/configure.in | 2407 ++ contrib/bind9/lib/bind/dst/Makefile.in | 32 + contrib/bind9/lib/bind/dst/dst_api.c | 1048 + contrib/bind9/lib/bind/dst/dst_internal.h | 154 + contrib/bind9/lib/bind/dst/hmac_link.c | 468 + contrib/bind9/lib/bind/dst/md5.h | 101 + contrib/bind9/lib/bind/dst/md5_dgst.c | 370 + contrib/bind9/lib/bind/dst/md5_locl.h | 190 + contrib/bind9/lib/bind/dst/support.c | 350 + contrib/bind9/lib/bind/include/Makefile.in | 47 + contrib/bind9/lib/bind/include/arpa/inet.h | 124 + contrib/bind9/lib/bind/include/arpa/nameser.h | 576 + .../bind9/lib/bind/include/arpa/nameser_compat.h | 232 + contrib/bind9/lib/bind/include/fd_setsize.h | 9 + contrib/bind9/lib/bind/include/hesiod.h | 38 + contrib/bind9/lib/bind/include/irp.h | 103 + contrib/bind9/lib/bind/include/irs.h | 345 + contrib/bind9/lib/bind/include/isc/assertions.h | 122 + contrib/bind9/lib/bind/include/isc/ctl.h | 109 + contrib/bind9/lib/bind/include/isc/dst.h | 180 + contrib/bind9/lib/bind/include/isc/eventlib.h | 200 + contrib/bind9/lib/bind/include/isc/heap.h | 47 + contrib/bind9/lib/bind/include/isc/irpmarshall.h | 115 + contrib/bind9/lib/bind/include/isc/list.h | 112 + contrib/bind9/lib/bind/include/isc/logging.h | 112 + contrib/bind9/lib/bind/include/isc/memcluster.h | 49 + contrib/bind9/lib/bind/include/isc/misc.h | 39 + contrib/bind9/lib/bind/include/isc/tree.h | 58 + contrib/bind9/lib/bind/include/netdb.h | 549 + contrib/bind9/lib/bind/include/netgroup.h | 24 + contrib/bind9/lib/bind/include/res_update.h | 65 + contrib/bind9/lib/bind/include/resolv.h | 501 + contrib/bind9/lib/bind/inet/Makefile.in | 35 + contrib/bind9/lib/bind/inet/inet_addr.c | 206 + contrib/bind9/lib/bind/inet/inet_cidr_ntop.c | 259 + contrib/bind9/lib/bind/inet/inet_cidr_pton.c | 275 + contrib/bind9/lib/bind/inet/inet_data.c | 44 + contrib/bind9/lib/bind/inet/inet_lnaof.c | 63 + contrib/bind9/lib/bind/inet/inet_makeaddr.c | 66 + contrib/bind9/lib/bind/inet/inet_net_ntop.c | 277 + contrib/bind9/lib/bind/inet/inet_net_pton.c | 405 + contrib/bind9/lib/bind/inet/inet_neta.c | 87 + contrib/bind9/lib/bind/inet/inet_netof.c | 62 + contrib/bind9/lib/bind/inet/inet_network.c | 104 + contrib/bind9/lib/bind/inet/inet_ntoa.c | 62 + contrib/bind9/lib/bind/inet/inet_ntop.c | 203 + contrib/bind9/lib/bind/inet/inet_pton.c | 222 + contrib/bind9/lib/bind/inet/nsap_addr.c | 108 + contrib/bind9/lib/bind/irs/Makefile.in | 70 + contrib/bind9/lib/bind/irs/dns.c | 153 + contrib/bind9/lib/bind/irs/dns_gr.c | 293 + contrib/bind9/lib/bind/irs/dns_ho.c | 1150 + contrib/bind9/lib/bind/irs/dns_nw.c | 589 + contrib/bind9/lib/bind/irs/dns_p.h | 50 + contrib/bind9/lib/bind/irs/dns_pr.c | 266 + contrib/bind9/lib/bind/irs/dns_pw.c | 231 + contrib/bind9/lib/bind/irs/dns_sv.c | 298 + contrib/bind9/lib/bind/irs/gai_strerror.c | 86 + contrib/bind9/lib/bind/irs/gen.c | 430 + contrib/bind9/lib/bind/irs/gen_gr.c | 492 + contrib/bind9/lib/bind/irs/gen_ho.c | 391 + contrib/bind9/lib/bind/irs/gen_ng.c | 172 + contrib/bind9/lib/bind/irs/gen_nw.c | 262 + contrib/bind9/lib/bind/irs/gen_p.h | 113 + contrib/bind9/lib/bind/irs/gen_pr.c | 226 + contrib/bind9/lib/bind/irs/gen_pw.c | 233 + contrib/bind9/lib/bind/irs/gen_sv.c | 227 + contrib/bind9/lib/bind/irs/getaddrinfo.c | 1227 + contrib/bind9/lib/bind/irs/getgrent.c | 223 + contrib/bind9/lib/bind/irs/getgrent_r.c | 229 + contrib/bind9/lib/bind/irs/gethostent.c | 1069 + contrib/bind9/lib/bind/irs/gethostent_r.c | 262 + contrib/bind9/lib/bind/irs/getnameinfo.c | 322 + contrib/bind9/lib/bind/irs/getnetent.c | 343 + contrib/bind9/lib/bind/irs/getnetent_r.c | 227 + contrib/bind9/lib/bind/irs/getnetgrent.c | 156 + contrib/bind9/lib/bind/irs/getnetgrent_r.c | 167 + contrib/bind9/lib/bind/irs/getprotoent.c | 174 + contrib/bind9/lib/bind/irs/getprotoent_r.c | 216 + contrib/bind9/lib/bind/irs/getpwent.c | 200 + contrib/bind9/lib/bind/irs/getpwent_r.c | 275 + contrib/bind9/lib/bind/irs/getservent.c | 177 + contrib/bind9/lib/bind/irs/getservent_r.c | 237 + contrib/bind9/lib/bind/irs/hesiod.c | 507 + contrib/bind9/lib/bind/irs/hesiod_p.h | 48 + contrib/bind9/lib/bind/irs/irp.c | 592 + contrib/bind9/lib/bind/irs/irp_gr.c | 408 + contrib/bind9/lib/bind/irs/irp_ho.c | 429 + contrib/bind9/lib/bind/irs/irp_ng.c | 272 + contrib/bind9/lib/bind/irs/irp_nw.c | 375 + contrib/bind9/lib/bind/irs/irp_p.h | 59 + contrib/bind9/lib/bind/irs/irp_pr.c | 353 + contrib/bind9/lib/bind/irs/irp_pw.c | 358 + contrib/bind9/lib/bind/irs/irp_sv.c | 369 + contrib/bind9/lib/bind/irs/irpmarshall.c | 2344 ++ contrib/bind9/lib/bind/irs/irs_data.c | 230 + contrib/bind9/lib/bind/irs/irs_data.h | 62 + contrib/bind9/lib/bind/irs/irs_p.h | 49 + contrib/bind9/lib/bind/irs/lcl.c | 140 + contrib/bind9/lib/bind/irs/lcl_gr.c | 354 + contrib/bind9/lib/bind/irs/lcl_ho.c | 576 + contrib/bind9/lib/bind/irs/lcl_ng.c | 444 + contrib/bind9/lib/bind/irs/lcl_nw.c | 371 + contrib/bind9/lib/bind/irs/lcl_p.h | 50 + contrib/bind9/lib/bind/irs/lcl_pr.c | 284 + contrib/bind9/lib/bind/irs/lcl_pw.c | 308 + contrib/bind9/lib/bind/irs/lcl_sv.c | 431 + contrib/bind9/lib/bind/irs/nis.c | 154 + contrib/bind9/lib/bind/irs/nis_gr.c | 353 + contrib/bind9/lib/bind/irs/nis_ho.c | 533 + contrib/bind9/lib/bind/irs/nis_ng.c | 302 + contrib/bind9/lib/bind/irs/nis_nw.c | 383 + contrib/bind9/lib/bind/irs/nis_p.h | 46 + contrib/bind9/lib/bind/irs/nis_pr.c | 300 + contrib/bind9/lib/bind/irs/nis_pw.c | 287 + contrib/bind9/lib/bind/irs/nis_sv.c | 308 + contrib/bind9/lib/bind/irs/nul_ng.c | 126 + contrib/bind9/lib/bind/irs/pathnames.h | 50 + contrib/bind9/lib/bind/irs/util.c | 107 + contrib/bind9/lib/bind/isc/Makefile.in | 35 + contrib/bind9/lib/bind/isc/assertions.c | 91 + contrib/bind9/lib/bind/isc/assertions.mdoc | 138 + contrib/bind9/lib/bind/isc/base64.c | 320 + contrib/bind9/lib/bind/isc/bitncmp.c | 66 + contrib/bind9/lib/bind/isc/bitncmp.mdoc | 82 + contrib/bind9/lib/bind/isc/ctl_clnt.c | 602 + contrib/bind9/lib/bind/isc/ctl_p.c | 186 + contrib/bind9/lib/bind/isc/ctl_p.h | 26 + contrib/bind9/lib/bind/isc/ctl_srvr.c | 780 + contrib/bind9/lib/bind/isc/ev_connects.c | 367 + contrib/bind9/lib/bind/isc/ev_files.c | 283 + contrib/bind9/lib/bind/isc/ev_streams.c | 306 + contrib/bind9/lib/bind/isc/ev_timers.c | 497 + contrib/bind9/lib/bind/isc/ev_waits.c | 245 + contrib/bind9/lib/bind/isc/eventlib.c | 728 + contrib/bind9/lib/bind/isc/eventlib.mdoc | 918 + contrib/bind9/lib/bind/isc/eventlib_p.h | 219 + contrib/bind9/lib/bind/isc/heap.c | 230 + contrib/bind9/lib/bind/isc/heap.mdoc | 378 + contrib/bind9/lib/bind/isc/hex.c | 116 + contrib/bind9/lib/bind/isc/logging.c | 720 + contrib/bind9/lib/bind/isc/logging.mdoc | 1056 + contrib/bind9/lib/bind/isc/logging_p.h | 60 + contrib/bind9/lib/bind/isc/memcluster.c | 545 + contrib/bind9/lib/bind/isc/memcluster.mdoc | 376 + contrib/bind9/lib/bind/isc/movefile.c | 35 + contrib/bind9/lib/bind/isc/tree.c | 532 + contrib/bind9/lib/bind/isc/tree.mdoc | 154 + contrib/bind9/lib/bind/libtool.m4 | 5943 ++++ contrib/bind9/lib/bind/ltmain.sh | 4950 +++ contrib/bind9/lib/bind/make/includes.in | 44 + contrib/bind9/lib/bind/make/mkdep.in | 147 + contrib/bind9/lib/bind/make/rules.in | 177 + contrib/bind9/lib/bind/mkinstalldirs | 40 + contrib/bind9/lib/bind/nameser/Makefile.in | 31 + contrib/bind9/lib/bind/nameser/ns_date.c | 128 + contrib/bind9/lib/bind/nameser/ns_name.c | 963 + contrib/bind9/lib/bind/nameser/ns_netint.c | 56 + contrib/bind9/lib/bind/nameser/ns_parse.c | 203 + contrib/bind9/lib/bind/nameser/ns_print.c | 898 + contrib/bind9/lib/bind/nameser/ns_samedomain.c | 206 + contrib/bind9/lib/bind/nameser/ns_sign.c | 380 + contrib/bind9/lib/bind/nameser/ns_ttl.c | 159 + contrib/bind9/lib/bind/nameser/ns_verify.c | 480 + contrib/bind9/lib/bind/port/Makefile.in | 14 + contrib/bind9/lib/bind/port/freebsd/Makefile.in | 14 + .../lib/bind/port/freebsd/include/Makefile.in | 34 + .../lib/bind/port/freebsd/include/sys/bitypes.h | 37 + contrib/bind9/lib/bind/port_after.h.in | 395 + contrib/bind9/lib/bind/port_before.h.in | 138 + contrib/bind9/lib/bind/resolv/Makefile.in | 34 + contrib/bind9/lib/bind/resolv/herror.c | 127 + contrib/bind9/lib/bind/resolv/res_comp.c | 251 + contrib/bind9/lib/bind/resolv/res_data.c | 291 + contrib/bind9/lib/bind/resolv/res_debug.c | 1163 + contrib/bind9/lib/bind/resolv/res_debug.h | 34 + contrib/bind9/lib/bind/resolv/res_findzonecut.c | 722 + contrib/bind9/lib/bind/resolv/res_init.c | 740 + contrib/bind9/lib/bind/resolv/res_mkquery.c | 256 + contrib/bind9/lib/bind/resolv/res_mkupdate.c | 1159 + contrib/bind9/lib/bind/resolv/res_mkupdate.h | 24 + contrib/bind9/lib/bind/resolv/res_private.h | 20 + contrib/bind9/lib/bind/resolv/res_query.c | 432 + contrib/bind9/lib/bind/resolv/res_send.c | 1052 + contrib/bind9/lib/bind/resolv/res_sendsigned.c | 159 + contrib/bind9/lib/bind/resolv/res_update.c | 212 + contrib/bind9/lib/bind9/Makefile.in | 76 + contrib/bind9/lib/bind9/api | 3 + contrib/bind9/lib/bind9/check.c | 1412 + contrib/bind9/lib/bind9/getaddresses.c | 229 + contrib/bind9/lib/bind9/include/Makefile.in | 25 + contrib/bind9/lib/bind9/include/bind9/Makefile.in | 42 + contrib/bind9/lib/bind9/include/bind9/check.h | 54 + .../bind9/lib/bind9/include/bind9/getaddresses.h | 59 + contrib/bind9/lib/bind9/include/bind9/version.h | 26 + contrib/bind9/lib/bind9/version.c | 26 + contrib/bind9/lib/dns/Makefile.in | 164 + contrib/bind9/lib/dns/acl.c | 446 + contrib/bind9/lib/dns/adb.c | 3575 +++ contrib/bind9/lib/dns/api | 3 + contrib/bind9/lib/dns/byaddr.c | 314 + contrib/bind9/lib/dns/cache.c | 1058 + contrib/bind9/lib/dns/callbacks.c | 111 + contrib/bind9/lib/dns/compress.c | 316 + contrib/bind9/lib/dns/db.c | 793 + contrib/bind9/lib/dns/dbiterator.c | 141 + contrib/bind9/lib/dns/dbtable.c | 291 + contrib/bind9/lib/dns/diff.c | 539 + contrib/bind9/lib/dns/dispatch.c | 2199 ++ contrib/bind9/lib/dns/dnssec.c | 857 + contrib/bind9/lib/dns/ds.c | 83 + contrib/bind9/lib/dns/forward.c | 195 + contrib/bind9/lib/dns/gen-unix.h | 92 + contrib/bind9/lib/dns/gen.c | 878 + contrib/bind9/lib/dns/include/Makefile.in | 25 + contrib/bind9/lib/dns/include/dns/Makefile.in | 54 + contrib/bind9/lib/dns/include/dns/acl.h | 221 + contrib/bind9/lib/dns/include/dns/adb.h | 596 + contrib/bind9/lib/dns/include/dns/bit.h | 37 + contrib/bind9/lib/dns/include/dns/byaddr.h | 169 + contrib/bind9/lib/dns/include/dns/cache.h | 255 + contrib/bind9/lib/dns/include/dns/callbacks.h | 83 + contrib/bind9/lib/dns/include/dns/cert.h | 67 + contrib/bind9/lib/dns/include/dns/compress.h | 248 + contrib/bind9/lib/dns/include/dns/db.h | 1271 + contrib/bind9/lib/dns/include/dns/dbiterator.h | 298 + contrib/bind9/lib/dns/include/dns/dbtable.h | 164 + contrib/bind9/lib/dns/include/dns/diff.h | 279 + contrib/bind9/lib/dns/include/dns/dispatch.h | 442 + contrib/bind9/lib/dns/include/dns/dnssec.h | 179 + contrib/bind9/lib/dns/include/dns/ds.h | 56 + contrib/bind9/lib/dns/include/dns/events.h | 70 + contrib/bind9/lib/dns/include/dns/fixedname.h | 83 + contrib/bind9/lib/dns/include/dns/forward.h | 98 + contrib/bind9/lib/dns/include/dns/journal.h | 271 + contrib/bind9/lib/dns/include/dns/keyflags.h | 52 + contrib/bind9/lib/dns/include/dns/keytable.h | 255 + contrib/bind9/lib/dns/include/dns/keyvalues.h | 96 + contrib/bind9/lib/dns/include/dns/lib.h | 39 + contrib/bind9/lib/dns/include/dns/log.h | 103 + contrib/bind9/lib/dns/include/dns/lookup.h | 138 + contrib/bind9/lib/dns/include/dns/master.h | 214 + contrib/bind9/lib/dns/include/dns/masterdump.h | 303 + contrib/bind9/lib/dns/include/dns/message.h | 1297 + contrib/bind9/lib/dns/include/dns/name.h | 1246 + contrib/bind9/lib/dns/include/dns/ncache.h | 158 + contrib/bind9/lib/dns/include/dns/nsec.h | 67 + contrib/bind9/lib/dns/include/dns/opcode.h | 49 + contrib/bind9/lib/dns/include/dns/order.h | 97 + contrib/bind9/lib/dns/include/dns/peer.h | 177 + contrib/bind9/lib/dns/include/dns/portlist.h | 99 + contrib/bind9/lib/dns/include/dns/rbt.h | 835 + contrib/bind9/lib/dns/include/dns/rcode.h | 96 + contrib/bind9/lib/dns/include/dns/rdata.h | 706 + contrib/bind9/lib/dns/include/dns/rdataclass.h | 79 + contrib/bind9/lib/dns/include/dns/rdatalist.h | 104 + contrib/bind9/lib/dns/include/dns/rdataset.h | 468 + contrib/bind9/lib/dns/include/dns/rdatasetiter.h | 171 + contrib/bind9/lib/dns/include/dns/rdataslab.h | 167 + contrib/bind9/lib/dns/include/dns/rdatatype.h | 81 + contrib/bind9/lib/dns/include/dns/request.h | 371 + contrib/bind9/lib/dns/include/dns/resolver.h | 431 + contrib/bind9/lib/dns/include/dns/result.h | 186 + contrib/bind9/lib/dns/include/dns/rootns.h | 35 + contrib/bind9/lib/dns/include/dns/sdb.h | 206 + contrib/bind9/lib/dns/include/dns/secalg.h | 69 + contrib/bind9/lib/dns/include/dns/secproto.h | 69 + contrib/bind9/lib/dns/include/dns/soa.h | 80 + contrib/bind9/lib/dns/include/dns/ssu.h | 157 + contrib/bind9/lib/dns/include/dns/stats.h | 57 + contrib/bind9/lib/dns/include/dns/tcpmsg.h | 145 + contrib/bind9/lib/dns/include/dns/time.h | 70 + contrib/bind9/lib/dns/include/dns/timer.h | 50 + contrib/bind9/lib/dns/include/dns/tkey.h | 196 + contrib/bind9/lib/dns/include/dns/tsig.h | 242 + contrib/bind9/lib/dns/include/dns/ttl.h | 76 + contrib/bind9/lib/dns/include/dns/types.h | 299 + contrib/bind9/lib/dns/include/dns/validator.h | 201 + contrib/bind9/lib/dns/include/dns/version.h | 26 + contrib/bind9/lib/dns/include/dns/view.h | 789 + contrib/bind9/lib/dns/include/dns/xfrin.h | 107 + contrib/bind9/lib/dns/include/dns/zone.h | 1430 + contrib/bind9/lib/dns/include/dns/zonekey.h | 40 + contrib/bind9/lib/dns/include/dns/zt.h | 167 + contrib/bind9/lib/dns/journal.c | 2131 ++ contrib/bind9/lib/dns/keytable.c | 396 + contrib/bind9/lib/dns/lib.c | 62 + contrib/bind9/lib/dns/log.c | 93 + contrib/bind9/lib/dns/lookup.c | 487 + contrib/bind9/lib/dns/master.c | 2376 ++ contrib/bind9/lib/dns/masterdump.c | 1455 + contrib/bind9/lib/dns/message.c | 3160 ++ contrib/bind9/lib/dns/name.c | 2202 ++ contrib/bind9/lib/dns/ncache.c | 554 + contrib/bind9/lib/dns/nsec.c | 218 + contrib/bind9/lib/dns/order.c | 157 + contrib/bind9/lib/dns/peer.c | 522 + contrib/bind9/lib/dns/portlist.c | 260 + contrib/bind9/lib/dns/rbt.c | 2543 ++ contrib/bind9/lib/dns/rbtdb.c | 5706 ++++ contrib/bind9/lib/dns/rbtdb.h | 43 + contrib/bind9/lib/dns/rbtdb64.c | 21 + contrib/bind9/lib/dns/rbtdb64.h | 44 + contrib/bind9/lib/dns/rcode.c | 473 + contrib/bind9/lib/dns/rdata.c | 1720 + contrib/bind9/lib/dns/rdata/any_255/tsig_250.c | 593 + contrib/bind9/lib/dns/rdata/any_255/tsig_250.h | 39 + contrib/bind9/lib/dns/rdata/generic/afsdb_18.c | 309 + contrib/bind9/lib/dns/rdata/generic/afsdb_18.h | 33 + contrib/bind9/lib/dns/rdata/generic/cert_37.c | 280 + contrib/bind9/lib/dns/rdata/generic/cert_37.h | 34 + contrib/bind9/lib/dns/rdata/generic/cname_5.c | 232 + contrib/bind9/lib/dns/rdata/generic/cname_5.h | 29 + contrib/bind9/lib/dns/rdata/generic/dlv_65323.c | 281 + contrib/bind9/lib/dns/rdata/generic/dlv_65323.h | 33 + contrib/bind9/lib/dns/rdata/generic/dname_39.c | 233 + contrib/bind9/lib/dns/rdata/generic/dname_39.h | 31 + contrib/bind9/lib/dns/rdata/generic/dnskey_48.c | 312 + contrib/bind9/lib/dns/rdata/generic/dnskey_48.h | 36 + contrib/bind9/lib/dns/rdata/generic/ds_43.c | 283 + contrib/bind9/lib/dns/rdata/generic/ds_43.h | 34 + contrib/bind9/lib/dns/rdata/generic/gpos_27.c | 252 + contrib/bind9/lib/dns/rdata/generic/gpos_27.h | 36 + contrib/bind9/lib/dns/rdata/generic/hinfo_13.c | 224 + contrib/bind9/lib/dns/rdata/generic/hinfo_13.h | 32 + contrib/bind9/lib/dns/rdata/generic/isdn_20.c | 234 + contrib/bind9/lib/dns/rdata/generic/isdn_20.h | 34 + contrib/bind9/lib/dns/rdata/generic/key_25.c | 312 + contrib/bind9/lib/dns/rdata/generic/key_25.h | 36 + contrib/bind9/lib/dns/rdata/generic/loc_29.c | 794 + contrib/bind9/lib/dns/rdata/generic/loc_29.h | 42 + contrib/bind9/lib/dns/rdata/generic/mb_7.c | 234 + contrib/bind9/lib/dns/rdata/generic/mb_7.h | 29 + contrib/bind9/lib/dns/rdata/generic/md_3.c | 236 + contrib/bind9/lib/dns/rdata/generic/md_3.h | 30 + contrib/bind9/lib/dns/rdata/generic/mf_4.c | 235 + contrib/bind9/lib/dns/rdata/generic/mf_4.h | 29 + contrib/bind9/lib/dns/rdata/generic/mg_8.c | 230 + contrib/bind9/lib/dns/rdata/generic/mg_8.h | 29 + contrib/bind9/lib/dns/rdata/generic/minfo_14.c | 324 + contrib/bind9/lib/dns/rdata/generic/minfo_14.h | 30 + contrib/bind9/lib/dns/rdata/generic/mr_9.c | 231 + contrib/bind9/lib/dns/rdata/generic/mr_9.h | 29 + contrib/bind9/lib/dns/rdata/generic/mx_15.c | 288 + contrib/bind9/lib/dns/rdata/generic/mx_15.h | 30 + contrib/bind9/lib/dns/rdata/generic/ns_2.c | 251 + contrib/bind9/lib/dns/rdata/generic/ns_2.h | 30 + contrib/bind9/lib/dns/rdata/generic/nsec_47.c | 366 + contrib/bind9/lib/dns/rdata/generic/nsec_47.h | 33 + contrib/bind9/lib/dns/rdata/generic/null_10.c | 192 + contrib/bind9/lib/dns/rdata/generic/null_10.h | 31 + contrib/bind9/lib/dns/rdata/generic/nxt_30.c | 329 + contrib/bind9/lib/dns/rdata/generic/nxt_30.h | 33 + contrib/bind9/lib/dns/rdata/generic/opt_41.c | 280 + contrib/bind9/lib/dns/rdata/generic/opt_41.h | 54 + contrib/bind9/lib/dns/rdata/generic/proforma.c | 173 + contrib/bind9/lib/dns/rdata/generic/proforma.h | 29 + contrib/bind9/lib/dns/rdata/generic/ptr_12.c | 291 + contrib/bind9/lib/dns/rdata/generic/ptr_12.h | 29 + contrib/bind9/lib/dns/rdata/generic/rp_17.c | 314 + contrib/bind9/lib/dns/rdata/generic/rp_17.h | 33 + contrib/bind9/lib/dns/rdata/generic/rrsig_46.c | 551 + contrib/bind9/lib/dns/rdata/generic/rrsig_46.h | 40 + contrib/bind9/lib/dns/rdata/generic/rt_21.c | 311 + contrib/bind9/lib/dns/rdata/generic/rt_21.h | 32 + contrib/bind9/lib/dns/rdata/generic/sig_24.c | 578 + contrib/bind9/lib/dns/rdata/generic/sig_24.h | 41 + contrib/bind9/lib/dns/rdata/generic/soa_6.c | 443 + contrib/bind9/lib/dns/rdata/generic/soa_6.h | 36 + contrib/bind9/lib/dns/rdata/generic/sshfp_44.c | 262 + contrib/bind9/lib/dns/rdata/generic/sshfp_44.h | 34 + contrib/bind9/lib/dns/rdata/generic/tkey_249.c | 555 + contrib/bind9/lib/dns/rdata/generic/tkey_249.h | 40 + contrib/bind9/lib/dns/rdata/generic/txt_16.c | 238 + contrib/bind9/lib/dns/rdata/generic/txt_16.h | 51 + contrib/bind9/lib/dns/rdata/generic/unspec_103.c | 189 + contrib/bind9/lib/dns/rdata/generic/unspec_103.h | 30 + contrib/bind9/lib/dns/rdata/generic/x25_19.c | 219 + contrib/bind9/lib/dns/rdata/generic/x25_19.h | 32 + contrib/bind9/lib/dns/rdata/hs_4/a_1.c | 232 + contrib/bind9/lib/dns/rdata/hs_4/a_1.h | 28 + contrib/bind9/lib/dns/rdata/in_1/a6_38.c | 461 + contrib/bind9/lib/dns/rdata/in_1/a6_38.h | 33 + contrib/bind9/lib/dns/rdata/in_1/a_1.c | 236 + contrib/bind9/lib/dns/rdata/in_1/a_1.h | 28 + contrib/bind9/lib/dns/rdata/in_1/aaaa_28.c | 233 + contrib/bind9/lib/dns/rdata/in_1/aaaa_28.h | 30 + contrib/bind9/lib/dns/rdata/in_1/apl_42.c | 402 + contrib/bind9/lib/dns/rdata/in_1/apl_42.h | 55 + contrib/bind9/lib/dns/rdata/in_1/kx_36.c | 288 + contrib/bind9/lib/dns/rdata/in_1/kx_36.h | 32 + contrib/bind9/lib/dns/rdata/in_1/naptr_35.c | 578 + contrib/bind9/lib/dns/rdata/in_1/naptr_35.h | 39 + contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.c | 245 + contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.h | 31 + contrib/bind9/lib/dns/rdata/in_1/nsap_22.c | 255 + contrib/bind9/lib/dns/rdata/in_1/nsap_22.h | 32 + contrib/bind9/lib/dns/rdata/in_1/px_26.c | 374 + contrib/bind9/lib/dns/rdata/in_1/px_26.h | 33 + contrib/bind9/lib/dns/rdata/in_1/srv_33.c | 373 + contrib/bind9/lib/dns/rdata/in_1/srv_33.h | 36 + contrib/bind9/lib/dns/rdata/in_1/wks_11.c | 349 + contrib/bind9/lib/dns/rdata/in_1/wks_11.h | 32 + contrib/bind9/lib/dns/rdata/rdatastructpre.h | 42 + contrib/bind9/lib/dns/rdata/rdatastructsuf.h | 22 + contrib/bind9/lib/dns/rdatalist.c | 224 + contrib/bind9/lib/dns/rdatalist_p.h | 55 + contrib/bind9/lib/dns/rdataset.c | 626 + contrib/bind9/lib/dns/rdatasetiter.c | 78 + contrib/bind9/lib/dns/rdataslab.c | 715 + contrib/bind9/lib/dns/request.c | 1455 + contrib/bind9/lib/dns/resolver.c | 6473 ++++ contrib/bind9/lib/dns/result.c | 272 + contrib/bind9/lib/dns/rootns.c | 247 + contrib/bind9/lib/dns/sdb.c | 1528 + contrib/bind9/lib/dns/sec/Makefile.in | 25 + contrib/bind9/lib/dns/sec/dst/Makefile.in | 48 + contrib/bind9/lib/dns/sec/dst/dst_api.c | 1185 + contrib/bind9/lib/dns/sec/dst/dst_internal.h | 134 + contrib/bind9/lib/dns/sec/dst/dst_lib.c | 65 + contrib/bind9/lib/dns/sec/dst/dst_openssl.h | 33 + contrib/bind9/lib/dns/sec/dst/dst_parse.c | 412 + contrib/bind9/lib/dns/sec/dst/dst_parse.h | 95 + contrib/bind9/lib/dns/sec/dst/dst_result.c | 86 + contrib/bind9/lib/dns/sec/dst/gssapi_link.c | 220 + contrib/bind9/lib/dns/sec/dst/gssapictx.c | 262 + contrib/bind9/lib/dns/sec/dst/hmac_link.c | 282 + contrib/bind9/lib/dns/sec/dst/include/Makefile.in | 25 + .../bind9/lib/dns/sec/dst/include/dst/Makefile.in | 37 + contrib/bind9/lib/dns/sec/dst/include/dst/dst.h | 570 + contrib/bind9/lib/dns/sec/dst/include/dst/gssapi.h | 56 + contrib/bind9/lib/dns/sec/dst/include/dst/lib.h | 39 + contrib/bind9/lib/dns/sec/dst/include/dst/result.h | 68 + contrib/bind9/lib/dns/sec/dst/key.c | 126 + contrib/bind9/lib/dns/sec/dst/openssl_link.c | 219 + contrib/bind9/lib/dns/sec/dst/openssldh_link.c | 608 + contrib/bind9/lib/dns/sec/dst/openssldsa_link.c | 443 + contrib/bind9/lib/dns/sec/dst/opensslrsa_link.c | 567 + contrib/bind9/lib/dns/soa.c | 109 + contrib/bind9/lib/dns/ssu.c | 357 + contrib/bind9/lib/dns/stats.c | 53 + contrib/bind9/lib/dns/tcpmsg.c | 240 + contrib/bind9/lib/dns/time.c | 172 + contrib/bind9/lib/dns/timer.c | 58 + contrib/bind9/lib/dns/tkey.c | 1240 + contrib/bind9/lib/dns/tsig.c | 1218 + contrib/bind9/lib/dns/ttl.c | 214 + contrib/bind9/lib/dns/validator.c | 2823 ++ contrib/bind9/lib/dns/version.c | 26 + contrib/bind9/lib/dns/view.c | 1332 + contrib/bind9/lib/dns/xfrin.c | 1402 + contrib/bind9/lib/dns/zone.c | 6804 ++++ contrib/bind9/lib/dns/zonekey.c | 53 + contrib/bind9/lib/dns/zt.c | 320 + contrib/bind9/lib/isc/Makefile.in | 111 + contrib/bind9/lib/isc/api | 3 + contrib/bind9/lib/isc/assertions.c | 93 + contrib/bind9/lib/isc/base64.c | 246 + contrib/bind9/lib/isc/bitstring.c | 125 + contrib/bind9/lib/isc/buffer.c | 411 + contrib/bind9/lib/isc/bufferlist.c | 62 + contrib/bind9/lib/isc/commandline.c | 222 + contrib/bind9/lib/isc/entropy.c | 1256 + contrib/bind9/lib/isc/error.c | 101 + contrib/bind9/lib/isc/event.c | 87 + contrib/bind9/lib/isc/fsaccess.c | 101 + contrib/bind9/lib/isc/hash.c | 387 + contrib/bind9/lib/isc/heap.c | 252 + contrib/bind9/lib/isc/hex.c | 199 + contrib/bind9/lib/isc/hmacmd5.c | 113 + contrib/bind9/lib/isc/include/Makefile.in | 25 + contrib/bind9/lib/isc/include/isc/Makefile.in | 57 + contrib/bind9/lib/isc/include/isc/app.h | 212 + contrib/bind9/lib/isc/include/isc/assertions.h | 120 + contrib/bind9/lib/isc/include/isc/base64.h | 97 + contrib/bind9/lib/isc/include/isc/bitstring.h | 152 + contrib/bind9/lib/isc/include/isc/boolean.h | 29 + contrib/bind9/lib/isc/include/isc/buffer.h | 800 + contrib/bind9/lib/isc/include/isc/bufferlist.h | 86 + contrib/bind9/lib/isc/include/isc/commandline.h | 47 + contrib/bind9/lib/isc/include/isc/entropy.h | 288 + contrib/bind9/lib/isc/include/isc/error.h | 55 + contrib/bind9/lib/isc/include/isc/event.h | 115 + contrib/bind9/lib/isc/include/isc/eventclass.h | 53 + contrib/bind9/lib/isc/include/isc/file.h | 252 + contrib/bind9/lib/isc/include/isc/formatcheck.h | 34 + contrib/bind9/lib/isc/include/isc/fsaccess.h | 177 + contrib/bind9/lib/isc/include/isc/hash.h | 175 + contrib/bind9/lib/isc/include/isc/heap.h | 51 + contrib/bind9/lib/isc/include/isc/hex.h | 96 + contrib/bind9/lib/isc/include/isc/hmacmd5.h | 60 + contrib/bind9/lib/isc/include/isc/interfaceiter.h | 134 + contrib/bind9/lib/isc/include/isc/ipv6.h | 148 + contrib/bind9/lib/isc/include/isc/lang.h | 31 + contrib/bind9/lib/isc/include/isc/lex.h | 410 + contrib/bind9/lib/isc/include/isc/lfsr.h | 133 + contrib/bind9/lib/isc/include/isc/lib.h | 39 + contrib/bind9/lib/isc/include/isc/list.h | 180 + contrib/bind9/lib/isc/include/isc/log.h | 879 + contrib/bind9/lib/isc/include/isc/magic.h | 40 + contrib/bind9/lib/isc/include/isc/md5.h | 72 + contrib/bind9/lib/isc/include/isc/mem.h | 452 + contrib/bind9/lib/isc/include/isc/msgcat.h | 132 + contrib/bind9/lib/isc/include/isc/msgs.h | 183 + contrib/bind9/lib/isc/include/isc/mutexblock.h | 69 + contrib/bind9/lib/isc/include/isc/netaddr.h | 149 + contrib/bind9/lib/isc/include/isc/netscope.h | 40 + contrib/bind9/lib/isc/include/isc/ondestroy.h | 108 + contrib/bind9/lib/isc/include/isc/os.h | 36 + contrib/bind9/lib/isc/include/isc/parseint.h | 63 + contrib/bind9/lib/isc/include/isc/platform.h.in | 255 + contrib/bind9/lib/isc/include/isc/print.h | 81 + contrib/bind9/lib/isc/include/isc/quota.h | 114 + contrib/bind9/lib/isc/include/isc/random.h | 60 + contrib/bind9/lib/isc/include/isc/ratelimiter.h | 132 + contrib/bind9/lib/isc/include/isc/refcount.h | 164 + contrib/bind9/lib/isc/include/isc/region.h | 95 + contrib/bind9/lib/isc/include/isc/resource.h | 85 + contrib/bind9/lib/isc/include/isc/result.h | 106 + contrib/bind9/lib/isc/include/isc/resultclass.h | 54 + contrib/bind9/lib/isc/include/isc/rwlock.h | 95 + contrib/bind9/lib/isc/include/isc/serial.h | 76 + contrib/bind9/lib/isc/include/isc/sha1.h | 58 + contrib/bind9/lib/isc/include/isc/sockaddr.h | 202 + contrib/bind9/lib/isc/include/isc/socket.h | 704 + contrib/bind9/lib/isc/include/isc/stdio.h | 67 + contrib/bind9/lib/isc/include/isc/stdlib.h | 38 + contrib/bind9/lib/isc/include/isc/string.h | 76 + contrib/bind9/lib/isc/include/isc/symtab.h | 127 + contrib/bind9/lib/isc/include/isc/task.h | 615 + contrib/bind9/lib/isc/include/isc/taskpool.h | 107 + contrib/bind9/lib/isc/include/isc/timer.h | 336 + contrib/bind9/lib/isc/include/isc/types.h | 103 + contrib/bind9/lib/isc/include/isc/util.h | 225 + contrib/bind9/lib/isc/include/isc/version.h | 26 + contrib/bind9/lib/isc/inet_aton.c | 195 + contrib/bind9/lib/isc/inet_ntop.c | 195 + contrib/bind9/lib/isc/inet_pton.c | 211 + contrib/bind9/lib/isc/lex.c | 921 + contrib/bind9/lib/isc/lfsr.c | 161 + contrib/bind9/lib/isc/lib.c | 77 + contrib/bind9/lib/isc/log.c | 1753 + contrib/bind9/lib/isc/md5.c | 249 + contrib/bind9/lib/isc/mem.c | 1776 ++ contrib/bind9/lib/isc/mutexblock.c | 57 + contrib/bind9/lib/isc/netaddr.c | 357 + contrib/bind9/lib/isc/netscope.c | 72 + contrib/bind9/lib/isc/nls/Makefile.in | 37 + contrib/bind9/lib/isc/nls/msgcat.c | 129 + contrib/bind9/lib/isc/nothreads/Makefile.in | 38 + contrib/bind9/lib/isc/nothreads/condition.c | 22 + .../bind9/lib/isc/nothreads/include/Makefile.in | 25 + .../lib/isc/nothreads/include/isc/Makefile.in | 37 + .../lib/isc/nothreads/include/isc/condition.h | 59 + .../bind9/lib/isc/nothreads/include/isc/mutex.h | 39 + contrib/bind9/lib/isc/nothreads/include/isc/once.h | 32 + .../bind9/lib/isc/nothreads/include/isc/thread.h | 35 + contrib/bind9/lib/isc/nothreads/mutex.c | 23 + contrib/bind9/lib/isc/nothreads/thread.c | 28 + contrib/bind9/lib/isc/ondestroy.c | 83 + contrib/bind9/lib/isc/parseint.c | 70 + contrib/bind9/lib/isc/print.c | 556 + contrib/bind9/lib/isc/pthreads/Makefile.in | 38 + contrib/bind9/lib/isc/pthreads/condition.c | 72 + contrib/bind9/lib/isc/pthreads/include/Makefile.in | 25 + .../bind9/lib/isc/pthreads/include/isc/Makefile.in | 37 + .../bind9/lib/isc/pthreads/include/isc/condition.h | 63 + contrib/bind9/lib/isc/pthreads/include/isc/mutex.h | 139 + contrib/bind9/lib/isc/pthreads/include/isc/once.h | 48 + .../bind9/lib/isc/pthreads/include/isc/thread.h | 52 + contrib/bind9/lib/isc/pthreads/mutex.c | 241 + contrib/bind9/lib/isc/pthreads/thread.c | 68 + contrib/bind9/lib/isc/quota.c | 92 + contrib/bind9/lib/isc/random.c | 102 + contrib/bind9/lib/isc/ratelimiter.c | 326 + contrib/bind9/lib/isc/region.c | 43 + contrib/bind9/lib/isc/result.c | 209 + contrib/bind9/lib/isc/rwlock.c | 417 + contrib/bind9/lib/isc/serial.c | 56 + contrib/bind9/lib/isc/sha1.c | 309 + contrib/bind9/lib/isc/sockaddr.c | 463 + contrib/bind9/lib/isc/string.c | 165 + contrib/bind9/lib/isc/strtoul.c | 128 + contrib/bind9/lib/isc/symtab.c | 250 + contrib/bind9/lib/isc/task.c | 1303 + contrib/bind9/lib/isc/task_p.h | 29 + contrib/bind9/lib/isc/taskpool.c | 89 + contrib/bind9/lib/isc/timer.c | 920 + contrib/bind9/lib/isc/timer_p.h | 29 + contrib/bind9/lib/isc/unix/Makefile.in | 51 + contrib/bind9/lib/isc/unix/app.c | 681 + contrib/bind9/lib/isc/unix/dir.c | 225 + contrib/bind9/lib/isc/unix/entropy.c | 589 + contrib/bind9/lib/isc/unix/errno2result.c | 121 + contrib/bind9/lib/isc/unix/errno2result.h | 37 + contrib/bind9/lib/isc/unix/file.c | 435 + contrib/bind9/lib/isc/unix/fsaccess.c | 90 + contrib/bind9/lib/isc/unix/ifiter_getifaddrs.c | 178 + contrib/bind9/lib/isc/unix/ifiter_ioctl.c | 1016 + contrib/bind9/lib/isc/unix/ifiter_sysctl.c | 301 + contrib/bind9/lib/isc/unix/include/Makefile.in | 25 + contrib/bind9/lib/isc/unix/include/isc/Makefile.in | 38 + contrib/bind9/lib/isc/unix/include/isc/dir.h | 90 + contrib/bind9/lib/isc/unix/include/isc/int.h | 53 + contrib/bind9/lib/isc/unix/include/isc/keyboard.h | 50 + contrib/bind9/lib/isc/unix/include/isc/net.h | 327 + contrib/bind9/lib/isc/unix/include/isc/netdb.h | 56 + contrib/bind9/lib/isc/unix/include/isc/offset.h | 44 + contrib/bind9/lib/isc/unix/include/isc/stat.h | 53 + contrib/bind9/lib/isc/unix/include/isc/stdtime.h | 47 + contrib/bind9/lib/isc/unix/include/isc/strerror.h | 42 + contrib/bind9/lib/isc/unix/include/isc/syslog.h | 45 + contrib/bind9/lib/isc/unix/include/isc/time.h | 299 + contrib/bind9/lib/isc/unix/interfaceiter.c | 220 + contrib/bind9/lib/isc/unix/ipv6.c | 23 + contrib/bind9/lib/isc/unix/keyboard.c | 126 + contrib/bind9/lib/isc/unix/net.c | 344 + contrib/bind9/lib/isc/unix/os.c | 92 + contrib/bind9/lib/isc/unix/resource.c | 204 + contrib/bind9/lib/isc/unix/socket.c | 3505 ++ contrib/bind9/lib/isc/unix/socket_p.h | 33 + contrib/bind9/lib/isc/unix/stdio.c | 117 + contrib/bind9/lib/isc/unix/stdtime.c | 83 + contrib/bind9/lib/isc/unix/strerror.c | 72 + contrib/bind9/lib/isc/unix/syslog.c | 82 + contrib/bind9/lib/isc/unix/time.c | 412 + contrib/bind9/lib/isc/version.c | 26 + contrib/bind9/lib/isccc/Makefile.in | 86 + contrib/bind9/lib/isccc/alist.c | 297 + contrib/bind9/lib/isccc/api | 3 + contrib/bind9/lib/isccc/base64.c | 63 + contrib/bind9/lib/isccc/cc.c | 807 + contrib/bind9/lib/isccc/ccmsg.c | 220 + contrib/bind9/lib/isccc/include/Makefile.in | 25 + contrib/bind9/lib/isccc/include/isccc/Makefile.in | 42 + contrib/bind9/lib/isccc/include/isccc/alist.h | 72 + contrib/bind9/lib/isccc/include/isccc/base64.h | 70 + contrib/bind9/lib/isccc/include/isccc/cc.h | 88 + contrib/bind9/lib/isccc/include/isccc/ccmsg.h | 132 + contrib/bind9/lib/isccc/include/isccc/events.h | 35 + contrib/bind9/lib/isccc/include/isccc/lib.h | 40 + contrib/bind9/lib/isccc/include/isccc/result.h | 52 + contrib/bind9/lib/isccc/include/isccc/sexpr.h | 107 + contrib/bind9/lib/isccc/include/isccc/symtab.h | 123 + contrib/bind9/lib/isccc/include/isccc/symtype.h | 29 + contrib/bind9/lib/isccc/include/isccc/types.h | 38 + contrib/bind9/lib/isccc/include/isccc/util.h | 211 + contrib/bind9/lib/isccc/include/isccc/version.h | 26 + contrib/bind9/lib/isccc/lib.c | 63 + contrib/bind9/lib/isccc/result.c | 70 + contrib/bind9/lib/isccc/sexpr.c | 310 + contrib/bind9/lib/isccc/symtab.c | 278 + contrib/bind9/lib/isccc/version.c | 26 + contrib/bind9/lib/isccfg/Makefile.in | 83 + contrib/bind9/lib/isccfg/api | 3 + contrib/bind9/lib/isccfg/include/Makefile.in | 25 + .../bind9/lib/isccfg/include/isccfg/Makefile.in | 42 + contrib/bind9/lib/isccfg/include/isccfg/cfg.h | 415 + contrib/bind9/lib/isccfg/include/isccfg/grammar.h | 439 + contrib/bind9/lib/isccfg/include/isccfg/log.h | 53 + .../bind9/lib/isccfg/include/isccfg/namedconf.h | 44 + contrib/bind9/lib/isccfg/include/isccfg/version.h | 26 + contrib/bind9/lib/isccfg/log.c | 50 + contrib/bind9/lib/isccfg/namedconf.c | 1906 ++ contrib/bind9/lib/isccfg/parser.c | 2289 ++ contrib/bind9/lib/isccfg/version.c | 27 + contrib/bind9/lib/lwres/Makefile.in | 82 + contrib/bind9/lib/lwres/api | 3 + contrib/bind9/lib/lwres/assert_p.h | 33 + contrib/bind9/lib/lwres/context.c | 380 + contrib/bind9/lib/lwres/context_p.h | 59 + contrib/bind9/lib/lwres/gai_strerror.c | 52 + contrib/bind9/lib/lwres/getaddrinfo.c | 691 + contrib/bind9/lib/lwres/gethost.c | 219 + contrib/bind9/lib/lwres/getipnode.c | 1026 + contrib/bind9/lib/lwres/getnameinfo.c | 286 + contrib/bind9/lib/lwres/getrrset.c | 211 + contrib/bind9/lib/lwres/herror.c | 101 + contrib/bind9/lib/lwres/include/Makefile.in | 25 + contrib/bind9/lib/lwres/include/lwres/Makefile.in | 46 + contrib/bind9/lib/lwres/include/lwres/context.h | 133 + contrib/bind9/lib/lwres/include/lwres/int.h | 32 + contrib/bind9/lib/lwres/include/lwres/ipv6.h | 118 + contrib/bind9/lib/lwres/include/lwres/lang.h | 31 + contrib/bind9/lib/lwres/include/lwres/list.h | 119 + contrib/bind9/lib/lwres/include/lwres/lwbuffer.h | 402 + contrib/bind9/lib/lwres/include/lwres/lwpacket.h | 124 + contrib/bind9/lib/lwres/include/lwres/lwres.h | 579 + contrib/bind9/lib/lwres/include/lwres/netdb.h.in | 518 + .../bind9/lib/lwres/include/lwres/platform.h.in | 101 + contrib/bind9/lib/lwres/include/lwres/result.h | 40 + contrib/bind9/lib/lwres/include/lwres/version.h | 26 + contrib/bind9/lib/lwres/lwbuffer.c | 287 + contrib/bind9/lib/lwres/lwconfig.c | 703 + contrib/bind9/lib/lwres/lwpacket.c | 85 + contrib/bind9/lib/lwres/lwres_gabn.c | 415 + contrib/bind9/lib/lwres/lwres_gnba.c | 328 + contrib/bind9/lib/lwres/lwres_grbn.c | 416 + contrib/bind9/lib/lwres/lwres_noop.c | 255 + contrib/bind9/lib/lwres/lwresutil.c | 491 + contrib/bind9/lib/lwres/man/Makefile.in | 232 + contrib/bind9/lib/lwres/man/lwres.3 | 159 + contrib/bind9/lib/lwres/man/lwres.docbook | 244 + contrib/bind9/lib/lwres/man/lwres.html | 433 + contrib/bind9/lib/lwres/man/lwres_buffer.3 | 279 + contrib/bind9/lib/lwres/man/lwres_buffer.docbook | 378 + contrib/bind9/lib/lwres/man/lwres_buffer.html | 576 + contrib/bind9/lib/lwres/man/lwres_config.3 | 107 + contrib/bind9/lib/lwres/man/lwres_config.docbook | 159 + contrib/bind9/lib/lwres/man/lwres_config.html | 282 + contrib/bind9/lib/lwres/man/lwres_context.3 | 196 + contrib/bind9/lib/lwres/man/lwres_context.docbook | 283 + contrib/bind9/lib/lwres/man/lwres_context.html | 478 + contrib/bind9/lib/lwres/man/lwres_gabn.3 | 195 + contrib/bind9/lib/lwres/man/lwres_gabn.docbook | 255 + contrib/bind9/lib/lwres/man/lwres_gabn.html | 419 + contrib/bind9/lib/lwres/man/lwres_gai_strerror.3 | 88 + .../bind9/lib/lwres/man/lwres_gai_strerror.docbook | 161 + .../bind9/lib/lwres/man/lwres_gai_strerror.html | 295 + contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3 | 249 + .../bind9/lib/lwres/man/lwres_getaddrinfo.docbook | 372 + contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html | 693 + contrib/bind9/lib/lwres/man/lwres_gethostent.3 | 272 + .../bind9/lib/lwres/man/lwres_gethostent.docbook | 407 + contrib/bind9/lib/lwres/man/lwres_gethostent.html | 784 + contrib/bind9/lib/lwres/man/lwres_getipnode.3 | 189 + .../bind9/lib/lwres/man/lwres_getipnode.docbook | 307 + contrib/bind9/lib/lwres/man/lwres_getipnode.html | 512 + contrib/bind9/lib/lwres/man/lwres_getnameinfo.3 | 86 + .../bind9/lib/lwres/man/lwres_getnameinfo.docbook | 154 + contrib/bind9/lib/lwres/man/lwres_getnameinfo.html | 290 + contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3 | 144 + .../lib/lwres/man/lwres_getrrsetbyname.docbook | 208 + .../bind9/lib/lwres/man/lwres_getrrsetbyname.html | 360 + contrib/bind9/lib/lwres/man/lwres_gnba.3 | 188 + contrib/bind9/lib/lwres/man/lwres_gnba.docbook | 259 + contrib/bind9/lib/lwres/man/lwres_gnba.html | 409 + contrib/bind9/lib/lwres/man/lwres_hstrerror.3 | 69 + .../bind9/lib/lwres/man/lwres_hstrerror.docbook | 124 + contrib/bind9/lib/lwres/man/lwres_hstrerror.html | 241 + contrib/bind9/lib/lwres/man/lwres_inetntop.3 | 54 + contrib/bind9/lib/lwres/man/lwres_inetntop.docbook | 99 + contrib/bind9/lib/lwres/man/lwres_inetntop.html | 177 + contrib/bind9/lib/lwres/man/lwres_noop.3 | 162 + contrib/bind9/lib/lwres/man/lwres_noop.docbook | 229 + contrib/bind9/lib/lwres/man/lwres_noop.html | 388 + contrib/bind9/lib/lwres/man/lwres_packet.3 | 151 + contrib/bind9/lib/lwres/man/lwres_packet.docbook | 218 + contrib/bind9/lib/lwres/man/lwres_packet.html | 362 + contrib/bind9/lib/lwres/man/lwres_resutil.3 | 153 + contrib/bind9/lib/lwres/man/lwres_resutil.docbook | 221 + contrib/bind9/lib/lwres/man/lwres_resutil.html | 387 + contrib/bind9/lib/lwres/print.c | 553 + contrib/bind9/lib/lwres/print_p.h | 86 + contrib/bind9/lib/lwres/unix/Makefile.in | 25 + contrib/bind9/lib/lwres/unix/include/Makefile.in | 25 + .../bind9/lib/lwres/unix/include/lwres/Makefile.in | 34 + contrib/bind9/lib/lwres/unix/include/lwres/net.h | 130 + contrib/bind9/lib/lwres/version.c | 26 + contrib/bind9/libtool.m4 | 5943 ++++ contrib/bind9/ltmain.sh | 6399 ++++ contrib/bind9/make/Makefile.in | 28 + contrib/bind9/make/includes.in | 48 + contrib/bind9/make/mkdep.in | 148 + contrib/bind9/make/rules.in | 228 + contrib/bind9/mkinstalldirs | 40 + contrib/bind9/version | 10 + 1090 files changed, 509412 insertions(+) create mode 100644 contrib/bind9/CHANGES create mode 100644 contrib/bind9/COPYRIGHT create mode 100644 contrib/bind9/FAQ create mode 100644 contrib/bind9/Makefile.in create mode 100644 contrib/bind9/README create mode 100644 contrib/bind9/acconfig.h create mode 100644 contrib/bind9/bin/Makefile.in create mode 100644 contrib/bind9/bin/check/Makefile.in create mode 100644 contrib/bind9/bin/check/check-tool.c create mode 100644 contrib/bind9/bin/check/check-tool.h create mode 100644 contrib/bind9/bin/check/named-checkconf.8 create mode 100644 contrib/bind9/bin/check/named-checkconf.c create mode 100644 contrib/bind9/bin/check/named-checkconf.docbook create mode 100644 contrib/bind9/bin/check/named-checkconf.html create mode 100644 contrib/bind9/bin/check/named-checkzone.8 create mode 100644 contrib/bind9/bin/check/named-checkzone.c create mode 100644 contrib/bind9/bin/check/named-checkzone.docbook create mode 100644 contrib/bind9/bin/check/named-checkzone.html create mode 100644 contrib/bind9/bin/dig/Makefile.in create mode 100644 contrib/bind9/bin/dig/dig.1 create mode 100644 contrib/bind9/bin/dig/dig.c create mode 100644 contrib/bind9/bin/dig/dig.docbook create mode 100644 contrib/bind9/bin/dig/dig.html create mode 100644 contrib/bind9/bin/dig/dighost.c create mode 100644 contrib/bind9/bin/dig/host.1 create mode 100644 contrib/bind9/bin/dig/host.c create mode 100644 contrib/bind9/bin/dig/host.docbook create mode 100644 contrib/bind9/bin/dig/host.html create mode 100644 contrib/bind9/bin/dig/include/dig/dig.h create mode 100644 contrib/bind9/bin/dig/nslookup.1 create mode 100644 contrib/bind9/bin/dig/nslookup.c create mode 100644 contrib/bind9/bin/dig/nslookup.docbook create mode 100644 contrib/bind9/bin/dig/nslookup.html create mode 100644 contrib/bind9/bin/dnssec/Makefile.in create mode 100644 contrib/bind9/bin/dnssec/dnssec-keygen.8 create mode 100644 contrib/bind9/bin/dnssec/dnssec-keygen.c create mode 100644 contrib/bind9/bin/dnssec/dnssec-keygen.docbook create mode 100644 contrib/bind9/bin/dnssec/dnssec-keygen.html create mode 100644 contrib/bind9/bin/dnssec/dnssec-makekeyset.8 create mode 100644 contrib/bind9/bin/dnssec/dnssec-makekeyset.c create mode 100644 contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook create mode 100644 contrib/bind9/bin/dnssec/dnssec-makekeyset.html create mode 100644 contrib/bind9/bin/dnssec/dnssec-signkey.8 create mode 100644 contrib/bind9/bin/dnssec/dnssec-signkey.c create mode 100644 contrib/bind9/bin/dnssec/dnssec-signkey.docbook create mode 100644 contrib/bind9/bin/dnssec/dnssec-signkey.html create mode 100644 contrib/bind9/bin/dnssec/dnssec-signzone.8 create mode 100644 contrib/bind9/bin/dnssec/dnssec-signzone.c create mode 100644 contrib/bind9/bin/dnssec/dnssec-signzone.docbook create mode 100644 contrib/bind9/bin/dnssec/dnssec-signzone.html create mode 100644 contrib/bind9/bin/dnssec/dnssectool.c create mode 100644 contrib/bind9/bin/dnssec/dnssectool.h create mode 100644 contrib/bind9/bin/named/Makefile.in create mode 100644 contrib/bind9/bin/named/aclconf.c create mode 100644 contrib/bind9/bin/named/builtin.c create mode 100644 contrib/bind9/bin/named/client.c create mode 100644 contrib/bind9/bin/named/config.c create mode 100644 contrib/bind9/bin/named/control.c create mode 100644 contrib/bind9/bin/named/controlconf.c create mode 100644 contrib/bind9/bin/named/include/named/aclconf.h create mode 100644 contrib/bind9/bin/named/include/named/builtin.h create mode 100644 contrib/bind9/bin/named/include/named/client.h create mode 100644 contrib/bind9/bin/named/include/named/config.h create mode 100644 contrib/bind9/bin/named/include/named/control.h create mode 100644 contrib/bind9/bin/named/include/named/globals.h create mode 100644 contrib/bind9/bin/named/include/named/interfacemgr.h create mode 100644 contrib/bind9/bin/named/include/named/listenlist.h create mode 100644 contrib/bind9/bin/named/include/named/log.h create mode 100644 contrib/bind9/bin/named/include/named/logconf.h create mode 100644 contrib/bind9/bin/named/include/named/lwaddr.h create mode 100644 contrib/bind9/bin/named/include/named/lwdclient.h create mode 100644 contrib/bind9/bin/named/include/named/lwresd.h create mode 100644 contrib/bind9/bin/named/include/named/lwsearch.h create mode 100644 contrib/bind9/bin/named/include/named/main.h create mode 100644 contrib/bind9/bin/named/include/named/notify.h create mode 100644 contrib/bind9/bin/named/include/named/query.h create mode 100644 contrib/bind9/bin/named/include/named/server.h create mode 100644 contrib/bind9/bin/named/include/named/sortlist.h create mode 100644 contrib/bind9/bin/named/include/named/tkeyconf.h create mode 100644 contrib/bind9/bin/named/include/named/tsigconf.h create mode 100644 contrib/bind9/bin/named/include/named/types.h create mode 100644 contrib/bind9/bin/named/include/named/update.h create mode 100644 contrib/bind9/bin/named/include/named/xfrout.h create mode 100644 contrib/bind9/bin/named/include/named/zoneconf.h create mode 100644 contrib/bind9/bin/named/interfacemgr.c create mode 100644 contrib/bind9/bin/named/listenlist.c create mode 100644 contrib/bind9/bin/named/log.c create mode 100644 contrib/bind9/bin/named/logconf.c create mode 100644 contrib/bind9/bin/named/lwaddr.c create mode 100644 contrib/bind9/bin/named/lwdclient.c create mode 100644 contrib/bind9/bin/named/lwderror.c create mode 100644 contrib/bind9/bin/named/lwdgabn.c create mode 100644 contrib/bind9/bin/named/lwdgnba.c create mode 100644 contrib/bind9/bin/named/lwdgrbn.c create mode 100644 contrib/bind9/bin/named/lwdnoop.c create mode 100644 contrib/bind9/bin/named/lwresd.8 create mode 100644 contrib/bind9/bin/named/lwresd.c create mode 100644 contrib/bind9/bin/named/lwresd.docbook create mode 100644 contrib/bind9/bin/named/lwresd.html create mode 100644 contrib/bind9/bin/named/lwsearch.c create mode 100644 contrib/bind9/bin/named/main.c create mode 100644 contrib/bind9/bin/named/named.8 create mode 100644 contrib/bind9/bin/named/named.conf.5 create mode 100644 contrib/bind9/bin/named/named.conf.docbook create mode 100644 contrib/bind9/bin/named/named.conf.html create mode 100644 contrib/bind9/bin/named/named.docbook create mode 100644 contrib/bind9/bin/named/named.html create mode 100644 contrib/bind9/bin/named/notify.c create mode 100644 contrib/bind9/bin/named/query.c create mode 100644 contrib/bind9/bin/named/server.c create mode 100644 contrib/bind9/bin/named/sortlist.c create mode 100644 contrib/bind9/bin/named/tkeyconf.c create mode 100644 contrib/bind9/bin/named/tsigconf.c create mode 100644 contrib/bind9/bin/named/unix/Makefile.in create mode 100644 contrib/bind9/bin/named/unix/include/named/os.h create mode 100644 contrib/bind9/bin/named/unix/os.c create mode 100644 contrib/bind9/bin/named/update.c create mode 100644 contrib/bind9/bin/named/xfrout.c create mode 100644 contrib/bind9/bin/named/zoneconf.c create mode 100644 contrib/bind9/bin/nsupdate/Makefile.in create mode 100644 contrib/bind9/bin/nsupdate/nsupdate.8 create mode 100644 contrib/bind9/bin/nsupdate/nsupdate.c create mode 100644 contrib/bind9/bin/nsupdate/nsupdate.docbook create mode 100644 contrib/bind9/bin/nsupdate/nsupdate.html create mode 100644 contrib/bind9/bin/rndc/Makefile.in create mode 100644 contrib/bind9/bin/rndc/include/rndc/os.h create mode 100644 contrib/bind9/bin/rndc/rndc-confgen.8 create mode 100644 contrib/bind9/bin/rndc/rndc-confgen.c create mode 100644 contrib/bind9/bin/rndc/rndc-confgen.docbook create mode 100644 contrib/bind9/bin/rndc/rndc-confgen.html create mode 100644 contrib/bind9/bin/rndc/rndc.8 create mode 100644 contrib/bind9/bin/rndc/rndc.c create mode 100644 contrib/bind9/bin/rndc/rndc.conf create mode 100644 contrib/bind9/bin/rndc/rndc.conf.5 create mode 100644 contrib/bind9/bin/rndc/rndc.conf.docbook create mode 100644 contrib/bind9/bin/rndc/rndc.conf.html create mode 100644 contrib/bind9/bin/rndc/rndc.docbook create mode 100644 contrib/bind9/bin/rndc/rndc.html create mode 100644 contrib/bind9/bin/rndc/unix/Makefile.in create mode 100644 contrib/bind9/bin/rndc/unix/os.c create mode 100644 contrib/bind9/bin/rndc/util.c create mode 100644 contrib/bind9/bin/rndc/util.h create mode 100644 contrib/bind9/config.guess create mode 100644 contrib/bind9/config.sub create mode 100644 contrib/bind9/configure.in create mode 100644 contrib/bind9/doc/Makefile.in create mode 100644 contrib/bind9/doc/arm/Bv9ARM-book.xml create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch01.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch02.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch03.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch04.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch05.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch06.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch07.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch08.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.ch09.html create mode 100644 contrib/bind9/doc/arm/Bv9ARM.html create mode 100644 contrib/bind9/doc/arm/Makefile.in create mode 100644 contrib/bind9/doc/arm/README-SGML create mode 100644 contrib/bind9/doc/arm/isc.color.gif create mode 100644 contrib/bind9/doc/arm/nominum-docbook-html.dsl.in create mode 100644 contrib/bind9/doc/arm/nominum-docbook-print.dsl.in create mode 100644 contrib/bind9/doc/arm/validate.sh.in create mode 100644 contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt create mode 100644 contrib/bind9/doc/draft/draft-daigle-napstr-04.txt create mode 100644 contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt create mode 100644 contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt create mode 100644 contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt create mode 100644 contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt create mode 100644 contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt create mode 100644 contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt create mode 100644 contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt create mode 100644 contrib/bind9/doc/draft/update create mode 100644 contrib/bind9/doc/misc/Makefile.in create mode 100644 contrib/bind9/doc/misc/dnssec create mode 100644 contrib/bind9/doc/misc/format-options.pl create mode 100644 contrib/bind9/doc/misc/ipv6 create mode 100644 contrib/bind9/doc/misc/migration create mode 100644 contrib/bind9/doc/misc/migration-4to9 create mode 100644 contrib/bind9/doc/misc/options create mode 100644 contrib/bind9/doc/misc/rfc-compliance create mode 100644 contrib/bind9/doc/misc/roadmap create mode 100644 contrib/bind9/doc/misc/sdb create mode 100644 contrib/bind9/doc/rfc/index create mode 100644 contrib/bind9/doc/rfc/rfc1032.txt create mode 100644 contrib/bind9/doc/rfc/rfc1033.txt create mode 100644 contrib/bind9/doc/rfc/rfc1034.txt create mode 100644 contrib/bind9/doc/rfc/rfc1035.txt create mode 100644 contrib/bind9/doc/rfc/rfc1101.txt create mode 100644 contrib/bind9/doc/rfc/rfc1122.txt create mode 100644 contrib/bind9/doc/rfc/rfc1123.txt create mode 100644 contrib/bind9/doc/rfc/rfc1183.txt create mode 100644 contrib/bind9/doc/rfc/rfc1348.txt create mode 100644 contrib/bind9/doc/rfc/rfc1535.txt create mode 100644 contrib/bind9/doc/rfc/rfc1536.txt create mode 100644 contrib/bind9/doc/rfc/rfc1537.txt create mode 100644 contrib/bind9/doc/rfc/rfc1591.txt create mode 100644 contrib/bind9/doc/rfc/rfc1611.txt create mode 100644 contrib/bind9/doc/rfc/rfc1612.txt create mode 100644 contrib/bind9/doc/rfc/rfc1706.txt create mode 100644 contrib/bind9/doc/rfc/rfc1712.txt create mode 100644 contrib/bind9/doc/rfc/rfc1750.txt create mode 100644 contrib/bind9/doc/rfc/rfc1876.txt create mode 100644 contrib/bind9/doc/rfc/rfc1886.txt create mode 100644 contrib/bind9/doc/rfc/rfc1982.txt create mode 100644 contrib/bind9/doc/rfc/rfc1995.txt create mode 100644 contrib/bind9/doc/rfc/rfc1996.txt create mode 100644 contrib/bind9/doc/rfc/rfc2052.txt create mode 100644 contrib/bind9/doc/rfc/rfc2104.txt create mode 100644 contrib/bind9/doc/rfc/rfc2119.txt create mode 100644 contrib/bind9/doc/rfc/rfc2133.txt create mode 100644 contrib/bind9/doc/rfc/rfc2136.txt create mode 100644 contrib/bind9/doc/rfc/rfc2137.txt create mode 100644 contrib/bind9/doc/rfc/rfc2163.txt create mode 100644 contrib/bind9/doc/rfc/rfc2168.txt create mode 100644 contrib/bind9/doc/rfc/rfc2181.txt create mode 100644 contrib/bind9/doc/rfc/rfc2230.txt create mode 100644 contrib/bind9/doc/rfc/rfc2308.txt create mode 100644 contrib/bind9/doc/rfc/rfc2317.txt create mode 100644 contrib/bind9/doc/rfc/rfc2373.txt create mode 100644 contrib/bind9/doc/rfc/rfc2374.txt create mode 100644 contrib/bind9/doc/rfc/rfc2375.txt create mode 100644 contrib/bind9/doc/rfc/rfc2418.txt create mode 100644 contrib/bind9/doc/rfc/rfc2535.txt create mode 100644 contrib/bind9/doc/rfc/rfc2536.txt create mode 100644 contrib/bind9/doc/rfc/rfc2537.txt create mode 100644 contrib/bind9/doc/rfc/rfc2538.txt create mode 100644 contrib/bind9/doc/rfc/rfc2539.txt create mode 100644 contrib/bind9/doc/rfc/rfc2540.txt create mode 100644 contrib/bind9/doc/rfc/rfc2541.txt create mode 100644 contrib/bind9/doc/rfc/rfc2553.txt create mode 100644 contrib/bind9/doc/rfc/rfc2671.txt create mode 100644 contrib/bind9/doc/rfc/rfc2672.txt create mode 100644 contrib/bind9/doc/rfc/rfc2673.txt create mode 100644 contrib/bind9/doc/rfc/rfc2782.txt create mode 100644 contrib/bind9/doc/rfc/rfc2825.txt create mode 100644 contrib/bind9/doc/rfc/rfc2826.txt create mode 100644 contrib/bind9/doc/rfc/rfc2845.txt create mode 100644 contrib/bind9/doc/rfc/rfc2874.txt create mode 100644 contrib/bind9/doc/rfc/rfc2915.txt create mode 100644 contrib/bind9/doc/rfc/rfc2929.txt create mode 100644 contrib/bind9/doc/rfc/rfc2930.txt create mode 100644 contrib/bind9/doc/rfc/rfc2931.txt create mode 100644 contrib/bind9/doc/rfc/rfc3007.txt create mode 100644 contrib/bind9/doc/rfc/rfc3008.txt create mode 100644 contrib/bind9/doc/rfc/rfc3071.txt create mode 100644 contrib/bind9/doc/rfc/rfc3090.txt create mode 100644 contrib/bind9/doc/rfc/rfc3110.txt create mode 100644 contrib/bind9/doc/rfc/rfc3123.txt create mode 100644 contrib/bind9/doc/rfc/rfc3152.txt create mode 100644 contrib/bind9/doc/rfc/rfc3197.txt create mode 100644 contrib/bind9/doc/rfc/rfc3225.txt create mode 100644 contrib/bind9/doc/rfc/rfc3226.txt create mode 100644 contrib/bind9/doc/rfc/rfc3258.txt create mode 100644 contrib/bind9/doc/rfc/rfc3363.txt create mode 100644 contrib/bind9/doc/rfc/rfc3364.txt create mode 100644 contrib/bind9/doc/rfc/rfc3425.txt create mode 100644 contrib/bind9/doc/rfc/rfc3445.txt create mode 100644 contrib/bind9/doc/rfc/rfc3467.txt create mode 100644 contrib/bind9/doc/rfc/rfc3490.txt create mode 100644 contrib/bind9/doc/rfc/rfc3491.txt create mode 100644 contrib/bind9/doc/rfc/rfc3492.txt create mode 100644 contrib/bind9/doc/rfc/rfc3493.txt create mode 100644 contrib/bind9/doc/rfc/rfc3513.txt create mode 100644 contrib/bind9/doc/rfc/rfc3596.txt create mode 100644 contrib/bind9/doc/rfc/rfc3597.txt create mode 100644 contrib/bind9/doc/rfc/rfc3645.txt create mode 100644 contrib/bind9/doc/rfc/rfc3655.txt create mode 100644 contrib/bind9/doc/rfc/rfc3658.txt create mode 100644 contrib/bind9/doc/rfc/rfc3833.txt create mode 100644 contrib/bind9/doc/rfc/rfc3845.txt create mode 100644 contrib/bind9/doc/rfc/rfc952.txt create mode 100755 contrib/bind9/install-sh create mode 100644 contrib/bind9/isc-config.sh.in create mode 100644 contrib/bind9/lib/Makefile.in create mode 100644 contrib/bind9/lib/bind/Makefile.in create mode 100644 contrib/bind9/lib/bind/README create mode 100644 contrib/bind9/lib/bind/aclocal.m4 create mode 100644 contrib/bind9/lib/bind/api create mode 100644 contrib/bind9/lib/bind/bsd/Makefile.in create mode 100644 contrib/bind9/lib/bind/bsd/daemon.c create mode 100644 contrib/bind9/lib/bind/bsd/ftruncate.c create mode 100644 contrib/bind9/lib/bind/bsd/gettimeofday.c create mode 100644 contrib/bind9/lib/bind/bsd/mktemp.c create mode 100644 contrib/bind9/lib/bind/bsd/putenv.c create mode 100644 contrib/bind9/lib/bind/bsd/readv.c create mode 100644 contrib/bind9/lib/bind/bsd/setenv.c create mode 100644 contrib/bind9/lib/bind/bsd/setitimer.c create mode 100644 contrib/bind9/lib/bind/bsd/strcasecmp.c create mode 100644 contrib/bind9/lib/bind/bsd/strdup.c create mode 100644 contrib/bind9/lib/bind/bsd/strerror.c create mode 100644 contrib/bind9/lib/bind/bsd/strpbrk.c create mode 100644 contrib/bind9/lib/bind/bsd/strsep.c create mode 100644 contrib/bind9/lib/bind/bsd/strtoul.c create mode 100644 contrib/bind9/lib/bind/bsd/utimes.c create mode 100644 contrib/bind9/lib/bind/bsd/writev.c create mode 100644 contrib/bind9/lib/bind/config.h.in create mode 100755 contrib/bind9/lib/bind/configure create mode 100644 contrib/bind9/lib/bind/configure.in create mode 100644 contrib/bind9/lib/bind/dst/Makefile.in create mode 100644 contrib/bind9/lib/bind/dst/dst_api.c create mode 100644 contrib/bind9/lib/bind/dst/dst_internal.h create mode 100644 contrib/bind9/lib/bind/dst/hmac_link.c create mode 100644 contrib/bind9/lib/bind/dst/md5.h create mode 100644 contrib/bind9/lib/bind/dst/md5_dgst.c create mode 100644 contrib/bind9/lib/bind/dst/md5_locl.h create mode 100644 contrib/bind9/lib/bind/dst/support.c create mode 100644 contrib/bind9/lib/bind/include/Makefile.in create mode 100644 contrib/bind9/lib/bind/include/arpa/inet.h create mode 100644 contrib/bind9/lib/bind/include/arpa/nameser.h create mode 100644 contrib/bind9/lib/bind/include/arpa/nameser_compat.h create mode 100644 contrib/bind9/lib/bind/include/fd_setsize.h create mode 100644 contrib/bind9/lib/bind/include/hesiod.h create mode 100644 contrib/bind9/lib/bind/include/irp.h create mode 100644 contrib/bind9/lib/bind/include/irs.h create mode 100644 contrib/bind9/lib/bind/include/isc/assertions.h create mode 100644 contrib/bind9/lib/bind/include/isc/ctl.h create mode 100644 contrib/bind9/lib/bind/include/isc/dst.h create mode 100644 contrib/bind9/lib/bind/include/isc/eventlib.h create mode 100644 contrib/bind9/lib/bind/include/isc/heap.h create mode 100644 contrib/bind9/lib/bind/include/isc/irpmarshall.h create mode 100644 contrib/bind9/lib/bind/include/isc/list.h create mode 100644 contrib/bind9/lib/bind/include/isc/logging.h create mode 100644 contrib/bind9/lib/bind/include/isc/memcluster.h create mode 100644 contrib/bind9/lib/bind/include/isc/misc.h create mode 100644 contrib/bind9/lib/bind/include/isc/tree.h create mode 100644 contrib/bind9/lib/bind/include/netdb.h create mode 100644 contrib/bind9/lib/bind/include/netgroup.h create mode 100644 contrib/bind9/lib/bind/include/res_update.h create mode 100644 contrib/bind9/lib/bind/include/resolv.h create mode 100644 contrib/bind9/lib/bind/inet/Makefile.in create mode 100644 contrib/bind9/lib/bind/inet/inet_addr.c create mode 100644 contrib/bind9/lib/bind/inet/inet_cidr_ntop.c create mode 100644 contrib/bind9/lib/bind/inet/inet_cidr_pton.c create mode 100644 contrib/bind9/lib/bind/inet/inet_data.c create mode 100644 contrib/bind9/lib/bind/inet/inet_lnaof.c create mode 100644 contrib/bind9/lib/bind/inet/inet_makeaddr.c create mode 100644 contrib/bind9/lib/bind/inet/inet_net_ntop.c create mode 100644 contrib/bind9/lib/bind/inet/inet_net_pton.c create mode 100644 contrib/bind9/lib/bind/inet/inet_neta.c create mode 100644 contrib/bind9/lib/bind/inet/inet_netof.c create mode 100644 contrib/bind9/lib/bind/inet/inet_network.c create mode 100644 contrib/bind9/lib/bind/inet/inet_ntoa.c create mode 100644 contrib/bind9/lib/bind/inet/inet_ntop.c create mode 100644 contrib/bind9/lib/bind/inet/inet_pton.c create mode 100644 contrib/bind9/lib/bind/inet/nsap_addr.c create mode 100644 contrib/bind9/lib/bind/irs/Makefile.in create mode 100644 contrib/bind9/lib/bind/irs/dns.c create mode 100644 contrib/bind9/lib/bind/irs/dns_gr.c create mode 100644 contrib/bind9/lib/bind/irs/dns_ho.c create mode 100644 contrib/bind9/lib/bind/irs/dns_nw.c create mode 100644 contrib/bind9/lib/bind/irs/dns_p.h create mode 100644 contrib/bind9/lib/bind/irs/dns_pr.c create mode 100644 contrib/bind9/lib/bind/irs/dns_pw.c create mode 100644 contrib/bind9/lib/bind/irs/dns_sv.c create mode 100644 contrib/bind9/lib/bind/irs/gai_strerror.c create mode 100644 contrib/bind9/lib/bind/irs/gen.c create mode 100644 contrib/bind9/lib/bind/irs/gen_gr.c create mode 100644 contrib/bind9/lib/bind/irs/gen_ho.c create mode 100644 contrib/bind9/lib/bind/irs/gen_ng.c create mode 100644 contrib/bind9/lib/bind/irs/gen_nw.c create mode 100644 contrib/bind9/lib/bind/irs/gen_p.h create mode 100644 contrib/bind9/lib/bind/irs/gen_pr.c create mode 100644 contrib/bind9/lib/bind/irs/gen_pw.c create mode 100644 contrib/bind9/lib/bind/irs/gen_sv.c create mode 100644 contrib/bind9/lib/bind/irs/getaddrinfo.c create mode 100644 contrib/bind9/lib/bind/irs/getgrent.c create mode 100644 contrib/bind9/lib/bind/irs/getgrent_r.c create mode 100644 contrib/bind9/lib/bind/irs/gethostent.c create mode 100644 contrib/bind9/lib/bind/irs/gethostent_r.c create mode 100644 contrib/bind9/lib/bind/irs/getnameinfo.c create mode 100644 contrib/bind9/lib/bind/irs/getnetent.c create mode 100644 contrib/bind9/lib/bind/irs/getnetent_r.c create mode 100644 contrib/bind9/lib/bind/irs/getnetgrent.c create mode 100644 contrib/bind9/lib/bind/irs/getnetgrent_r.c create mode 100644 contrib/bind9/lib/bind/irs/getprotoent.c create mode 100644 contrib/bind9/lib/bind/irs/getprotoent_r.c create mode 100644 contrib/bind9/lib/bind/irs/getpwent.c create mode 100644 contrib/bind9/lib/bind/irs/getpwent_r.c create mode 100644 contrib/bind9/lib/bind/irs/getservent.c create mode 100644 contrib/bind9/lib/bind/irs/getservent_r.c create mode 100644 contrib/bind9/lib/bind/irs/hesiod.c create mode 100644 contrib/bind9/lib/bind/irs/hesiod_p.h create mode 100644 contrib/bind9/lib/bind/irs/irp.c create mode 100644 contrib/bind9/lib/bind/irs/irp_gr.c create mode 100644 contrib/bind9/lib/bind/irs/irp_ho.c create mode 100644 contrib/bind9/lib/bind/irs/irp_ng.c create mode 100644 contrib/bind9/lib/bind/irs/irp_nw.c create mode 100644 contrib/bind9/lib/bind/irs/irp_p.h create mode 100644 contrib/bind9/lib/bind/irs/irp_pr.c create mode 100644 contrib/bind9/lib/bind/irs/irp_pw.c create mode 100644 contrib/bind9/lib/bind/irs/irp_sv.c create mode 100644 contrib/bind9/lib/bind/irs/irpmarshall.c create mode 100644 contrib/bind9/lib/bind/irs/irs_data.c create mode 100644 contrib/bind9/lib/bind/irs/irs_data.h create mode 100644 contrib/bind9/lib/bind/irs/irs_p.h create mode 100644 contrib/bind9/lib/bind/irs/lcl.c create mode 100644 contrib/bind9/lib/bind/irs/lcl_gr.c create mode 100644 contrib/bind9/lib/bind/irs/lcl_ho.c create mode 100644 contrib/bind9/lib/bind/irs/lcl_ng.c create mode 100644 contrib/bind9/lib/bind/irs/lcl_nw.c create mode 100644 contrib/bind9/lib/bind/irs/lcl_p.h create mode 100644 contrib/bind9/lib/bind/irs/lcl_pr.c create mode 100644 contrib/bind9/lib/bind/irs/lcl_pw.c create mode 100644 contrib/bind9/lib/bind/irs/lcl_sv.c create mode 100644 contrib/bind9/lib/bind/irs/nis.c create mode 100644 contrib/bind9/lib/bind/irs/nis_gr.c create mode 100644 contrib/bind9/lib/bind/irs/nis_ho.c create mode 100644 contrib/bind9/lib/bind/irs/nis_ng.c create mode 100644 contrib/bind9/lib/bind/irs/nis_nw.c create mode 100644 contrib/bind9/lib/bind/irs/nis_p.h create mode 100644 contrib/bind9/lib/bind/irs/nis_pr.c create mode 100644 contrib/bind9/lib/bind/irs/nis_pw.c create mode 100644 contrib/bind9/lib/bind/irs/nis_sv.c create mode 100644 contrib/bind9/lib/bind/irs/nul_ng.c create mode 100644 contrib/bind9/lib/bind/irs/pathnames.h create mode 100644 contrib/bind9/lib/bind/irs/util.c create mode 100644 contrib/bind9/lib/bind/isc/Makefile.in create mode 100644 contrib/bind9/lib/bind/isc/assertions.c create mode 100644 contrib/bind9/lib/bind/isc/assertions.mdoc create mode 100644 contrib/bind9/lib/bind/isc/base64.c create mode 100644 contrib/bind9/lib/bind/isc/bitncmp.c create mode 100644 contrib/bind9/lib/bind/isc/bitncmp.mdoc create mode 100644 contrib/bind9/lib/bind/isc/ctl_clnt.c create mode 100644 contrib/bind9/lib/bind/isc/ctl_p.c create mode 100644 contrib/bind9/lib/bind/isc/ctl_p.h create mode 100644 contrib/bind9/lib/bind/isc/ctl_srvr.c create mode 100644 contrib/bind9/lib/bind/isc/ev_connects.c create mode 100644 contrib/bind9/lib/bind/isc/ev_files.c create mode 100644 contrib/bind9/lib/bind/isc/ev_streams.c create mode 100644 contrib/bind9/lib/bind/isc/ev_timers.c create mode 100644 contrib/bind9/lib/bind/isc/ev_waits.c create mode 100644 contrib/bind9/lib/bind/isc/eventlib.c create mode 100644 contrib/bind9/lib/bind/isc/eventlib.mdoc create mode 100644 contrib/bind9/lib/bind/isc/eventlib_p.h create mode 100644 contrib/bind9/lib/bind/isc/heap.c create mode 100644 contrib/bind9/lib/bind/isc/heap.mdoc create mode 100644 contrib/bind9/lib/bind/isc/hex.c create mode 100644 contrib/bind9/lib/bind/isc/logging.c create mode 100644 contrib/bind9/lib/bind/isc/logging.mdoc create mode 100644 contrib/bind9/lib/bind/isc/logging_p.h create mode 100644 contrib/bind9/lib/bind/isc/memcluster.c create mode 100644 contrib/bind9/lib/bind/isc/memcluster.mdoc create mode 100644 contrib/bind9/lib/bind/isc/movefile.c create mode 100644 contrib/bind9/lib/bind/isc/tree.c create mode 100644 contrib/bind9/lib/bind/isc/tree.mdoc create mode 100644 contrib/bind9/lib/bind/libtool.m4 create mode 100644 contrib/bind9/lib/bind/ltmain.sh create mode 100644 contrib/bind9/lib/bind/make/includes.in create mode 100644 contrib/bind9/lib/bind/make/mkdep.in create mode 100644 contrib/bind9/lib/bind/make/rules.in create mode 100755 contrib/bind9/lib/bind/mkinstalldirs create mode 100644 contrib/bind9/lib/bind/nameser/Makefile.in create mode 100644 contrib/bind9/lib/bind/nameser/ns_date.c create mode 100644 contrib/bind9/lib/bind/nameser/ns_name.c create mode 100644 contrib/bind9/lib/bind/nameser/ns_netint.c create mode 100644 contrib/bind9/lib/bind/nameser/ns_parse.c create mode 100644 contrib/bind9/lib/bind/nameser/ns_print.c create mode 100644 contrib/bind9/lib/bind/nameser/ns_samedomain.c create mode 100644 contrib/bind9/lib/bind/nameser/ns_sign.c create mode 100644 contrib/bind9/lib/bind/nameser/ns_ttl.c create mode 100644 contrib/bind9/lib/bind/nameser/ns_verify.c create mode 100644 contrib/bind9/lib/bind/port/Makefile.in create mode 100644 contrib/bind9/lib/bind/port/freebsd/Makefile.in create mode 100644 contrib/bind9/lib/bind/port/freebsd/include/Makefile.in create mode 100644 contrib/bind9/lib/bind/port/freebsd/include/sys/bitypes.h create mode 100644 contrib/bind9/lib/bind/port_after.h.in create mode 100644 contrib/bind9/lib/bind/port_before.h.in create mode 100644 contrib/bind9/lib/bind/resolv/Makefile.in create mode 100644 contrib/bind9/lib/bind/resolv/herror.c create mode 100644 contrib/bind9/lib/bind/resolv/res_comp.c create mode 100644 contrib/bind9/lib/bind/resolv/res_data.c create mode 100644 contrib/bind9/lib/bind/resolv/res_debug.c create mode 100644 contrib/bind9/lib/bind/resolv/res_debug.h create mode 100644 contrib/bind9/lib/bind/resolv/res_findzonecut.c create mode 100644 contrib/bind9/lib/bind/resolv/res_init.c create mode 100644 contrib/bind9/lib/bind/resolv/res_mkquery.c create mode 100644 contrib/bind9/lib/bind/resolv/res_mkupdate.c create mode 100644 contrib/bind9/lib/bind/resolv/res_mkupdate.h create mode 100644 contrib/bind9/lib/bind/resolv/res_private.h create mode 100644 contrib/bind9/lib/bind/resolv/res_query.c create mode 100644 contrib/bind9/lib/bind/resolv/res_send.c create mode 100644 contrib/bind9/lib/bind/resolv/res_sendsigned.c create mode 100644 contrib/bind9/lib/bind/resolv/res_update.c create mode 100644 contrib/bind9/lib/bind9/Makefile.in create mode 100644 contrib/bind9/lib/bind9/api create mode 100644 contrib/bind9/lib/bind9/check.c create mode 100644 contrib/bind9/lib/bind9/getaddresses.c create mode 100644 contrib/bind9/lib/bind9/include/Makefile.in create mode 100644 contrib/bind9/lib/bind9/include/bind9/Makefile.in create mode 100644 contrib/bind9/lib/bind9/include/bind9/check.h create mode 100644 contrib/bind9/lib/bind9/include/bind9/getaddresses.h create mode 100644 contrib/bind9/lib/bind9/include/bind9/version.h create mode 100644 contrib/bind9/lib/bind9/version.c create mode 100644 contrib/bind9/lib/dns/Makefile.in create mode 100644 contrib/bind9/lib/dns/acl.c create mode 100644 contrib/bind9/lib/dns/adb.c create mode 100644 contrib/bind9/lib/dns/api create mode 100644 contrib/bind9/lib/dns/byaddr.c create mode 100644 contrib/bind9/lib/dns/cache.c create mode 100644 contrib/bind9/lib/dns/callbacks.c create mode 100644 contrib/bind9/lib/dns/compress.c create mode 100644 contrib/bind9/lib/dns/db.c create mode 100644 contrib/bind9/lib/dns/dbiterator.c create mode 100644 contrib/bind9/lib/dns/dbtable.c create mode 100644 contrib/bind9/lib/dns/diff.c create mode 100644 contrib/bind9/lib/dns/dispatch.c create mode 100644 contrib/bind9/lib/dns/dnssec.c create mode 100644 contrib/bind9/lib/dns/ds.c create mode 100644 contrib/bind9/lib/dns/forward.c create mode 100644 contrib/bind9/lib/dns/gen-unix.h create mode 100644 contrib/bind9/lib/dns/gen.c create mode 100644 contrib/bind9/lib/dns/include/Makefile.in create mode 100644 contrib/bind9/lib/dns/include/dns/Makefile.in create mode 100644 contrib/bind9/lib/dns/include/dns/acl.h create mode 100644 contrib/bind9/lib/dns/include/dns/adb.h create mode 100644 contrib/bind9/lib/dns/include/dns/bit.h create mode 100644 contrib/bind9/lib/dns/include/dns/byaddr.h create mode 100644 contrib/bind9/lib/dns/include/dns/cache.h create mode 100644 contrib/bind9/lib/dns/include/dns/callbacks.h create mode 100644 contrib/bind9/lib/dns/include/dns/cert.h create mode 100644 contrib/bind9/lib/dns/include/dns/compress.h create mode 100644 contrib/bind9/lib/dns/include/dns/db.h create mode 100644 contrib/bind9/lib/dns/include/dns/dbiterator.h create mode 100644 contrib/bind9/lib/dns/include/dns/dbtable.h create mode 100644 contrib/bind9/lib/dns/include/dns/diff.h create mode 100644 contrib/bind9/lib/dns/include/dns/dispatch.h create mode 100644 contrib/bind9/lib/dns/include/dns/dnssec.h create mode 100644 contrib/bind9/lib/dns/include/dns/ds.h create mode 100644 contrib/bind9/lib/dns/include/dns/events.h create mode 100644 contrib/bind9/lib/dns/include/dns/fixedname.h create mode 100644 contrib/bind9/lib/dns/include/dns/forward.h create mode 100644 contrib/bind9/lib/dns/include/dns/journal.h create mode 100644 contrib/bind9/lib/dns/include/dns/keyflags.h create mode 100644 contrib/bind9/lib/dns/include/dns/keytable.h create mode 100644 contrib/bind9/lib/dns/include/dns/keyvalues.h create mode 100644 contrib/bind9/lib/dns/include/dns/lib.h create mode 100644 contrib/bind9/lib/dns/include/dns/log.h create mode 100644 contrib/bind9/lib/dns/include/dns/lookup.h create mode 100644 contrib/bind9/lib/dns/include/dns/master.h create mode 100644 contrib/bind9/lib/dns/include/dns/masterdump.h create mode 100644 contrib/bind9/lib/dns/include/dns/message.h create mode 100644 contrib/bind9/lib/dns/include/dns/name.h create mode 100644 contrib/bind9/lib/dns/include/dns/ncache.h create mode 100644 contrib/bind9/lib/dns/include/dns/nsec.h create mode 100644 contrib/bind9/lib/dns/include/dns/opcode.h create mode 100644 contrib/bind9/lib/dns/include/dns/order.h create mode 100644 contrib/bind9/lib/dns/include/dns/peer.h create mode 100644 contrib/bind9/lib/dns/include/dns/portlist.h create mode 100644 contrib/bind9/lib/dns/include/dns/rbt.h create mode 100644 contrib/bind9/lib/dns/include/dns/rcode.h create mode 100644 contrib/bind9/lib/dns/include/dns/rdata.h create mode 100644 contrib/bind9/lib/dns/include/dns/rdataclass.h create mode 100644 contrib/bind9/lib/dns/include/dns/rdatalist.h create mode 100644 contrib/bind9/lib/dns/include/dns/rdataset.h create mode 100644 contrib/bind9/lib/dns/include/dns/rdatasetiter.h create mode 100644 contrib/bind9/lib/dns/include/dns/rdataslab.h create mode 100644 contrib/bind9/lib/dns/include/dns/rdatatype.h create mode 100644 contrib/bind9/lib/dns/include/dns/request.h create mode 100644 contrib/bind9/lib/dns/include/dns/resolver.h create mode 100644 contrib/bind9/lib/dns/include/dns/result.h create mode 100644 contrib/bind9/lib/dns/include/dns/rootns.h create mode 100644 contrib/bind9/lib/dns/include/dns/sdb.h create mode 100644 contrib/bind9/lib/dns/include/dns/secalg.h create mode 100644 contrib/bind9/lib/dns/include/dns/secproto.h create mode 100644 contrib/bind9/lib/dns/include/dns/soa.h create mode 100644 contrib/bind9/lib/dns/include/dns/ssu.h create mode 100644 contrib/bind9/lib/dns/include/dns/stats.h create mode 100644 contrib/bind9/lib/dns/include/dns/tcpmsg.h create mode 100644 contrib/bind9/lib/dns/include/dns/time.h create mode 100644 contrib/bind9/lib/dns/include/dns/timer.h create mode 100644 contrib/bind9/lib/dns/include/dns/tkey.h create mode 100644 contrib/bind9/lib/dns/include/dns/tsig.h create mode 100644 contrib/bind9/lib/dns/include/dns/ttl.h create mode 100644 contrib/bind9/lib/dns/include/dns/types.h create mode 100644 contrib/bind9/lib/dns/include/dns/validator.h create mode 100644 contrib/bind9/lib/dns/include/dns/version.h create mode 100644 contrib/bind9/lib/dns/include/dns/view.h create mode 100644 contrib/bind9/lib/dns/include/dns/xfrin.h create mode 100644 contrib/bind9/lib/dns/include/dns/zone.h create mode 100644 contrib/bind9/lib/dns/include/dns/zonekey.h create mode 100644 contrib/bind9/lib/dns/include/dns/zt.h create mode 100644 contrib/bind9/lib/dns/journal.c create mode 100644 contrib/bind9/lib/dns/keytable.c create mode 100644 contrib/bind9/lib/dns/lib.c create mode 100644 contrib/bind9/lib/dns/log.c create mode 100644 contrib/bind9/lib/dns/lookup.c create mode 100644 contrib/bind9/lib/dns/master.c create mode 100644 contrib/bind9/lib/dns/masterdump.c create mode 100644 contrib/bind9/lib/dns/message.c create mode 100644 contrib/bind9/lib/dns/name.c create mode 100644 contrib/bind9/lib/dns/ncache.c create mode 100644 contrib/bind9/lib/dns/nsec.c create mode 100644 contrib/bind9/lib/dns/order.c create mode 100644 contrib/bind9/lib/dns/peer.c create mode 100644 contrib/bind9/lib/dns/portlist.c create mode 100644 contrib/bind9/lib/dns/rbt.c create mode 100644 contrib/bind9/lib/dns/rbtdb.c create mode 100644 contrib/bind9/lib/dns/rbtdb.h create mode 100644 contrib/bind9/lib/dns/rbtdb64.c create mode 100644 contrib/bind9/lib/dns/rbtdb64.h create mode 100644 contrib/bind9/lib/dns/rcode.c create mode 100644 contrib/bind9/lib/dns/rdata.c create mode 100644 contrib/bind9/lib/dns/rdata/any_255/tsig_250.c create mode 100644 contrib/bind9/lib/dns/rdata/any_255/tsig_250.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/afsdb_18.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/afsdb_18.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/cert_37.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/cert_37.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/cname_5.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/cname_5.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/dlv_65323.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/dlv_65323.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/dname_39.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/dname_39.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/dnskey_48.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/dnskey_48.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/ds_43.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/ds_43.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/gpos_27.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/gpos_27.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/hinfo_13.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/hinfo_13.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/isdn_20.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/isdn_20.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/key_25.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/key_25.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/loc_29.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/loc_29.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/mb_7.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/mb_7.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/md_3.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/md_3.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/mf_4.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/mf_4.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/mg_8.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/mg_8.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/minfo_14.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/minfo_14.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/mr_9.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/mr_9.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/mx_15.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/mx_15.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/ns_2.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/ns_2.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/nsec_47.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/nsec_47.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/null_10.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/null_10.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/nxt_30.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/nxt_30.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/opt_41.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/opt_41.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/proforma.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/proforma.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/ptr_12.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/ptr_12.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/rp_17.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/rp_17.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/rrsig_46.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/rrsig_46.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/rt_21.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/rt_21.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/sig_24.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/sig_24.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/soa_6.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/soa_6.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/sshfp_44.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/sshfp_44.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/tkey_249.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/tkey_249.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/txt_16.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/txt_16.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/unspec_103.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/unspec_103.h create mode 100644 contrib/bind9/lib/dns/rdata/generic/x25_19.c create mode 100644 contrib/bind9/lib/dns/rdata/generic/x25_19.h create mode 100644 contrib/bind9/lib/dns/rdata/hs_4/a_1.c create mode 100644 contrib/bind9/lib/dns/rdata/hs_4/a_1.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/a6_38.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/a6_38.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/a_1.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/a_1.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/aaaa_28.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/aaaa_28.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/apl_42.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/apl_42.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/kx_36.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/kx_36.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/naptr_35.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/naptr_35.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/nsap_22.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/nsap_22.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/px_26.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/px_26.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/srv_33.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/srv_33.h create mode 100644 contrib/bind9/lib/dns/rdata/in_1/wks_11.c create mode 100644 contrib/bind9/lib/dns/rdata/in_1/wks_11.h create mode 100644 contrib/bind9/lib/dns/rdata/rdatastructpre.h create mode 100644 contrib/bind9/lib/dns/rdata/rdatastructsuf.h create mode 100644 contrib/bind9/lib/dns/rdatalist.c create mode 100644 contrib/bind9/lib/dns/rdatalist_p.h create mode 100644 contrib/bind9/lib/dns/rdataset.c create mode 100644 contrib/bind9/lib/dns/rdatasetiter.c create mode 100644 contrib/bind9/lib/dns/rdataslab.c create mode 100644 contrib/bind9/lib/dns/request.c create mode 100644 contrib/bind9/lib/dns/resolver.c create mode 100644 contrib/bind9/lib/dns/result.c create mode 100644 contrib/bind9/lib/dns/rootns.c create mode 100644 contrib/bind9/lib/dns/sdb.c create mode 100644 contrib/bind9/lib/dns/sec/Makefile.in create mode 100644 contrib/bind9/lib/dns/sec/dst/Makefile.in create mode 100644 contrib/bind9/lib/dns/sec/dst/dst_api.c create mode 100644 contrib/bind9/lib/dns/sec/dst/dst_internal.h create mode 100644 contrib/bind9/lib/dns/sec/dst/dst_lib.c create mode 100644 contrib/bind9/lib/dns/sec/dst/dst_openssl.h create mode 100644 contrib/bind9/lib/dns/sec/dst/dst_parse.c create mode 100644 contrib/bind9/lib/dns/sec/dst/dst_parse.h create mode 100644 contrib/bind9/lib/dns/sec/dst/dst_result.c create mode 100644 contrib/bind9/lib/dns/sec/dst/gssapi_link.c create mode 100644 contrib/bind9/lib/dns/sec/dst/gssapictx.c create mode 100644 contrib/bind9/lib/dns/sec/dst/hmac_link.c create mode 100644 contrib/bind9/lib/dns/sec/dst/include/Makefile.in create mode 100644 contrib/bind9/lib/dns/sec/dst/include/dst/Makefile.in create mode 100644 contrib/bind9/lib/dns/sec/dst/include/dst/dst.h create mode 100644 contrib/bind9/lib/dns/sec/dst/include/dst/gssapi.h create mode 100644 contrib/bind9/lib/dns/sec/dst/include/dst/lib.h create mode 100644 contrib/bind9/lib/dns/sec/dst/include/dst/result.h create mode 100644 contrib/bind9/lib/dns/sec/dst/key.c create mode 100644 contrib/bind9/lib/dns/sec/dst/openssl_link.c create mode 100644 contrib/bind9/lib/dns/sec/dst/openssldh_link.c create mode 100644 contrib/bind9/lib/dns/sec/dst/openssldsa_link.c create mode 100644 contrib/bind9/lib/dns/sec/dst/opensslrsa_link.c create mode 100644 contrib/bind9/lib/dns/soa.c create mode 100644 contrib/bind9/lib/dns/ssu.c create mode 100644 contrib/bind9/lib/dns/stats.c create mode 100644 contrib/bind9/lib/dns/tcpmsg.c create mode 100644 contrib/bind9/lib/dns/time.c create mode 100644 contrib/bind9/lib/dns/timer.c create mode 100644 contrib/bind9/lib/dns/tkey.c create mode 100644 contrib/bind9/lib/dns/tsig.c create mode 100644 contrib/bind9/lib/dns/ttl.c create mode 100644 contrib/bind9/lib/dns/validator.c create mode 100644 contrib/bind9/lib/dns/version.c create mode 100644 contrib/bind9/lib/dns/view.c create mode 100644 contrib/bind9/lib/dns/xfrin.c create mode 100644 contrib/bind9/lib/dns/zone.c create mode 100644 contrib/bind9/lib/dns/zonekey.c create mode 100644 contrib/bind9/lib/dns/zt.c create mode 100644 contrib/bind9/lib/isc/Makefile.in create mode 100644 contrib/bind9/lib/isc/api create mode 100644 contrib/bind9/lib/isc/assertions.c create mode 100644 contrib/bind9/lib/isc/base64.c create mode 100644 contrib/bind9/lib/isc/bitstring.c create mode 100644 contrib/bind9/lib/isc/buffer.c create mode 100644 contrib/bind9/lib/isc/bufferlist.c create mode 100644 contrib/bind9/lib/isc/commandline.c create mode 100644 contrib/bind9/lib/isc/entropy.c create mode 100644 contrib/bind9/lib/isc/error.c create mode 100644 contrib/bind9/lib/isc/event.c create mode 100644 contrib/bind9/lib/isc/fsaccess.c create mode 100644 contrib/bind9/lib/isc/hash.c create mode 100644 contrib/bind9/lib/isc/heap.c create mode 100644 contrib/bind9/lib/isc/hex.c create mode 100644 contrib/bind9/lib/isc/hmacmd5.c create mode 100644 contrib/bind9/lib/isc/include/Makefile.in create mode 100644 contrib/bind9/lib/isc/include/isc/Makefile.in create mode 100644 contrib/bind9/lib/isc/include/isc/app.h create mode 100644 contrib/bind9/lib/isc/include/isc/assertions.h create mode 100644 contrib/bind9/lib/isc/include/isc/base64.h create mode 100644 contrib/bind9/lib/isc/include/isc/bitstring.h create mode 100644 contrib/bind9/lib/isc/include/isc/boolean.h create mode 100644 contrib/bind9/lib/isc/include/isc/buffer.h create mode 100644 contrib/bind9/lib/isc/include/isc/bufferlist.h create mode 100644 contrib/bind9/lib/isc/include/isc/commandline.h create mode 100644 contrib/bind9/lib/isc/include/isc/entropy.h create mode 100644 contrib/bind9/lib/isc/include/isc/error.h create mode 100644 contrib/bind9/lib/isc/include/isc/event.h create mode 100644 contrib/bind9/lib/isc/include/isc/eventclass.h create mode 100644 contrib/bind9/lib/isc/include/isc/file.h create mode 100644 contrib/bind9/lib/isc/include/isc/formatcheck.h create mode 100644 contrib/bind9/lib/isc/include/isc/fsaccess.h create mode 100644 contrib/bind9/lib/isc/include/isc/hash.h create mode 100644 contrib/bind9/lib/isc/include/isc/heap.h create mode 100644 contrib/bind9/lib/isc/include/isc/hex.h create mode 100644 contrib/bind9/lib/isc/include/isc/hmacmd5.h create mode 100644 contrib/bind9/lib/isc/include/isc/interfaceiter.h create mode 100644 contrib/bind9/lib/isc/include/isc/ipv6.h create mode 100644 contrib/bind9/lib/isc/include/isc/lang.h create mode 100644 contrib/bind9/lib/isc/include/isc/lex.h create mode 100644 contrib/bind9/lib/isc/include/isc/lfsr.h create mode 100644 contrib/bind9/lib/isc/include/isc/lib.h create mode 100644 contrib/bind9/lib/isc/include/isc/list.h create mode 100644 contrib/bind9/lib/isc/include/isc/log.h create mode 100644 contrib/bind9/lib/isc/include/isc/magic.h create mode 100644 contrib/bind9/lib/isc/include/isc/md5.h create mode 100644 contrib/bind9/lib/isc/include/isc/mem.h create mode 100644 contrib/bind9/lib/isc/include/isc/msgcat.h create mode 100644 contrib/bind9/lib/isc/include/isc/msgs.h create mode 100644 contrib/bind9/lib/isc/include/isc/mutexblock.h create mode 100644 contrib/bind9/lib/isc/include/isc/netaddr.h create mode 100644 contrib/bind9/lib/isc/include/isc/netscope.h create mode 100644 contrib/bind9/lib/isc/include/isc/ondestroy.h create mode 100644 contrib/bind9/lib/isc/include/isc/os.h create mode 100644 contrib/bind9/lib/isc/include/isc/parseint.h create mode 100644 contrib/bind9/lib/isc/include/isc/platform.h.in create mode 100644 contrib/bind9/lib/isc/include/isc/print.h create mode 100644 contrib/bind9/lib/isc/include/isc/quota.h create mode 100644 contrib/bind9/lib/isc/include/isc/random.h create mode 100644 contrib/bind9/lib/isc/include/isc/ratelimiter.h create mode 100644 contrib/bind9/lib/isc/include/isc/refcount.h create mode 100644 contrib/bind9/lib/isc/include/isc/region.h create mode 100644 contrib/bind9/lib/isc/include/isc/resource.h create mode 100644 contrib/bind9/lib/isc/include/isc/result.h create mode 100644 contrib/bind9/lib/isc/include/isc/resultclass.h create mode 100644 contrib/bind9/lib/isc/include/isc/rwlock.h create mode 100644 contrib/bind9/lib/isc/include/isc/serial.h create mode 100644 contrib/bind9/lib/isc/include/isc/sha1.h create mode 100644 contrib/bind9/lib/isc/include/isc/sockaddr.h create mode 100644 contrib/bind9/lib/isc/include/isc/socket.h create mode 100644 contrib/bind9/lib/isc/include/isc/stdio.h create mode 100644 contrib/bind9/lib/isc/include/isc/stdlib.h create mode 100644 contrib/bind9/lib/isc/include/isc/string.h create mode 100644 contrib/bind9/lib/isc/include/isc/symtab.h create mode 100644 contrib/bind9/lib/isc/include/isc/task.h create mode 100644 contrib/bind9/lib/isc/include/isc/taskpool.h create mode 100644 contrib/bind9/lib/isc/include/isc/timer.h create mode 100644 contrib/bind9/lib/isc/include/isc/types.h create mode 100644 contrib/bind9/lib/isc/include/isc/util.h create mode 100644 contrib/bind9/lib/isc/include/isc/version.h create mode 100644 contrib/bind9/lib/isc/inet_aton.c create mode 100644 contrib/bind9/lib/isc/inet_ntop.c create mode 100644 contrib/bind9/lib/isc/inet_pton.c create mode 100644 contrib/bind9/lib/isc/lex.c create mode 100644 contrib/bind9/lib/isc/lfsr.c create mode 100644 contrib/bind9/lib/isc/lib.c create mode 100644 contrib/bind9/lib/isc/log.c create mode 100644 contrib/bind9/lib/isc/md5.c create mode 100644 contrib/bind9/lib/isc/mem.c create mode 100644 contrib/bind9/lib/isc/mutexblock.c create mode 100644 contrib/bind9/lib/isc/netaddr.c create mode 100644 contrib/bind9/lib/isc/netscope.c create mode 100644 contrib/bind9/lib/isc/nls/Makefile.in create mode 100644 contrib/bind9/lib/isc/nls/msgcat.c create mode 100644 contrib/bind9/lib/isc/nothreads/Makefile.in create mode 100644 contrib/bind9/lib/isc/nothreads/condition.c create mode 100644 contrib/bind9/lib/isc/nothreads/include/Makefile.in create mode 100644 contrib/bind9/lib/isc/nothreads/include/isc/Makefile.in create mode 100644 contrib/bind9/lib/isc/nothreads/include/isc/condition.h create mode 100644 contrib/bind9/lib/isc/nothreads/include/isc/mutex.h create mode 100644 contrib/bind9/lib/isc/nothreads/include/isc/once.h create mode 100644 contrib/bind9/lib/isc/nothreads/include/isc/thread.h create mode 100644 contrib/bind9/lib/isc/nothreads/mutex.c create mode 100644 contrib/bind9/lib/isc/nothreads/thread.c create mode 100644 contrib/bind9/lib/isc/ondestroy.c create mode 100644 contrib/bind9/lib/isc/parseint.c create mode 100644 contrib/bind9/lib/isc/print.c create mode 100644 contrib/bind9/lib/isc/pthreads/Makefile.in create mode 100644 contrib/bind9/lib/isc/pthreads/condition.c create mode 100644 contrib/bind9/lib/isc/pthreads/include/Makefile.in create mode 100644 contrib/bind9/lib/isc/pthreads/include/isc/Makefile.in create mode 100644 contrib/bind9/lib/isc/pthreads/include/isc/condition.h create mode 100644 contrib/bind9/lib/isc/pthreads/include/isc/mutex.h create mode 100644 contrib/bind9/lib/isc/pthreads/include/isc/once.h create mode 100644 contrib/bind9/lib/isc/pthreads/include/isc/thread.h create mode 100644 contrib/bind9/lib/isc/pthreads/mutex.c create mode 100644 contrib/bind9/lib/isc/pthreads/thread.c create mode 100644 contrib/bind9/lib/isc/quota.c create mode 100644 contrib/bind9/lib/isc/random.c create mode 100644 contrib/bind9/lib/isc/ratelimiter.c create mode 100644 contrib/bind9/lib/isc/region.c create mode 100644 contrib/bind9/lib/isc/result.c create mode 100644 contrib/bind9/lib/isc/rwlock.c create mode 100644 contrib/bind9/lib/isc/serial.c create mode 100644 contrib/bind9/lib/isc/sha1.c create mode 100644 contrib/bind9/lib/isc/sockaddr.c create mode 100644 contrib/bind9/lib/isc/string.c create mode 100644 contrib/bind9/lib/isc/strtoul.c create mode 100644 contrib/bind9/lib/isc/symtab.c create mode 100644 contrib/bind9/lib/isc/task.c create mode 100644 contrib/bind9/lib/isc/task_p.h create mode 100644 contrib/bind9/lib/isc/taskpool.c create mode 100644 contrib/bind9/lib/isc/timer.c create mode 100644 contrib/bind9/lib/isc/timer_p.h create mode 100644 contrib/bind9/lib/isc/unix/Makefile.in create mode 100644 contrib/bind9/lib/isc/unix/app.c create mode 100644 contrib/bind9/lib/isc/unix/dir.c create mode 100644 contrib/bind9/lib/isc/unix/entropy.c create mode 100644 contrib/bind9/lib/isc/unix/errno2result.c create mode 100644 contrib/bind9/lib/isc/unix/errno2result.h create mode 100644 contrib/bind9/lib/isc/unix/file.c create mode 100644 contrib/bind9/lib/isc/unix/fsaccess.c create mode 100644 contrib/bind9/lib/isc/unix/ifiter_getifaddrs.c create mode 100644 contrib/bind9/lib/isc/unix/ifiter_ioctl.c create mode 100644 contrib/bind9/lib/isc/unix/ifiter_sysctl.c create mode 100644 contrib/bind9/lib/isc/unix/include/Makefile.in create mode 100644 contrib/bind9/lib/isc/unix/include/isc/Makefile.in create mode 100644 contrib/bind9/lib/isc/unix/include/isc/dir.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/int.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/keyboard.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/net.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/netdb.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/offset.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/stat.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/stdtime.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/strerror.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/syslog.h create mode 100644 contrib/bind9/lib/isc/unix/include/isc/time.h create mode 100644 contrib/bind9/lib/isc/unix/interfaceiter.c create mode 100644 contrib/bind9/lib/isc/unix/ipv6.c create mode 100644 contrib/bind9/lib/isc/unix/keyboard.c create mode 100644 contrib/bind9/lib/isc/unix/net.c create mode 100644 contrib/bind9/lib/isc/unix/os.c create mode 100644 contrib/bind9/lib/isc/unix/resource.c create mode 100644 contrib/bind9/lib/isc/unix/socket.c create mode 100644 contrib/bind9/lib/isc/unix/socket_p.h create mode 100644 contrib/bind9/lib/isc/unix/stdio.c create mode 100644 contrib/bind9/lib/isc/unix/stdtime.c create mode 100644 contrib/bind9/lib/isc/unix/strerror.c create mode 100644 contrib/bind9/lib/isc/unix/syslog.c create mode 100644 contrib/bind9/lib/isc/unix/time.c create mode 100644 contrib/bind9/lib/isc/version.c create mode 100644 contrib/bind9/lib/isccc/Makefile.in create mode 100644 contrib/bind9/lib/isccc/alist.c create mode 100644 contrib/bind9/lib/isccc/api create mode 100644 contrib/bind9/lib/isccc/base64.c create mode 100644 contrib/bind9/lib/isccc/cc.c create mode 100644 contrib/bind9/lib/isccc/ccmsg.c create mode 100644 contrib/bind9/lib/isccc/include/Makefile.in create mode 100644 contrib/bind9/lib/isccc/include/isccc/Makefile.in create mode 100644 contrib/bind9/lib/isccc/include/isccc/alist.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/base64.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/cc.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/ccmsg.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/events.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/lib.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/result.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/sexpr.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/symtab.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/symtype.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/types.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/util.h create mode 100644 contrib/bind9/lib/isccc/include/isccc/version.h create mode 100644 contrib/bind9/lib/isccc/lib.c create mode 100644 contrib/bind9/lib/isccc/result.c create mode 100644 contrib/bind9/lib/isccc/sexpr.c create mode 100644 contrib/bind9/lib/isccc/symtab.c create mode 100644 contrib/bind9/lib/isccc/version.c create mode 100644 contrib/bind9/lib/isccfg/Makefile.in create mode 100644 contrib/bind9/lib/isccfg/api create mode 100644 contrib/bind9/lib/isccfg/include/Makefile.in create mode 100644 contrib/bind9/lib/isccfg/include/isccfg/Makefile.in create mode 100644 contrib/bind9/lib/isccfg/include/isccfg/cfg.h create mode 100644 contrib/bind9/lib/isccfg/include/isccfg/grammar.h create mode 100644 contrib/bind9/lib/isccfg/include/isccfg/log.h create mode 100644 contrib/bind9/lib/isccfg/include/isccfg/namedconf.h create mode 100644 contrib/bind9/lib/isccfg/include/isccfg/version.h create mode 100644 contrib/bind9/lib/isccfg/log.c create mode 100644 contrib/bind9/lib/isccfg/namedconf.c create mode 100644 contrib/bind9/lib/isccfg/parser.c create mode 100644 contrib/bind9/lib/isccfg/version.c create mode 100644 contrib/bind9/lib/lwres/Makefile.in create mode 100644 contrib/bind9/lib/lwres/api create mode 100644 contrib/bind9/lib/lwres/assert_p.h create mode 100644 contrib/bind9/lib/lwres/context.c create mode 100644 contrib/bind9/lib/lwres/context_p.h create mode 100644 contrib/bind9/lib/lwres/gai_strerror.c create mode 100644 contrib/bind9/lib/lwres/getaddrinfo.c create mode 100644 contrib/bind9/lib/lwres/gethost.c create mode 100644 contrib/bind9/lib/lwres/getipnode.c create mode 100644 contrib/bind9/lib/lwres/getnameinfo.c create mode 100644 contrib/bind9/lib/lwres/getrrset.c create mode 100644 contrib/bind9/lib/lwres/herror.c create mode 100644 contrib/bind9/lib/lwres/include/Makefile.in create mode 100644 contrib/bind9/lib/lwres/include/lwres/Makefile.in create mode 100644 contrib/bind9/lib/lwres/include/lwres/context.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/int.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/ipv6.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/lang.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/list.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/lwbuffer.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/lwpacket.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/lwres.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/netdb.h.in create mode 100644 contrib/bind9/lib/lwres/include/lwres/platform.h.in create mode 100644 contrib/bind9/lib/lwres/include/lwres/result.h create mode 100644 contrib/bind9/lib/lwres/include/lwres/version.h create mode 100644 contrib/bind9/lib/lwres/lwbuffer.c create mode 100644 contrib/bind9/lib/lwres/lwconfig.c create mode 100644 contrib/bind9/lib/lwres/lwpacket.c create mode 100644 contrib/bind9/lib/lwres/lwres_gabn.c create mode 100644 contrib/bind9/lib/lwres/lwres_gnba.c create mode 100644 contrib/bind9/lib/lwres/lwres_grbn.c create mode 100644 contrib/bind9/lib/lwres/lwres_noop.c create mode 100644 contrib/bind9/lib/lwres/lwresutil.c create mode 100644 contrib/bind9/lib/lwres/man/Makefile.in create mode 100644 contrib/bind9/lib/lwres/man/lwres.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_buffer.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_buffer.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_buffer.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_config.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_config.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_config.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_context.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_context.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_context.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_gabn.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_gabn.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_gabn.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_gai_strerror.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_gai_strerror.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_gethostent.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_gethostent.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_gethostent.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_getipnode.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_getipnode.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_getipnode.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_getnameinfo.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_getnameinfo.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_gnba.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_gnba.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_gnba.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_hstrerror.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_hstrerror.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_inetntop.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_inetntop.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_inetntop.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_noop.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_noop.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_noop.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_packet.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_packet.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_packet.html create mode 100644 contrib/bind9/lib/lwres/man/lwres_resutil.3 create mode 100644 contrib/bind9/lib/lwres/man/lwres_resutil.docbook create mode 100644 contrib/bind9/lib/lwres/man/lwres_resutil.html create mode 100644 contrib/bind9/lib/lwres/print.c create mode 100644 contrib/bind9/lib/lwres/print_p.h create mode 100644 contrib/bind9/lib/lwres/unix/Makefile.in create mode 100644 contrib/bind9/lib/lwres/unix/include/Makefile.in create mode 100644 contrib/bind9/lib/lwres/unix/include/lwres/Makefile.in create mode 100644 contrib/bind9/lib/lwres/unix/include/lwres/net.h create mode 100644 contrib/bind9/lib/lwres/version.c create mode 100644 contrib/bind9/libtool.m4 create mode 100644 contrib/bind9/ltmain.sh create mode 100644 contrib/bind9/make/Makefile.in create mode 100644 contrib/bind9/make/includes.in create mode 100644 contrib/bind9/make/mkdep.in create mode 100644 contrib/bind9/make/rules.in create mode 100755 contrib/bind9/mkinstalldirs create mode 100644 contrib/bind9/version diff --git a/contrib/bind9/CHANGES b/contrib/bind9/CHANGES new file mode 100644 index 000000000000..ac7f212853fa --- /dev/null +++ b/contrib/bind9/CHANGES @@ -0,0 +1,5479 @@ + + --- 9.3.0rc4 released --- + +1709. [port] solaris: add SMF support. + +1708. [cleanup] Replaced dns_fullname_hash() with dns_name_fullhash() + for conformance to the name space convention. Binary + backward compatibility to the old function name is + provided. [RT #12376] + +1707. [contrib] sdb/ldap updated to version 1.0-beta. + +1706. [bug] 'rndc stop' failed to cause zones to be flushed + sometimes. [RT #12328] + +1704. [port] lwres needed a snprintf() implementation for + platforms without snprintf(). Add missing + "#include ". [RT #12321] + +1703. [bug] named would loop sending NOTIFY messages when it + failed to receive a response. [RT #12322] + +1702. [bug] also-notify should not be applied to builtin zones. + [RT #12323] + +1701. [doc] A minimal named.conf man page. + +1700. [func] nslookup is no longer to be treated as deprecated. + Remove "deprecated" warning message. Add man page. + +1699. [bug] dnssec-signzone can generate "not exact" errors + when resigning. [RT #12281] + +1698. [doc] Use reserved IPv6 documentation prefix. + +1697. [bug] xxx-source{,-v6} was not effective when it + specified one of listening addresses and a + different port than the listening port. [RT #12257] + + --- 9.3.0rc3 released --- + +1696. [bug] dnssec-signzone failed to clean out nodes that + consisted of only NSEC and RRSIG records. + [RT #12154] + +1695. [bug] DS records when forwarding require special handling. + [RT #12133] + +1694. [bug] Report if the builtin views of "_default" / "_bind" + are defined in named.conf. [RT #12023] + +1693. [bug] max-journal-size was not effective for master zones + with ixfr-from-differences set. [RT# 12024] + +1692. [bug] Don't set -I, -L and -R flags when libcrypto is in + /usr/lib. [RT #11971] + +1691. [bug] sdb's attachversion was not complete. [RT #11990] + +1690. [bug] Delay detaching view from the client until UPDATE + processing completes when shutting down. [RT #11714] + +1689. [bug] DNS_NAME_TOREGION() and DNS_NAME_SPLIT() macros + contained gratuitous semicolons. [RT #11707] + +1688. [bug] LDFLAGS was not supported. + +1687. [bug] Race condition in dispatch. [RT #10272] + +1686. [bug] Named sent a extraneous NOTIFY when it received a + redundant UPDATE request. [RT #11943] + + --- 9.3.0rc2 released --- + +1685. [bug] Change #1679 loop tests weren't quite right. + +1683. [bug] dig +sigchase could leak memory. [RT #11445] + +1682. [port] Update configure test for (long long) printf format. + [RT #5066] + +1681. [bug] Only set SO_REUSEADDR when a port is specified in + isc_socket_bind(). [RT #11742] + +1679. [bug] When there was a single nameserver with multiple + addresses for a zone not all addresses were tried. + [RT #11706] + +1678. [bug] RRSIG should use TYPEXXXXX for unknown types. + +1677. [bug] dig: +aaonly didn't work, +aaflag undocumented. + +1675. [bug] named would sometimes add extra NSEC records to + the authority section. + +1674. [port] linux: increase buffer size used to scan + /proc/net/if_inet6. + +1673. [port] linux: issue a error messages if IPv6 interface + scans fails. + +1672. [cleanup] Tests which only function in a threaded build + now return R:THREADONLY (rather than R:UNTESTED) + in a non-threaded build. + +1671. [contrib] queryperf: add NAPTR to the list of known types. + +1670. [func] Log UPDATE requests to slave zones without an acl as + "disabled" at debug level 3. [RT# 11657] + +1668. [bug] DIG_SIGCHASE was making bin/dig/host dump core. + +1667. [port] linux: not all versions have IF_NAMESIZE. + +1666. [bug] The optional port on hostnames in dual-stack-servers + was being ignored. + +1663. [func] Look for OpenSSL by default. + +1661. [bug] Restore dns_name_concatenate() call in + adb.c:set_target(). [RT #11582] + +1660. [bug] win32: connection_reset_fix() was being called + unconditionally. [RT #11595] + + --- 9.3.0rc1 released --- + +1664. [bug] nsupdate needed KEY for SIG(0), not DNSKEY. + +1662. [bug] Change #1658 failed to change one use of 'type' + to 'keytype'. + +1659. [cleanup] Cleanup some messages that were referring to KEY vs + DNSKEY, NXT vs NSEC and SIG vs RRSIG. + +1658. [func] Update dnssec-keygen to default to KEY for HMAC-MD5 + and DH. Tighten which options apply to KEY and + DNSKEY records. + +1657. [doc] ARM: document query log output. + +1656. [doc] Update DNSSEC description in ARM to cover DS, NSEC + DNSKEY and RRSIG. [RT #11542] + +1655. [bug] Logging multiple versions w/o a size was broken. + [RT #11446] + +1654. [bug] isc_result_totext() contained array bounds read + error. + +1653. [func] Add key type checking to dst_key_fromfilename(), + DST_TYPE_KEY should be used to read TSIG, TKEY and + SIG(0) keys. + +1652. [bug] TKEY still uses KEY. + +1651. [bug] dig: process multiple dash options. + +1650. [bug] dig, nslookup: flush standard out after each command. + +1649. [bug] Silence "unexpected non-minimal diff" message. + [RT #11206] + +1648. [func] Update dnssec-lookaside named.conf syntax to support + multiple dnssec-lookaside namespaces (not yet + implemented). + +1647. [bug] It was possible trigger a INSIST when chasing a DS + record that required walking back over a empty node. + [RT #11445] + +1646. [bug] win32: logging file versions didn't work with + non-UNC filenames. [RT#11486] + +1645. [bug] named could trigger a REQUIRE failure if multiple + masters with keys are specified. + +1644. [bug] Update the journal modification time after a + sucessfull refresh query. [RT #11436] + +1643. [bug] dns_db_closeversion() could leak memory / node + references. [RT #11163] + +1642. [port] Support OpenSSL implementations which don't have + DSA support. [RT #11360] + +1641. [bug] Update the check-names description in ARM. [RT #11389] + + --- 9.3.0beta4 released --- + +1640. [bug] win32: isc_socket_cancel(ISC_SOCKCANCEL_ACCEPT) was + incorrectly closing the socket. [RT #11291] + +1639. [func] Initial dlv system test. + +1638. [bug] "ixfr-from-differences" could generate a REQUIRE + failure if the journal open failed. [RT #11347] + +1637. [bug] Node reference leak on error in addnoqname(). + +1636. [bug] The dump done callback could get ISC_R_SUCCESS even if + a error had occured. The database version no longer + matched the version of the database that was dumped. + +1635. [bug] Memory leak on error in query_addds(). + +1634. [bug] named didn't supply a useful error message when it + detected duplicate views. [RT #11208] + +1633. [bug] named should return NOTIMP to update requests to a + slaves without a allow-update-forwarding acl specified. + [RT #11331] + +1632. [bug] nsupdate failed to send prerequisite only UPDATE + messages. [RT #11288] + +1631. [bug] dns_journal_compact() could sometimes corrupt the + journal. [RT #11124] + +1630. [contrib] queryperf: add support for IPv6 transport. + +1629. [func] dig now supports IPv6 scoped addresses with the + extended format in the local-server part. [RT #8753] + +1628. [bug] Typo in Compaq Trucluster support. [RT# 11264] + +1627. [bug] win32: sockets were not being closed when the + last external reference was removed. [RT# 11179] + +1626. [bug] --enable-getifaddrs was broken. [RT#11259] + +1625. [bug] named failed to load/transfer RFC2535 signed zones + which contained CNAMES. [RT# 11237] + +1606. [bug] DLV insecurity proof was failing. + +1605. [func] New dns_db_find() option DNS_DBFIND_COVERINGNSEC. + + --- 9.3.0beta3 released --- + +1624. [bug] zonemgr_putio() call should be locked. [RT# 11163] + +1623. [bug] A serial number of zero was being displayed in the + "sending notifies" log message when also-notify was + used. [RT #11177] + +1622. [func] probe the system to see if IPV6_(RECV)PKTINFO is + available, and suppress wildcard binding if not. + +1621. [bug] match-destinations did not work for IPv6 TCP queries. + [RT# 11156] + +1620. [func] When loading a zone report if it is signed. [RT #11149] + +1619. [bug] Missing ISC_LIST_UNLINK in end_reserved_dispatches(). + [RT# 11118] + +1618. [bug] Fencepost errors in dns_name_ishostname() and + dns_name_ismailbox() could trigger a INSIST(). + +1617. [port] win32: VC++ 6.0 support. + +1616. [compat] Ensure that named's version is visible in the core + dump. [RT #11127] + +1615. [port] Define ISC_SOCKADDR_LEN_T based on _BSD_SOCKLEN_T_ if + it is defined. + +1614. [port] win32: silence resource limit messages. [RT# 11101] + +1613. [bug] Builds would fail on machines w/o a if_nametoindex(). + Missing #ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX/#endif. + [RT #11119] + +1612. [bug] check-names at the option/view level could trigger + an INSIST. [RT# 11116] + +1611. [bug] solaris: IPv6 interface scanning failed to cope with + no active IPv6 interfaces. + +1610. [bug] On dual stack machines "dig -b" failed to set the + address type to be looked up with "@server". + [RT #11069] + +1600. [bug] Duplicate zone pre-load checks were not case + insensitive. + +1599. [bug] Fix memory leak on error path when checking named.conf. + +1598. [func] Specify that certain parts of the namespace must + be secure (dnssec-must-be-secure). + + --- 9.3.0beta2 released --- + +1609. [func] dig now has support to chase DNSSEC signature chains. + Requires -DDIG_SIGCHASE=1 to be set in STD_CDEFINES. + +1608. [func] dig and host now accept -4/-6 to select IP transport + to use when making queries. + +1607. [bug] dig, host and nslookup were still using random() + to generate query ids. [RT# 11013] + +1604. [bug] A xfrout_ctx_create() failure would result in + xfrout_ctx_destroy() being called with a + partially initialized structure. + +1603. [bug] nsupdate: set interactive based on isatty(). + [RT# 10929] + +1602. [bug] Logging to a file failed unless a size was specified. + [RT# 10925] + +1601. [bug] Silence spurious warning 'both "recursion no;" and + "allow-recursion" active' warning from view "_bind". + [RT# 10920] + +1594. [bug] 'rndc dumpdb' could prevent named from answering + queries while the dump was in progress. [RT #10565] + +1593. [bug] rndc should return "unknown command" to unknown + commands. [RT# 10642] + + --- 9.3.0beta1 released --- + +1592. [bug] configure_view() could leak a dispatch. [RT #10675] + +1591. [bug] libbind: updated to BIND 8.4.5. + +1590. [port] netbsd: update thread support. + +1589. [func] DNSSEC lookaside validation. + +1588. [bug] win32: TCP sockets could become blocked. [RT #10115] + +1587. [bug] dns_message_settsigkey() failed to clear existing key. + [RT #10590] + +1586. [func] "check-names" is now implemented. + +1584. [bug] "make test" failed with a read only source tree. + [RT #10461] + +1583. [bug] Records add via UPDATE failed to get the correct trust + level. [RT #10452] + +1582. [bug] rrset-order failed to work on RRsets with more + than 32 elements. [RT #10381] + +1581. [func] Disable DNSSEC support by default. To enable + DNSSEC specify "dnssec-enable yes;" in named.conf. + +1580. [bug] Zone destruction on final detach takes a long time. + [RT #3746] + +1579. [bug] Multiple task managers could not be created. + +1578. [bug] Don't use CLASS E IPv4 addresses when resolving. + [RT #10346] + +1577. [bug] Use isc_uint32_t in ultrasparc optimizer bug + workaround code. [RT #10331] + +1576. [bug] Race condition in dns_dispatch_addresponse(). + [RT# 10272] + +1575. [func] Log TSIG name on TSIG verify failure. [RT #4404] + +1574. [bug] Don't attempt to open the controls socket(s) when + running tests. [RT #9091] + +1573. [port] linux: update to libtool 1.5.2 so that + "make install DESTDIR=/xx" works with + "configure --with-libtool". [RT #9941] + +1572. [bug] nsupdate: sign the soa query to find the enclosing + zone if the server is specified. [RT #10148] + +1571. [bug] rbt:hash_node() could fail leaving the hash table + in an inconsistent state. [RT #10208] + +1570. [bug] nsupdate failed to handle classes other than IN. + New keyword 'class' which sets the default class. + [RT #10202] + +1569. [func] nsupdate new command 'answer' which displays the + complete answer message to the last update. + +1568. [bug] nsupdate now reports that the update failed in + interactive mode. [RT# 10236] + +1567. [bug] B.ROOT-SERVERS.NET is now 192.228.79.201. + +1566. [port] Support for the cmsg framework on Solaris and HP/UX. + This also solved the problem that match-destinations + for IPv6 addresses did not work on these systems. + [RT #10221] + +1565. [bug] CD flag should be copied to outgoing queries unless + the query is under a secure entry point in which case + CD should be set. + +1564. [func] Attempt to provide a fallback entropy source to be + used if named is running chrooted and named is unable + to open entropy source within the chroot area. + [RT #10133] + +1563. [bug] Gracefully fail when unable to obtain neither an IPv4 + nor an IPv6 dispatch. [RT #10230] + +1562. [bug] isc_socket_create() and isc_socket_accept() could + leak memory under error conditions. [RT #10230] + +1561. [bug] It was possible to release the same name twice if + named ran out of memory. [RT #10197] + +1560. [port] FreeBSD: work around FreeBSD 5.2 mapping EAI_NODATA + and EAI_NONAME to the same value. + +1559. [port] named should ignore SIGFSZ. + +1558. [func] New DNSSEC 'disable-algorithms'. Support entry into + child zones for which we don't have a supported + algorithm. Such child zones are treated as unsigned. + +1557. [func] Implement missing DNSSEC tests for + * NOQNAME proof with wildcard answers. + * NOWILDARD proof with NXDOMAIN. + Cache and return NOQNAME with wildcard answers. + +1556. [bug] nsupdate now treats all names as fully qualified. + [RT #6427] + +1555. [func] 'rrset-order cyclic' no longer has a random starting + point. [RT #7572] + +1554. [bug] dig, host, nslookup failed when no nameservers + were specified in /etc/resolv.conf. [RT #8232] + +1553. [bug] The windows socket code could stop accepting + connections. [RT#10115] + +1552. [bug] Accept NOTIFY requests from mapped masters if + matched-mapped is set. [RT #10049] + +1551. [port] Open "/dev/null" before calling chroot(). + +1550. [port] Call tzset(), if available, before calling chroot(). + +1549. [func] named-checkzone can now write out the zone contents + in a easily parsable format (-D and -o). + +1548. [bug] When parsing APL records it was possible to silently + accept out of range ADDRESSFAMILY values. [RT# 9979] + +1547. [bug] Named wasted memory recording duplicate lame zone + entries. [RT #9341] + +1546. [bug] We were rejecting valid secure CNAME to negative + answers. + +1545. [bug] It was possible to leak memory if named was unable to + bind to the specified transfer source and TSIG was + being used. [RT #10120] + +1544. [bug] Named would logged a single entry to a file despite it + being over the specified size limit. + +1543. [bug] Logging using "versions unlimited" did not work. + +1541. [func] NSEC now uses new bitmap format. + +1540. [bug] "rndc reload " was silently accepted. + [RT #8934] + +1539. [bug] Open UDP sockets for notify-source and transfer-source + that use reserved ports at startup. [RT #9475] + +1537. [func] New option "querylog". If set specify whether query + logging is to be enabled or disabled at startup. + +1536. [bug] Windows socket code failed to log a error description + when returning ISC_R_UNEXPECTED. [RT #9998] + +1534. [bug] Race condition when priming cache. [RT# 9940] + +1533. [func] Warn if both "recursion no;" and "allow-recursion" + are active. [RT# 4389] + +1532. [port] netbsd: the configure test for + requires . + +1531. [port] AIX more libtool fixes. + +1530. [bug] It was possible to trigger a INSIST() failure if a + slave master file was removed at just the correct + moment. [RT #9462] + +1529. [bug] "notify explicit;" failed to log that NOTIFY messages + were being sent for the zone. [RT# 9442] + +1528. [cleanup] Simplify some dns_name_ functions based on the + deprecation of bitstring labels. + +1527. [cleanup] Reduce the number of gettimeofday() calls without + losing necessary timer granularity. + +1525. [bug] dns_cache_create() could trigger a REQUIRE + failure in isc_mem_put() during error cleanup. + [RT# 9360] + +1524. [port] AIX needs to be able to resolve all symbols when + creating shared libraries (--with-libtool). + +1523. [bug] Fix race condition in rbtdb. [RT# 9189] + +1522. [bug] dns_db_findnode() relax the requirements on 'name'. + [RT# 9286] + +1521. [bug] dns_view_createresolver() failed to check the + result from isc_mem_create(). [RT# 9294] + +1520. [protocol] Add SSHFP (SSH Finger Print) type. + +1519. [bug] dnssec-signzone:nsec_setbit() computed the wrong + length of the new bitmap. + +1518. [bug] dns_nsec_buildrdata(), and hence dns_nsec_build(), + contained a off-by-one error when working out the + number of octets in the bitmap. + +1517. [port] Support for IPv6 interface scanning on HP/UX and + TrueUNIX 5.1. + +1516. [func] Roll the DNSSEC types to RRSIG, NSEC and DNSKEY. + +1515. [func] Allow transfer source to be set in a server statement. + [RT #6496] + +1514. [bug] named: isc_hash_destroy() was being called too early. + [RT #9160] + +1513. [doc] Add "US" to root-delegation-only exclude list. + +1512. [bug] Extend the delegation-only logging to return query + type, class and responding nameserver. + +1511. [bug] delegation-only was generating false positives + on negative answers from subzones. + +1510. [func] New view option "root-delegation-only". Apply + delegation-only check to all TLDs and root. + Note there are some TLDs that are NOT delegation + only (e.g. DE, LV, US and MUSEUM) these can be excluded + from the checks by using exclude. + + root-delegation-only exclude { + "DE"; "LV"; "US"; "MUSEUM"; + }; + +1509. [bug] Hint zones should accept delegation-only. Forward + zone should not accept delegation-only. + +1508. [bug] Don't apply delegation-only checks to answers from + forwarders. + +1507. [bug] Handle BIND 8 style returns to NS queries to parents + when making delegation-only checks. + +1506. [bug] Wrong return type for dns_view_isdelegationonly(). + +1505. [bug] Uninitialized rdataset in sdb. [RT #8750] + +1504. [func] New zone type "delegation-only". + +1503. [port] win32: install libeay32.dll outside of system32. + +1502. [bug] nsupdate: adjust timeouts for UPDATE requests over TCP. + +1501. [func] Allow TCP queue length to be specified via + named.conf, tcp-listen-queue. + +1500. [bug] host failed to lookup MX records. Also look up + AAAA records. + +1475. [port] Probe for old sprintf(). + +1474. [port] Provide strtoul() and memmove() for platforms + without them. + +1469. [func] Log end of outgoing zone transfer at same level + as the start of transfer is logged. [RT #4441] + +1468. [func] Internal zones are no longer counted for + 'rndc status'. [RT #4706] + +1467. [func] $GENERATES now supports optional class and ttl. + +1458. [cleanup] sprintf() -> snprintf(). + +1457. [port] Provide strlcat() and strlcpy() for platforms without + them. + +1455. [bug] missing from server grammar in + doc/misc/options. [RT #5616] + +1454. [port] Use getifaddrs() if available for interface scanning. + --disable-getifaddrs to override. Glibc currently + has a getifaddrs() that does not support IPv6. + Use --enable-getifaddrs=glibc to force the use of + this version under linux machines. + +1446. [func] Implemented undocumented alternate transfer sources + from BIND 8. See use-alt-transfer-source, + alt-transfer-source and alt-transfer-source-v6. + + SECURITY: use-alt-transfer-source is ENABLED unless + you are using views. This may cause a security risk + resulting in accidental disclosure of wrong zone + content if the master supplying different source + content based on IP address. If you are not certain + ISC recommends setting use-alt-transfer-source no; + +1444. [func] dns_view_findzonecut2() allows you to specify if the + cache should be searched for zone cuts. + +1443. [func] Masters lists can now be specified and referenced + in zone masters clauses and other masters lists. + +1442. [func] New functions for manipulating port lists: + dns_portlist_create(), dns_portlist_add(), + dns_portlist_remove(), dns_portlist_match(), + dns_portlist_attach() and dns_portlist_detach(). + +1441. [func] It is now possible to tell dig to bind to a specific + source port. + +1440. [func] It is now possible to tell named to avoid using + certain source ports (avoid-v4-udp-ports, + avoid-v6-udp-ports). + +1438. [func] Log TSIG (if any) when logging NOTIFY requests. + +1436. [func] dns_zonemgr_resumexfrs() can be used to restart + stalled transfers. + +1433. [bug] named could trigger a REQUIRE failure if it could + not get a file descriptor when attempting to write + a master file. [RT #4347] + +1432. [func] The advertised EDNS UDP buffer size can now be set + via named.conf (edns-udp-size). + +1430. [port] linux: IPv6 interface scanning support. + +1422. [func] Log name/type/class when denying a query. [RT #4663] + +1421. [func] Differentiate updates that don't succeed due to + prerequisites (unsuccessful) vs other reasons + (failed). + +1417. [func] ID.SERVER/CHAOS is now a built in zone. + See "server-id" for how to configure. + +1415. [func] DS TTL now derived from NS ttl. NXT TTL now derived + from SOA MINIMUM. + +1414. [func] Support for KSK flag. + +1413. [func] Explictly request the (re-)generation of DS records from + keysets (dnssec-signzone -g). + +1412. [func] You can now specify servers to be tried if a nameserver + has IPv6 address and you only support IPv4 or the + reverse. See dual-stack-servers. + +1410. [func] Handle records that live in the parent zone, e.g. DS. + +1409. [bug] DS should have attribute DNS_RDATATYPEATTR_DNSSEC. + +1404. [bug] libbind: ns_name_ntol() could overwrite a zero length + buffer. + +1403. [func] dnssec-signzone, dnssec-keygen, dnssec-makekeyset + dnssec-signkey now report their version in the + usage message. + +1402. [cleanup] A6 has been moved to experimental and is no longer + fully supported. + +1400. [bug] Block the addition of wildcard NS records by IXFR + or UPDATE. [RT #3502] + +1398. [doc] ARM: notify-also should have been also-notify. + [RT #4345] + +1396. [func] dnssec-signzone: adjust the default signing time by + 1 hour to allow for clock skew. + +1394. [func] It is now possible to check if a particular element is + in a acl. Remove duplicate entries from the localnets + acl. + +1393. [port] Bind to individual IPv6 interfaces if IPV6_IPV6ONLY + is not available in the kernel to prevent accidently + listening on IPv4 interfaces. + +1392. [bug] named-checkzone: update usage. + +1391. [func] Add support for IPv6 scoped addresses in named. + +1390. [func] host now supports ixfr. + +1386. [bug] named-checkzone -z stopped on errors in a zone. + [RT #3653] + +1383. [func] Track the serial number in a IXFR response and log if + a mismatch occurs. This is a more specific error than + "not exact". [RT #3445] + +1380. [func] 'rndc recursing' dump recursing queries to + 'recursing-file = "named.recursing";'. + +1379. [func] 'rndc status' now reports tcp and recursion quota + states. + +1378. [func] Improved positive feedback for 'rndc {reload|refresh}. + +1377. [func] dns_zone_load{new}() now reports if the zone was + loaded, queued for loading to up to date. + +1376. [func] New function dns_zone_logc() to log to specified + category. + +1375. [func] 'rndc dumpdb' now dumps the adb cache along with the + data cache. + +1374. [func] dns_adb_dump() now logs the lame zones associated + with each server. + +1371. [bug] notify-source-v6, transfer-source-v6 and + query-source-v6 with explicit addresses and using the + same ports as named was listening on could interfere + with named's ability to answer queries sent to those + addresses. + +1368. [func] remove support for bitstring labels. + +1367. [func] Use response times to select forwarders. + +1365. [func] "localhost" and "localnets" acls now include IPv6 + addresses / prefixes. + +1364. [func] Log file name when unable to open memory statistics + and dump database files. [RT# 3437] + +1363. [func] Listen-on-v6 now supports specific addresses. + +1362. [bug] remove IFF_RUNNING test when scanning interfaces. + +1361. [func] log the reason for rejecting a server when resolving + queries. + +1355. [bug] Fix DNSSEC wildcard proof for CNAME/DNAME. + +1344. [func] Log if the serial number on the master has gone + backwards. + If you have multiple machines specified in the masters + clause you may want to set 'multi-master yes;' to + suppress this warning. + +1343. [func] Log successful notifies received (info). Adjust log + level for failed notifies to notice. + +1342. [func] Log remote address with TCP dispatch failures. + +1341. [func] Allow a rate limiter to be stalled. + +1339. [func] dig, host and nslookup now use IP6.ARPA for nibble + lookups. Bit string lookups are no longer attempted. + +1336. [func] Nibble lookups under IP6.ARPA are now supported by + dns_byaddr_create(). dns_byaddr_createptrname() is + deprecated, use dns_byaddr_createptrname2() instead. + +1332. [func] Report the current serial with periodic commits when + rolling forward the journal. + +1331. [func] Generate DNSSEC wildcard proofs. + +1329. [func] named-checkzone will now check if nameservers that + appear to be IP addresses. Available modes "fail", + "warn" (default) and "ignore" the results of the + check. + +1328. [bug] The validator could incorrectly verify an invalid + negative proof. + +1322. [bug] dnssec-signzone usage message was misleading. + +1321. [bug] If the last RRset in a zone is glue, dnssec-signzone + would incorrectly duplicate its output and sign it. + +1313. [func] Query log now says if the query was signed (S) or + if EDNS was used (E). + +1312. [func] Log TSIG key used w/ outgoing zone transfers. + +1309. [func] Log that a zone transfer was covered by a TSIG. + +1308. [func] DS (delegation signer) support. + +1304. [func] New function: dns_zone_name(). + +1303. [func] Option 'flush-zones-on-shutdown ;'. + +1302. [func] Extended rndc dumpdb to support dumping of zones and + view selection: 'dumpdb [-all|-zones|-cache] [view]'. + +1301. [func] New category 'update-security'. + +1300. [port] Compaq Trucluster support. + +1293. [func] Entropy can now be retrieved from EGDs. [RT #2438] + +1292. [func] Enable IPv6 support when using ioctl style interface + scanning and OS supports SIOCGLIFADDR using struct + if_laddrreq. + +1291. [func] Enable IPv6 support when using sysctl style interface + scanning. + +1290. [func] "dig axfr" now reports the number of messages + as well as the number of records. + +1285. [func] lwres: probe the system to see what address families + are currently in use. + +1283. [func] Use "dataready" accept filter if available. + +1281. [func] Log zone when unable to get private keys to update + zone. Log zone when NXT records are missing from + secure zone. + +1278. [func] dig: now supports +[no]cl +[no]ttlid. + +1277. [func] You can now create your own customized printing + styles: dns_master_stylecreate() and + dns_master_styledestroy(). + +1271. [bug] "recursion available: {denied,approved}" was too + confusing. + +1267. [func] isc_file_openunique() now creates file using mode + 0666 rather than 0600. + +1254. [func] preferred-glue option from BIND 8.3. + +1250. [func] Nsupdate will report the address the update was + sent to. + +1247. [bug] Don't reset the interface index for link/site local + addresses. [RT #2576] + +1246. [func] New functions isc_sockaddr_issitelocal(), + isc_sockaddr_islinklocal(), isc_netaddr_issitelocal() + and isc_netaddr_islinklocal(). + +1243. [bug] It was possible to trigger a REQUIRE() in + dns_message_findtype(). [RT #2659] + +1235. [func] Report 'out of memory' errors from openssl. + +1234. [bug] contrib/sdb: 'zonetodb' failed to call + dns_result_register(). DNS_R_SEENINCLUDE should not + be fatal. + +1233. [bug] The flags field of a KEY record can be expressed in + hex as well as decimal. + +1226. [func] Use EDNS for zone refresh queries. [RT #2551] + +1225. [func] dns_message_setopt() no longer requires that + dns_message_renderbegin() to have been called. + +1224. [bug] 'rrset-order' and 'sortlist' should be additive + not exclusive. + +1223. [func] 'rrset-order' partially works 'cyclic' and 'random' + are supported. + +1220. [func] Support for APL rdata type. + +1219. [func] Named now reports the TSIG extended error code when + signature verification fails. [RT #1651] + +1217. [func] Report locations of previous key definition when a + duplicate is detected. + +1213. [func] Report view associated with client if it is not a + standard view (_default or _bind). + +1203. [func] Report locations of previous acl and zone definitions + when a duplicate is detected. + +1202. [func] New functions: cfg_obj_line() and cfg_obj_file(). + +1192. [bug] The seconds fields in LOC records were restricted + to three decimal places. More decimal places should + be allowed but warned about. + +1190. [func] Add the "rndc freeze" and "rndc unfreeze" commands. + [RT #2394] + +1187. [bug] named was incorrectly returning DNSSEC records + in negative responses when the DO bit was not set. + +1181. [func] Add the "key-directory" configuration statement, + which allows the server to look for online signing + keys in alternate directories. + +1180. [func] dnssec-keygen should always generate keys with + protocol 3 (DNSSEC), since it's less confusing + that way. + +1179. [func] Add SIG(0) support to nsupdate. + +1177. [func] Report view when loading zones if it is not a + standard view (_default or _bind). [RT #2270] + +1171. [func] Added function isc_region_compare(), updated files in + lib/dns to use this function instead of local one. + +1169. [func] Identify recursive queries in the query log. + +1163. [func] isc_time_formattimestamp() now includes the year. + +1159. [bug] MD and MF are not permitted to be loaded by RFC1123. + +1158. [func] Report the client's address when logging notify + messages. + +1157. [func] match-clients and match-destinations now accept + keys. [RT #2045] + +1155. [func] Recover from master files being removed from under + us. + +1153. [func] 'rndc {stop|halt} -p' now reports the process id + of the instance of named being shutdown. + +1151. [bug] nslookup failed to check that the arguments to + the port, timeout, and retry options were + valid integers and in range. [RT #2099] + +1150. [bug] named incorrectly accepted TTL values + containing plus or minus signs, such as + 1d+1h-1s. + +1149. [func] New function isc_parse_uint32(). + +1148. [func] 'rndc-confgen -a' now provides positive feedback. + +1147. [func] Set IPV6_V6ONLY on IPv6 sockets if supported by + the OS. listen-on-v6 { any; }; should no longer + result in IPv4 queries be accepted. Similarly + control { inet :: ... }; should no longer result + in IPv4 connections being accepted. This can be + overridden at compile time by defining + ISC_ALLOW_MAPPED=1. + +1146. [func] Allow IPV6_IPV6ONLY to be set/cleared on a socket if + supported by the OS by a new function + isc_socket_ipv6only(). + +1145. [func] "host" no longer reports a NOERROR/NODATA response + by printing nothing. [RT #2065] + +1143. [bug] When a trusted-keys statement was present and named + was built without crypto support, it would leak memory. + +1139. [func] It is now possible to flush a given name from the + cache(s) via 'rndc flushname name [view]'. [RT #2051] + +1138. [func] It is now possible to flush a given name from the + cache by calling the new function + dns_cache_flushname(). + +1137. [func] It is now possible to flush a given name from the + ADB by calling the new function dns_adb_flushname(). + +1135. [func] You can now override the default syslog() facility for + named/lwresd at compile time. [RT #1982] + +1132. [func] Improve UPDATE prerequisite failure diagnostic messages. + +1128. [func] sdb drivers can now provide RR data in either text + or wire format, the latter using the new functions + dns_sdb_putrdata() and dns_sdb_putnamedrdata(). + +1127. [func] rndc: If the server to contact has multiple addresses, + try all of them. + +1119. [func] Added support in Win32 for NTFS file/directory ACL's + for access control. + +1115. [func] Set maximum values for cleaning-interval, + heartbeat-interval, interface-interval, + max-transfer-idle-in, max-transfer-idle-out, + max-transfer-time-in, max-transfer-time-out, + statistics-interval of 28 days and + sig-validity-interval of 3660 days. [RT #2002] + +1110. [bug] dig should only accept valid abbreviations of +options. + [RT #2003] + +1105. [port] OpenUNIX 8 enable threads by default. [RT #1970] + +1080. [bug] BIND 8 compatibility: accept bare IP prefixes + as the second element of a two-element top level + sort list statement. [RT #1964] + +1079. [bug] BIND 8 compatibility: accept bare elements at top + level of sort list treating them as if they were + a single element list. [RT #1963] + +1077. [func] Do not accept further recursive clients when + the total number of recursive lookups being + processed exceeds max-recursive-clients, even + if some of the lookups are internally generated. + [RT #1915, #1938] + +1073. [bug] The ADB cache cleaning should also be space driven. + [RT #1915, #1938] + +1067. [func] Allow quotas to be soft, isc_quota_soft(). + +1065. [func] Runtime support to select new / old style interface + scanning using ioctls. + +1060. [func] Move refresh, stub and notify UDP retry processing + into dns_request. + +1059. [func] dns_request now support will now retry UDP queries, + dns_request_createvia2() and dns_request_createraw2(). + +1058. [func] Limited lifetime ticker timers are now available, + isc_timertype_limited. + +1055. [func] Version and hostname queries can now be disabled + using "version none;" and "hostname none;", + respectively. + +1049. [func] "pid-file none;" will disable writing a pid file. + [RT #1848] + +1037. [bug] Negative responses whose authority section contain + SOA or NS records whose owner names are not equal + equal to or parents of the query name should be + rejected. [RT #1862] + +1036. [func] Silently drop requests received via multicast as + long as there is no final multicast DNS standard. + +1035. [bug] If we respond to multicast queries (which we + currently do not), respond from a unicast address + as specified in RFC 1123. [RT #137] + +1034. [bug] Ignore the RD bit on multicast queries as specified + in RFC 1123. [RT #137] + +1032. [func] hostname.bind/txt/chaos now returns the name of + the machine hosting the nameserver. This is useful + in diagnosing problems with anycast servers. + +1025. [bug] Don't use multicast addresses to resolve iterative + queries. [RT #101] + +1024. [port] Compilation failed on HP-UX 11.11 due to + incompatible use of the SIOCGLIFCONF macro + name. [RT #1831] + +1023. [func] Accept hints without TTLs. + +1011. [cleanup] Removed isc_dir_current(). + +1009. [port] OpenUNIX 8 support. [RT #1728] + +1008. [port] libtool.m4, ltmain.sh from libtool-1.4.2. + +1007. [port] config.guess, config.sub from autoconf-2.52. + +1003. [func] Add the +retry option to dig. + + 999. [func] "rndc retransfer zone [class [view]]" added. + [RT #1752] + + 998. [func] named-checkzone now has arguments to specify the + chroot directory (-t) and working directory (-w). + [RT #1755] + + 997. [func] Add support for RSA-SHA1 keys (RFC3110). + + 996. [func] Issue warning if the configuration filename contains + the chroot path. + + 994. [func] Treat non-authoritative responses to queries for type + NS as referrals even if the NS records are in the + answer section, because BIND 8 servers incorrectly + send them that way. This is necessary for DNSSEC + validation of the NS records of a secure zone to + succeed when the parent is a BIND 8 server. [RT #1706] + + 993. [func] dig: -v now reports the version. + + 991. [func] Lower UDP refresh timeout messages to level + debug 1. + + 985. [func] Consider network interfaces to be up iff they have + a nonzero IP address rather than based on the + IFF_UP flag. [RT #1160] + + 983. [func] The server now supports generating IXFR difference + sequences for non-dynamic zones by comparing zone + versions, when enabled using the new config + option "ixfr-from-differences". [RT #1727] + + 982. [func] If "memstatistics-file" is set in options the memory + statistics will be written to it. + + 981. [func] The dnssec tools can now take multiple '-r randomfile' + arguments. + + 979. [func] Incremental master file dumping. dns_master_dumpinc(), + dns_master_dumptostreaminc(), dns_dumpctx_attach(), + dns_dumpctx_detach(), dns_dumpctx_cancel(), + dns_dumpctx_db() and dns_dumpctx_version(). + + 976. [func] named-checkconf can now test load master zones + (named-checkconf -z). [RT #1468] + + 970. [func] 'max-journal-size' can now be used to set a target + size for a journal. + + 969. [func] dig now supports the undocumented dig 8 feature + of allowing arbitrary labels, not just dotted + decimal quads, with the -x option. This can be + used to conveniently look up RFC2317 names as in + "dig -x 10.0.0.0-127". [RT #827, #1576, #1598] + + --- 9.2.3rc1 released --- + +1499. [bug] isc_random need to be seeded better if arc4random() + is not used. + +1498. [port] bsdos: 5.x support. + +1497. [protocol] dig, nslookup and host now perform nibble lookups + under IP6.ARPA, use -i for IP6.INT (dig and host). + lwres now uses IP6.ARPA. + +1496. [port] test for pthread_attr_setstacksize(). + +1495. [cleanup] Replace hash functions with universal hash. + +1494. [security] Turn on RSA BLINDING as a precaution. + +1493. [doc] A6 and "bitstring" labels are now experimental. + +1492. [cleanup] Preserve rwlock quota context when upgrading / + downgrading. [RT #5599] + +1491. [bug] dns_master_dump*() would produce extraneous $ORIGIN + lines. [RT #6206] + +1490. [bug] Accept reading state as well as working state in + ns_client_next(). [RT #6813] + +1489. [compat] Treat 'allow-update' on slave zones as a warning. + [RT #3469] + +1488. [bug] Don't override trust levels for glue addresses. + [RT #5764] + +1487. [bug] A REQUIRE() failure could be triggered if a zone was + queued for transfer and the zone was then removed. + [RT #6189] + +1486. [bug] isc_print_snprintf() '%%' consumed one too many format + characters. [RT# 8230] + +1485. [bug] gen failed to handle high type values. [RT #6225] + +1484. [bug] The number of records reported after a AXFR was wrong. + [RT #6229] + +1483. [bug] dig axfr failed if the message id in the answer failed + to match that in the request. Only the id in the first + message is required to match. [RT #8138] + +1482. [bug] named could fail to start if the kernel supports + IPv6 but no interfaces are configured. Similarly + for IPv4. [RT #6229] + +1481. [bug] Refresh and stub queries failed to use masters keys + if specified. [RT #7391] + +1480. [bug] Provide replay protection for rndc commands. Full + replay protection requires both rndc and named to + be updated. Partial replay protection (limited + exposure after restart) is provided if just named + is updated. + +1479. [bug] cfg_create_tuple() failed to handle out of + memory cleanup. parse_list() would leak memory + on syntax errors. + +1478. [port] ifconfig.sh didn't account for other virtual + interfaces. It now takes a optional argument + to specify the first interface number. [RT #3907] + +1477. [bug] memory leak using stub zones and TSIG. + +1476. [port] win32: port unreachables were blocking further i/o + on sockets (Windows 2000 SP2 and later). + +1473. [bug] create_map() and create_string() failed to handle out + of memory cleanup. [RT #6813] + +1472. [contrib] idnkit-1.0 from JPNIC, replaces mdnkit. + +1471. [bug] libbind: updated to BIND 8.4.0. + +1470. [bug] Incorrect length passed to snprintf. [RT #5966] + +1466. [bug] lwresd configuration errors resulted in memory + and lock leaks. [RT #5228] + +1465. [bug] isc_base64_decodestring() and isc_base64_tobuffer() + failed to check that trailing bits were zero allowing + some invalid base64 strings to be accepted. [RT #5397] + +1464. [bug] Preserve "out of zone" data for outgoing zone + transfers. [RT #5192] + +1463. [bug] dns_rdata_from{wire,struct}() failed to catch bad + NXT bit maps. [RT #5577] + +1462. [bug] parse_sizeval() failed to check the token type. + [RT #5586] + +1461. [bug] Remove deadlock from rbtdb code. [RT #5599] + +1460. [bug] inet_pton() failed to reject certain malformed + IPv6 literals. + +1459. [bug] win32: we were leaking a bits in the exception + fd_set resulting in "Socket operation on non-socket" + errors from select(). [RT #2966] + +1456. [contrib] gen-data-queryperf.py from Stephane Bortzmeyer. + +1453. [doc] ARM: $GENERATE example wasn't accurate. [RT #5298] + +1452. [bug] Bad #ifdef, ISC_RFC2335 -> ISC_RFC2535. + +1451. [bug] rndc-confgen didn't exit with a error code for all + failures. [RT #5209] + +1450. [bug] Fetching expired glue failed under certain + circumstances. [RT #5124] + +1449. [bug] query_addbestns() didn't handle running out of memory + gracefully. + +1448. [bug] Handle empty wildcards labels. + +1447. [bug] We were casting (unsigned int) to and from (void *). + rdataset->private4 is now rdataset->privateuint4 + to reflect a type change. + +1445. [bug] DNS_ADBFIND_STARTATROOT broke stub zones. This has + been replaced with DNS_ADBFIND_STARTATZONE which + causes the search to start using the closest zone. + +1439. [bug] Named could return NOERROR with certain NOTIFY + failures. Return NOTAUTH if the NOTIFY zone is + not being served. + +1435. [bug] zmgr_resume_xfrs() was being called read locked + rather than write locked. zmgr_resume_xfrs() + was not being called if the zone was being + shutdown. + +1437. [bug] Leave space for stdio to work in. [RT #5033] + +1434. [bug] "rndc reconfig" failed to initiate the initial + zone transfer of new slave zones. + +1431. [bug] isc_print_snprintf() "%s" with precision could walk off + end of argument. [RT #5191] + +1429. [bug] Prevent the cache getting locked to old servers. + +1424. [bug] EDNS version not being correctly printed. + +1423. [contrib] queryperf: added A6 and SRV. + +1420. [port] solaris: work around gcc optimizer bug. + +1419. [port] openbsd: use /dev/arandom. [RT #4950] + +1418. [bug] 'rndc reconfig' did not cause new slaves to load. + +1416. [bug] Empty node should return NOERROR NODATA, not NXDOMAIN. + [RT #4715] + +1411. [bug] empty nodes should stop wildcard matches. [RT #4802] + +1408. [bug] "make distclean" was not complete. [RT #4700] + +1407. [bug] lfsr incorrectly implements the shift register. + [RT #4617] + +1406. [bug] dispatch initializes one of the LFSR's with a incorrect + polynomial. [RT #4617] + +1405. [func] Use arc4random() if available. + +1401. [bug] adb wasn't clearing state when the timer expired. + +1399. [bug] Use serial number arithmetic when testing SIG + timestamps. [RT #4268] + +1397. [bug] J.ROOT-SERVERS.NET is now 192.58.128.30. + +1389. [bug] named could fail to rotate long log files. [RT #3666] + +1388. [port] irix: check for sys/sysctl.h and NET_RT_IFLIST before + defining HAVE_IFLIST_SYSCTL. [RT #3770] + +1387. [bug] named could crash due to an access to invalid memory + space (which caused an assertion failure) in + incremental cleaning. [RT #3588] + +1385. [bug] Setting serial-query-rate to 10 would trigger a + REQUIRE failure. + +1384. [bug] host was incompatible with BIND 8 in its exit code and + in the output with the -l option. [RT #3536] + +1373. [bug] Recovery from expired glue failed under certain + circumstances. + +1372. [bug] named crashes with an assertion failure on exit when + sharing the same port for listening and querying, and + changing listening addresses several times. [RT# 3509] + +1370. [bug] dig '+[no]recurse' was incorrectly documented. + +1369. [bug] Adding an NS record as the lexicographically last + record in a secure zone didn't work. + +1366. [contrib] queryperf usage was incomplete. Add '-h' for help. + +1348. [port] win32: Rewrote code to use I/O Completion Ports + in socket.c and eliminating a host of socket + errors. Performance is enhanced. + +1333. [contrib] queryperf now reports a summary of returned + rcodes (-c), rcodes are printed in mnemonic form (-v). + +1299. [bug] Set AI_ADDRCONFIG when looking up addresses + via getaddrinfo() (affects dig, host, nslookup, rndc + and nsupdate). + +1199. [doc] ARM reference to RFC 2157 should have been RFC 1918. + [RT #2436] + +1122. [tuning] Resolution timeout reduced from 90 to 30 seconds. + [RT #2046] + + 992. [doc] dig: ~/.digrc is now documented. + + --- 9.2.2 released --- + +1428. [port] hpux: temporary work around of hpux 11.11 interface + scanning. + +1427. [bug] Race condition in adb with threaded build. + +1426. [cleanup] Disable RFC2535 style DNSSEC. This is incompatible + with the forthcoming DS style DNSSEC. + +1425. [port] linux/libbind: define __USE_MISC when testing *_r() + function prototypes in netdb.h. [RT #4921] + +1395. [port] OpenSSL 0.9.7 defines CRYPTO_LOCK_ENGINE but doesn't + have a working implementation. [RT #4079] + +1382. [bug] make install failed with --enable-libbind. [RT #3656] + +1381. [bug] named failed to correctly process answers that + contained DNAME records where the resulting CNAME + resulted in a negative answer. + + --- 9.2.2rc1 released --- + +1360. [bug] --enable-libbind would fail when not built in the + source tree for certain OS's. + +1359. [security] Support patches OpenSSL libraries. + http://www.cert.org/advisories/CA-2002-23.html + +1358. [bug] It was possible to trigger a INSIST when debugging + large dynamic updates. [RT #3390] + +1357. [bug] nsupdate was extremely wasteful of memory. + +1356. [tuning] Reduce the number of events / quantum for zone tasks. + +1354. [doc] lwres man pages had illegal nroff. + +1353. [contrib] sdb/ldap to version 0.9. + +1352. [bug] dig, host, nslookup when falling back to TCP use the + current search entry (if any). [RT #3374] + +1351. [bug] lwres_getipnodebyname() returned the wrong name + when given a IPv4 literal, af=AF_INET6 and AI_MAPPED + was set. + +1350. [bug] dns_name_fromtext() failed to handle too many labels + gracefully. + +1349. [security] Minimum OpenSSL version now 0.9.6e (was 0.9.5a). + http://www.cert.org/advisories/CA-2002-23.html + +1346. [bug] Win32: select timeout in socket.c was too small + as value given was meant to be milliseconds and + timeval structure requires microseconds. This + caused high CPU loads with a compute bound loop. + [RT #3358] + +1345. [port] Use a explicit -Wformat with gcc. Not all versions + include it in -Wall. + +1340. [bug] Delay and spread out the startup refresh load. + +1335. [bug] When performing a nonexistence proof, the validator + should discard parent NXTs from higher in the DNS. + +1334. [bug] When signing/verifying rdatasets, duplicate rdatas + need to be suppressed. + +1330. [bug] When processing events (non-threaded) only allow + the task one chance to use to use its quantum. + +1327. [bug] The validator would incorrectly mark data as insecure + when seeing a bogus signature before a correct + signature. + +1326. [bug] DNAME/CNAME signatures were not being cached when + validation was not being performed. [RT #3284] + +1325. [bug] If the tcpquota was exhausted it was possible to + to trigger a INSIST() failure. + +1324. [port] darwin: ifconfig.sh now supports darwin. + +1323. [port] linux: Slackware 4.0 needs . [RT #3205] + +1320. [doc] query-source-v6 was missing from options section. + [RT #3218] + +1319. [func] libbind: log attempts to exploit #1318. + +1318. [bug] libbind: Remote buffer overrun. + +1317. [port] libbind: TrueUNIX 5.1 does not like __align as a + element name. + +1316. [bug] libbind: gethostans() could get out of sync parsing + the response if there was a very long CNAME chain. + +1315. [bug] Options should apply to the internal _bind view. + +1314. [port] Handle ECONNRESET from sendmsg() [unix]. + +1311. [bug] lwres_getrrsetbyname leaked memory. [RT #3159] + +1310. [bug] 'rndc stop' failed to cause zones to be flushed + sometimes. [RT #3157] + +1307. [bug] nsupdate: allow white space base64 key data. + +1306. [bug] Badly encoded LOC record when the size, horizontal + precision or vertical precision was 0.1m. + +1305. [bug] Document that internal zones are included in the + rndc status results. + +1298. [bug] The CINCLUDES macro in lib/dns/sec/dst/Makefile + could be left with a trailing "\" after configure + has been run. + +1297. [port] linux: make handling EINVAL from socket() no longer + conditional on #ifdef LINUX. + +1296. [bug] isc_log_closefilelogs() needed to lock the log + context. + +1295. [bug] isc_log_setdebuglevel() needed to lock the log + context. + +1294. [func] libbind: no longer attempts bit string labels for + IPv6 reverse resolution. Try IP6.ARPA then IP6.INT + for nibble style resolution. + +1289. [port] See if -ldl is required for OpenSSL? [RT #2672] + +1288. [bug] Adjusted REQUIRE's in lib/dns/name.c to better + reflect written requirements. + +1287. [bug] REQUIRE that DNS_DBADD_MERGE only be set when adding + a rdataset to a zone db in the rbtdb implementation of + addrdataset. + +1286. [bug] dns_name_downcase() enforce requirement that + target != NULL or name->buffer != NULL. + +1284. [bug] The RTT estimate on unused servers was not aged. + [RT #2569] + +1282. [port] libbind: hpux 11.11 interface scanning. + +1280. [bug] libbind: escape '(' and ')' when converting to + presentation form. + +1279. [port] Darwin uses (unsigned long) for size_t. [RT #2590] + +1276. [bug] libbind: const pointer conflicts in res_debug.c. + +1275. [port] libbind: hpux: treat all hpux systems as BIG_ENDIAN. + +1274. [bug] Memory leak in lwres_gnbarequest_parse(). + +1273. [port] libbind: solaris: 64 bit binary compatibility. + +1272. [contrib] Berkeley DB 4.0 sdb implementation from + Nuno Miguel Rodrigues . + +1270. [bug] Check that system inet_pton() and inet_ntop() support + AF_INET6. + +1269. [port] Openserver: ifconfig.sh support. + +1268. [port] Openserver: the value FD_SETSIZE depends on whether + is included or not. Be consistent. + +1266. [bug] ISC_LINK_INIT, ISC_LINK_UNLINK, ISC_LIST_DEQUEUE, + __ISC_LINK_UNLINKUNSAFE and __ISC_LIST_DEQUEUEUNSAFE + are not C++ compatible, use *_TYPE versions instead. + +1265. [bug] libbind: LINK_INIT and UNLINK were not compatible with + C++, use LINK_INIT_TYPE and UNLINK_TYPE instead. + +1263. [bug] Reference after free error if dns_dispatchmgr_create() + failed. + +1262. [bug] ns_server_destroy() failed to set *serverp to NULL. + +1261. [func] libbind: ns_sign2() and ns_sign_tcp() now provide + support for compressed TSIG owner names. + +1260. [func] libbind: res_update can now update IPv6 servers, + new function res_findzonecut2(). + +1259. [bug] libbind: get_salen() IPv6 support was broken for OSs + w/o sa_len. + +1258. [bug] libbind: res_nametotype() and res_nametoclass() were + broken. + +1257. [bug] Failure to write pid-file should not be fatal on + reload. [RT #2861] + +1256. [contrib] 'queryperf' now has EDNS (-e) + DNSSEC DO (-D) support. + +1255. [bug] When verifying that an NXT proves nonexistence, check + the rcode of the message and only do the matching NXT + check. That is, for NXDOMAIN responses, check that + the name is in the range between the NXT owner and + next name, and for NOERROR NODATA responses, check + that the type is not present in the NXT bitmap. + +1253. [bug] The dnssec system test failed to remove the correct + files. + +1252. [bug] Dig, host and nslookup were not checking the address + the answer was coming from against the address it was + sent to. [RT# 2692] + +1248. [bug] DESTDIR was not being propagated between makes. + +1245. [bug] Treat ENOBUFS, ENOMEM and ENFILE as soft errors for + accept(). + +1242. [bug] named-checkzone failed if a journal existed. [RT #2657] + +1241. [bug] Drop received UDP messages with a zero source port + as these are invariably forged. [RT #2621] + +1209. [bug] Dig, host, nslookup were not checking the message ids + on the responses. [RT #2454] + +1097. [func] libbind: RES_PRF_TRUNC for dig. + +1096. [func] libbind: "DNSSEC OK" (DO) support. + +1095. [func] libbind: resolver option: no-tld-query. disables + trying unqualified as a tld. no_tld_query is also + supported for FreeBSD compatibility. + +1094. [func] libbind: add support gcc's format string checking. + +1089. [func] libbind: inet_{cidr,net}_{pton,ntop}() now have IPv6 + support. + + --- 9.2.1 released --- + +1251. [port] win32: a make file contained absolute version specific + references. + +1249. [bug] Missing masters clause was not handled gracefully. + [RT #2703] + +1244. [bug] Receiving a TCP message from a blackhole address would + prevent further messages being received over that + interface. + +1178. [bug] Follow and cache (if appropriate) A6 and other + data chains to completion in the additional section. + + --- 9.2.1rc2 released --- + +1240. [bug] It was possible to leak zone references by + specifying an incorrect zone to rndc. + +1239. [bug] Under certain circumstances named could continue to + use a name after it had been freed triggering + INSIST() failures. [RT #2614] + +1238. [bug] It is possible to lockup the server when shutting down + if notifies were being processed. [RT #2591] + +1237. [bug] nslookup: "set q=type" failed. + +1236. [bug] dns_rdata{class,type}_fromtext() didn't handle non + NULL terminated text regions. [RT #2588] + +1232. [bug] unix/errno2result() didn't handle EADDRNOTAVAIL. + +1231. [port] HPUX 11.11 recvmsg() can return spurious EADDRNOTAVAIL. + +1230. [bug] isccc_cc_isreply() and isccc_cc_isack() were broken. + +1229. [bug] named would crash if it received a TSIG signed + query as part of an AXFR response. [RT #2570] + +1228. [bug] 'make install' did not depend on 'make all'. [RT #2559] + +1227. [bug] dns_lex_getmastertoken() now returns ISC_R_BADNUMBER + if a number was expected and some other token was + found. [RT#2532] + +1222. [bug] Specifying 'port *' did not always result in a system + selected (non-reserved) port being used. [RT #2537] + +1221. [bug] Zone types 'master', 'slave' and 'stub' were not being + compared case insensitively. [RT #2542] + +1218. [bug] Named incorrectly returned SERVFAIL rather than + NOTAUTH when there was a TSIG BADTIME error. [RT #2519] + +1216. [bug] Multiple server clauses for the same server were not + reported. [RT #2514] + +1215. [port] solaris: add support to ifconfig.sh for x86 2.5.1 + +1214. [bug] Win32: isc_file_renameunique() could leave zero length + files behind. + +1212. [port] libbind: 64k answer buffers were causing stack space + to be exceeded for certain OS. Use heap space instead. + +1211. [bug] dns_name_fromtext() incorrectly handled certain + valid octal bitlabels. [RT #2483] + +1210. [bug] libbind: getnameinfo() failed to lookup IPv4 mapped / + compatible addresses. [RT #2461] + +1208. [bug] dns_master_load*() failed to log a error message if + an error was detected when parsing the ownername of + a record. [RT #2448] + + --- 9.2.1rc1 released --- + +1207. [bug] libbind: getaddrinfo() could call freeaddrinfo() with + an invalid pointer. + +1206. [bug] SERVFAIL and NOTIMP responses to an EDNS query should + trigger a non-EDNS retry. + +1205. [bug] OPT, TSIG and TKEY cannot be used to set the "class" + of the message. [RT #2449] + +1204. [bug] libbind: res_nupdate() failed to update the name + server addresses before sending the update. + +1201. [bug] Require that if 'callbacks' is passed to + dns_rdata_fromtext(), callbacks->error and + callbacks->warn are initialized. + +1200. [bug] Log 'errno' that we are unable to convert to + isc_result_t. [RT #2404] + +1198. [bug] OPT printing style was not consistent with the way the + header fields are printed. The DO bit was not reported + if set. Report if any of the MBZ bits are set. + +1197. [bug] Attempts to define the same acl multiple times were not + detected. + +1196. [contrib] update mdnkit to 2.2.3. + +1195. [bug] Attempts to redefine builtin acls should be caught. + [RT #2403] + +1194. [bug] Not all duplicate zone definitions were being detected + at the named.conf checking stage. [RT #2431] + +1193. [bug] Best effort parsing didn't handle packet truncation. + +1191. [bug] A dynamic update removing the last non-apex name in + a secure zone would fail. [RT #2399] + +1189. [bug] On some systems, malloc(0) returns NULL, which + could cause the caller to report an out of memory + error. [RT #2398] + +1188. [bug] Dynamic updates of a signed zone would fail if + some of the zone private keys were unavailable. + +1186. [bug] isc_hex_tobuffer(,,length = 0) failed to unget the + EOL token when reading to end of line. + +1185. [bug] libbind: don't assume statp->_u._ext.ext is valid + unless RES_INIT is set when calling res_*init(). + +1184. [bug] libbind: call res_ndestroy() if RES_INIT is set + when res_*init() is called. + +1183. [bug] Handle ENOSR error when writing to the internal + control pipe. [RT #2395] + +1182. [bug] The server could throw an assertion failure when + constructing a negative response packet. + +1176. [doc] Document that allow-v6-synthesis is only performed + for clients that are supplied recursive service. + [RT #2260] + +1175. [bug] named-checkzone failed to call dns_result_register() + at startup which could result in runtime + exceptions when printing "out of memory" errors. + [RT #2335] + +1174. [bug] Win32: add WSAECONNRESET to the expected errors + from connect(). [RT #2308] + +1173. [bug] Potential memory leaks in isc_log_create() and + isc_log_settag(). [RT #2336] + +1172. [doc] Add CERT, GPOS, KX, NAPTR, NSAP, PX and TXT to + table of RR types in ARM. + +1170. [bug] Don't attempt to print the token when a I/O error + occurs when parsing named.conf. [RT #2275] + +1168. [bug] Empty also-notify clauses were not handled. [RT #2309] + +1167. [contrib] nslint-2.1a3 (from author). + +1166. [bug] "Not Implemented" should be reported as NOTIMP, + not NOTIMPL. [RT #2281] + +1165. [bug] We were rejecting notify-source{-v6} in zone clauses. + +1164. [bug] Empty masters clauses in slave / stub zones were not + handled gracefully. [RT #2262] + +1162. [bug] The allow-notify option was not accepted in slave + zone statements. + +1161. [bug] named-checkzone looped on unbalanced brackets. + [RT #2248] + +1160. [bug] Generating Diffie-Hellman keys longer than 1024 + bits could fail. [RT #2241] + +1156. [port] The configure test for strsep() incorrectly + succeeded on certain patched versions of + AIX 4.3.3. [RT #2190] + +1154. [bug] Don't attempt to obtain the netmask of a interface + if there is no address configured. [RT #2176] + +1152. [bug] libbind: read buffer overflows. + +1144. [bug] rndc-confgen would crash if both the -a and -t + options were specified. [RT #2159] + +1142. [bug] dnssec-signzone would fail to delete temporary files + in some failure cases. [RT #2144] + +1141. [bug] When named rejected a control message, it would + leak a file descriptor and memory. It would also + fail to respond, causing rndc to hang. + [RT #2139, #2164] + +1140. [bug] rndc-confgen did not accept IPv6 addresses as arguments + to the -s option. [RT #2138] + +1136. [bug] CNAME records synthesized from DNAMEs did not + have a TTL of zero as required by RFC2672. + [RT #2129] + +1125. [bug] rndc: -k option was missing from usage message. + [RT #2057] + +1124. [doc] dig: +[no]dnssec, +[no]besteffort and +[no]fail + are now documented. [RT #2052] + +1123. [bug] dig +[no]fail did not match description. [RT #2052] + +1109. [bug] nsupdate accepted illegal ttl values. + +1108. [bug] On Win32, rndc was hanging when named was not running + due to failure to select for exceptional conditions + in select(). [RT #1870] + +1081. [bug] Multicast queries were incorrectly identified + based on the source address, not the destination + address. + +1072. [bug] The TCP client quota could be exceeded when + recursion occurred. [RT #1937] + +1071. [bug] Sockets listening for TCP DNS connections + specified an excessive listen backlog. [RT #1937] + +1070. [bug] Copy DNSSEC OK (DO) to response as specified by + draft-ietf-dnsext-dnssec-okbit-03.txt. + +1014. [bug] Some queries would cause statistics counters to + increment more than once or not at all. [RT #1321] + +1012. [bug] The -p option to named did not behave as documented. + + 988. [bug] 'additional-from-auth no;' did not work reliably + in the case of queries answered from the cache. + [RT #1436] + + 995. [bug] dig, host, nslookup: using a raw IPv6 address as a + target address should be fatal on a IPv4 only system. + + --- 9.2.0 released --- + +1134. [bug] Multi-threaded servers could deadlock in ferror() + when reloading zone files. [RT #1951, #1998] + +1133. [bug] IN6_IS_ADDR_LOOPBACK was not portably defined on + platforms without IN6_IS_ADDR_LOOPBACK. [RT #2106] + + --- 9.2.0rc10 released --- + +1131. [bug] The match-destinations view option did not work with + IPv6 destinations. [RT #2073, #2074] + +1130. [bug] Log messages reporting an out-of-range serial number + did not include the out-of-range number but the + following token. [RT #2076] + +1129. [bug] Multi-threaded servers could crash under heavy + resolution load due to a race condition. [RT #2018] + +1126. [bug] The server could access a freed event if shut + down while a client start event was pending + delivery. [RT #2061] + +1121. [bug] The server could attempt to access a NULL zone + table if shut down while resolving. + [RT #1587, #2054] + +1120. [bug] Errors in options were not fatal. [RT #2002] + +1118. [bug] On multi-threaded servers, a race condition + could cause an assertion failure in resolver.c + during resolver shutdown. [RT #2029] + +1117. [port] The configure check for in6addr_loopback incorrectly + succeeded on AIX 4.3 when compiling with -O2 + because the test code was optimized away. + [RT #2016] + +1116. [bug] Setting transfers in a server clause, transfers-in, + or transfers-per-ns to a value greater than + 2147483647 disabled transfers. [RT #2002] + +1114. [port] Ignore more accept() errors. [RT #2021] + +1113. [bug] The allow-update-forwarding option was ignored + when specified in a view. [RT #2014] + +1111. [bug] Multi-threaded servers could deadlock processing + recursive queries due to a locking hierarchy + violation in adb.c. [RT #2017] + + --- 9.2.0rc9 released --- + +1107. [bug] nsupdate could catch an assertion failure if an + invalid domain name was given as the argument to + the "zone" command. + +1106. [bug] After seeing an out of range TTL, nsupdate would + treat all TTLs as out of range. [RT #2001] + +1104. [bug] Invalid arguments to the transfer-format option + could cause an assertion failure. [RT #1995] + +1103. [port] OpenUNIX 8 support (ifconfig.sh). [RT #1970] + +1102. [doc] Note that query logging is enabled by directing the + queries category to a channel. + +1101. [bug] Array bounds read error in lwres_gai_strerror. + +1100. [bug] libbind: DNSSEC key ids were computed incorrectly. + +1099. [cleanup] libbind: defining REPORT_ERRORS in lib/bind/dst caused + compile time errors. + +1098. [bug] libbind: HMAC-MD5 key files are now mode 0600. + +1093. [doc] libbind: miscellaneous nroff fixes. + +1092. [bug] libbind: get*by*() failed to check if res_init() had + been called. + +1091. [bug] libbind: misplaced va_end(). + +1090. [bug] libbind: dns_ho.c:add_hostent() was not returning + the amount of memory consumed resulting in garbage + address being returned. Alignment calculations were + wasting space. We weren't suppressing duplicate + addresses. + +1088. [port] libbind: MPE/iX C.70 (incomplete) + +1087. [bug] libbind: struct __res_state too large on 64 bit arch. + +1086. [port] libbind: sunos: old sprintf. + +1085. [port] libbind: solaris: sys_nerr and sys_errlist do not + exist when compiling in 64 bit mode. + +1084. [cleanup] libbind: gai_strerror() rewritten. + +1083. [bug] The default control channel listened on the + wildcard address, not the loopback as documented. + [RT #1975] + +1082. [bug] The -g option to named incorrectly caused logging + to be sent to syslog in addition to stderr. + [RT #1974] + +1078. [bug] We failed to correct bad tv_usec values in one case. + [RT #1966] + +1076. [bug] A badly defined global key could trigger an assertion + on load/reload if views were used. [RT #1947] + +1075. [bug] Out-of-range network prefix lengths were not + reported. [RT #1954] + +1074. [bug] Running out of memory in dump_rdataset() could + cause an assertion failure. [RT #1946] + + --- 9.2.0rc8 released --- + +1068. [bug] errno could be overwritten by catgets(). [RT #1921] + +1066. [bug] Provide a thread safe wrapper for strerror(). + [RT #1689] + +1064. [bug] Do not shut down active network interfaces if we + are unable to scan the interface list. [RT #1921] + +1063. [bug] libbind: "make install" was failing on IRIX. + [RT #1919] + +1062. [bug] If the control channel listener socket was shut + down before server exit, the listener object could + be freed twice. [RT #1916] + +1061. [bug] If periodic cache cleaning happened to start + while cleaning due to reaching the configured + maximum cache size was in progress, the server + could catch an assertion failure. [RT #1912] + +1057. [bug] Reloading the server after adding a "file" clause + to a zone statement could cause the server to + crash due to a typo in change 1016. + +1056. [bug] Rndc could catch an assertion failure on SIGINT due + to an uninitialized variable. [RT #1908] + + --- 9.2.0rc7 released --- + +1054. [bug] On Win32, cfg_categories and cfg_modules need to be + exported from the libisccfg DLL. + +1053. [bug] Dig did not increase its timeout when receiving + AXFRs unless the +time option was used. [RT #1904] + +1052. [bug] Journals were not being created in binary mode + resulting in "journal format not recognized" error + under Win32. [RT #1889] + +1051. [bug] Do not ignore a network interface completely just + because it has a noncontiguous netmask. Instead, + omit it from the localnets ACL and issue a warning. + [RT #1891] + +1050. [bug] Log messages reporting malformed IP addresses in + address lists such as that of the forwarders option + failed to include the correct error code, file + name, and line number. [RT #1890] + +1048. [bug] Servers built with -DISC_MEM_USE_INTERNAL_MALLOC=1 + didn't work. + +1047. [bug] named was incorrectly refusing all requests signed + with a TSIG key derived from an unsigned TKEY + negotiation with a NOERROR response. [RT #1886] + +1046. [bug] The help message for the --with-openssl configure + option was inaccurate. [RT #1880] + +1045. [bug] It was possible to skip saving glue for a nameserver + for a stub zone. + +1044. [bug] Specifying allow-transfer, notify-source, or + notify-source-v6 in a stub zone was not treated + as an error. + +1043. [bug] Specifying a transfer-source or transfer-source-v6 + option in the zone statement for a master zone was + not treated as an error. [RT #1876] + +1042. [bug] The "config" logging category did not work properly. + [RT #1873] + +1041. [bug] Dig/host/nslookup could catch an assertion failure + on SIGINT due to an uninitialized variable. [RT #1867] + +1040. [bug] Multiple listen-on-v6 options with different ports + were not accepted. [RT #1875] + +1039. [bug] Negative responses with CNAMEs in the answer section + were cached incorrectly. [RT #1862] + +1038. [bug] In servers configured with a tkey-domain option, + TKEY queries with an owner name other than the root + could cause an assertion failure. [RT #1866, #1869] + +1033. [bug] Always respond to requests with an unsupported opcode + with NOTIMP, even if we don't have a matching view + or cannot determine the class. + + --- 9.2.0rc6 released --- + +1031. [bug] libbind.a: isc__gettimeofday() infinite recursion. + [RT #1858] + +1030. [bug] On systems with no resolv.conf file, nsupdate + exited with an error rather than defaulting + to using the loopback address. [RT #1836] + +1029. [bug] Some named.conf errors did not cause the loading + of the configuration file to return a failure + status even though they were logged. [RT #1847] + +1028. [bug] On Win32, dig/host/nslookup looked for resolv.conf + in the wrong directory. [RT #1833] + +1027. [bug] RRs having the reserved type 0 should be rejected. + [RT #1471] + +1026. [port] Recognize OpenUNIX 8 in config.guess. [RT #1830] + +1022. [bug] Don't report empty root hints as "extra data". + [RT #1802] + + --- 9.2.0rc5 released --- + +1021. [bug] On Win32, log message timestamps were one month + later than they should have been, and the server + would exhibit unspecified behavior in December. + +1020. [bug] IXFR log messages did not distinguish between + true IXFRs, AXFR-style IXFRs, and mere version + polls. [RT #1811] + +1019. [bug] The value of the lame-ttl option was limited to 18000 + seconds, not 1800 seconds as documented. [RT #1803] + +1018. [bug] The default log channel was not always initialized + correctly. [RT #1813] + +1017. [bug] When specifying TSIG keys to dig and nsupdate using + the -k option, they must be HMAC-MD5 keys. [RT #1810] + +1016. [bug] Slave zones with no backup file were re-transferred + on every server reload. + +1015. [bug] Log channels that had a "versions" option but no + "size" option failed to create numbered log + files. [RT #1783] + + --- 9.2.0rc4 released --- + +1013. [bug] It was possible to cancel a query twice when marking + a server as bogus or by having a blackhole acl. + [RT #1776] + +1010. [bug] The server could attempt to execute a command channel + command after initiating server shutdown, causing + an assertion failure. [RT #1766] + +1006. [bug] If a KEY RR was found missing during DNSSEC validation, + an assertion failure could subsequently be triggered + in the resolver. [RT #1763] + +1005. [bug] Don't copy nonzero RCODEs from request to response. + [RT #1765] + +1004. [port] Deal with recvfrom() returning EHOSTDOWN. [RT #1770] + +1002. [bug] When reporting an unknown class name in named.conf, + including the file name and line number. [RT #1759] + +1001. [bug] win32 socket code doio_recv was not catching a + WSACONNRESET error when a client was timing out + the request and closing its socket. [RT #1745] + +1000. [bug] BIND 8 compatibility: accept "HESIOD" as an alias + for class "HS". [RT #1759] + + --- 9.2.0rc3 released --- + + 990. [bug] The rndc-confgen man page was not installed. + + 989. [bug] Report filename if $INCLUDE fails for file related + errors. [RT #1736] + + 987. [bug] "dig -help" didn't show "+[no]stats". + + 986. [bug] "dig +noall" failed to clear stats and command + printing. + + 984. [bug] Multi-threading should be enabled by default on + Solaris 2.7 and newer, but it wasn't. + + --- 9.2.0rc2 released --- + + 980. [bug] Incoming zone transfers restarting after an error + could trigger an assertion failure. [RT #1692] + + 978. [bug] dns_db_attachversion() had an invalid REQUIRE() + condition. + + 977. [bug] Improve "not at top of zone" error message. + + 975. [bug] "max-cache-size default;" as a view option + caused an assertion failure. + + 974. [bug] "max-cache-size unlimited;" as a global option + was not accepted. + + 973. [bug] Failed to log the question name when logging: + "bad zone transfer request: non-authoritative zone + (NOTAUTH)". + + 972. [bug] The file modification time code in zone.c was using the + wrong epoch. [RT #1667] + + 968. [bug] On win32, the isc_time_now() function was unnecessarily + calling strtime(). [RT #1671] + + 967. [bug] On win32, the link for bindevt was not including the + required resource file to enable the event viewer + to interpret the error messages in the event log, + [RT #1668] + + 966. [placeholder] + + 965. [bug] Including data other than root server NS and A + records in the root hint file could cause a rbtdb + node reference leak. [RT #1581, #1618] + + 964. [func] Warn if data other than root server NS and A records + are found in the root hint file. [RT #1581, #1618] + + 963. [bug] Bad ISC_LANG_ENDDECLS. [RT #1645] + + 962. [bug] libbind: bad "#undef", don't attempt to install + non-existant nlist.h. [RT #1640] + + 961. [bug] Tried to use a IPV6 feature when ISC_PLATFORM_HAVEIPV6 + was not defined. [RT #1482] + + 960. [port] liblwres failed to build on systems with support for + getrrsetbyname() in the OS. [RT #1592] + + 959. [port] On FreeBSD, determine the number of CPUs by calling + sysctlbyname(). [RT #1584] + + 958. [port] ssize_t is not available on all platforms. [RT #1607] + + 957. [bug] sys/select.h inclusion was broken on older platforms. + [RT #1607] + + 956. [bug] ns_g_autorndcfile changed to ns_g_keyfile + in named/win32/os.c due to code changes in + change #953. win32 .make file for rndc-confgen + updated to add include path for os.h header. + + --- 9.2.0rc1 released --- + + 955. [bug] When using views, the zone's class was not being + inherited from the view's class. [RT #1583] + + 954. [bug] When requesting AXFRs or IXFRs using dig, host, or + nslookup, the RD bit should not be set as zone + transfers are inherently nonrecursive. [RT #1575] + + 953. [func] The /var/run/named.key file from change #843 + has been replaced by /etc/rndc.key. Both + named and rndc will look for this file and use + it to configure a default control channel key + if not already configured using a different + method (rndc.conf / controls). Unlike + named.key, rndc.key is not created automatically; + it must be created by manually running + "rndc-confgen -a". + + 952. [bug] The server required manual intervention to serve the + affected zones if it died between creating a journal + and committing the first change to it. + + 951. [bug] CFLAGS was not passed to the linker when + linking some of the test programs under + bin/tests. [RT #1555]. + + 950. [bug] Explicit TTLs did not properly override $TTL + due to a bug in change 834. [RT #1558] + + 949. [bug] host was unable to print records larger than 512 + bytes. [RT #1557] + + --- 9.2.0b2 released --- + + 948. [port] Integrated support for building on Windows NT / + Windows 2000. + + 947. [bug] dns_rdata_soa_t had a badly named element "mname" which + was really the RNAME field from RFC1035. To avoid + confusion and silent errors that would occur it the + "origin" and "mname" elements were given their correct + names "mname" and "rname" respectively, the "mname" + element is renamed to "contact". + + 946. [cleanup] doc/misc/options is now machine-generated from the + configuration parser syntax tables, and therefore + more likely to be correct. + + 945. [func] Add the new view-specific options + "match-destinations" and "match-recursive-only". + + 944. [func] Check for expired signatures on load. + + 943. [bug] The server could crash when receiving a command + via rndc if the configuration file listed only + nonexistent keys in the controls statement. [RT #1530] + + 942. [port] libbind: GETNETBYADDR_ADDR_T was not correctly + defined on some platforms. + + 941. [bug] The configuration checker crashed if a slave + zone didn't contain a masters statement. [RT #1514] + + 940. [bug] Double zone locking failure on error path. [RT #1510] + + --- 9.2.0b1 released --- + + 939. [port] Add the --disable-linux-caps option to configure for + systems that manage capabilities outside of named. + [RT #1503] + + 938. [placeholder] + + 937. [bug] A race when shutting down a zone could trigger a + INSIST() failure. [RT #1034] + + 936. [func] Warn about IPv4 addresses that are not complete + dotted quads. [RT #1084] + + 935. [bug] inet_pton failed to reject leading zeros. + + 934. [port] Deal with systems where accept() spuriously returns + ECONNRESET. + + 933. [bug] configure failed doing libbind on platforms not + supported by BIND 8. [RT #1496] + + --- 9.2.0a3 released --- + + 932. [bug] Use INSTALL_SCRIPT, not INSTALL_PROGRAM, + when installing isc-config.sh. + [RT #198, #1466] + + 931. [bug] The controls statement only attempted to verify + messages using the first key in the key list. + (9.2.0a1/a2 only). + + 930. [func] Query performance testing tool added as + contrib/queryperf. + + 929. [placeholder] + + 928. [bug] nsupdate would send empty update packets if the + send (or empty line) command was run after + another send but before any new updates or + prerequisites were specified. It should simply + ignore this command. + + 927. [bug] Don't hold the zone lock for the entire dump to disk. + [RT #1423] + + 926. [bug] The resolver could deadlock with the ADB when + shutting down (multi-threaded builds only). + [RT #1324] + + 925. [cleanup] Remove openssl from the distribution; require that + --with-openssl be specified if DNSSEC is needed. + + 924. [port] Extend support for pre-RFC2133 IPv6 implementation. + [RT #987] + + 923. [bug] Multiline TSIG secrets (and other multiline strings) + were not accepted in named.conf. [RT #1469] + + 922. [func] Added two new lwres_getrrsetbyname() result codes, + ERR_NONAME and ERR_NODATA. + + 921. [bug] lwres returned an incorrect error code if it received + a truncated message. + + 920. [func] Increase the lwres receive buffer size to 16K. + [RT #1451] + + 919. [placeholder] + + 918. [func] In nsupdate, TSIG errors are no longer treated as + fatal errors. + + 917. [func] New nsupdate command 'key', allowing TSIG keys to + be specified in the nsupdate command stream rather + than the command line. + + 916. [bug] Specifying type ixfr to dig without specifying + a serial number failed in unexpected ways. + + 915. [func] The named-checkconf and named-checkzone programs + now have a '-v' option for printing their version. + [RT #1151] + + 914. [bug] Global 'server' statements were rejected when + using views, even though they were accepted + in 9.1. [RT #1368] + + 913. [bug] Cache cleaning was not sufficiently aggressive. + [RT #1441, #1444] + + 912. [bug] Attempts to set the 'additional-from-cache' or + 'additional-from-auth' option to 'no' in a + server with recursion enabled will now + be ignored and cause a warning message. + [RT #1145] + + 911. [placeholder] + + 910. [port] Some pre-RFC2133 IPv6 implementations do not define + IN6ADDR_ANY_INIT. [RT #1416] + + 908. [func] New program, rndc-confgen, to simplify setting up rndc. + + 907. [func] The ability to get entropy from either the + random device, a user-provided file or from + the keyboard was migrated from the DNSSEC tools + to libisc as isc_entropy_usebestsource(). + + 906. [port] Separated the system independent portion of + lib/isc/unix/entropy.c into lib/isc/entropy.c + and added lib/isc/win32/entropy.c. + + 905. [bug] Configuring a forward "zone" for the root domain + did not work. [RT #1418] + + 904. [bug] The server would leak memory if attempting to use + an expired TSIG key. [RT #1406] + + 903. [bug] dig should not crash when receiving a TCP packet + of length 0. + + 902. [bug] The -d option was ignored if both -t and -g were also + specified. + + 901. [placeholder] + + 900. [bug] A config.guess update changed the system identification + string of FreeBSD systems; configure and + bin/tests/system/ifconfig.sh now recognize the new + string. + + --- 9.2.0a2 released --- + + 899. [bug] lib/dns/soa.c failed to compile on many platforms + due to inappropriate use of a void value. + [RT #1372, #1373, #1386, #1387, #1395] + + 898. [bug] "dig" failed to set a nonzero exit status + on UDP query timeout. [RT #1323] + + 897. [bug] A config.guess update changed the system identification + string of UnixWare systems; configure now recognizes + the new string. + + 896. [bug] If a configuration file is set on named's command line + and it has a relative pathname, the current directory + (after any possible jailing resulting from named -t) + will be prepended to it so that reloading works + properly even when a directory option is present. + + 895. [func] New function, isc_dir_current(), akin to POSIX's + getcwd(). + + 894. [bug] When using the DNSSEC tools, a message intended to warn + when the keyboard was being used because of the lack + of a suitable random device was not being printed. + + 893. [func] Removed isc_file_test() and added isc_file_exists() + for the basic functionality that was being added + with isc_file_test(). + + 892. [placeholder] + + 891. [bug] Return an error when a SIG(0) signed response to + an unsigned query is seen. This should actually + do the verification, but it's not currently + possible. [RT #1391] + + 890. [cleanup] The man pages no longer require the mandoc macros + and should now format cleanly using most versions of + nroff, and HTML versions of the man pages have been + added. Both are generated from DocBook source. + + 889. [port] Eliminated blank lines before .TH in nroff man + pages since they cause problems with some versions + of nroff. [RT #1390] + + 888. [bug] Don't die when using TKEY to delete a nonexistent + TSIG key. [RT #1392] + + 887. [port] Detect broken compilers that can't call static + functions from inline functions. [RT #1212] + + 866. [func] Close debug only file channels when debug is set to + zero. [RT #1246] + + 865. [bug] The new configuration parser did not allow + the optional debug level in a "severity debug" + clause of a logging channel to be omitted. + This is now allowed and treated as "severity + debug 1;" like it does in BIND 8.2.4, not as + "severity debug 0;" like it did in BIND 9.1. + [RT #1367] + + 864. [cleanup] Multi-threading is now enabled by default on + OSF1, Solaris 2.7 and newer, AIX, IRIX, and HP-UX. + + 863. [bug] If an error occurred while an outgoing zone transfer + was starting up, the server could access a domain + name that had already been freed when logging a + message saying that the transfer was starting. + [RT #1383] + + 862. [bug] Use after realloc(), non portable pointer arithmetic in + grmerge(). + + 861. [port] Add support for Mac OS X, by making it equivalent + to Darwin. This was derived from the config.guess + file shipped with Mac OS X. [RT #1355] + + 860. [func] Drop cross class glue in zone transfers. + + 859. [bug] Cache cleaning now won't swamp the CPU if there + is a persistent overlimit condition. + + 858. [func] isc_mem_setwater() no longer requires that when the + callback function is non-NULL then its hi_water + argument must be greater than its lo_water argument + (they can now be equal) or that they be non-zero. + + 857. [cleanup] Use ISC_MAGIC() to define all magic numbers for + structs, for our friends in EBCDIC-land. + + 856. [func] Allow partial rdatasets to be returned in answer and + authority sections to help non-TCP capable clients + recover from truncation. [RT #1301] + + 855. [bug] Stop spurious "using RFC 1035 TTL semantics" warnings. + + 854. [bug] The config parser didn't properly handle config + options that were specified in units of time other + than seconds. [RT #1372] + + 853. [bug] configure_view_acl() failed to detach existing acls. + [RT #1374] + + 852. [bug] Handle responses from servers which do not know + about IXFR. + + 851. [cleanup] The obsolete support-ixfr option was not properly + ignored. + + --- 9.2.0a1 released --- + + 850. [bug] dns_rbt_findnode() would not find nodes that were + split on a bitstring label somewhere other than in + the last label of the node. [RT #1351] + + 849. [func] will ensure INADDR_LOOPBACK is defined. + + 848. [func] A minimum max-cache-size of two megabytes is enforced + by the cache cleaner. + + 847. [func] Added isc_file_test(), which currently only has + some very basic functionality to test for the + existence of a file, whether a pathname is absolute, + or whether a pathname is the fundamental representation + of the current directory. It is intended that this + function can be expanded to test other things a + programmer might want to know about a file. + + 846. [func] A non-zero 'param' to dst_key_generate() when making an + hmac-md5 key means that good entropy is not required. + + 845. [bug] The access rights on the public file of a symmetric + key are now restricted as soon as the file is opened, + rather than after it has been written and closed. + + 844. [func] will ensure INADDR_LOOPBACK is defined, + just as does. + + 843. [func] If no controls statement is present in named.conf, + or if any inet phrase of a controls statement is + lacking a keys clause, then a key will be automatically + generated by named and an rndc.conf-style file + named named.key will be written that uses it. rndc + will use this file only if its normal configuration + file, or one provided on the command line, does not + exist. + + 842. [func] 'rndc flush' now takes an optional view. + + 841. [bug] When sdb modules were not declared threadsafe, their + create and destroy functions were not serialized. + + 840. [bug] The config file parser could print the wrong file + name if an error was detected after an included file + was parsed. [RT #1353] + + 839. [func] Dump packets for which there was no view or that the + class could not be determined to category "unmatched". + + 838. [port] UnixWare 7.x.x is now suported by + bin/tests/system/ifconfig.sh. + + 837. [cleanup] Multi-threading is now enabled by default only on + OSF1, Solaris 2.7 and newer, and AIX. + + 836. [func] Upgraded libtool to 1.4. + + 835. [bug] The dispatcher could enter a busy loop if + it got an I/O error receiving on a UDP socket. + [RT #1293] + + 834. [func] Accept (but warn about) master files beginning with + an SOA record without an explicit TTL field and + lacking a $TTL directive, by using the SOA MINTTL + as a default TTL. This is for backwards compatibility + with old versions of BIND 8, which accepted such + files without warning although they are illegal + according to RFC1035. + + 833. [cleanup] Moved dns_soa_*() from to + , and extended them to support + all the integer-valued fields of the SOA RR. + + 832. [bug] The default location for named.conf in named-checkconf + should depend on --sysconfdir like it does in named. + [RT #1258] + + 831. [placeholder] + + 830. [func] Implement 'rndc status'. + + 829. [bug] The DNS_R_ZONECUT result code should only be returned + when an ANY query is made with DNS_DBFIND_GLUEOK set. + In all other ANY query cases, returning the delegation + is better. + + 828. [bug] The errno value from recvfrom() could be overwritten + by logging code. [RT #1293] + + 827. [bug] When an IXFR protocol error occurs, the slave + should retry with AXFR. + + 826. [bug] Some IXFR protocol errors were not detected. + + 825. [bug] zone.c:ns_query() detached from the wrong zone + reference. [RT #1264] + + 824. [bug] Correct line numbers reported by dns_master_load(). + [RT #1263] + + 823. [func] The output of "dig -h" now goes to stdout so that it + can easily be piped through "more". [RT #1254] + + 822. [bug] Sending nxrrset prerequisites would crash nsupdate. + [RT #1248] + + 821. [bug] The program name used when logging to syslog should + be stripped of leading path components. + [RT #1178, #1232] + + 820. [bug] Name server address lookups failed to follow + A6 chains into the glue of local authoritative + zones. + + 819. [bug] In certain cases, the resolver's attempts to + restart an address lookup at the root could cause + the fetch to deadlock (with itself) instead of + restarting. [RT #1225] + + 818. [bug] Certain pathological responses to ANY queries could + cause an assertion failure. [RT #1218] + + 817. [func] Adjust timeouts for dialup zone queries. + + 816. [bug] Report potential problems with log file accessibility + at configuration time, since such problems can't + reliably be reported at the time they actually occur. + + 815. [bug] If a log file was specified with a path separator + character (i.e. "/") in its name and the directory + did not exist, the log file's name was treated as + though it were the directory name. [RT #1189] + + 814. [bug] Socket objects left over from accept() failures + were incorrectly destroyed, causing corruption + of socket manager data structures. + + 813. [bug] File descriptors exceeding FD_SETSIZE were handled + badly. [RT #1192] + + 812. [bug] dig sometimes printed incomplete IXFR responses + due to an uninitialized variable. [RT #1188] + + 811. [bug] Parentheses were not quoted in zone dumps. [RT #1194] + + 810. [bug] The signer name in SIG records was not properly + downcased when signing/verifying records. [RT #1186] + + 809. [bug] Configuring a non-local address as a transfer-source + could cause an assertion failure during load. + + 808. [func] Add 'rndc flush' to flush the server's cache. + + 807. [bug] When setting up TCP connections for incoming zone + transfers, the transfer-source port was not + ignored like it should be. + + 806. [bug] DNS_R_SEENINCLUDE was failing to propagate back up + the calling stack to the zone maintence level, causing + zones to not reload when an included file was touched + but the top-level zone file was not. + + 805. [bug] When using "forward only", missing root hints should + not cause queries to fail. [RT #1143] + + 804. [bug] Attempting to obtain entropy could fail in some + situations. This would be most common on systems + with user-space threads. [RT #1131] + + 803. [bug] Treat all SIG queries as if they have the CD bit set, + otherwise no data will be returned [RT #749] + + 802. [bug] DNSSEC key tags were computed incorrectly in almost + all cases. [RT #1146] + + 801. [bug] nsupdate should treat lines beginning with ';' as + comments. [RT #1139] + + 800. [bug] dnssec-signzone produced incorrect statistics for + large zones. [RT #1133] + + 799. [bug] The ADB didn't find AAAA glue in a zone unless A6 + glue was also present. + + 798. [bug] nsupdate should be able to reject bad input lines + and continue. [RT #1130] + + 797. [func] Issue a warning if the 'directory' option contains + a relative path. [RT #269] + + 796. [func] When a size limit is associated with a log file, + only roll it when the size is reached, not every + time the log file is opened. [RT #1096] + + 795. [func] Add the +multiline option to dig. [RT #1095] + + 794. [func] Implement the "port" and "default-port" statements + in rndc.conf. + + 793. [cleanup] The DNSSEC tools could create filenames that were + illegal or contained shell metacharacters. They + now use a different text encoding of names that + doesn't have these problems. [RT #1101] + + 792. [cleanup] Replace the OMAPI command channel protocol with a + simpler one. + + 791. [bug] The command channel now works over IPv6. + + 790. [bug] Wildcards created using dynamic update or IXFR + could fail to match. [RT #1111] + + 789. [bug] The "localhost" and "localnets" ACLs did not match + when used as the second element of a two-element + sortlist item. + + 788. [func] Add the "match-mapped-addresses" option, which + causes IPv6 v4mapped addresses to be treated as + IPv4 addresses for the purpose of acl matching. + + 787. [bug] The DNSSEC tools failed to downcase domain + names when mapping them into file names. + + 786. [bug] When DNSSEC signing/verifying data, owner names were + not properly downcased. + + 785. [bug] A race condition in the resolver could cause + an assertion failure. [RT #673, #872, #1048] + + 784. [bug] nsupdate and other programs would not quit properly + if some signals were blocked by the caller. [RT #1081] + + 783. [bug] Following CNAMEs could cause an assertion failure + when either using an sdb database or under very + rare conditions. + + 782. [func] Implement the "serial-query-rate" option. + + 781. [func] Avoid error packet loops by dropping duplicate FORMERR + responses. [RT #1006] + + 780. [bug] Error handling code dealing with out of memory or + other rare errors could lead to assertion failures + by calling functions on unitialized names. [RT #1065] + + 779. [func] Added the "minimal-responses" option. + + 778. [bug] When starting cache cleaning, cleaning_timer_action() + returned without first pausing the iterator, which + could cause deadlock. [RT #998] + + 777. [bug] An empty forwarders list in a zone failed to override + global forwarders. [RT #995] + + 776. [func] Improved error reporting in denied messages. [RT #252] + + 775. [placeholder] + + 774. [func] max-cache-size is implemented. + + 773. [func] Added isc_rwlock_trylock() to attempt to lock without + blocking. + + 772. [bug] Owner names could be incorrectly omitted from cache + dumps in the presence of negative caching entries. + [RT #991] + + 771. [cleanup] TSIG errors related to unsynchronized clocks + are logged better. [RT #919] + + 770. [func] Add the "edns yes_or_no" statement to the server + clause. [RT #524] + + 769. [func] Improved error reporting when parsing rdata. [RT #740] + + 768. [bug] The server did not emit an SOA when a CNAME + or DNAME chain ended in NXDOMAIN in an + authoritative zone. + + 767. [placeholder] + + 766. [bug] A few cases in query_find() could leak fname. + This would trigger the mpctx->allocated == 0 + assertion when the server exited. + [RT #739, #776, #798, #812, #818, #821, #845, + #892, #935, #966] + + 765. [func] ACL names are once again case insensitive, like + in BIND 8. [RT #252] + + 764. [func] Configuration files now allow "include" directives + in more places, such as inside the "view" statement. + [RT #377, #728, #860] + + 763. [func] Configuration files no longer have reserved words. + [RT #731, #753] + + 762. [cleanup] The named.conf and rndc.conf file parsers have + been completely rewritten. + + 761. [bug] _REENTRANT was still defined when building with + --disable-threads. + + 760. [contrib] Significant enhancements to the pgsql sdb driver. + + 759. [bug] The resolver didn't turn off "avoid fetches" mode + when restarting, possibly causing resolution + to fail when it should not. This bug only affected + platforms which support both IPv4 and IPv6. [RT #927] + + 758. [bug] The "avoid fetches" code did not treat negative + cache entries correctly, causing fetches that would + be useful to be avoided. This bug only affected + platforms which support both IPv4 and IPv6. [RT #927] + + 757. [func] Log zone transfers. + + 756. [bug] dns_zone_load() could "return" success when no master + file was configured. + + 755. [bug] Fix incorrectly formatted log messages in zone.c. + + 754. [bug] Certain failure conditions sending UDP packets + could cause the server to retry the transmission + indefinitely. [RT #902] + + 753. [bug] dig, host, and nslookup would fail to contact a + remote server if getaddrinfo() returned an IPv6 + address on a system that doesn't support IPv6. + [RT #917] + + 752. [func] Correct bad tv_usec elements returned by + gettimeofday(). + + 751. [func] Log successful zone loads / transfers. [RT #898] + + 750. [bug] A query should not match a DNAME whose trust level + is pending. [RT #916] + + 749. [bug] When a query matched a DNAME in a secure zone, the + server did not return the signature of the DNAME. + [RT #915] + + 748. [doc] List supported RFCs in doc/misc/rfc-compliance. + [RT #781] + + 747. [bug] The code to determine whether an IXFR was possible + did not properly check for a database that could + not have a journal. [RT #865, #908] + + 746. [bug] The sdb didn't clone rdatasets properly, causing + a crash when the server followed delegations. [RT #905] + + 745. [func] Report the owner name of records that fail + semantic checks while loading. + + 744. [bug] When returning DNS_R_CNAME or DNS_R_DNAME as the + result of an ANY or SIG query, the resolver failed + to setup the return event's rdatasets, causing an + assertion failure in the query code. [RT #881] + + 743. [bug] Receiving a large number of certain malformed + answers could cause named to stop responding. + [RT #861] + + 742. [placeholder] + + 741. [port] Support openssl-engine. [RT #709] + + 740. [port] Handle openssl library mismatches slightly better. + + 739. [port] Look for /dev/random in configure, rather than + assuming it will be there for only a predefined + set of OSes. + + 738. [bug] If a non-threadsafe sdb driver supported AXFR and + received an AXFR request, it would deadlock or die + with an assertion failure. [RT #852] + + 737. [port] stdtime.c failed to compile on certain platforms. + + 736. [func] New functions isc_task_{begin,end}exclusive(). + + 735. [doc] Add BIND 4 migration notes. + + 734. [bug] An attempt to re-lock the zone lock could occur if + the server was shutdown during a zone tranfer. + [RT #830] + + 733. [bug] Reference counts of dns_acl_t objects need to be + locked but were not. [RT #801, #821] + + 732. [bug] Glue with 0 TTL could also cause SERVFAIL. [RT #828] + + 731. [bug] Certain zone errors could cause named-checkzone to + fail ungracefully. [RT #819] + + 730. [bug] lwres_getaddrinfo() returns the correct result when + it fails to contact a server. [RT #768] + + 729. [port] pthread_setconcurrency() needs to be called on Solaris. + + 728. [bug] Fix comment processing on master file directives. + [RT# 757] + + 727. [port] Work around OS bug where accept() succeeds but + fails to fill in the peer address of the accepted + connection, by treating it as an error rather than + an assertion failure. [RT #809] + + 726. [func] Implement the "trace" and "notrace" commands in rndc. + + 725. [bug] Installing man pages could fail. + + 724. [func] New libisc functions isc_netaddr_any(), + isc_netaddr_any6(). + + 723. [bug] Referrals whose NS RRs had a 0 TTL caused the resolver + to return DNS_R_SERVFAIL. [RT #783] + + 722. [func] Allow incremental loads to be canceled. + + 721. [cleanup] Load manager and dns_master_loadfilequota() are no + more. + + 720. [bug] Server could enter infinite loop in + dispatch.c:do_cancel(). [RT #733] + + 719. [bug] Rapid reloads could trigger an assertion failure. + [RT #743, #763] + + 718. [cleanup] "internal" is no longer a reserved word in named.conf. + [RT #753, #731] + + 717. [bug] Certain TKEY processing failure modes could + reference an uninitialized variable, causing the + server to crash. [RT #750] + + 716. [bug] The first line of a $INCLUDE master file was lost if + an origin was specified. [RT #744] + + 715. [bug] Resolving some A6 chains could cause an assertion + failure in adb.c. [RT #738] + + 714. [bug] Preserve interval timers across reloads unless changed. + [RT# 729] + + 713. [func] named-checkconf takes '-t directory' similar to named. + [RT #726] + + 712. [bug] Sending a large signed update message caused an + assertion failure. [RT #718] + + 711. [bug] The libisc and liblwres implementations of + inet_ntop contained an off by one error. + + 710. [func] The forwarders statement now takes an optional + port. [RT #418] + + 709. [bug] ANY or SIG queries for data with a TTL of 0 + would return SERVFAIL. [RT #620] + + 708. [bug] When building with --with-openssl, the openssl headers + included with BIND 9 should not be used. [RT #702] + + 707. [func] The "filename" argument to named-checkzone is no + longer optional, to reduce confusion. [RT #612] + + 706. [bug] Zones with an explicit "allow-update { none; };" + were considered dynamic and therefore not reloaded + on SIGHUP or "rndc reload". + + 705. [port] Work out resource limit type for use where rlim_t is + not available. [RT #695] + + 704. [port] RLIMIT_NOFILE is not available on all platforms. + [RT #695] + + 703. [port] sys/select.h is needed on older platforms. [RT #695] + + 702. [func] If the address 0.0.0.0 is seen in resolv.conf, + use 127.0.0.1 instead. [RT #693] + + 701. [func] Root hints are now fully optional. Class IN + views use compiled-in hints by default, as + before. Non-IN views with no root hints now + provide authoritative service but not recursion. + A warning is logged if a view has neither root + hints nor authoritative data for the root. [RT #696] + + 700. [bug] $GENERATE range check was wrong. [RT #688] + + 699. [bug] The lexer mishandled empty quoted strings. [RT #694] + + 698. [bug] Aborting nsupdate with ^C would lead to several + race conditions. + + 697. [bug] nsupdate was not compatible with the undocumented + BIND 8 behavior of ignoring TTLs in "update delete" + commands. [RT #693] + + 696. [bug] lwresd would die with an assertion failure when passed + a zero-length name. [RT #692] + + 695. [bug] If the resolver attempted to query a blackholed or + bogus server, the resolution would fail immediately. + + 694. [bug] $GENERATE did not produce the last entry. + [RT #682, #683] + + 693. [bug] An empty lwres statement in named.conf caused + the server to crash while loading. + + 692. [bug] Deal with systems that have getaddrinfo() but not + gai_strerror(). [RT #679] + + 691. [bug] Configuring per-view forwarders caused an assertion + failure. [RT #675, #734] + + 690. [func] $GENERATE now supports DNAME. [RT #654] + + 689. [doc] man pages are now installed. [RT #210] + + 688. [func] "make tags" now works on systems with the + "Exuberant Ctags" etags. + + 687. [bug] Only say we have IPv6, with sufficent functionality, + if it has actually been tested. [RT #586] + + 686. [bug] dig and nslookup can now be properly aborted during + blocking operations. [RT #568] + + 685. [bug] nslookup should use the search list/domain options + from resolv.conf by default. [RT #405, #630] + + 684. [bug] Memory leak with view forwarders. [RT #656] + + 683. [bug] File descriptor leak in isc_lex_openfile(). + + 682. [bug] nslookup displayed SOA records incorrectly. [RT #665] + + 681. [bug] $GENERATE specifying output format was broken. [RT #653] + + 680. [bug] dns_rdata_fromstruct() mishandled options bigger + than 255 octets. + + 679. [bug] $INCLUDE could leak memory and file descriptors on + reload. [RT #639] + + 678. [bug] "transfer-format one-answer;" could trigger an assertion + failure. [RT #646] + + 677. [bug] dnssec-signzone would occasionally use the wrong ttl + for database operations and fail. [RT #643] + + 676. [bug] Log messages about lame servers to category + 'lame-servers' rather than 'resolver', so as not + to be gratuitously incompatible with BIND 8. + + 675. [bug] TKEY queries could cause the server to leak + memory. + + 674. [func] Allow messages to be TSIG signed / verified using + a offset from the current time. + + 673. [func] The server can now convert RFC1886-style recursive + lookup requests into RFC2874-style lookups, when + enabled using the new option "allow-v6-synthesis". + + 672. [bug] The wrong time was in the "time signed" field when + replying with BADTIME error. + + 671. [bug] The message code was failing to parse a message with + no question section and a TSIG record. [RT #628] + + 670. [bug] The lwres replacements for getaddrinfo and + getipnodebyname didn't properly check for the + existence of the sockaddr sa_len field. + + 669. [bug] dnssec-keygen now makes the public key file + non-world-readable for symmetric keys. [RT #403] + + 668. [func] named-checkzone now reports multiple errors in master + files. + + 667. [bug] On Linux, running named with the -u option and a + non-world-readable configuration file didn't work. + [RT #626] + + 666. [bug] If a request sent by dig is longer than 512 bytes, + use TCP. + + 665. [bug] Signed responses were not sent when the size of the + TSIG + question exceeded the maximum message size. + [RT #628] + + 664. [bug] The t_tasks and t_timers module tests are now skipped + when building without threads, since they require + threads. + + 663. [func] Accept a size_spec, not just an integer, in the + (unimplemented and ignored) max-ixfr-log-size option + for compatibility with recent versions of BIND 8. + [RT #613] + + 662. [bug] dns_rdata_fromtext() failed to log certain errors. + + 661. [bug] Certain UDP IXFR requests caused an assertion failure + (mpctx->allocated == 0). [RT #355, #394, #623] + + 660. [port] Detect multiple CPUs on HP-UX and IRIX. + + 659. [performance] Rewrite the name compression code to be much faster. + + 658. [cleanup] Remove all vestiges of 16 bit global compression. + + 657. [bug] When a listen-on statement in an lwres block does not + specify a port, use 921, not 53. Also update the + listen-on documentation. [RT #616] + + 656. [func] Treat an unescaped newline in a quoted string as + an error. This means that TXT records with missing + close quotes should have meaningful errors printed. + + 655. [bug] Improve error reporting on unexpected eof when loading + zones. [RT #611] + + 654. [bug] Origin was being forgotten in TCP retries in dig. + [RT #574] + + 653. [bug] +defname option in dig was reversed in sense. + [RT #549] + + 652. [bug] zone_saveunique() did not report the new name. + + 651. [func] The AD bit in responses now has the meaning + specified in . + + 650. [bug] SIG(0) records were being generated and verified + incorrectly. [RT #606] + + 649. [bug] It was possible to join to an already running fctx + after it had "cloned" its events, but before it sent + them. In this case, the event of the newly joined + fetch would not contain the answer, and would + trigger the INSIST() in fctx_sendevents(). In + BIND 9.0, this bug did not trigger an INSIST(), but + caused the fetch to fail with a SERVFAIL result. + [RT #588, #597, #605, #607] + + 648. [port] Add support for pre-RFC2133 IPv6 implementations. + + 647. [bug] Resolver queries sent after following multiple + referrals had excessively long retransmission + timeouts due to incorrectly counting the referrals + as "restarts". + + 646. [bug] The UnixWare ISC_PLATFORM_FIXIN6INADDR fix in isc/net.h + didn't _cleanly_ fix the problem it was trying to fix. + + 645. [port] BSD/OS 3.0 needs pthread_init(). [RT #603] + + 644. [bug] #622 needed more work. [RT #562] + + 643. [bug] xfrin error messages made more verbose, added class + of the zone. [RT# 599] + + 642. [bug] Break the exit_check() race in the zone module. + [RT #598] + + --- 9.1.0b2 released --- + + 641. [bug] $GENERATE caused a uninitialized link to be used. + [RT #595] + + 640. [bug] Memory leak in error path could cause + "mpctx->allocated == 0" failure. [RT #584] + + 639. [bug] Reading entropy from the keyboard would sometimes fail. + [RT #591] + + 638. [port] lib/isc/random.c needed to explicitly include time.h + to get a prototype for time() when pthreads was not + being used. [RT #592] + + 637. [port] Use isc_u?int64_t instead of (unsigned) long long in + lib/isc/print.c. Also allow lib/isc/print.c to + be compiled even if the platform does not need it. + [RT #592] + + 636. [port] Shut up MSVC++ about a possible loss of precision + in the ISC__BUFFER_PUTUINT*() macros. [RT #592] + + 635. [bug] Reloading a server with a configured blackhole list + would cause an assertion. [RT #590] + + 634. [bug] A log file will completely stop being written when + it reaches the maximum size in all cases, not just + when versioning is also enabled. [RT #570] + + 633. [port] Cope with rlim_t missing on BSD/OS systems. [RT #575] + + 632. [bug] The index array of the journal file was + corrupted as it was written to disk. + + 631. [port] Build without thread support on systems without + pthreads. + + 630. [bug] Locking failure in zone code. [RT #582] + + 629. [bug] 9.1.0b1 dereferenced a null pointer and crashed + when responding to a UDP IXFR request. + + 628. [bug] If the root hints contained only AAAA addresses, + named would be unable to perform resolution. + + 627. [bug] The EDNS0 blackhole detection code of change 324 + waited for three retransmissions to each server, + which takes much too long when a domain has many + name servers and all of them drop EDNS0 queries. + Now we retry without EDNS0 after three consecutive + timeouts, even if they are all from different + servers. [RT #143] + + 626. [bug] The lightweight resolver daemon no longer crashes + when asked for a SIG rrset. [RT #558] + + 625. [func] Zones now inherit their class from the enclosing view. + + 624. [bug] The zone object could get timer events after it had + been destroyed, causing a server crash. [RT #571] + + 623. [func] Added "named-checkconf" and "named-checkzone" program + for syntax checking named.conf files and zone files, + respectively. + + 622. [bug] A canceled request could be destroyed before + dns_request_destroy() was called. [RT #562] + + 621. [port] Disable IPv6 at runtime if IPv6 sockets are unusable. + This mostly affects Red Hat Linux 7.0, which has + conflicts between libc and the kernel. + + 620. [bug] dns_master_load*inc() now require 'task' and 'load' + to be non-null. Also 'done' will not be called if + dns_master_load*inc() fails immediately. [RT #565] + + 618. [bug] Queries to a signed zone could sometimes cause + an assertion failure. + + 617. [bug] When using dynamic update to add a new RR to an + existing RRset with a different TTL, the journal + entries generated from the update did not include + explicit deletions and re-additions of the existing + RRs to update their TTL to the new value. + + 616. [func] dnssec-signzone -t output now includes performance + statistics. + + 615. [bug] dnssec-signzone did not like child keysets signed + by multiple keys. + + 614. [bug] Checks for uninitialized link fields were prone + to false positives, causing assertion failures. + The checks are now disabled by default and may + be re-enabled by defining ISC_LIST_CHECKINIT. + + 613. [bug] "rndc reload zone" now reloads primary zones. + It previously only updated slave and stub zones, + if an SOA query indicated an out of date serial. + + 612. [cleanup] Shutup a ridiculously noisy HP-UX compiler that + complains relentlessly about how its treatment + of 'const' has changed as well as how casting + sometimes tightens alignment constraints. + + 611. [func] allow-notify can be used to permit processing of + notify messages from hosts other than a slave's + masters. + + 610. [func] rndc dumpdb is now supported. + + 609. [bug] getrrsetbyname() would crash lwresd if the server + found more SIGs than answers. [RT #554] + + 608. [func] dnssec-signzone now adds a comment to the zone + with the time the file was signed. + + 607. [bug] nsupdate would fail if it encountered a CNAME or + DNAME in a response to an SOA query. [RT #515] + + 606. [bug] Compiling with --disable-threads failed due + to isc_thread_self() being incorrectly defined + as an integer rather than a function. + + 605. [func] New function isc_lex_getlasttokentext(). + + 604. [bug] The named.conf parser could print incorrect line + numbers when long comments were present. + + 603. [bug] Make dig handle multiple types or classes on the same + query more correctly. + + 602. [func] Cope automatically with UnixWare's broken + IN6_IS_ADDR_* macros. [RT #539] + + 601. [func] Return a non-zero exit code if an update fails + in nsupdate. + + 600. [bug] Reverse lookups sometimes failed in dig, etc... + + 599. [func] Added four new functions to the libisc log API to + support i18n messages. isc_log_iwrite(), + isc_log_ivwrite(), isc_log_iwrite1() and + isc_log_ivwrite1() were added. + + 598. [bug] An update-policy statement would cause the server + to assert while loading. [RT #536] + + 597. [func] dnssec-signzone is now multi-threaded. + + 596. [bug] DNS_RDATASLAB_FORCE and DNS_RDATASLAB_EXACT are + not mutually exclusive. + + 595. [port] On Linux 2.2, socket() returns EINVAL when it + should return EAFNOSUPPORT. Work around this. + [RT #531] + + 594. [func] sdb drivers are now assumed to not be thread-safe + unless the DNS_SDBFLAG_THREADSAFE flag is supplied. + + 593. [bug] If a secure zone was missing all its NXTs and + a dynamic update was attempted, the server entered + an infinite loop. + + 592. [bug] The sig-validity-interval option now specifies a + number of days, not seconds. This matches the + documentation. [RT #529] + + --- 9.1.0b1 released --- + + 591. [bug] Work around non-reentrancy in openssl by disabling + precomputation in keys. + + 590. [doc] There are now man pages for the lwres library in + doc/man/lwres. + + 589. [bug] The server could deadlock if a zone was updated + while being transferred out. + + 588. [bug] ctx->in_use was not being correctly initialized when + when pushing a file for $INCLUDE. [RT #523] + + 587. [func] A warning is now printed if the "allow-update" + option allows updates based on the source IP + address, to alert users to the fact that this + is insecure and becoming increasingly so as + servers capable of update forwarding are being + deployed. + + 586. [bug] multiple views with the same name were fatal. [RT #516] + + 585. [func] dns_db_addrdataset() and and dns_rdataslab_merge() + now support 'exact' additions in a similar manner to + dns_db_subtractrdataset() and dns_rdataslab_subtract(). + + 584. [func] You can now say 'notify explicit'; to suppress + notification of the servers listed in NS records + and notify only those servers listed in the + 'also-notify' option. + + 583. [func] "rndc querylog" will now toggle logging of + queries, like "ndc querylog" in BIND 8. + + 582. [bug] dns_zone_idetach() failed to lock the zone. + [RT #199, #463] + + 581. [bug] log severity was not being correctly processed. + [RT #485] + + 580. [func] Ignore trailing garbage on incoming DNS packets, + for interoperability with broken server + implementations. [RT #491] + + 579. [bug] nsupdate did not take a filename to read update from. + [RT #492] + + 578. [func] New config option "notify-source", to specify the + source address for notify messages. + + 577. [func] Log illegal RDATA combinations. e.g. multiple + singlton types, cname and other data. + + 576. [doc] isc_log_create() description did not match reality. + + 575. [bug] isc_log_create() was not setting internal state + correctly to reflect the default channels created. + + 574. [bug] TSIG signed queries sent by the resolver would fail to + have their responses validated and would leak memory. + + 573. [bug] The journal files of IXFRed slave zones were + inadvertantly discarded on server reload, causing + "journal out of sync with zone" errors on subsequent + reloads. [RT #482] + + 572. [bug] Quoted strings were not accepted as key names in + address match lists. + + 571. [bug] It was possible to create an rdataset of singleton + type which had more than one rdata. [RT #154] + [RT #279] + + 570. [bug] rbtdb.c allowed zones containing nodes which had + both a CNAME and "other data". [RT #154] + + 569. [func] The DNSSEC AD bit will not be set on queries which + have not requested a DNSSEC response. + + 568. [func] Add sample simple database drivers in contrib/sdb. + + 567. [bug] Setting the zone transfer timeout to zero caused an + assertion failure. [RT #302] + + 566. [func] New public function dns_timer_setidle(). + + 565. [func] Log queries more like BIND 8: query logging is now + done to category "queries", level "info". [RT #169] + + 564. [func] Add sortlist support to lwresd. + + 563. [func] New public functions dns_rdatatype_format() and + dns_rdataclass_format(), for convenient formatting + of rdata type/class mnemonics in log messages. + + 562. [cleanup] Moved lib/dns/*conf.c to bin/named where they belong. + + 561. [func] The 'datasize', 'stacksize', 'coresize' and 'files' + clauses of the options{} statement are now implemented. + + 560. [bug] dns_name_split did not properly the resulting prefix + when a maximal length bitstring label was split which + was preceded by another bitstring label. [RT #429] + + 559. [bug] dns_name_split did not properly create the suffix + when splitting within a maximal length bitstring label. + + 558. [func] New functions, isc_resource_getlimit and + isc_resource_setlimit. + + 557. [func] Symbolic constants for libisc integral types. + + 556. [func] The DNSSEC OK bit in the EDNS extended flags + is now implemented. Responses to queries without + this bit set will not contain any DNSSEC records. + + 555. [bug] A slave server attempting a zone transfer could + crash with an assertion failure on certain + malformed responses from the master. [RT #457] + + 554. [bug] In some cases, not all of the dnssec tools were + properly installed. + + 553. [bug] Incoming zone transfers deferred due to quota + were not started when quota was increased but + only when a transfer in progress finished. [RT #456] + + 552. [bug] We were not correctly detecting the end of all c-style + comments. [RT #455] + + 551. [func] Implemented the 'sortlist' option. + + 550. [func] Support unknown rdata types and classes. + + 549. [bug] "make" did not immediately abort the build when a + subdirectory make failed [RT #450]. + + 548. [func] The lexer now ungets tokens more correctly. + + 546. [func] Option 'lame-ttl' is now implemented. + + 545. [func] Name limit and counting options removed from dig; + they didn't work properly, and cannot be correctly + implemented without significant changes. + + 544. [func] Add statistics option, enable statistics-file option, + add RNDC option "dump-statistics" to write out a + query statistics file. + + 543. [doc] The 'port' option is now documented. + + 542. [func] Add support for update forwarding as required for + full compliance with RFC2136. It is turned off + by default and can be enabled using the + 'allow-update-forwarding' option. + + 541. [func] Add bogus server support. + + 540. [func] Add dialup support. + + 539. [func] Support the blackhole option. + + 538. [bug] fix buffer overruns by 1 in lwres_getnameinfo(). + + 536. [func] Use transfer-source{-v6} when sending refresh queries. + Transfer-source{-v6} now take a optional port + parameter for setting the UDP source port. The port + parameter is ignored for TCP. + + 535. [func] Use transfer-source{-v6} when forwarding update + requests. + + 534. [func] Ancestors have been removed from RBT chains. Ancestor + information can be discerned via node parent pointers. + + 533. [func] Incorporated name hashing into the RBT database to + improve search speed. + + 532. [func] Implement DNS UPDATE pseudo records using + DNS_RDATA_UPDATE flag. + + 531. [func] Rdata really should be initialized before being assigned + to (dns_rdata_fromwire(), dns_rdata_fromtext(), + dns_rdata_clone(), dns_rdata_fromregion()), + check that it is. + + 530. [func] New function dns_rdata_invalidate(). + + 529. [bug] 521 contained a bug which caused zones to always + reload. [RT #410] + + 528. [func] The ISC_LIST_XXXX macros now perform sanity checks + on their arguments. ISC_LIST_XXXXUNSAFE can be use + to skip the checks however use with caution. + + 527. [func] New function dns_rdata_clone(). + + 526. [bug] nsupdate incorrectly refused to add RRs with a TTL + of 0. + + 525. [func] New arguments 'options' for dns_db_subtractrdataset(), + and 'flags' for dns_rdataslab_subtract() allowing you + to request that the RR's must exist prior to deletion. + DNS_R_NOTEXACT is returned if the condition is not met. + + 524. [func] The 'forward' and 'forwarders' statement in + non-forward zones should work now. + + 523. [doc] The source to the Administrator Reference Manual is + now an XML file using the DocBook DTD, and is included + in the distribution. The plain text version of the + ARM is temporarily unavailable while we figure out + how to generate readable plain text from the XML. + + 522. [func] The lightweight resolver daemon can now use + a real configuration file, and its functionality + can be provided by a name server. Also, the -p and -P + options to lwresd have been reversed. + + 521. [bug] Detect master files which contain $INCLUDE and always + reload. [RT #196] + + 520. [bug] Upgraded libtool to 1.3.5, which makes shared + library builds almost work on AIX (and possibly + others). + + 519. [bug] dns_name_split() would improperly split some bitstring + labels, zeroing a few of the least signficant bits in + the prefix part. When such an improperly created + prefix was returned to the RBT database, the bogus + label was dutifully stored, corrupting the tree. + [RT #369] + + 518. [bug] The resolver did not realize that a DNAME which was + "the answer" to the client's query was "the answer", + and such queries would fail. [RT #399] + + 517. [bug] The resolver's DNAME code would trigger an assertion + if there was more than one DNAME in the chain. + [RT #399] + + 516. [bug] Cache lookups which had a NULL node pointer, e.g. + those by dns_view_find(), and which would match a + DNAME, would trigger an INSIST(!search.need_cleanup) + assertion. [RT #399] + + 515. [bug] The ssu table was not being attached / detached + by dns_zone_[sg]etssutable. [RT#397] + + 514. [func] Retry refresh and notify queries if they timeout. + [RT #388] + + 513. [func] New functionality added to rdnc and server to allow + individual zones to be refreshed or reloaded. + + 512. [bug] The zone transfer code could throw an execption with + an invalid IXFR stream. + + 511. [bug] The message code could throw an assertion on an + out of memory failure. [RT #392] + + 510. [bug] Remove spurious view notify warning. [RT #376] + + 509. [func] Add support for write of zone files on shutdown. + + 508. [func] dns_message_parse() can now do a best-effort + attempt, which should allow dig to print more invalid + messages. + + 507. [func] New functions dns_zone_flush(), dns_zt_flushanddetach() + and dns_view_flushanddetach(). + + 506. [func] Do not fail to start on errors in zone files. + + 505. [bug] nsupdate was printing "unknown result code". [RT #373] + + 504. [bug] The zone was not being marked as dirty when updated via + IXFR. + + 503. [bug] dumptime was not being set along with + DNS_ZONEFLG_NEEDDUMP. + + 502. [func] On a SERVFAIL reply, DiG will now try the next server + in the list, unless the +fail option is specified. + + 501. [bug] Incorrect port numbers were being displayed by + nslookup. [RT #352] + + 500. [func] Nearly useless +details option removed from DiG. + + 499. [func] In DiG, specifying a class with -c or type with -t + changes command-line parsing so that classes and + types are only recognized if following -c or -t. + This allows hosts with the same name as a class or + type to be looked up. + + 498. [doc] There is now a man page for "dig" + in doc/man/bin/dig.1. + + 497. [bug] The error messages printed when an IP match list + contained a network address with a nonzero host + part where not sufficiently detailed. [RT #365] + + 496. [bug] named didn't sanity check numeric parameters. [RT #361] + + 495. [bug] nsupdate was unable to handle large records. [RT #368] + + 494. [func] Do not cache NXDOMAIN responses for SOA queries. + + 493. [func] Return non-cachable (ttl = 0) NXDOMAIN responses + for SOA queries. This makes it easier to locate + the containing zone without polluting intermediate + caches. + + 492. [bug] attempting to reload a zone caused the server fail + to shutdown cleanly. [RT #360] + + 491. [bug] nsupdate would segfault when sending certain + prerequisites with empty RDATA. [RT #356] + + 490. [func] When a slave/stub zone has not yet successfully + obtained an SOA containing the zone's configured + retry time, perform the SOA query retries using + exponential backoff. [RT #337] + + 489. [func] The zone manager now has a "i/o" queue. + + 488. [bug] Locks weren't properly destroyed in some cases. + + 487. [port] flockfile() is not defined on all systems. + + 486. [bug] nslookup: "set all" and "server" commands showed + the incorrect port number if a port other than 53 + was specified. [RT #352] + + 485. [func] When dig had more than one server to query, it would + send all of the messages at the same time. Add + rate limiting of the transmitted messages. + + 484. [bug] When the server was reloaded after removing addresses + from the named.conf "listen-on" statement, sockets + were still listening on the removed addresses due + to reference count loops. [RT #325] + + 483. [bug] nslookup: "set all" showed a "search" option but it + was not settable. + + 482. [bug] nslookup: a plain "server" or "lserver" should be + treated as a lookup. + + 481. [bug] nslookup:get_next_command() stack size could exceed + per thread limit. + + 480. [bug] strtok() is not thread safe. [RT #349] + + 479. [func] The test suite can now be run by typing "make check" + or "make test" at the top level. + + 478. [bug] "make install" failed if the directory specified with + --prefix did not already exist. + + 477. [bug] The the isc-config.sh script could be installed before + its directory was created. [RT #324] + + 476. [bug] A zone could expire while a zone transfer was in + progress triggering a INSIST failure. [RT #329] + + 475. [bug] query_getzonedb() sometimes returned a non-null version + on failure. This caused assertion failures when + generating query responses where names subject to + additional section processing pointed to a zone + to which access had been denied by means of the + allow-query option. [RT #336] + + 474. [bug] The mnemonic of the CHAOS class is CH according to + RFC1035, but it was printed and read only as CHAOS. + We now accept both forms as input, and print it + as CH. [RT #305] + + 473. [bug] nsupdate overran the end of the list of name servers + when no servers could be reached, typically causing + it to print the error message "dns_request_create: + not implemented". + + 472. [bug] Off-by-one error caused isc_time_add() to sometimes + produce invalid time values. + + 471. [bug] nsupdate didn't compile on HP/UX 10.20 + + 470. [func] $GENERATE is now supported. See also + doc/misc/migration. + + 469. [bug] "query-source address * port 53;" now works. + + 468. [bug] dns_master_load*() failed to report file and line + number in certain error conditions. + + 467. [bug] dns_master_load*() failed to log an error if + pushfile() failed. + + 466. [bug] dns_master_load*() could return success when it failed. + + 465. [cleanup] Allow 0 to be set as an omapi_value_t value by + omapi_value_storeint(). + + 464. [cleanup] Build with openssl's RSA code instead of dnssafe. + + 463. [bug] nsupdate sent malformed SOA queries to the second + and subsequent name servers in resolv.conf if the + query sent to the first one failed. + + 462. [bug] --disable-ipv6 should work now. + + 461. [bug] Specifying an unknown key in the "keys" clause of the + "controls" statement caused a NULL pointer dereference. + [RT #316] + + 460. [bug] Much of the DNSSEC code only worked with class IN. + + 459. [bug] Nslookup processed the "set" command incorrectly. + + 458. [bug] Nslookup didn't properly check class and type values. + [RT #305] + + 457. [bug] Dig/host/hslookup didn't properly handle connect + timeouts in certain situations, causing an + unnecessary warning message to be printed. + + 456. [bug] Stub zones were not resetting the refresh and expire + counters, loadtime or clearing the DNS_ZONE_REFRESH + (refresh in progress) flag upon successful update. + This disabled further refreshing of the stub zone, + causing it to eventually expire. [RT #300] + + 455. [doc] Document IPv4 prefix notation does not require a + dotted decimal quad but may be just dotted decimal. + + 454. [bug] Enforce dotted decimal and dotted decimal quad where + documented as such in named.conf. [RT #304, RT #311] + + 453. [bug] Warn if the obsolete option "maintain-ixfr-base" + is specified in named.conf. [RT #306] + + 452. [bug] Warn if the unimplemented option "statistics-file" + is specified in named.conf. [RT #301] + + 451. [func] Update forwarding implememted. + + 450. [func] New function ns_client_sendraw(). + + 449. [bug] isc_bitstring_copy() only works correctly if the + two bitstrings have the same lsb0 value, but this + requirement was not documented, nor was there a + REQUIRE for it. + + 448. [bug] Host output formatting change, to match v8. [RT #255] + + 447. [bug] Dig didn't properly retry in TCP mode after + a truncated reply. [RT #277] + + 446. [bug] Confusing notify log message. [RT #298] + + 445. [bug] Doing a 0 bit isc_bitstring_copy() of an lsb0 + bitstring triggered a REQUIRE statement. The REQUIRE + statement was incorrect. [RT #297] + + 444. [func] "recursion denied" messages are always logged at + debug level 1, now, rather than sometimes at ERROR. + This silences these warnings in the usual case, where + some clients set the RD bit in all queries. + + 443. [bug] When loading a master file failed because of an + unrecognized RR type name, the error message + did not include the file name and line number. + [RT #285] + + 442. [bug] TSIG signed messages that did not match any view + crashed the server. [RT #290] + + 441. [bug] Nodes obscured by a DNAME were inaccessible even + when DNS_DBFIND_GLUEOK was set. + + 440. [func] New function dns_zone_forwardupdate(). + + 439. [func] New function dns_request_createraw(). + + 438. [func] New function dns_message_getrawmessage(). + + 437. [func] Log NOTIFY activity to the notify channel. + + 436. [bug] If recvmsg() returned EHOSTUNREACH or ENETUNREACH, + which sometimes happens on Linux, named would enter + a busy loop. Also, unexpected socket errors were + not logged at a high enough logging level to be + useful in diagnosing this situation. [RT #275] + + 435. [bug] dns_zone_dump() overwrote existing zone files + rather than writing to a temporary file and + renaming. This could lead to empty or partial + zone files being left around in certain error + conditions involving the initial transfer of a + slave zone, interfering with subsequent server + startup. [RT #282] + + 434. [func] New function isc_file_isabsolute(). + + 433. [func] isc_base64_decodestring() now accepts newlines + within the base64 data. This makes it possible + to break up the key data in a "trusted-keys" + statement into multiple lines. [RT #284] + + 432. [func] Added refresh/retry jitter. The actual refresh/ + retry time is now a random value between 75% and + 100% of the configured value. + + 431. [func] Log at ISC_LOG_INFO when a zone is successfully + loaded. + + 430. [bug] Rewrote the lightweight resolver client management + code to handle shutdown correctly and general + cleanup. + + 429. [bug] The space reserved for a TSIG record in a response + was 2 bytes too short, leading to message + generation failures. + + 428. [bug] rbtdb.c:find_closest_nxt() erroneously returned + DNS_R_BADDB for nodes which had neither NXT nor SIG NXT + (e.g. glue). This could cause SERVFAILs when + generating negative responses in a secure zone. + + 427. [bug] Avoid going into an infinite loop when the validator + gets a negative response to a key query where the + records are signed by the missing key. + + 426. [bug] Attempting to generate an oversized RSA key could + cause dnssec-keygen to dump core. + + 425. [bug] Warn about the auth-nxdomain default value change + if there is no auth-nxdomain statement in the + config file. [RT #287] + + 424. [bug] notify_createmessage() could trigger an assertion + failure when creating the notify message failed, + e.g. due to corrupt zones with multiple SOA records. + [RT #279] + + 423. [bug] When responding to a recusive query, errors that occur + after following a CNAME should cause the query to fail. + [RT #274] + + 422. [func] get rid of isc_random_t, and make isc_random_get() + and isc_random_jitter() use rand() internally + instead of local state. Note that isc_random_*() + functions are only for weak, non-critical "randomness" + such as timing jitter and such. + + 421. [bug] nslookup would exit when given a blank line as input. + + 420. [bug] nslookup failed to implement the "exit" command. + + 419. [bug] The certificate type PKIX was misspelled as SKIX. + + 418. [bug] At debug levels >= 10, getting an unexpected + socket receive error would crash the server + while trying to log the error message. + + 417. [func] Add isc_app_block() and isc_app_unblock(), which + allow an application to handle signals while + blocking. + + 416. [bug] Slave zones with no master file tried to use a + NULL pointer for a journal file name when they + received an IXFR. [RT #273] + + 415. [bug] The logging code leaked file descriptors. + + 414. [bug] Server did not shut down until all incoming zone + transfers were finished. + + 413. [bug] Notify could attempt to use the zone database after + it had been unloaded. [RT#267] + + 412. [bug] named -v didn't print the version. + + 411. [bug] A typo in the HS A code caused an assertion failure. + + 410. [bug] lwres_gethostbyname() and company set lwres_h_errno + to a random value on success. + + 409. [bug] If named was shut down early in the startup + process, ns_omapi_shutdown() would attempt to lock + an unintialized mutex. [RT #262] + + 408. [bug] stub zones could leak memory and reference counts if + all the masters were unreachable. + + 407. [bug] isc_rwlock_lock() would needlessly block + readers when it reached the read quota even + if no writers were waiting. + + 406. [bug] Log messages were occasionally lost or corrupted + due to a race condition in isc_log_doit(). + + 405. [func] Add support for selective forwarding (forward zones) + + 404. [bug] The request library didn't completely work with IPv6. + + 403. [bug] "host" did not use the search list. + + 402. [bug] Treat undefined acls as errors, rather than + warning and then later throwing an assertion. + [RT #252] + + 401. [func] Added simple database API. + + 400. [bug] SIG(0) signing and verifying was done incorrectly. + [RT #249] + + 399. [bug] When reloading the server with a config file + containing a syntax error, it could catch an + assertion failure trying to perform zone + maintenance on, or sending notifies from, + tentatively created zones whose views were + never fully configured and lacked an address + database and request manager. + + 398. [bug] "dig" sometimes caught an assertion failure when + using TSIG, depending on the key length. + + 397. [func] Added utility functions dns_view_gettsig() and + dns_view_getpeertsig(). + + 396. [doc] There is now a man page for "nsupdate" + in doc/man/bin/nsupdate.8. + + 395. [bug] nslookup printed incorrect RR type mnemonics + for RRs of type >= 21 [RT #237]. + + 394. [bug] Current name was not propagated via $INCLUDE. + + 393. [func] Initial answer while loading (awl) support. + Entry points: dns_master_loadfileinc(), + dns_master_loadstreaminc(), dns_master_loadbufferinc(). + Note: calls to dns_master_load*inc() should be rate + be rate limited so as to not use up all file + descriptors. + + 392. [func] Add ISC_R_FAMILYNOSUPPORT. Returned when OS does + not support the given address family requested. + + 391. [clarity] ISC_R_FAMILY -> ISC_R_FAMILYMISMATCH. + + 390. [func] The function dns_zone_setdbtype() now takes + an argc/argv style vector of words and sets + both the zone database type and its arguments, + making the functions dns_zone_adddbarg() + and dns_zone_cleardbargs() unnecessary. + + 389. [bug] Attempting to send a reqeust over IPv6 using + dns_request_create() on a system without IPv6 + support caused an assertion failure [RT #235]. + + 388. [func] dig and host can now do reverse ipv6 lookups. + + 387. [func] Add dns_byaddr_createptrname(), which converts + an address into the name used by a PTR query. + + 386. [bug] Missing strdup() of ACL name caused random + ACL matching failures [RT #228]. + + 385. [cleanup] Removed functions dns_zone_equal(), dns_zone_print(), + and dns_zt_print(). + + 384. [bug] nsupdate was incorrectly limiting TTLs to 65535 instead + of 2147483647. + + 383. [func] When writing a master file, print the SOA and NS + records (and their SIGs) before other records. + + 382. [bug] named -u failed on many Linux systems where the + libc provided kernel headers do not match + the current kernel. + + 381. [bug] Check for IPV6_RECVPKTINFO and use it instead of + IPV6_PKTINFO if found. [RT #229] + + 380. [bug] nsupdate didn't work with IPv6. + + 379. [func] New library function isc_sockaddr_anyofpf(). + + 378. [func] named and lwresd will log the command line arguments + they were started with in the "starting ..." message. + + 377. [bug] When additional data lookups were refused due to + "allow-query", the databases were still being + attached causing reference leaks. + + 376. [bug] The server should always use good entropy when + performing cryptographic functions needing entropy. + + 375. [bug] Per-zone "allow-query" did not properly override the + view/global one for CNAME targets and additional + data [RT #220]. + + 374. [bug] SOA in authoritative negative responses had wrong TTL. + + 373. [func] nslookup is now installed by "make install". + + 372. [bug] Deal with Microsoft DNS servers appending two bytes of + garbage to zone transfer requests. + + 371. [bug] At high debug levels, doing an outgoing zone transfer + of a very large RRset could cause an assertion failure + during logging. + + 370. [bug] The error messages for rollforward failures were + overly terse. + + 369. [func] Support new named.conf options, view and zone + statements: + + max-retry-time, min-retry-time, + max-refresh-time, min-refresh-time. + + 368. [func] Restructure the internal ".bind" view so that more + zones can be added to it. + + 367. [bug] Allow proper selection of server on nslookup command + line. + + 366. [func] Allow use of '-' batch file in dig for stdin. + + 365. [bug] nsupdate -k leaked memory. + + 364. [func] Added additional-from-{cache,auth} + + 362. [bug] rndc no longer aborts if the configuration file is + missing an options statement. [RT #209] + + 361. [func] When the RBT find or chain functions set the name and + origin for a node that stores the root label + the name is now set to an empty name, instead of ".", + to simplify later use of the name and origin by + dns_name_concatenate(), dns_name_totext() or + dns_name_format(). + + 360. [func] dns_name_totext() and dns_name_format() now allow + an empty name to be passed, which is formatted as "@". + + 359. [bug] dnssec-signzone occasionally signed glue records. + + 358. [cleanup] Rename the intermediate files used by the dnssec + programs. + + 357. [bug] The zone file parser crashed if the argument + to $INCLUDE was a quoted string. + + 356. [cleanup] isc_task_send no longer requires event->sender to + be non-null. + + 355. [func] Added isc_dir_createunique(), similar to mkdtemp(). + + 354. [doc] Man pages for the dnssec tools are now included in + the distribution, in doc/man/dnssec. + + 353. [bug] double increment in lwres/gethost.c:copytobuf(). + [RT# 187] + + 352. [bug] Race condition in dns_client_t startup could cause + an assertion failure. + + 351. [bug] Constructing a response with rcode SERVFAIL to a TSIG + signed query could crash the server. + + 350. [bug] Also-notify lists specified in the global options + block were not correctly reference counted, causing + a memory leak. + + 349. [bug] Processing a query with the CD bit set now works + as expected. + + 348. [func] New boolean named.conf options 'additional-from-auth' + and 'additional-from-cache' now supported in view and + global options statement. + + 347. [bug] Don't crash if an argument is left off options in dig. + + 346. [func] Add support for .digrc config file, in the + user's current directory. + + 345. [bug] Large-scale changes/cleanups to dig: + * Significantly improve structure handling + * Don't pre-load entire batch files + * Add name/rr counting/limiting + * Fix SIGINT handling + * Shorten timeouts to match v8's behavior + + 344. [bug] When shutting down, lwresd sometimes tried + to shut down its client tasks twice, + triggering an assertion. + + 343. [bug] Although zone maintenance SOA queries and + notify requests were signed with TSIG keys + when configured for the server in case, + the TSIG was not verified on the response. + + 342. [bug] The wrong name was being passed to + dns_name_dup() when generating a TSIG + key using TKEY. + + 341. [func] Support 'key' clause in named.conf zone masters + statement to allow authentication via TSIG keys: + + masters { + 10.0.0.1 port 5353 key "foo"; + 10.0.0.2 ; + }; + + 340. [bug] The top-level COPYRIGHT file was missing from + the distribution. + + 339. [bug] DNSSEC validation of the response to an ANY + query at a name with a CNAME RR in a secure + zone triggered an assertion failure. + + 338. [bug] lwresd logged to syslog as named, not lwresd. + + 337. [bug] "dig" did not recognize "nsap-ptr" as an RR type + on the command line. + + 336. [bug] "dig -f" used 64 k of memory for each line in + the file. It now uses much less, though still + proportionally to the file size. + + 335. [bug] named would occasionally attempt recursion when + it was disallowed or undesired. + + 334. [func] Added hmac-md5 to libisc. + + 333. [bug] The resolver incorrectly accepted referrals to + domains that were not parents of the query name, + causing assertion failures. + + 332. [func] New function dns_name_reset(). + + 331. [bug] Only log "recursion denied" if RD is set. [RT #178] + + 330. [bug] Many debugging messages were partially formatted + even when debugging was turned off, causing a + significant decrease in query performance. + + 329. [func] omapi_auth_register() now takes a size_t argument for + the length of a key's secret data. Previously + OMAPI only stored secrets up to the first NUL byte. + + 328. [func] Added isc_base64_decodestring(). + + 327. [bug] rndc.conf parser wasn't correctly recognising an IP + address where a host specification was required. + + 326. [func] 'keys' in an 'inet' control statement is now + required and must have at least one item in it. + A "not supported" warning is now issued if a 'unix' + control channel is defined. + + 325. [bug] isc_lex_gettoken was processing octal strings when + ISC_LEXOPT_CNUMBER was not set. + + 324. [func] In the resolver, turn EDNS0 off if there is no + response after a number of retransmissions. + This is to allow queries some chance of succeeding + even if all the authoritative servers of a zone + silently discard EDNS0 requests instead of + sending an error response like they ought to. + + 323. [bug] dns_rbt_findname() did not ignore empty rbt nodes. + Because of this, servers authoritative for a parent + and grandchild zone but not authoritative for the + intervening child zone did not correctly issue + referrals to the servers of the child zone. + + 322. [bug] Queries for KEY RRs are now sent to the parent + server before the authoritative one, making + DNSSEC insecurity proofs work in many cases + where they previously didn't. + + 321. [bug] When synthesizing a CNAME RR for a DNAME + response, query_addcname() failed to intitialize + the type and class of the CNAME dns_rdata_t, + causing random failures. + + 320. [func] Multiple rndc changes: parses an rndc.conf file, + uses authentication to talk to named, command + line syntax changed. This will all be described + in the ARM. + + 319. [func] The named.conf "controls" statement is now used + to configure the OMAPI command channel. + + 318. [func] dns_c_ndcctx_destroy() could never return anything + except ISC_R_SUCCESS; made it have void return instead. + + 317. [func] Use callbacks from libomapi to determine if a + new connection is valid, and if a key requested + to be used with that connection is valid. + + 316. [bug] Generate a warning if we detect an unexpected + but treat as . + + 315. [bug] Handle non-empty blanks lines. [RT #163] + + 314. [func] The named.conf controls statement can now have + more than one key specified for the inet clause. + + 313. [bug] When parsing resolv.conf, don't terminate on an + error. Instead, parse as much as possible, but + still return an error if one was found. + + 312. [bug] Increase the number of allowed elements in the + resolv.conf search path from 6 to 8. If there + are more than this, ignore the remainder rather + than returning a failure in lwres_conf_parse. + + 311. [bug] lwres_conf_parse failed when the first line of + resolv.conf was empty or a comment. + + 310. [func] Changes to named.conf "controls" statement (inet + subtype only) + + - support "keys" clause + + controls { + inet * port 1024 + allow { any; } keys { "foo"; } + } + + - allow "port xxx" to be left out of statement, + in which case it defaults to omapi's default port + of 953. + + 309. [bug] When sending a referral, the server did not look + for name server addresses as glue in the zone + holding the NS RRset in the case where this zone + was not the same as the one where it looked for + name server addresses as authoritative data. + + 308. [bug] Treat a SOA record not at top of zone as an error + when loading a zone. [RT #154] + + 307. [bug] When canceling a query, the resolver didn't check for + isc_socket_sendto() calls that did not yet have their + completion events posted, so it could (rarely) end up + destroying the query context and then want to use + it again when the send event posted, triggering an + assertion as it tried to cancel an already-canceled + query. [RT #77] + + 306. [bug] Reading HMAC-MD5 private key files didn't work. + + 305. [bug] When reloading the server with a config file + containing a syntax error, it could catch an + assertion failure trying to perform zone + maintenance on tentatively created zones whose + views were never fully configured and lacked + an address database. + + 304. [bug] If more than LWRES_CONFMAXNAMESERVERS servers + are listed in resolv.conf, silently ignore them + instead of returning failure. + + 303. [bug] Add additional sanity checks to differentiate a AXFR + response vs a IXFR response. [RT #157] + + 302. [bug] In dig, host, and nslookup, MXNAME should be large + enough to hold any legal domain name in presentation + format + terminating NULL. + + 301. [bug] Uninitialized pointer in host:printmessage(). [RT #159] + + 300. [bug] Using both and didn't work + on platforms lacking IPv6 because each included their + own ipv6 header file for the missing definitions. Now + each library's ipv6.h defines the wrapper symbol of + the other (ISC_IPV6_H and LWRES_IPV6_H). + + 299. [cleanup] Get the user and group information before changing the + root directory, so the administrator does not need to + keep a copy of the user and group databases in the + chroot'ed environment. Suggested by Hakan Olsson. + + 298. [bug] A mutex deadlock occurred during shutdown of the + interface manager under certain conditions. + Digital Unix systems were the most affected. + + 297. [bug] Specifying a key name that wasn't fully qualified + in certain parts of the config file could cause + an assertion failure. + + 296. [bug] "make install" from a separate build directory + failed unless configure had been run in the source + directory, too. + + 295. [bug] When invoked with type==CNAME and a message + not constructed by dns_message_parse(), + dns_message_findname() failed to find anything + due to checking for attribute bits that are set + only in dns_message_parse(). This caused an + infinite loop when constructing the response to + an ANY query at a CNAME in a secure zone. + + 294. [bug] If we run out of space in while processing glue + when reading a master file and commit "current name" + reverts to "name_current" instead of staying as + "name_glue". + + 293. [port] Add support for FreeBSD 4.0 system tests. + + 292. [bug] Due to problems with the way some operating systems + handle simultaneous listening on IPv4 and IPv6 + addresses, the server no longer listens on IPv6 + addresses by default. To revert to the previous + behavior, specify "listen-on-v6 { any; };" in + the config file. + + 291. [func] Caching servers no longer send outgoing queries + over TCP just because the incoming recursive query + was a TCP one. + + 290. [cleanup] +twiddle option to dig (for testing only) removed. + + 289. [cleanup] dig is now installed in $bindir instead of $sbindir. + host is now installed in $bindir. (Be sure to remove + any $sbindir/dig from a previous release.) + + 288. [func] rndc is now installed by "make install" into $sbindir. + + 287. [bug] rndc now works again as "rndc 127.1 reload" (for + only that task). Parsing its configuration file and + using digital signatures for authentication has been + disabled until named supports the "controls" statement, + post-9.0.0. + + 286. [bug] On Solaris 2, when named inherited a signal state + where SIGHUP had the SIG_IGN action, SIGHUP would + be ignored rather than causing the server to reload + its configuration. + + 285. [bug] A change made to the dst API for beta4 inadvertently + broke OMAPI's creation of a dst key from an incoming + message, causing an assertion to be triggered. Fixed. + + 284. [func] The DNSSEC key generation and signing tools now + generate randomness from keyboard input on systems + that lack /dev/random. + + 283. [cleanup] The 'lwresd' program is now a link to 'named'. + + 282. [bug] The lexer now returns ISC_R_RANGE if parsed integer is + too big for an unsigned long. + + 281. [bug] Fixed list of recognized config file category names. + + 280. [func] Add isc-config.sh, which can be used to more + easily build applications that link with + our libraries. + + 279. [bug] Private omapi function symbols shared between + two or more files in libomapi.a were not namespace + protected using the ISC convention of starting with + the library name and two underscores ("omapi__"...) + + 278. [bug] bin/named/logconf.c:category_fromconf() didn't take + note of when isc_log_categorybyname() wasn't able + to find the category name and would then apply the + channel list of the unknown category to all categories. + + 277. [bug] isc_log_categorybyname() and isc_log_modulebyname() + would fail to find the first member of any category + or module array apart from the internal defaults. + Thus, for example, the "notify" category was improperly + configured by named. + + 276. [bug] dig now supports maximum sized TCP messages. + + 275. [bug] The definition of lwres_gai_strerror() was missing + the lwres_ prefix. + + 274. [bug] TSIG AXFR verify failed when talking to a BIND 8 + server. + + 273. [func] The default for the 'transfer-format' option is + now 'many-answers'. This will break zone transfers + to BIND 4.9.5 and older unless there is an explicit + 'one-answer' configuration. + + 272. [bug] The sending of large TCP responses was canceled + in mid-transmission due to a race condition + caused by the failure to set the client object's + "newstate" variable correctly when transitioning + to the "working" state. + + 271. [func] Attempt to probe the number of cpus in named + if unspecified rather than defaulting to 1. + + 270. [func] Allow maximum sized TCP answers. + + 269. [bug] Failed DNSSEC validations could cause an assertion + failure by causing clone_results() to be called with + with hevent->node == NULL. + + 268. [doc] A plain text version of the Administrator + Reference Manual is now included in the distribution, + as doc/arm/Bv9ARM.txt. + + 267. [func] Nsupdate is now provided in the distribution. + + 266. [bug] zone.c:save_nsrrset() node was not initialized. + + 265. [bug] dns_request_create() now works for TCP. + + 264. [func] Dispatch can not take TCP sockets in connecting + state. Set DNS_DISPATCHATTR_CONNECTED when calling + dns_dispatch_createtcp() for connected TCP sockets + or call dns_dispatch_starttcp() when the socket is + connected. + + 263. [func] New logging channel type 'stderr' + + channel some-name { + stderr; + severity error; + } + + 262. [bug] 'master' was not initialized in zone.c:stub_callback(). + + 261. [func] Add dns_zone_markdirty(). + + 260. [bug] Running named as a non-root user failed on Linux + kernels new enough to support retaining capabilities + after setuid(). + + 259. [func] New random-device and random-seed-file statements + for global options block of named.conf. Both accept + a single string argument. + + 258. [bug] Fixed printing of lwres_addr_t.address field. + + 257. [bug] The server detached the last zone manager reference + too early, while it could still be in use by queries. + This manifested itself as assertion failures during the + shutdown process for busy name servers. [RT #133] + + 256. [func] isc_ratelimiter_t now has attach/detach semantics, and + isc_ratelimiter_shutdown guarantees that the rate + limiter is detached from its task. + + 255. [func] New function dns_zonemgr_attach(). + + 254. [bug] Suppress "query denied" messages on additional data + lookups. + + --- 9.0.0b4 released --- + + 253. [func] resolv.conf parser now recognises ';' and '#' as + comments (anywhere in line, not just as the beginning). + + 252. [bug] resolv.conf parser mishandled masks on sortlists. + It also aborted when an unrecognized keyword was seen, + now it silently ignores the entire line. + + 251. [bug] lwresd caught an assertion failure on startup. + + 250. [bug] fixed handling of size+unit when value would be too + large for internal representation. + + 249. [cleanup] max-cache-size config option now takes a size-spec + like 'datasize', except 'default' is not allowed. + + 248. [bug] global lame-ttl option was not being printed when + config structures were written out. + + 247. [cleanup] Rename cache-size config option to max-cache-size. + + 246. [func] Rename global option cachesize to cache-size and + add corresponding option to view statement. + + 245. [bug] If an uncompressed name will take more than 255 + bytes and the buffer is sufficiently long, + dns_name_fromwire should return DNS_R_FORMERR, + not ISC_R_NOSPACE. This bug caused cause the + server to catch an assertion failure when it + received a query for a name longer than 255 + bytes. + + 244. [bug] empty named.conf file and empty options statement are + now parsed properly. + + 243. [func] new cachesize option for named.conf + + 242. [cleanup] fixed incorrect warning about auth-nxdomain usage. + + 241. [cleanup] nscount and soacount have been removed from the + dns_master_*() argument lists. + + 240. [func] databases now come in three flavours: zone, cache + and stub. + + 239. [func] If ISC_MEM_DEBUG is enabled, the variable + isc_mem_debugging controls whether messages + are printed or not. + + 238. [cleanup] A few more compilation warnings have been quieted: + + missing sigwait prototype on BSD/OS 4.0/4.0.1. + + PTHREAD_ONCE_INIT unbraced initializer warnings on + Solaris 2.8. + + IN6ADDR_ANY_INIT unbraced initializer warnings on + BSD/OS 4.*, Linux and Solaris 2.8. + + 237. [bug] If connect() returned ENOBUFS when the resolver was + initiating a TCP query, the socket didn't get + destroyed, and the server did not shut down cleanly. + + 236. [func] Added new listen-on-v6 config file statement. + + 235. [func] Consider it a config file error if a listen-on + statement has an IPv6 address in it, or a + listen-on-v6 statement has an IPv4 address in it. + + 234. [bug] Allow a trusted-key's first field (domain-name) be + either a quoted or an unquoted string, instead of + requiring a quoted string. + + 233. [cleanup] Convert all config structure integer values to unsigned + integer (isc_uint32_t) to match grammer. + + 232. [bug] Allow slave zones to not have a file. + + 231. [func] Support new 'port' clause in config file options + section. Causes 'listen-on', 'masters' and + 'also-notify' statements to use its value instead of + default (53). + + 230. [func] Replace the dst sign/verify API with a cleaner one. + + 229. [func] Support config file sig-validity-interval statement + in options, views and zone statements (master + zones only). + + 228. [cleanup] Logging messages in config module stripped of + trailing period. + + 227. [cleanup] The enumerated identifiers dns_rdataclass_*, + dns_rcode_*, dns_opcode_*, and dns_trust_* are + also now cast to their appropriate types, as with + dns_rdatatype_* in item number 225 below. + + 226. [func] dns_name_totext() now always prints the root name as + '.', even when omit_final_dot is true. + + 225. [cleanup] The enumerated dns_rdatatype_* identifiers are now + cast to dns_rdatatype_t via macros of their same name + so that they are of the proper integral type wherever + a dns_rdatatype_t is needed. + + 224. [cleanup] The entire project builds cleanly with gcc's + -Wcast-qual and -Wwrite-strings warnings enabled, + which is now the default when using gcc. (Warnings + from confparser.c, because of yacc's code, are + unfortunately to be expected.) + + 223. [func] Several functions were reprototyped to qualify one + or more of their arguments with "const". Similarly, + several functions that return pointers now have + those pointers qualified with const. + + 222. [bug] The global 'also-notify' option was ignored. + + 221. [bug] An uninitialized variable was sometimes passed to + dns_rdata_freestruct() when loading a zone, causing + an assertion failure. + + 220. [cleanup] Set the default outgoing port in the view, and + set it in sockaddrs returned from the ADB. + [31-May-2000 explorer] + + 219. [bug] Signed truncated messages more correctly follow + the respective specs. + + 218. [func] When an rdataset is signed, its ttl is normalized + based on the signature validity period. + + 217. [func] Also-notify and trusted-keys can now be used in + the 'view' statement. + + 216. [func] The 'max-cache-ttl' and 'max-ncache-ttl' options + now work. + + 215. [bug] Failures at certain points in request processing + could cause the assertion INSIST(client->lockview + == NULL) to be triggered. + + 214. [func] New public function isc_netaddr_format(), for + formatting network addresses in log messages. + + 213. [bug] Don't leak memory when reloading the zone if + an update-policy clause was present in the old zone. + + 212. [func] Added dns_message_get/settsigkey, to make TSIG + key management reasonable. + + 211. [func] The 'key' and 'server' statements can now occur + inside 'view' statements. + + 210. [bug] The 'allow-transfer' option was ignored for slave + zones, and the 'transfers-per-ns' option was + was ignored for all zones. + + 209. [cleanup] Upgraded openssl files to new version 0.9.5a + + 208. [func] Added ISC_OFFSET_MAXIMUM for the maximum value + of an isc_offset_t. + + 207. [func] The dnssec tools properly use the logging subsystem. + + 206. [cleanup] dst now stores the key name as a dns_name_t, not + a char *. + + 205. [cleanup] On IRIX, turn off the mostly harmless warnings 1692 + ("prototyped function redeclared without prototype") + and 1552 ("variable ... set but not used") when + compiling in the lib/dns/sec/{dnssafe,openssl} + directories, which contain code imported from outside + sources. + + 204. [cleanup] On HP/UX, pass +vnocompatwarnings to the linker + to quiet the warnings that "The linked output may not + run on a PA 1.x system." + + 203. [func] notify and zone soa queries are now tsig signed when + appropriate. + + 202. [func] isc_lex_getsourceline() changed from returning int + to returning unsigned long, the type of its underlying + counter. + + 201. [cleanup] Removed the test/sdig program, it has been + replaced by bin/dig/dig. + + + --- 9.0.0b3 released --- + + 200. [bug] Failures in sending query responses to clients + (e.g., running out of network buffers) were + not logged. + + 199. [bug] isc_heap_delete() sometimes violated the heap + invariant, causing timer events not to be posted + when due. + + 198. [func] Dispatch managers hold memory pools which + any managed dispatcher may use. This allows + us to avoid dipping into the memory context for + most allocations. [19-May-2000 explorer] + + 197. [bug] When an incoming AXFR or IXFR completes, the + zone's internal state is refreshed from the + SOA data. [19-May-2000 explorer] + + 196. [func] Dispatchers can be shared easily between views + and/or interfaces. [19-May-2000 explorer] + + 195. [bug] Including the NXT record of the root domain + in a negative response caused an assertion + failure. + + 194. [doc] The PDF version of the Administrator's Reference + Manual is no longer included in the ISC BIND9 + distribution. + + 193. [func] changed dst_key_free() prototype. + + 192. [bug] Zone configuration validation is now done at end + of config file parsing, and before loading + callbacks. + + 191. [func] Patched to compile on UnixWare 7.x. This platform + is not directly supported by the ISC. + + 190. [cleanup] The DNSSEC tools have been moved to a separate + directory dnssec/ and given the following new, + more descriptive names: + + dnssec-keygen + dnssec-signzone + dnssec-signkey + dnssec-makekeyset + + Their command line arguments have also been changed to + be more consistent. dnssec-keygen now prints the + name of the generated key files (sans extension) + on standard output to simplify its use in automated + scripts. + + 189. [func] isc_time_secondsastimet(), a new function, will ensure + that the number of seconds in an isc_time_t does not + exceed the range of a time_t, or return ISC_R_RANGE. + Similarly, isc_time_now(), isc_time_nowplusinterval(), + isc_time_add() and isc_time_subtract() now check the + range for overflow/underflow. In the case of + isc_time_subtract, this changed a calling requirement + (ie, something that could generate an assertion) + into merely a condition that returns an error result. + isc_time_add() and isc_time_subtract() were void- + valued before but now return isc_result_t. + + 188. [func] Log a warning message when an incoming zone transfer + contains out-of-zone data. + + 187. [func] isc_ratelimter_enqueue() has an additional argument + 'task'. + + 186. [func] dns_request_getresponse() has an additional argument + 'preserve_order'. + + 185. [bug] Fixed up handling of ISC_MEMCLUSTER_LEGACY. Several + public functions did not have an isc__ prefix, and + referred to functions that had previously been + renamed. + + 184. [cleanup] Variables/functions which began with two leading + underscores were made to conform to the ANSI/ISO + standard, which says that such names are reserved. + + 183. [func] ISC_LOG_PRINTTAG option for log channels. Useful + for logging the program name or other identifier. + + 182. [cleanup] New commandline parameters for dnssec tools + + 181. [func] Added dst_key_buildfilename and dst_key_parsefilename + + 180. [func] New isc_result_t ISC_R_RANGE. Supersedes DNS_R_RANGE. + + 179. [func] options named.conf statement *must* now come + before any zone or view statements. + + 178. [func] Post-load of named.conf check verifies a slave zone + has non-empty list of masters defined. + + 177. [func] New per-zone boolean: + + enable-zone yes | no ; + + intended to let a zone be disabled without having + to comment out the entire zone statement. + + 176. [func] New global and per-view option: + + max-cache-ttl number + + 175. [func] New global and per-view option: + + additional-data internal | minimal | maximal; + + 174. [func] New public function isc_sockaddr_format(), for + formatting socket addresses in log messages. + + 173. [func] Keep a queue of zones waiting for zone transfer + quota so that a new transfer can be dispatched + immediately whenever quota becomes available. + + 172. [bug] $TTL directive was sometimes missing from dumped + master files because totext_ctx_init() failed to + initialize ctx->current_ttl_valid. + + 171. [cleanup] On NetBSD systems, the mit-pthreads or + unproven-pthreads library is now always used + unless --with-ptl2 is explicitly specified on + the configure command line. The + --with-mit-pthreads option is no longer needed + and has been removed. + + 170. [cleanup] Remove inter server consistancy checks from zone, + these should return as a seperate module in 9.1. + dns_zone_checkservers(), dns_zone_checkparents(), + dns_zone_checkchildren(), dns_zone_checkglue(). + + Remove dns_zone_setadb(), dns_zone_setresolver(), + dns_zone_setrequestmgr() these should now be found + via the view. + + 169. [func] ratelimiter can now process N events per interval. + + 168. [bug] include statements in named.conf caused syntax errors + due to not consuming the semicolon ending the include + statement before switching input streams. + + 167. [bug] Make lack of masters for a slave zone a soft error. + + 166. [bug] Keygen was overwriting existing keys if key_id + conflicted, now it will retry, and non-null keys + with key_id == 0 are not generated anymore. Key + was not able to generate NOAUTHCONF DSA key, + increased RSA key size to 2048 bits. + + 165. [cleanup] Silence "end-of-loop condition not reached" warnings + from Solaris compiler. + + 164. [func] Added functions isc_stdio_open(), isc_stdio_close(), + isc_stdio_seek(), isc_stdio_read(), isc_stdio_write(), + isc_stdio_flush(), isc_stdio_sync(), isc_file_remove() + to encapsulate nonportable usage of errno and sync. + + 163. [func] Added result codes ISC_R_FILENOTFOUND and + ISC_R_FILEEXISTS. + + 162. [bug] Ensure proper range for arguments to ctype.h functions. + + 161. [cleanup] error in yyparse prototype that only HPUX caught. + + 160. [cleanup] getnet*() are not going to be implemented at this + stage. + + 159. [func] Redefinition of config file elements is now an + error (instead of a warning). + + 158. [bug] Log channel and category list copy routines + weren't assigning properly to output parameter. + + 157. [port] Fix missing prototype for getopt(). + + 156. [func] Support new 'database' statement in zone. + + database "quoted-string"; + + 155. [bug] ns_notify_start() was not detaching the found zone. + + 154. [func] The signer now logs libdns warnings to stderr even when + not verbose, and in a nicer format. + + 153. [func] dns_rdata_tostruct() 'mctx' is now optional. If 'mctx' + is NULL then you need to preserve the 'rdata' until + you have finished using the structure as there may be + references to the associated memory. If 'mctx' is + non-NULL it is guaranteed that there are no references + to memory associated with 'rdata'. + + dns_rdata_freestruct() must be called if 'mctx' was + non-NULL and may safely be called if 'mctx' was NULL. + + 152. [bug] keygen dumped core if domain name argument was omitted + from command line. + + 151. [func] Support 'disabled' statement in zone config (causes + zone to be parsed and then ignored). Currently must + come after the 'type' clause. + + 150. [func] Support optional ports in masters and also-notify + statements: + + masters [ port xxx ] { y.y.y.y [ port zzz ] ; } + + 149. [cleanup] Removed usused argument 'olist' from + dns_c_view_unsetordering(). + + 148. [cleanup] Stop issuing some warnings about some configuration + file statements that were not implemented, but now are. + + 147. [bug] Changed yacc union size to be smaller for yaccs that + put yacc-stack on the real stack. + + 146. [cleanup] More general redundant header file cleanup. Rather + than continuing to itemize every header which changed, + this changelog entry just notes that if a header file + did not need another header file that it was including + in order to provide its advertized functionality, the + inclusion of the other header file was removed. See + util/check-includes for how this was tested. + + 145. [cleanup] Added and ISC_LANG_BEGINDECLS/ + ISC_LANG_ENDDECLS to header files that had function + prototypes, and removed it from those that did not. + + 144. [cleanup] libdns header files too numerous to name were made + to conform to the same style for multiple inclusion + protection. + + 143. [func] Added function dns_rdatatype_isknown(). + + 142. [cleanup] does not need or + . + + 141. [bug] Corrupt requests with multiple questions could + cause an assertion failure. + + 140. [cleanup] does not need or . + + 139. [cleanup] now includes instead of + and . + + 138. [cleanup] isc_strtouq moved from str.[ch] to string.[ch] and + renamed isc_string_touint64. isc_strsep moved from + strsep.c to string.c and renamed isc_string_separate. + + 137. [cleanup] , , + , and + made to conform to the same style for multiple + inclusion protection. + + 136. [cleanup] , , + and Win32's needed + ISC_LANG_BEGINDECLS/ISC_LANG_ENDDECLS. + + 135. [cleanup] Win32's did not need + or , now uses in place + of , and needed ISC_LANG_BEGINDECLS + and ISC_LANG_ENDDECLS. + + 134. [cleanup] does not need . + + 133. [cleanup] needs . + + 132. [cleanup] does not need , but does + need . + + 131. [cleanup] and need + for ISC_R_* codes used in macros. + + 130. [cleanup] does not need or + , and now includes + instead of . + + 129. [bug] The 'default_debug' log channel was not set up when + 'category default' was present in the config file + + 128. [cleanup] had ISC_LANG_BEGINDECLS instead of + ISC_LANG_ENDDECLS at end of header. + + 127. [cleanup] The contracts for the comparision routines + dns_name_fullcompare(), dns_name_compare(), + dns_name_rdatacompare(), and dns_rdata_compare() now + specify that the order value returned is < 0, 0, or > 0 + instead of -1, 0, or 1. + + 126. [cleanup] and need . + + 125. [cleanup] , , , + , , , and + do not need . + + 124. [func] signer now imports parent's zone key signature + and creates null keys/sets zone status bit for + children when necessary + + 123. [cleanup] does not need . + + 122. [cleanup] does not need or + . + + 121. [cleanup] does not need or + . Multiple inclusion protection + symbol fixed from ISC_SYMBOL_H to ISC_SYMTAB_H. + isc_symtab_t moved to . + + 120. [cleanup] does not need , + , , or + . + + 119. [cleanup] structure definitions for generic rdata stuctures do + not have _generic_ in their names. + + 118. [cleanup] libdns.a is now namespace-clean, on NetBSD, excepting + YACC crust (yyparse, etc) [2000-apr-27 explorer] + + 117. [cleanup] libdns.a changes: + dns_zone_clearnotify() and dns_zone_addnotify() + are replaced by dns_zone_setnotifyalso(). + dns_zone_clearmasters() and dns_zone_addmaster() + are replaced by dns_zone_setmasters(). + + 116. [func] Added for isc_offset_t (aka off_t + on Unix systems). + + 115. [port] Shut up the -Wmissing-declarations warning about + 's __sputaux on BSD/OS pre-4.1. + + 114. [cleanup] does not need or + . + + 113. [func] Utility programs dig and host added. + + 112. [cleanup] does not need . + + 111. [cleanup] does not need or + . + + 110. [cleanup] does not need or + . + + 109. [bug] "make depend" did nothing for + bin/tests/{db,mem,sockaddr,tasks,timers}/. + + 108. [cleanup] DNS_SETBIT/DNS_GETBIT/DNS_CLEARBIT moved from + to and renamed to + DNS_BIT_SET/DNS_BIT_GET/DNS_BIT_CLEAR. + + 107. [func] Add keysigner and keysettool. + + 106. [func] Allow dnssec verifications to ignore the validity + period. Used by several of the dnssec tools. + + 105. [doc] doc/dev/coding.html expanded with other + implicit conventions the developers have used. + + 104. [bug] Made compress_add and compress_find static to + lib/dns/compress.c. + + 103. [func] libisc buffer API changes for : + Added: + isc_buffer_base(b) (pointer) + isc_buffer_current(b) (pointer) + isc_buffer_active(b) (pointer) + isc_buffer_used(b) (pointer) + isc_buffer_length(b) (int) + isc_buffer_usedlength(b) (int) + isc_buffer_consumedlength(b) (int) + isc_buffer_remaininglength(b) (int) + isc_buffer_activelength(b) (int) + isc_buffer_availablelength(b) (int) + Removed: + ISC_BUFFER_USEDCOUNT(b) + ISC_BUFFER_AVAILABLECOUNT(b) + isc_buffer_type(b) + Changed names: + isc_buffer_used(b, r) -> + isc_buffer_usedregion(b, r) + isc_buffer_available(b, r) -> + isc_buffer_available_region(b, r) + isc_buffer_consumed(b, r) -> + isc_buffer_consumedregion(b, r) + isc_buffer_active(b, r) -> + isc_buffer_activeregion(b, r) + isc_buffer_remaining(b, r) -> + isc_buffer_remainingregion(b, r) + + Buffer types were removed, so the ISC_BUFFERTYPE_* + macros are no more, and the type argument to + isc_buffer_init and isc_buffer_allocate were removed. + isc_buffer_putstr is now void (instead of isc_result_t) + and requires that the caller ensure that there + is enough available buffer space for the string. + + 102. [port] Correctly detect inet_aton, inet_pton and inet_ptop + on BSD/OS 4.1. + + 101. [cleanup] Quieted EGCS warnings from lib/isc/print.c. + + 100. [cleanup] does not need or + . isc_random_t moved to . + + 99. [cleanup] Rate limiter now has separate shutdown() and + destroy() functions, and it guarantees that all + queued events are delivered even in the shutdown case. + + 98. [cleanup] does not need or + unless ISC_PLATFORM_NEEDVSNPRINTF is defined. + + 97. [cleanup] does not need or + . + + 96. [cleanup] does not need . + + 95. [cleanup] does not need . + + 94. [cleanup] Some installed header files did not compile as C++. + + 93. [cleanup] does not need . + + 92. [cleanup] does not need , , + or . + + 91. [cleanup] does not need or + . + + 90. [cleanup] Removed unneeded ISC_LANG_BEGINDECLS/ISC_LANG_ENDDECLS + from . + + 89. [cleanup] does not need . + + 88. [cleanup] does not need or + . isc_interface_t and isc_interfaceiter_t + moved to . + + 87. [cleanup] does not need , + or . + + 86. [cleanup] isc_bufferlist_t moved from to + . + + 85. [cleanup] does not need , + , , or + . + + 84. [func] allow-query ACL checks now apply to all data + added to a response. + + 83. [func] If the server is authoritative for both a + delegating zone and its (nonsecure) delegatee, and + a query is made for a KEY RR at the top of the + delegatee, then the server will look for a KEY + in the delegator if it is not found in the delegatee. + + 82. [cleanup] does not need . + + 81. [cleanup] and do not need + . + + 80. [cleanup] does not need or . + + 79. [cleanup] does not need . + + 78. [cleanup] lwres_conftest renamed to lwresconf_test for + consistency with other *_test programs. + + 77. [cleanup] typedef of isc_time_t and isc_interval_t moved from + to . + + 76. [cleanup] Rewrote keygen. + + 75. [func] Don't load a zone if its database file is older + than the last time the zone was loaded. + + 74. [cleanup] Removed mktemplate.o and ufile.o from libisc.a, + subsumed by file.o. + + 73. [func] New "file" API in libisc, including new function + isc_file_getmodtime, isc_mktemplate renamed to + isc_file_mktemplate and isc_ufile renamed to + isc_file_openunique. By no means an exhaustive API, + it is just what's needed for now. + + 72. [func] DNS_RBTFIND_NOPREDECESSOR and DNS_RBTFIND_NOOPTIONS + added for dns_rbt_findnode, the former to disable the + setting of the chain to the predecessor, and the + latter to make clear when no options are set. + + 71. [cleanup] Made explicit the implicit REQUIREs of + isc_time_seconds, isc_time_nanoseconds, and + isc_time_subtract. + + 70. [func] isc_time_set() added. + + 69. [bug] The zone object's master and also-notify lists grew + longer with each server reload. + + 68. [func] Partial support for SIG(0) on incoming messages. + + 67. [performance] Allow use of alternate (compile-time supplied) + OpenSSL libraries/headers. + + 66. [func] Data in authoritative zones should have a trust level + beyond secure. + + 65. [cleanup] Removed obsolete typedef of dns_zone_callbackarg_t + from . + + 64. [func] The RBT, DB, and zone table APIs now allow the + caller find the most-enclosing superdomain of + a name. + + 63. [func] Generate NOTIFY messages. + + 62. [func] Add UDP refresh support. + + 61. [cleanup] Use single quotes consistently in log messages. + + 60. [func] Catch and disallow singleton types on message + parse. + + 59. [bug] Cause net/host unreachable to be a hard error + when sending and receiving. + + 58. [bug] bin/named/query.c could sometimes trigger the + (client->query.attributes & NS_QUERYATTR_NAMEBUFUSED) + == 0 assertion in query_newname(). + + 57. [func] Added dns_nxt_typepresent() + + 56. [bug] SIG records were not properly returned in cached + negative answers. + + 55. [bug] Responses containing multiple names in the authority + section were not negatively cached. + + 54. [bug] If a fetch with sigrdataset==NULL joined one with + sigrdataset!=NULL or vice versa, the resolver + could catch an assertion or lose signature data, + respectively. + + 53. [port] freebsd 4.0: lib/isc/unix/socket.c requires + . + + 52. [bug] rndc: taskmgr and socketmgr were not initialized + to NULL. + + 51. [cleanup] dns/compress.h and dns/zt.h did not need to include + dns/rbt.h; it was needed only by compress.c and zt.c. + + 50. [func] RBT deletion no longer requires a valid chain to work, + and dns_rbt_deletenode was added. + + 49. [func] Each cache now has its own mctx. + + 48. [func] isc_task_create() no longer takes an mctx. + isc_task_mem() has been eliminated. + + 47. [func] A number of modules now use memory context reference + counting. + + 46. [func] Memory contexts are now reference counted. + Added isc_mem_inuse() and isc_mem_preallocate(). + Renamed isc_mem_destroy_check() to + isc_mem_setdestroycheck(). + + 45. [bug] The trusted-key statement incorrectly loaded keys. + + 44. [bug] Don't include authority data if it would force us + to unset the AD bit in the message. + + 43. [bug] DNSSEC verification of cached rdatasets was failing. + + 42. [cleanup] Simplified logging of messages with embedded domain + names by introducing a new convenience function + dns_name_format(). + + 41. [func] Use PR_SET_KEEPCAPS on Linux 2.3.99-pre3 and later + to allow 'named' to run as a non-root user while + retaining the ability to bind() to privileged + ports. + + 40. [func] Introduced new logging category "dnssec" and + logging module "dns/validator". + + 39. [cleanup] Moved the typedefs for isc_region_t, isc_textregion_t, + and isc_lex_t to . + + 38. [bug] TSIG signed incoming zone transfers work now. + + 37. [bug] If the first RR in an incoming zone transfer was + not an SOA, the server died with an assertion failure + instead of just reporting an error. + + 36. [cleanup] Change DNS_R_SUCCESS (and others) to ISC_R_SUCCESS + + 35. [performance] Log messages which are of a level too high to be + logged by any channel in the logging configuration + will not cause the log mutex to be locked. + + 34. [bug] Recursion was allowed even with 'recursion no'. + + 33. [func] The RBT now maintains a parent pointer at each node. + + 32. [cleanup] bin/lwresd/client.c needs for memset() + prototype. + + 31. [bug] Use ${LIBTOOL} to compile bin/named/main.@O@. + + 30. [func] config file grammer change to support optional + class type for a view. + + 29. [func] support new config file view options: + + auth-nxdomain recursion query-source + query-source-v6 transfer-source + transfer-source-v6 max-transfer-time-out + max-transfer-idle-out transfer-format + request-ixfr provide-ixfr cleaning-interval + fetch-glue notify rfc2308-type1 lame-ttl + max-ncache-ttl min-roots + + 28. [func] support lame-ttl, min-roots and serial-queries + config global options. + + 27. [bug] Only include on BSD/OS 4.[01]*. + Including it on other platforms (eg, NetBSD) can + cause a forced #error from the C preprocessor. + + 26. [func] new match-clients statement in config file view. + + 25. [bug] make install failed to install and + . + + 24. [cleanup] Eliminate some unnecessary #includes of header + files from header files. + + 23. [cleanup] Provide more context in log messages about client + requests, using a new function ns_client_log(). + + 22. [bug] SIGs weren't returned in the answer section when + the query resulted in a fetch. + + 21. [port] Look at STD_CINCLUDES after CINCLUDES during + compilation, so additional system include directories + can be searched but header files in the bind9 source + tree with conflicting names take precedence. This + avoids issues with installed versions of dnssafe and + openssl. + + 20. [func] Configuration file post-load validation of zones + failed if there were no zones. + + 19. [bug] dns_zone_notifyreceive() failed to unlock the zone + lock in certain error cases. + + 18. [bug] Use AC_TRY_LINK rather than AC_TRY_COMPILE in + configure.in to check for presence of in6addr_any. + + 17. [func] Do configuration file post-load validation of zones. + + 16. [bug] put quotes around key names on config file + output to avoid possible keyword clashes. + + 15. [func] Add dns_name_dupwithoffsets(). This function is + improves comparison performance for duped names. + + 14. [bug] free_rbtdb() could have 'put' unallocated memory in + an unlikely error path. + + 13. [bug] lib/dns/master.c and lib/dns/xfrin.c didn't ignore + out-of-zone data. + + 12. [bug] Fixed possible unitialized variable error. + + 11. [bug] axfr_rrstream_first() didn't check the result code of + db_rr_iterator_first(), possibly causing an assertion + to be triggered later. + + 10. [bug] A bug in the code which makes EDNS0 OPT records in + bin/named/client.c and lib/dns/resolver.c could + trigger an assertion. + + 9. [cleanup] replaced bit-setting code in confctx.c and replaced + repeated code with macro calls. + + 8. [bug] Shutdown of incoming zone transfer accessed + freed memory. + + 7. [cleanup] removed 'listen-on' from view statement. + + 6. [bug] quote RR names when generating config file to + prevent possible clash with config file keywords + (such as 'key'). + + 5. [func] syntax change to named.conf file: new ssu grant/deny + statements must now be enclosed by an 'update-policy' + block. + + 4. [port] bin/named/unix/os.c didn't compile on systems with + linux 2.3 kernel includes due to conflicts between + C library includes and the kernel includes. We now + get only what we need from , and + avoid pulling in other linux kernel .h files. + + 3. [bug] TKEYs go in the answer section of responses, not + the additional section. + + 2. [bug] Generating cryptographic randomness failed on + systems without /dev/random. + + 1. [bug] The installdirs rule in + lib/isc/unix/include/isc/Makefile.in had a typo which + prevented the isc directory from being created if it + didn't exist. + + --- 9.0.0b2 released --- + +# This tells Emacs to use hard tabs in this file. +# Local Variables: +# indent-tabs-mode: t +# End: diff --git a/contrib/bind9/COPYRIGHT b/contrib/bind9/COPYRIGHT new file mode 100644 index 000000000000..ee104781f533 --- /dev/null +++ b/contrib/bind9/COPYRIGHT @@ -0,0 +1,30 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 1996-2003 Internet Software Consortium. + +Permission to use, copy, modify, and distribute this software for any +purpose with or without fee is hereby granted, provided that the above +copyright notice and this permission notice appear in all copies. + +THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +PERFORMANCE OF THIS SOFTWARE. + +$Id: COPYRIGHT,v 1.6.2.2.8.2 2004/03/08 04:04:12 marka Exp $ + +Portions Copyright (C) 1996-2001 Nominum, Inc. + +Permission to use, copy, modify, and distribute this software for any +purpose with or without fee is hereby granted, provided that the above +copyright notice and this permission notice appear in all copies. + +THE SOFTWARE IS PROVIDED "AS IS" AND NOMINUM DISCLAIMS ALL WARRANTIES +WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL NOMINUM BE LIABLE FOR +ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT +OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. diff --git a/contrib/bind9/FAQ b/contrib/bind9/FAQ new file mode 100644 index 000000000000..25eb00ce38b8 --- /dev/null +++ b/contrib/bind9/FAQ @@ -0,0 +1,454 @@ + + + +Frequently Asked Questions about BIND 9 + + +Q: Why doesn't -u work on Linux 2.2.x when I build with --enable-threads? + +A: Linux threads do not fully implement the Posix threads (pthreads) standard. +In particular, setuid() operates only on the current thread, not the full +process. Because of this limitation, BIND 9 cannot use setuid() on Linux as it +can on all other supported platforms. setuid() cannot be called before +creating threads, since the server does not start listening on reserved ports +until after threads have started. + + In the 2.2.18 or 2.3.99-pre3 and newer kernels, the ability to preserve +capabilities across a setuid() call is present. This allows BIND 9 to call +setuid() early, while retaining the ability to bind reserved ports. This is +a Linux-specific hack. + + On a 2.2 kernel, BIND 9 does drop many root privileges, so it should be less +of a security risk than a root process that has not dropped privileges. + + If Linux threads ever work correctly, this restriction will go away. + + Configuring BIND9 with the --disable-threads option (the default) causes a +non-threaded version to be built, which will allow -u to be used. + + +Q: Why does named log the warning message "no TTL specified - using SOA +MINTTL instead"? + +A: Your zone file is illegal according to RFC1035. It must either +have a line like + + $TTL 86400 + +at the beginning, or the first record in it must have a TTL field, +like the "84600" in this example: + + example.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 ) + +Q: Why do I see 5 (or more) copies of named on Linux? + +A: Linux threads each show up as a process under ps. The approximate +number of threads running is n+4, where n is the number of CPUs. Note that +the amount of memory used is not cumulative; if each process is using 10M of +memory, only a total of 10M is used. + + +Q: Why does BIND 9 log "permission denied" errors accessing its +configuration files or zones on my Linux system even though it is running +as root? + +A: On Linux, BIND 9 drops most of its root privileges on startup. +This including the privilege to open files owned by other users. +Therefore, if the server is running as root, the configuration files +and zone files should also be owned by root. + + +Q: Why do I get errors like "dns_zone_load: zone foo/IN: loading master file +bar: ran out of space" + +A: This is often caused by TXT records with missing close quotes. Check that +all TXT records containing quoted strings have both open and close quotes. + + +Q: How do I produce a usable core file from a multithreaded named on Linux? + +A: If the Linux kernel is 2.4.7 or newer, multithreaded core dumps +are usable (that is, the correct thread is dumped). Otherwise, if using +a 2.2 kernel, apply the kernel patch found in contrib/linux/coredump-patch +and rebuild the kernel. This patch will cause multithreaded programs to dump +the correct thread. + + +Q: How do I restrict people from looking up the server version? + +A: Put a "version" option containing something other than the real +version in the "options" section of named.conf. Note doing this will +not prevent attacks and may impede people trying to diagnose problems +with your server. Also it is possible to "fingerprint" nameservers to +determine their version. + + +Q: How do I restrict only remote users from looking up the server +version? + +A: The following view statement will intercept lookups as the internal +view that holds the version information will be matched last. The +caveats of the previous answer still apply, of course. + + view "chaos" chaos { + match-clients { ; }; + allow-query { none; }; + zone "." { + type hint; + file "/dev/null"; // or any empty file + }; + }; + + +Q: What do "no source of entropy found" or "could not open entropy source foo" +mean? + +A: The server requires a source of entropy to perform certain operations, +mostly DNSSEC related. These messages indicate that you have no source +of entropy. On systems with /dev/random or an equivalent, it is used by +default. A source of entropy can also be defined using the random-device +option in named.conf. + + +Q: I installed BIND 9 and restarted named, but it's still BIND 8. Why? + +A: BIND 9 is installed under /usr/local by default. BIND 8 is often +installed under /usr. Check that the correct named is running. + + +Q: I'm trying to use TSIG to authenticate dynamic updates or zone +transfers. I'm sure I have the keys set up correctly, but the server +is rejecting the TSIG. Why? + +A: This may be a clock skew problem. Check that the the clocks on +the client and server are properly synchronized (e.g., using ntp). + + +Q: I'm trying to compile BIND 9, and "make" is failing due to files not +being found. Why? + +A: Using a parallel or distributed "make" to build BIND 9 is not +supported, and doesn't work. If you are using one of these, use +normal make or gmake instead. + + +Q: I have a BIND 9 master and a BIND 8.2.3 slave, and the master is +logging error messages like "notify to 10.0.0.1#53 failed: unexpected +end of input". What's wrong? + +A: This error message is caused by a known bug in BIND 8.2.3 and is fixed +in BIND 8.2.4. It can be safely ignored - the notify has been acted on by +the slave despite the error message. + + +Q: I keep getting log messages like the following. Why? + + Dec 4 23:47:59 client 10.0.0.1#1355: updating zone 'example.com/IN': + update failed: 'RRset exists (value dependent)' prerequisite not + satisfied (NXRRSET) + +A: DNS updates allow the update request to test to see if certain +conditions are met prior to proceeding with the update. The message +above is saying that conditions were not met and the update is not +proceeding. See doc/rfc/rfc2136.txt for more details on prerequisites. + + +Q: I keep getting log messages like the following. Why? + + Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied + +A: Someone is trying to update your DNS data using the RFC2136 Dynamic +Update protocol. Windows 2000 machines have a habit of sending dynamic +update requests to DNS servers without being specifically configured to +do so. If the update requests are coming from a Windows 2000 machine, +see +for information about how to turn them off. + + +Q: I see a log message like the following. Why? + + couldn't open pid file '/var/run/named.pid': Permission denied + +A: You are most likely running named as a non-root user, and that user +does not have permission to write in /var/run. The common ways of +fixing this are to create a /var/run/named directory owned by the named +user and set pid-file to "/var/run/named/named.pid", or set +pid-file to "named.pid", which will put the file in the directory +specified by the directory option (which, in this case, must be writable +by the named user). + + +Q: When I do a "dig . ns", many of the A records for the root +servers are missing. Why? + +A: This is normal and harmless. It is a somewhat confusing side effect +of the way BIND 9 does RFC2181 trust ranking and of the efforts BIND 9 +makes to avoid promoting glue into answers. + +When BIND 9 first starts up and primes its cache, it receives the root +server addresses as additional data in an authoritative response from +a root server, and these records are eligible for inclusion as +additional data in responses. Subsequently it receives a subset of +the root server addresses as additional data in a non-authoritative +(referral) response from a root server. This causes the addresses to +now be considered non-authoritative (glue) data, which is not eligible +for inclusion in responses. + +The server does have a complete set of root server addresses cached +at all times, it just may not include all of them as additional data, +depending on whether they were last received as answers or as glue. +You can always look up the addresses with explicit queries like +"dig a.root-servers.net A". + + +Q: Zone transfers from my BIND 9 master to my Windows 2000 slave +fail. Why? + +A: This may be caused by a bug in the Windows 2000 DNS server where +DNS messages larger than 16K are not handled properly. This can be +worked around by setting the option "transfer-format one-answer;". +Also check whether your zone contains domain names with embedded +spaces or other special characters, like "John\032Doe\213s\032Computer", +since such names have been known to cause Windows 2000 slaves to +incorrectly reject the zone. + + +Q: Why don't my zones reload when I do an "rndc reload" or SIGHUP? + +A: A zone can be updated either by editing zone files and reloading +the server or by dynamic update, but not both. If you have enabled +dynamic update for a zone using the "allow-update" option, you are not +supposed to edit the zone file by hand, and the server will not +attempt to reload it. + + +Q: I can query the nameserver from the nameserver but not from other +machines. Why? + +A: This is usually the result of the firewall configuration stopping +the queries and / or the replies. + + +Q: How can I make a server a slave for both an internal and +an external view at the same time? When I tried, both views +on the slave were transferred from the same view on the master. + +A: You will need to give the master and slave multiple IP addresses and +use those to make sure you reach the correct view on the other machine. + + e.g. + Master: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias) + internal: + match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; }; + notify-source 10.0.1.1; + transfer-source 10.0.1.1; + query-source address 10.0.1.1; + external: + match-clients { any; }; + recursion no; // don't offer recursion to the world + notify-source 10.0.1.2; + transfer-source 10.0.1.2; + query-source address 10.0.1.2; + + Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias) + internal: + match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; }; + notify-source 10.0.1.3; + transfer-source 10.0.1.3; + query-source address 10.0.1.3; + external: + match-clients { any; }; + recursion no; // don't offer recursion to the world + notify-source 10.0.1.4; + transfer-source 10.0.1.4; + query-source address 10.0.1.4; + + You put the external address on the alias so that all the other + dns clients on these boxes see the internal view by default. + +A: (BIND 9.3 and later) Use TSIG to select the appropriate view. + + Master 10.0.1.1: + key "external" { + algorithm hmac-md5; + secret "xxxxxxxx"; + }; + view "internal" { + match-clients { !key external; 10.0.1/24; }; + ... + }; + view "external" { + match-clients { key external; any; }; + server 10.0.0.2 { keys external; }; + recursion no; + ... + }; + + Slave 10.0.1.2: + key "external" { + algorithm hmac-md5; + secret "xxxxxxxx"; + }; + view "internal" { + match-clients { !key external; 10.0.1/24; }; + }; + view "external" { + match-clients { key external; any; }; + server 10.0.0.1 { keys external; }; + recursion no; + ... + }; + + +Q: I have Freebsd 4.x and "rndc-confgen -a" just sits there. + +A: /dev/random is not configured. Use rndcontrol(8) to tell the kernel +to use certain interrupts as a source of random events. You can make this +permanent by setting rand_irqs in /etc/rc.conf. + +e.g. + /etc/rc.conf + rand_irqs="3 14 15" + +See also http://people.freebsd.org/~dougb/randomness.html + + +Q: Why is named listening on UDP port other than 53? + +A: Named uses a system selected port to make queries of other nameservers. +This behaviour can be overridden by using query-source to lock down the +port and/or address. See also notify-source and transfer-source. + + +Q: I get error messages like "multiple RRs of singleton type" and +"CNAME and other data" when transferring a zone. What does this mean? + +A: These indicate a malformed master zone. You can identify the +exact records involved by transferring the zone using dig then +running named-checkzone on it. + + e.g. + dig axfr example.com @master-server > tmp + named-checkzone example.com tmp + + +Q: I get error messages like "named.conf:99: unexpected end of input" where +99 is the last line of named.conf. + +A: Some text editors (notepad and wordpad) fail to put a line termination +indication (e.g. CR/LF) on the last line of a text file. This can be fixed +by "adding" a blank line to the end of the file. Named expects to see EOF +immediately after EOL and treats text files where this is not met as truncated. + + +Q: I get warning messages like "zone example.com/IN: refresh: failure trying master +1.2.3.4#53: timed out". + +A: Check that you can make UDP queries from the slave to the master + + dig +norec example.com soa @1.2.3.4 + +A: You could be generating queries faster than the slave can cope with. Lower +the serial query rate. + + serial-query-rate 5; // default 20 + +Q: How do I share a dynamic zone between multiple views? + +A: You choose one view to be master and the second a slave and transfer +the zone between views. + + Master 10.0.1.1: + key "external" { + algorithm hmac-md5; + secret "xxxxxxxx"; + }; + + key "mykey" { + algorithm hmac-md5; + secret "yyyyyyyy"; + }; + + view "internal" { + match-clients { !external; 10.0.1/24; }; + server 10.0.1.1 { + /* Deliver notify messages to external view. */ + keys { external; }; + }; + zone "example.com" { + type master; + file "internal/example.db"; + allow-update { key mykey; }; + notify-also { 10.0.1.1; }; + }; + }; + + view "external" { + match-clients { external; any; }; + zone "example.com" { + type slave; + file "external/example.db"; + masters { 10.0.1.1; }; + transfer-source { 10.0.1.1; }; + // allow-update-forwarding { any; }; + // allow-notify { ... }; + }; + }; + +Q: I get a error message like "zone wireless.ietf56.ietf.org/IN: loading master +file primaries/wireless.ietf56.ietf.org: no owner". + +A: This error is produced when a line in the master file contains leading +white space (tab/space) but the is no current record owner name to inherit +the name from. Usually this is the result of putting white space before +a comment. Forgeting the "@" for the SOA record or indenting the master +file. + + +Q: Why are my logs in GMT (UTC). + +A: You are running chrooted (-t) and have not supplied local timzone +information in the chroot area. + + FreeBSD: /etc/localtime + Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo + OSF: /etc/zoneinfo/localtime + + See also tzset(3) and zic(8). + + +Q: I get the error message "named: capset failed: Operation not permitted" +when starting named. + +A: The capset module has not been loaded into the kernel. See insmod(8). + + +Q: I get "rndc: connect failed: connection refused" when I try to run + rndc. + +A: This is usually a configuration error. + + First ensure that named is running and no errors are being + reported at startup (/var/log/messages or equivalent). Running + "named -g " from a terminal can help at this + point. + + Secondly ensure that named is configured to use rndc either by + "rndc-confgen -a", rndc-confgen or manually. The Administators + Reference manual has details on how to do this. + + Old versions of rndc-confgen used localhost rather than 127.0.0.1 + in /etc/rndc.conf for the default server. Update /etc/rndc.conf + if necessary so that the default server listed in /etc/rndc.conf + matches the addresses used in named.conf. "localhost" has two + address (127.0.0.1 and ::1). + + If you use "rndc-confgen -a" and named is running with -t or -u + ensure that /etc/rndc.conf has the correct ownership and that + a copy is in the chroot area. You can do this by re-running + "rndc-confgen -a" with appropriate -t and -u arguements. + + +Q: I don't get RRSIG's returned when I use "dig +dnssec". + +A: You need to ensure DNSSEC is enabled (dnssec-enable yes;). diff --git a/contrib/bind9/Makefile.in b/contrib/bind9/Makefile.in new file mode 100644 index 000000000000..a2a06531b878 --- /dev/null +++ b/contrib/bind9/Makefile.in @@ -0,0 +1,59 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 1998-2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.41.2.2.2.2 2004/03/08 04:04:12 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_VERSION@ + +SUBDIRS = make lib bin doc @LIBBIND@ +TARGETS = + +@BIND9_MAKE_RULES@ + +distclean:: + @if [ "X@LIBBIND@" = "X" ] ; then \ + i=lib/bind; \ + echo "making $@ in `pwd`/$$i"; \ + (cd $$i; ${MAKE} ${MAKEDEFS} $@) || exit 1; \ + fi + +distclean:: + rm -f config.cache config.h config.log config.status TAGS + rm -f libtool isc-config.sh configure.lineno + rm -f util/conf.sh docutil/docbook2man-wrapper.sh + +# XXX we should clean libtool stuff too. Only do this after we add rules +# to make it. +maintainer-clean:: + rm -f configure + +installdirs: + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${bindir} + +install:: isc-config.sh installdirs + ${INSTALL_SCRIPT} isc-config.sh ${DESTDIR}${bindir} + +tags: + rm -f TAGS + find lib bin -name "*.[ch]" -print | @ETAGS@ - + +check: test + +test: + (cd bin/tests && ${MAKE} ${MAKEDEFS} test) diff --git a/contrib/bind9/README b/contrib/bind9/README new file mode 100644 index 000000000000..73715ce09de4 --- /dev/null +++ b/contrib/bind9/README @@ -0,0 +1,344 @@ +BIND 9 + + BIND version 9 is a major rewrite of nearly all aspects of the + underlying BIND architecture. Some of the important features of + BIND 9 are: + + - DNS Security + DNSSEC (signed zones) + TSIG (signed DNS requests) + + - IP version 6 + Answers DNS queries on IPv6 sockets + IPv6 resource records (AAAA) + Experimental IPv6 Resolver Library + + - DNS Protocol Enhancements + IXFR, DDNS, Notify, EDNS0 + Improved standards conformance + + - Views + One server process can provide multiple "views" of + the DNS namespace, e.g. an "inside" view to certain + clients, and an "outside" view to others. + + - Multiprocessor Support + + - Improved Portability Architecture + + + BIND version 9 development has been underwritten by the following + organizations: + + Sun Microsystems, Inc. + Hewlett Packard + Compaq Computer Corporation + IBM + Process Software Corporation + Silicon Graphics, Inc. + Network Associates, Inc. + U.S. Defense Information Systems Agency + USENIX Association + Stichting NLnet - NLnet Foundation + Nominum, Inc. + + +BIND 9.3.0 + + BIND 9.3.0 has a number of new features over 9.2, + including: + + DNSSEC is now DS based (RFC 3658). + See also RFC 3845, doc/draft/draft-ietf-dnsext-dnssec-*. + + DNSSEC lookaside validation. + + check-names is now implemented. + rrset-order in more complete. + + IPv4/IPv6 transition support, dual-stack-servers. + + IXFR deltas can now be generated when loading master files, + ixfr-from-differences. + + It is now possible to specify the size of a journal, max-journal-size. + + It is now possible to define a named set of master servers to be + used in masters clause, masters. + + The advertised EDNS UDP size can now be set, edns-udp-size. + + allow-v6-synthesis has been obsoleted. + + NOTE: + * Zones containing MD and MF will now be rejected. + * dig, nslookup name. now report "Not Implemented" as + NOTIMP rather than NOTIMPL. This will have impact on scripts + that are looking for NOTIMPL. + + libbind: corresponds to that from BIND 8.4.5. + +BIND 9.2.0 + + BIND 9.2.0 has a number of new features over 9.1, + including: + + - The size of the cache can now be limited using the + "max-cache-size" option. + + - The server can now automatically convert RFC1886-style + recursive lookup requests into RFC2874-style lookups, + when enabled using the new option "allow-v6-synthesis". + This allows stub resolvers that support AAAA records + but not A6 record chains or binary labels to perform + lookups in domains that make use of these IPv6 DNS + features. + + - Performance has been improved. + + - The man pages now use the more portable "man" macros + rather than the "mandoc" macros, and are installed + by "make install". + + - The named.conf parser has been completely rewritten. + It now supports "include" directives in more + places such as inside "view" statements, and it no + longer has any reserved words. + + - The "rndc status" command is now implemented. + + - rndc can now be configured automatically. + + - A BIND 8 compatible stub resolver library is now + included in lib/bind. + + - OpenSSL has been removed from the distribution. This + means that to use DNSSEC, OpenSSL must be installed and + the --with-openssl option must be supplied to configure. + This does not apply to the use of TSIG, which does not + require OpenSSL. + + - The source distribution now builds on Windows NT/2000. + See win32utils/readme1.txt and win32utils/win32-build.txt + for details. + + This distribution also includes a new lightweight stub + resolver library and associated resolver daemon that fully + support forward and reverse lookups of both IPv4 and IPv6 + addresses. This library is considered experimental and + is not a complete replacement for the BIND 8 resolver library. + Applications that use the BIND 8 res_* functions to perform + DNS lookups or dynamic updates still need to be linked against + the BIND 8 libraries. For DNS lookups, they can also use the + new "getrrsetbyname()" API. + + BIND 9.2 is capable of acting as an authoritative server + for DNSSEC secured zones. This functionality is believed to + be stable and complete except for lacking support for + verifications involving wildcard records in secure zones. + + When acting as a caching server, BIND 9.2 can be configured + to perform DNSSEC secure resolution on behalf of its clients. + This part of the DNSSEC implementation is still considered + experimental. For detailed information about the state of the + DNSSEC implementation, see the file doc/misc/dnssec. + + There are a few known bugs: + + On some systems, IPv6 and IPv4 sockets interact in + unexpected ways. For details, see doc/misc/ipv6. + To reduce the impact of these problems, the server + no longer listens for requests on IPv6 addresses + by default. If you need to accept DNS queries over + IPv6, you must specify "listen-on-v6 { any; };" + in the named.conf options statement. + + FreeBSD prior to 4.2 (and 4.2 if running as non-root) + and OpenBSD prior to 2.8 log messages like + "fcntl(8, F_SETFL, 4): Inappropriate ioctl for device". + This is due to a bug in "/dev/random" and impacts the + server's DNSSEC support. + + OS X 10.1.4 (Darwin 5.4), OS X 10.1.5 (Darwin 5.5) and + OS X 10.2 (Darwin 6.0) reports errors like + "fcntl(3, F_SETFL, 4): Operation not supported by device". + This is due to a bug in "/dev/random" and impacts the + server's DNSSEC support. + + --with-libtool does not work on AIX. + + A bug in the Windows 2000 DNS server can cause zone transfers + from a BIND 9 server to a W2K server to fail. For details, + see the "Zone Transfers" section in doc/misc/migration. + + For a detailed list of user-visible changes from + previous releases, see the CHANGES file. + + +Building + + BIND 9 currently requires a UNIX system with an ANSI C compiler, + basic POSIX support, and a 64 bit integer type. + + We've had successful builds and tests on the following systems: + + COMPAQ Tru64 UNIX 5.1B + FreeBSD 4.10, 5.2.1 + HP-UX 11.11 + NetBSD 1.5 + Slackware Linux 8.1 + Solaris 8, 9, 9 (x86) + Windows NT/2000/XP/2003 + + Additionally, we have unverified reports of success building + previous versions of BIND 9 from users of the following systems: + + AIX 5L + SuSE Linux 7.0 + Slackware Linux 7.x, 8.0 + Red Hat Linux 7.1 + Debian GNU/Linux 2.2 and 3.0 + Mandrake 8.1 + OpenBSD 2.6, 2.8, 2.9 + UnixWare 7.1.1 + HP-UX 10.20 + BSD/OS 4.2 + Mac OS X 10.1 + + To build, just + + ./configure + make + + Do not use a parallel "make". + + Several environment variables that can be set before running + configure will affect compilation: + + CC + The C compiler to use. configure tries to figure + out the right one for supported systems. + + CFLAGS + C compiler flags. Defaults to include -g and/or -O2 + as supported by the compiler. + + STD_CINCLUDES + System header file directories. Can be used to specify + where add-on thread or IPv6 support is, for example. + Defaults to empty string. + + STD_CDEFINES + Any additional preprocessor symbols you want defined. + Defaults to empty string. + + Possible settings: + Change the default syslog facility of named/lwresd. + -DISC_FACILITY=LOG_LOCAL0 + Enable DNSSEC signature chasing support in dig. + -DDIG_SIGCHASE=1 (sets -DDIG_SIGCHASE_TD=1 and + -DDIG_SIGCHASE_BU=1) + + LDFLAGS + Linker flags. Defaults to empty string. + + To build shared libraries, specify "--with-libtool" on the + configure command line. + + For the server to support DNSSEC, you need to build it + with crypto support. You must have OpenSSL 0.9.5a + or newer installed and specify "--with-openssl" on the + configure command line. If OpenSSL is installed under + a nonstandard prefix, you can tell configure where to + look for it using "--with-openssl=/prefix". + + To build libbind (the BIND 8 resolver library), specify + "--enable-libbind" on the configure command line. + + On some platforms, BIND 9 can be built with multithreading + support, allowing it to take advantage of multiple CPUs. + You can specify whether to build a multithreaded BIND 9 + by specifying "--enable-threads" or "--disable-threads" + on the configure command line. The default is operating + system dependent. + + If your operating system has integrated support for IPv6, it + will be used automatically. If you have installed KAME IPv6 + separately, use "--with-kame[=PATH]" to specify its location. + + "make install" will install "named" and the various BIND 9 libraries. + By default, installation is into /usr/local, but this can be changed + with the "--prefix" option when running "configure". + + You may specify the option "--sysconfdir" to set the directory + where configuration files like "named.conf" go by default, + and "--localstatedir" to set the default parent directory + of "run/named.pid". For backwards compatibility with BIND 8, + --sysconfdir defaults to "/etc" and --localstatedir defaults to + "/var" if no --prefix option is given. If there is a --prefix + option, sysconfdir defaults to "$prefix/etc" and localstatedir + defaults to "$prefix/var". + + To see additional configure options, run "configure --help". + Note that the help message does not reflect the BIND 8 + compatibility defaults for sysconfdir and localstatedir. + + If you're planning on making changes to the BIND 9 source, you + should also "make depend". If you're using Emacs, you might find + "make tags" helpful. + + If you need to re-run configure please run "make distclean" first. + This will ensure that all the option changes take. + + Building with gcc is not supported, unless gcc is the vendor's usual + compiler (e.g. the various BSD systems, Linux). + + * gcc-3.2.1 and gcc-3.1.1 is known to cause problems with solaris-x86. + * gcc prior to gcc-3.2.3 ultrasparc generates incorrect code at -02. + + A limited test suite can be run with "make test". Many of + the tests require you to configure a set of virtual IP addresses + on your system, and some require Perl; see bin/tests/system/README + for details. + + +Documentation + + The BIND 9 Administrator Reference Manual is included with the + source distribution in DocBook XML and HTML format, in the + doc/arm directory. + + Some of the programs in the BIND 9 distribution have man pages + in their directories. In particular, the command line + options of "named" are documented in /bin/named/named.8. + There is now also a set of man pages for the lwres library. + + If you are upgrading from BIND 8, please read the migration + notes in doc/misc/migration. If you are upgrading from + BIND 4, read doc/misc/migration-4to9. + + Frequently asked questions and their answers can be found in + FAQ. + + +Bug Reports and Mailing Lists + + Bugs reports should be sent to + + bind9-bugs@isc.org + + To join the BIND Users mailing list, send mail to + + bind-users-request@isc.org + + archives of which can be found via + + http://www.isc.org/ops/lists/ + + If you're planning on making changes to the BIND 9 source + code, you might want to join the BIND Workers mailing list. + Send mail to + + bind-workers-request@isc.org + + diff --git a/contrib/bind9/acconfig.h b/contrib/bind9/acconfig.h new file mode 100644 index 000000000000..0eacd065ad3e --- /dev/null +++ b/contrib/bind9/acconfig.h @@ -0,0 +1,141 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: acconfig.h,v 1.35.2.4.2.8 2004/05/21 08:24:04 marka Exp $ */ + +/*** + *** This file is not to be included by any public header files, because + *** it does not get installed. + ***/ +@TOP@ + +/* define to `int' if doesn't define. */ +#undef ssize_t + +/* define on DEC OSF to enable 4.4BSD style sa_len support */ +#undef _SOCKADDR_LEN + +/* define if your system needs pthread_init() before using pthreads */ +#undef NEED_PTHREAD_INIT + +/* define if your system has sigwait() */ +#undef HAVE_SIGWAIT + +/* define if sigwait() is the UnixWare flavor */ +#undef HAVE_UNIXWARE_SIGWAIT + +/* define on Solaris to get sigwait() to work using pthreads semantics */ +#undef _POSIX_PTHREAD_SEMANTICS + +/* define if LinuxThreads is in use */ +#undef HAVE_LINUXTHREADS + +/* define if sysconf() is available */ +#undef HAVE_SYSCONF + +/* define if sysctlbyname() is available */ +#undef HAVE_SYSCTLBYNAME + +/* define if catgets() is available */ +#undef HAVE_CATGETS + +/* define if getifaddrs() exists */ +#undef HAVE_GETIFADDRS + +/* define if you have the NET_RT_IFLIST sysctl variable and sys/sysctl.h */ +#undef HAVE_IFLIST_SYSCTL + +/* define if chroot() is available */ +#undef HAVE_CHROOT + +/* define if tzset() is available */ +#undef HAVE_TZSET + +/* define if struct addrinfo exists */ +#undef HAVE_ADDRINFO + +/* define if getaddrinfo() exists */ +#undef HAVE_GETADDRINFO + +/* define if gai_strerror() exists */ +#undef HAVE_GAISTRERROR + +/* define if arc4random() exists */ +#undef HAVE_ARC4RANDOM + +/* define if pthread_setconcurrency() should be called to tell the + * OS how many threads we might want to run. + */ +#undef CALL_PTHREAD_SETCONCURRENCY + +/* define if IPv6 is not disabled */ +#undef WANT_IPV6 + +/* define if flockfile() is available */ +#undef HAVE_FLOCKFILE + +/* define if getc_unlocked() is available */ +#undef HAVE_GETCUNLOCKED + +/* Shut up warnings about sputaux in stdio.h on BSD/OS pre-4.1 */ +#undef SHUTUP_SPUTAUX +#ifdef SHUTUP_SPUTAUX +struct __sFILE; +extern __inline int __sputaux(int _c, struct __sFILE *_p); +#endif + +/* Shut up warnings about missing sigwait prototype on BSD/OS 4.0* */ +#undef SHUTUP_SIGWAIT +#ifdef SHUTUP_SIGWAIT +int sigwait(const unsigned int *set, int *sig); +#endif + +/* Shut up warnings from gcc -Wcast-qual on BSD/OS 4.1. */ +#undef SHUTUP_STDARG_CAST +#if defined(SHUTUP_STDARG_CAST) && defined(__GNUC__) +#include /* Grr. Must be included *every time*. */ +/* + * The silly continuation line is to keep configure from + * commenting out the #undef. + */ +#undef \ + va_start +#define va_start(ap, last) \ + do { \ + union { const void *konst; long *var; } _u; \ + _u.konst = &(last); \ + ap = (va_list)(_u.var + __va_words(__typeof(last))); \ + } while (0) +#endif /* SHUTUP_STDARG_CAST && __GNUC__ */ + +/* define if the system has a random number generating device */ +#undef PATH_RANDOMDEV + +/* define if pthread_attr_getstacksize() is available */ +#undef HAVE_PTHREAD_ATTR_GETSTACKSIZE + +/* define if pthread_attr_setstacksize() is available */ +#undef HAVE_PTHREAD_ATTR_SETSTACKSIZE + +/* define if you have strerror in the C library. */ +#undef HAVE_STRERROR + +/* Define if you are running under Compaq TruCluster.. */ +#undef HAVE_TRUCLUSTER + +/* Define if OpenSSL includes DSA support */ +#undef HAVE_OPENSSL_DSA diff --git a/contrib/bind9/bin/Makefile.in b/contrib/bind9/bin/Makefile.in new file mode 100644 index 000000000000..d8261d7b4c2a --- /dev/null +++ b/contrib/bind9/bin/Makefile.in @@ -0,0 +1,25 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 1998-2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.22.208.1 2004/03/06 10:21:10 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +SUBDIRS = named rndc dig dnssec tests nsupdate check +TARGETS = + +@BIND9_MAKE_RULES@ diff --git a/contrib/bind9/bin/check/Makefile.in b/contrib/bind9/bin/check/Makefile.in new file mode 100644 index 000000000000..5fdf4637afe6 --- /dev/null +++ b/contrib/bind9/bin/check/Makefile.in @@ -0,0 +1,95 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000-2003 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.15.2.3.8.6 2004/07/20 07:01:48 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_VERSION@ + +@BIND9_MAKE_INCLUDES@ + +CINCLUDES = ${BIND9_INCLUDES} ${DNS_INCLUDES} ${ISCCFG_INCLUDES} \ + ${ISC_INCLUDES} + +CDEFINES = -DNAMED_CONFFILE=\"${sysconfdir}/named.conf\" +CWARNINGS = + +DNSLIBS = ../../lib/dns/libdns.@A@ @DNS_CRYPTO_LIBS@ +ISCCFGLIBS = ../../lib/isccfg/libisccfg.@A@ +ISCLIBS = ../../lib/isc/libisc.@A@ +BIND9LIBS = ../../lib/bind9/libbind9.@A@ + +DNSDEPLIBS = ../../lib/dns/libdns.@A@ +ISCCFGDEPLIBS = ../../lib/isccfg/libisccfg.@A@ +ISCDEPLIBS = ../../lib/isc/libisc.@A@ +BIND9DEPLIBS = ../../lib/bind9/libbind9.@A@ + +LIBS = @LIBS@ + +SUBDIRS = + +# Alphabetically +TARGETS = named-checkconf@EXEEXT@ named-checkzone@EXEEXT@ + +# Alphabetically +SRCS = named-checkconf.c named-checkzone.c check-tool.c + +MANPAGES = named-checkconf.8 named-checkzone.8 + +HTMLPAGES = named-checkconf.html named-checkzone.html + +MANOBJS = ${MANPAGES} ${HTMLPAGES} + +@BIND9_MAKE_RULES@ + +named-checkconf.@O@: named-checkconf.c + ${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} \ + -DVERSION=\"${VERSION}\" \ + -c ${srcdir}/named-checkconf.c + +named-checkzone.@O@: named-checkzone.c + ${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} \ + -DVERSION=\"${VERSION}\" \ + -c ${srcdir}/named-checkzone.c + +named-checkconf@EXEEXT@: named-checkconf.@O@ check-tool.@O@ ${ISCDEPLIBS} \ + ${ISCCFGDEPLIBS} ${BIND9DEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ + named-checkconf.@O@ check-tool.@O@ ${BIND9LIBS} ${ISCCFGLIBS} \ + ${DNSLIBS} ${ISCLIBS} ${LIBS} + +named-checkzone@EXEEXT@: named-checkzone.@O@ check-tool.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ + named-checkzone.@O@ check-tool.@O@ ${DNSLIBS} ${ISCLIBS} ${LIBS} + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f ${MANOBJS} + +installdirs: + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${sbindir} + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man8 + +install:: named-checkconf@EXEEXT@ named-checkzone@EXEEXT@ installdirs + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} named-checkconf@EXEEXT@ ${DESTDIR}${sbindir} + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} named-checkzone@EXEEXT@ ${DESTDIR}${sbindir} + for m in ${MANPAGES}; do ${INSTALL_DATA} ${srcdir}/$$m ${DESTDIR}${mandir}/man8; done + +clean distclean:: + rm -f ${TARGETS} r1.htm diff --git a/contrib/bind9/bin/check/check-tool.c b/contrib/bind9/bin/check/check-tool.c new file mode 100644 index 000000000000..cefee82cfe27 --- /dev/null +++ b/contrib/bind9/bin/check/check-tool.c @@ -0,0 +1,159 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: check-tool.c,v 1.4.12.5 2004/03/08 04:04:13 marka Exp $ */ + +#include + +#include +#include + +#include "check-tool.h" +#include + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#define CHECK(r) \ + do { \ + result = (r); \ + if (result != ISC_R_SUCCESS) \ + goto cleanup; \ + } while (0) + +static const char *dbtype[] = { "rbt" }; + +int debug = 0; +isc_boolean_t nomerge = ISC_TRUE; +unsigned int zone_options = DNS_ZONEOPT_CHECKNS|DNS_ZONEOPT_MANYERRORS; + +isc_result_t +setup_logging(isc_mem_t *mctx, isc_log_t **logp) { + isc_logdestination_t destination; + isc_logconfig_t *logconfig = NULL; + isc_log_t *log = NULL; + + RUNTIME_CHECK(isc_log_create(mctx, &log, &logconfig) == ISC_R_SUCCESS); + isc_log_setcontext(log); + + destination.file.stream = stdout; + destination.file.name = NULL; + destination.file.versions = ISC_LOG_ROLLNEVER; + destination.file.maximum_size = 0; + RUNTIME_CHECK(isc_log_createchannel(logconfig, "stderr", + ISC_LOG_TOFILEDESC, + ISC_LOG_DYNAMIC, + &destination, 0) == ISC_R_SUCCESS); + RUNTIME_CHECK(isc_log_usechannel(logconfig, "stderr", + NULL, NULL) == ISC_R_SUCCESS); + + *logp = log; + return (ISC_R_SUCCESS); +} + +isc_result_t +load_zone(isc_mem_t *mctx, const char *zonename, const char *filename, + const char *classname, dns_zone_t **zonep) +{ + isc_result_t result; + dns_rdataclass_t rdclass; + isc_textregion_t region; + isc_buffer_t buffer; + dns_fixedname_t fixorigin; + dns_name_t *origin; + dns_zone_t *zone = NULL; + + REQUIRE(zonep == NULL || *zonep == NULL); + + if (debug) + fprintf(stderr, "loading \"%s\" from \"%s\" class \"%s\"\n", + zonename, filename, classname); + + CHECK(dns_zone_create(&zone, mctx)); + + dns_zone_settype(zone, dns_zone_master); + + isc_buffer_init(&buffer, zonename, strlen(zonename)); + isc_buffer_add(&buffer, strlen(zonename)); + dns_fixedname_init(&fixorigin); + origin = dns_fixedname_name(&fixorigin); + CHECK(dns_name_fromtext(origin, &buffer, dns_rootname, + ISC_FALSE, NULL)); + CHECK(dns_zone_setorigin(zone, origin)); + CHECK(dns_zone_setdbtype(zone, 1, (const char * const *) dbtype)); + CHECK(dns_zone_setfile(zone, filename)); + + DE_CONST(classname, region.base); + region.length = strlen(classname); + CHECK(dns_rdataclass_fromtext(&rdclass, ®ion)); + + dns_zone_setclass(zone, rdclass); + dns_zone_setoption(zone, zone_options, ISC_TRUE); + dns_zone_setoption(zone, DNS_ZONEOPT_NOMERGE, nomerge); + + CHECK(dns_zone_load(zone)); + if (zonep != NULL){ + *zonep = zone; + zone = NULL; + } + + cleanup: + if (zone != NULL) + dns_zone_detach(&zone); + return (result); +} + +isc_result_t +dump_zone(const char *zonename, dns_zone_t *zone, const char *filename) +{ + isc_result_t result; + FILE *output = stdout; + + if (debug) { + if (filename != NULL) + fprintf(stderr, "dumping \"%s\" to \"%s\"\n", + zonename, filename); + else + fprintf(stderr, "dumping \"%s\"\n", zonename); + } + + if (filename != NULL) { + result = isc_stdio_open(filename, "w+", &output); + + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not open output " + "file \"%s\" for writing\n", filename); + return (ISC_R_FAILURE); + } + } + + result = dns_zone_fulldumptostream(zone, output); + + if (filename != NULL) + (void)isc_stdio_close(output); + + return (result); +} diff --git a/contrib/bind9/bin/check/check-tool.h b/contrib/bind9/bin/check/check-tool.h new file mode 100644 index 000000000000..105cd258ca3d --- /dev/null +++ b/contrib/bind9/bin/check/check-tool.h @@ -0,0 +1,46 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: check-tool.h,v 1.2.12.5 2004/03/08 04:04:13 marka Exp $ */ + +#ifndef CHECK_TOOL_H +#define CHECK_TOOL_H + +#include + +#include +#include + +ISC_LANG_BEGINDECLS + +isc_result_t +setup_logging(isc_mem_t *mctx, isc_log_t **logp); + +isc_result_t +load_zone(isc_mem_t *mctx, const char *zonename, const char *filename, + const char *classname, dns_zone_t **zonep); + +isc_result_t +dump_zone(const char *zonename, dns_zone_t *zone, const char *filename); + +extern int debug; +extern isc_boolean_t nomerge; +extern unsigned int zone_options; + +ISC_LANG_ENDDECLS + +#endif diff --git a/contrib/bind9/bin/check/named-checkconf.8 b/contrib/bind9/bin/check/named-checkconf.8 new file mode 100644 index 000000000000..25dbdd86ff15 --- /dev/null +++ b/contrib/bind9/bin/check/named-checkconf.8 @@ -0,0 +1,59 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2002 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: named-checkconf.8,v 1.11.12.4 2004/06/03 05:35:41 marka Exp $ +.\" +.TH "NAMED-CHECKCONF" "8" "June 14, 2000" "BIND9" "" +.SH NAME +named-checkconf \- named configuration file syntax checking tool +.SH SYNOPSIS +.sp +\fBnamed-checkconf\fR [ \fB-v\fR ] [ \fB-j\fR ] [ \fB-t \fIdirectory\fB\fR ] \fBfilename\fR [ \fB-z\fR ] +.SH "DESCRIPTION" +.PP +\fBnamed-checkconf\fR checks the syntax, but not +the semantics, of a named configuration file. +.SH "OPTIONS" +.TP +\fB-t \fIdirectory\fB\fR +chroot to \fIdirectory\fR so that include +directives in the configuration file are processed as if +run by a similarly chrooted named. +.TP +\fB-v\fR +Print the version of the \fBnamed-checkconf\fR +program and exit. +.TP +\fB-z\fR +Perform a check load the master zonefiles found in +\fInamed.conf\fR. +.TP +\fB-j\fR +When loading a zonefile read the journal if it exists. +.TP +\fBfilename\fR +The name of the configuration file to be checked. If not +specified, it defaults to \fI/etc/named.conf\fR. +.SH "RETURN VALUES" +.PP +\fBnamed-checkconf\fR returns an exit status of 1 if +errors were detected and 0 otherwise. +.SH "SEE ALSO" +.PP +\fBnamed\fR(8), +\fIBIND 9 Administrator Reference Manual\fR. +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/check/named-checkconf.c b/contrib/bind9/bin/check/named-checkconf.c new file mode 100644 index 000000000000..88a7299b0168 --- /dev/null +++ b/contrib/bind9/bin/check/named-checkconf.c @@ -0,0 +1,286 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: named-checkconf.c,v 1.12.12.7 2004/03/08 09:04:14 marka Exp $ */ + +#include + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include + +#include +#include + +#include "check-tool.h" + +isc_log_t *logc = NULL; + +#define CHECK(r)\ + do { \ + result = (r); \ + if (result != ISC_R_SUCCESS) \ + goto cleanup; \ + } while (0) + +static void +usage(void) { + fprintf(stderr, "usage: named-checkconf [-j] [-v] [-z] [-t directory] " + "[named.conf]\n"); + exit(1); +} + +static isc_result_t +directory_callback(const char *clausename, cfg_obj_t *obj, void *arg) { + isc_result_t result; + char *directory; + + REQUIRE(strcasecmp("directory", clausename) == 0); + + UNUSED(arg); + UNUSED(clausename); + + /* + * Change directory. + */ + directory = cfg_obj_asstring(obj); + result = isc_dir_chdir(directory); + if (result != ISC_R_SUCCESS) { + cfg_obj_log(obj, logc, ISC_LOG_ERROR, + "change directory to '%s' failed: %s\n", + directory, isc_result_totext(result)); + return (result); + } + + return (ISC_R_SUCCESS); +} + +static isc_result_t +configure_zone(const char *vclass, const char *view, cfg_obj_t *zconfig, + isc_mem_t *mctx) +{ + isc_result_t result; + const char *zclass; + const char *zname; + const char *zfile; + cfg_obj_t *zoptions = NULL; + cfg_obj_t *classobj = NULL; + cfg_obj_t *typeobj = NULL; + cfg_obj_t *fileobj = NULL; + cfg_obj_t *dbobj = NULL; + + zname = cfg_obj_asstring(cfg_tuple_get(zconfig, "name")); + classobj = cfg_tuple_get(zconfig, "class"); + if (!cfg_obj_isstring(classobj)) + zclass = vclass; + else + zclass = cfg_obj_asstring(classobj); + zoptions = cfg_tuple_get(zconfig, "options"); + cfg_map_get(zoptions, "type", &typeobj); + if (typeobj == NULL) + return (ISC_R_FAILURE); + if (strcasecmp(cfg_obj_asstring(typeobj), "master") != 0) + return (ISC_R_SUCCESS); + cfg_map_get(zoptions, "database", &dbobj); + if (dbobj != NULL) + return (ISC_R_SUCCESS); + cfg_map_get(zoptions, "file", &fileobj); + if (fileobj == NULL) + return (ISC_R_FAILURE); + zfile = cfg_obj_asstring(fileobj); + result = load_zone(mctx, zname, zfile, zclass, NULL); + if (result != ISC_R_SUCCESS) + fprintf(stderr, "%s/%s/%s: %s\n", view, zname, zclass, + dns_result_totext(result)); + return(result); +} + +static isc_result_t +configure_view(const char *vclass, const char *view, cfg_obj_t *config, + cfg_obj_t *vconfig, isc_mem_t *mctx) +{ + cfg_listelt_t *element; + cfg_obj_t *voptions; + cfg_obj_t *zonelist; + isc_result_t result = ISC_R_SUCCESS; + isc_result_t tresult; + + voptions = NULL; + if (vconfig != NULL) + voptions = cfg_tuple_get(vconfig, "options"); + + zonelist = NULL; + if (voptions != NULL) + (void)cfg_map_get(voptions, "zone", &zonelist); + else + (void)cfg_map_get(config, "zone", &zonelist); + + for (element = cfg_list_first(zonelist); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *zconfig = cfg_listelt_value(element); + tresult = configure_zone(vclass, view, zconfig, mctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; + } + return (result); +} + + +static isc_result_t +load_zones_fromconfig(cfg_obj_t *config, isc_mem_t *mctx) { + cfg_listelt_t *element; + cfg_obj_t *classobj; + cfg_obj_t *views; + cfg_obj_t *vconfig; + const char *vclass; + isc_result_t result = ISC_R_SUCCESS; + isc_result_t tresult; + + views = NULL; + + (void)cfg_map_get(config, "view", &views); + for (element = cfg_list_first(views); + element != NULL; + element = cfg_list_next(element)) + { + const char *vname; + + vclass = "IN"; + vconfig = cfg_listelt_value(element); + if (vconfig != NULL) { + classobj = cfg_tuple_get(vconfig, "class"); + if (cfg_obj_isstring(classobj)) + vclass = cfg_obj_asstring(classobj); + } + vname = cfg_obj_asstring(cfg_tuple_get(vconfig, "name")); + tresult = configure_view(vclass, vname, config, vconfig, mctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; + } + + if (views == NULL) { + tresult = configure_view("IN", "_default", config, NULL, mctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; + } + return (result); +} + +int +main(int argc, char **argv) { + int c; + cfg_parser_t *parser = NULL; + cfg_obj_t *config = NULL; + const char *conffile = NULL; + isc_mem_t *mctx = NULL; + isc_result_t result; + int exit_status = 0; + isc_boolean_t load_zones = ISC_FALSE; + + while ((c = isc_commandline_parse(argc, argv, "djt:vz")) != EOF) { + switch (c) { + case 'd': + debug++; + break; + + case 'j': + nomerge = ISC_FALSE; + break; + + case 't': + result = isc_dir_chroot(isc_commandline_argument); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "isc_dir_chroot: %s\n", + isc_result_totext(result)); + exit(1); + } + result = isc_dir_chdir("/"); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "isc_dir_chdir: %s\n", + isc_result_totext(result)); + exit(1); + } + break; + + case 'v': + printf(VERSION "\n"); + exit(0); + + case 'z': + load_zones = ISC_TRUE; + break; + + default: + usage(); + } + } + + if (argv[isc_commandline_index] != NULL) + conffile = argv[isc_commandline_index]; + if (conffile == NULL || conffile[0] == '\0') + conffile = NAMED_CONFFILE; + + RUNTIME_CHECK(isc_mem_create(0, 0, &mctx) == ISC_R_SUCCESS); + + RUNTIME_CHECK(setup_logging(mctx, &logc) == ISC_R_SUCCESS); + + dns_result_register(); + + RUNTIME_CHECK(cfg_parser_create(mctx, logc, &parser) == ISC_R_SUCCESS); + + cfg_parser_setcallback(parser, directory_callback, NULL); + + if (cfg_parse_file(parser, conffile, &cfg_type_namedconf, &config) != + ISC_R_SUCCESS) + exit(1); + + result = bind9_check_namedconf(config, logc, mctx); + if (result != ISC_R_SUCCESS) + exit_status = 1; + + if (result == ISC_R_SUCCESS && load_zones) { + dns_log_init(logc); + dns_log_setcontext(logc); + result = load_zones_fromconfig(config, mctx); + if (result != ISC_R_SUCCESS) + exit_status = 1; + } + + cfg_obj_destroy(parser, &config); + + cfg_parser_destroy(&parser); + + isc_log_destroy(&logc); + + isc_mem_destroy(&mctx); + + return (exit_status); +} diff --git a/contrib/bind9/bin/check/named-checkconf.docbook b/contrib/bind9/bin/check/named-checkconf.docbook new file mode 100644 index 000000000000..d1336cfa537b --- /dev/null +++ b/contrib/bind9/bin/check/named-checkconf.docbook @@ -0,0 +1,146 @@ + + + + + + + + June 14, 2000 + + + + named-checkconf + 8 + BIND9 + + + + named-checkconf + named configuration file syntax checking tool + + + + + named-checkconf + + + + filename + + + + + + DESCRIPTION + + named-checkconf checks the syntax, but not + the semantics, of a named configuration file. + + + + + OPTIONS + + + + -t directory + + + chroot to directory so that include + directives in the configuration file are processed as if + run by a similarly chrooted named. + + + + + + -v + + + Print the version of the named-checkconf + program and exit. + + + + + + -z + + + Perform a check load the master zonefiles found in + named.conf. + + + + + + -j + + + When loading a zonefile read the journal if it exists. + + + + + + filename + + + The name of the configuration file to be checked. If not + specified, it defaults to /etc/named.conf. + + + + + + + + + + RETURN VALUES + + named-checkconf returns an exit status of 1 if + errors were detected and 0 otherwise. + + + + SEE ALSO + + + named + 8 + , + BIND 9 Administrator Reference Manual. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + + diff --git a/contrib/bind9/bin/check/named-checkconf.html b/contrib/bind9/bin/check/named-checkconf.html new file mode 100644 index 000000000000..8d5f38e99c51 --- /dev/null +++ b/contrib/bind9/bin/check/named-checkconf.html @@ -0,0 +1,216 @@ + + + + + +named-checkconf

named-checkconf

Name

named-checkconf -- named configuration file syntax checking tool

Synopsis

named-checkconf [-v] [-j] [-t directory] {filename} [-z]

DESCRIPTION

named-checkconf checks the syntax, but not + the semantics, of a named configuration file. +

OPTIONS

-t directory

chroot to directory so that include + directives in the configuration file are processed as if + run by a similarly chrooted named. +

-v

Print the version of the named-checkconf + program and exit. +

-z

Perform a check load the master zonefiles found in + named.conf. +

-j

When loading a zonefile read the journal if it exists. +

filename

The name of the configuration file to be checked. If not + specified, it defaults to /etc/named.conf. +

RETURN VALUES

named-checkconf returns an exit status of 1 if + errors were detected and 0 otherwise. +

SEE ALSO

named(8), + BIND 9 Administrator Reference Manual. +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/check/named-checkzone.8 b/contrib/bind9/bin/check/named-checkzone.8 new file mode 100644 index 000000000000..efa600c8e087 --- /dev/null +++ b/contrib/bind9/bin/check/named-checkzone.8 @@ -0,0 +1,94 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2002 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: named-checkzone.8,v 1.11.2.1.8.4 2004/06/03 05:35:42 marka Exp $ +.\" +.TH "NAMED-CHECKZONE" "8" "June 13, 2000" "BIND9" "" +.SH NAME +named-checkzone \- zone file validity checking tool +.SH SYNOPSIS +.sp +\fBnamed-checkzone\fR [ \fB-d\fR ] [ \fB-j\fR ] [ \fB-q\fR ] [ \fB-v\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-k \fImode\fB\fR ] [ \fB-n \fImode\fB\fR ] [ \fB-o \fIfilename\fB\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-w \fIdirectory\fB\fR ] [ \fB-D\fR ] \fBzonename\fR \fBfilename\fR +.SH "DESCRIPTION" +.PP +\fBnamed-checkzone\fR checks the syntax and integrity of +a zone file. It performs the same checks as \fBnamed\fR +does when loading a zone. This makes +\fBnamed-checkzone\fR useful for checking zone +files before configuring them into a name server. +.SH "OPTIONS" +.TP +\fB-d\fR +Enable debugging. +.TP +\fB-q\fR +Quiet mode - exit code only. +.TP +\fB-v\fR +Print the version of the \fBnamed-checkzone\fR +program and exit. +.TP +\fB-j\fR +When loading the zone file read the journal if it exists. +.TP +\fB-c \fIclass\fB\fR +Specify the class of the zone. If not specified "IN" is assumed. +.TP +\fB-k \fImode\fB\fR +Perform \fB"check-name"\fR checks with the specified failure mode. +Possible modes are \fB"fail"\fR, +\fB"warn"\fR (default) and +\fB"ignore"\fR. +.TP +\fB-n \fImode\fB\fR +Specify whether NS records should be checked to see if they +are addresses. Possible modes are \fB"fail"\fR, +\fB"warn"\fR (default) and +\fB"ignore"\fR. +.TP +\fB-o \fIfilename\fB\fR +Write zone output to \fIdirectory\fR. +.TP +\fB-t \fIdirectory\fB\fR +chroot to \fIdirectory\fR so that include +directives in the configuration file are processed as if +run by a similarly chrooted named. +.TP +\fB-w \fIdirectory\fB\fR +chdir to \fIdirectory\fR so that relative +filenames in master file $INCLUDE directives work. This +is similar to the directory clause in +\fInamed.conf\fR. +.TP +\fB-D\fR +Dump zone file in canonical format. +.TP +\fBzonename\fR +The domain name of the zone being checked. +.TP +\fBfilename\fR +The name of the zone file. +.SH "RETURN VALUES" +.PP +\fBnamed-checkzone\fR returns an exit status of 1 if +errors were detected and 0 otherwise. +.SH "SEE ALSO" +.PP +\fBnamed\fR(8), +\fIRFC 1035\fR, +\fIBIND 9 Administrator Reference Manual\fR. +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/check/named-checkzone.c b/contrib/bind9/bin/check/named-checkzone.c new file mode 100644 index 000000000000..d023bd685774 --- /dev/null +++ b/contrib/bind9/bin/check/named-checkzone.c @@ -0,0 +1,200 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: named-checkzone.c,v 1.13.2.3.8.9 2004/03/06 10:21:11 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "check-tool.h" + +static int quiet = 0; +static isc_mem_t *mctx = NULL; +dns_zone_t *zone = NULL; +dns_zonetype_t zonetype = dns_zone_master; +static int dumpzone = 0; +static const char *output_filename; + +#define ERRRET(result, function) \ + do { \ + if (result != ISC_R_SUCCESS) { \ + if (!quiet) \ + fprintf(stderr, "%s() returned %s\n", \ + function, dns_result_totext(result)); \ + return (result); \ + } \ + } while (0) + +static void +usage(void) { + fprintf(stderr, + "usage: named-checkzone [-djqvD] [-c class] [-o output] " + "[-t directory] [-w directory] [-k option] zonename filename\n"); + exit(1); +} + +static void +destroy(void) { + if (zone != NULL) + dns_zone_detach(&zone); +} + +int +main(int argc, char **argv) { + int c; + char *origin = NULL; + char *filename = NULL; + isc_log_t *lctx = NULL; + isc_result_t result; + char classname_in[] = "IN"; + char *classname = classname_in; + const char *workdir = NULL; + + while ((c = isc_commandline_parse(argc, argv, "c:dijk:n:qst:o:vw:D")) != EOF) { + switch (c) { + case 'c': + classname = isc_commandline_argument; + break; + + case 'd': + debug++; + break; + + case 'j': + nomerge = ISC_FALSE; + break; + + case 'n': + if (!strcmp(isc_commandline_argument, "ignore")) + zone_options &= ~(DNS_ZONEOPT_CHECKNS| + DNS_ZONEOPT_FATALNS); + else if (!strcmp(isc_commandline_argument, "warn")) { + zone_options |= DNS_ZONEOPT_CHECKNS; + zone_options &= ~DNS_ZONEOPT_FATALNS; + } else if (!strcmp(isc_commandline_argument, "fail")) + zone_options |= DNS_ZONEOPT_CHECKNS| + DNS_ZONEOPT_FATALNS; + break; + + case 'k': + if (!strcmp(isc_commandline_argument, "check-names")) { + zone_options |= DNS_ZONEOPT_CHECKNAMES; + } else if (!strcmp(isc_commandline_argument, + "check-names-fail")) { + zone_options |= DNS_ZONEOPT_CHECKNAMES | + DNS_ZONEOPT_CHECKNAMESFAIL; + } + break; + + case 'q': + quiet++; + break; + + case 't': + result = isc_dir_chroot(isc_commandline_argument); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "isc_dir_chroot: %s: %s\n", + isc_commandline_argument, + isc_result_totext(result)); + exit(1); + } + result = isc_dir_chdir("/"); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "isc_dir_chdir: %s\n", + isc_result_totext(result)); + exit(1); + } + break; + + case 'o': + output_filename = isc_commandline_argument; + break; + + case 'v': + printf(VERSION "\n"); + exit(0); + + case 'w': + workdir = isc_commandline_argument; + break; + + case 'D': + dumpzone++; + break; + + default: + usage(); + } + } + + if (workdir != NULL) { + result = isc_dir_chdir(workdir); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "isc_dir_chdir: %s: %s\n", + workdir, isc_result_totext(result)); + exit(1); + } + } + + if (isc_commandline_index + 2 > argc) + usage(); + + RUNTIME_CHECK(isc_mem_create(0, 0, &mctx) == ISC_R_SUCCESS); + if (!quiet) { + RUNTIME_CHECK(setup_logging(mctx, &lctx) == ISC_R_SUCCESS); + dns_log_init(lctx); + dns_log_setcontext(lctx); + } + + dns_result_register(); + + origin = argv[isc_commandline_index++]; + filename = argv[isc_commandline_index++]; + result = load_zone(mctx, origin, filename, classname, &zone); + + if (result == ISC_R_SUCCESS && dumpzone) { + result = dump_zone(origin, zone, output_filename); + } + + if (!quiet && result == ISC_R_SUCCESS) + fprintf(stdout, "OK\n"); + destroy(); + if (lctx != NULL) + isc_log_destroy(&lctx); + isc_mem_destroy(&mctx); + return ((result == ISC_R_SUCCESS) ? 0 : 1); +} diff --git a/contrib/bind9/bin/check/named-checkzone.docbook b/contrib/bind9/bin/check/named-checkzone.docbook new file mode 100644 index 000000000000..68b0baeeba44 --- /dev/null +++ b/contrib/bind9/bin/check/named-checkzone.docbook @@ -0,0 +1,236 @@ + + + + + + + + June 13, 2000 + + + + named-checkzone + 8 + BIND9 + + + + named-checkzone + zone file validity checking tool + + + + + named-checkzone + + + + + + + + + + + + zonename + filename + + + + + DESCRIPTION + + named-checkzone checks the syntax and integrity of + a zone file. It performs the same checks as named + does when loading a zone. This makes + named-checkzone useful for checking zone + files before configuring them into a name server. + + + + + OPTIONS + + + + -d + + + Enable debugging. + + + + + + -q + + + Quiet mode - exit code only. + + + + + + -v + + + Print the version of the named-checkzone + program and exit. + + + + + + -j + + + When loading the zone file read the journal if it exists. + + + + + -c class + + + Specify the class of the zone. If not specified "IN" is assumed. + + + + + + -k mode + + + Perform "check-name" checks with the specified failure mode. + Possible modes are "fail", + "warn" (default) and + "ignore". + + + + + + -n mode + + + Specify whether NS records should be checked to see if they + are addresses. Possible modes are "fail", + "warn" (default) and + "ignore". + + + + + + -o filename + + + Write zone output to directory. + + + + + + -t directory + + + chroot to directory so that include + directives in the configuration file are processed as if + run by a similarly chrooted named. + + + + + + -w directory + + + chdir to directory so that relative + filenames in master file $INCLUDE directives work. This + is similar to the directory clause in + named.conf. + + + + + + -D + + + Dump zone file in canonical format. + + + + + + zonename + + + The domain name of the zone being checked. + + + + + + filename + + + The name of the zone file. + + + + + + + + + + RETURN VALUES + + named-checkzone returns an exit status of 1 if + errors were detected and 0 otherwise. + + + + SEE ALSO + + + named + 8 + , + RFC 1035, + BIND 9 Administrator Reference Manual. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + + diff --git a/contrib/bind9/bin/check/named-checkzone.html b/contrib/bind9/bin/check/named-checkzone.html new file mode 100644 index 000000000000..dd14c1f8fd73 --- /dev/null +++ b/contrib/bind9/bin/check/named-checkzone.html @@ -0,0 +1,367 @@ + + + + + +named-checkzone

named-checkzone

Name

named-checkzone -- zone file validity checking tool

Synopsis

named-checkzone [-d] [-j] [-q] [-v] [-c class] [-k mode] [-n mode] [-o filename] [-t directory] [-w directory] [-D] {zonename} {filename}

DESCRIPTION

named-checkzone checks the syntax and integrity of + a zone file. It performs the same checks as named + does when loading a zone. This makes + named-checkzone useful for checking zone + files before configuring them into a name server. +

OPTIONS

-d

Enable debugging. +

-q

Quiet mode - exit code only. +

-v

Print the version of the named-checkzone + program and exit. +

-j

When loading the zone file read the journal if it exists. +

-c class

Specify the class of the zone. If not specified "IN" is assumed. +

-k mode

Perform "check-name" checks with the specified failure mode. + Possible modes are "fail", + "warn" (default) and + "ignore". +

-n mode

Specify whether NS records should be checked to see if they + are addresses. Possible modes are "fail", + "warn" (default) and + "ignore". +

-o filename

Write zone output to directory. +

-t directory

chroot to directory so that include + directives in the configuration file are processed as if + run by a similarly chrooted named. +

-w directory

chdir to directory so that relative + filenames in master file $INCLUDE directives work. This + is similar to the directory clause in + named.conf. +

-D

Dump zone file in canonical format. +

zonename

The domain name of the zone being checked. +

filename

The name of the zone file. +

RETURN VALUES

named-checkzone returns an exit status of 1 if + errors were detected and 0 otherwise. +

SEE ALSO

named(8), + RFC 1035, + BIND 9 Administrator Reference Manual. +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/dig/Makefile.in b/contrib/bind9/bin/dig/Makefile.in new file mode 100644 index 000000000000..65c14ce88222 --- /dev/null +++ b/contrib/bind9/bin/dig/Makefile.in @@ -0,0 +1,101 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000-2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.25.12.12 2004/08/18 23:25:57 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_VERSION@ + +@BIND9_MAKE_INCLUDES@ + +CINCLUDES = -I${srcdir}/include ${DNS_INCLUDES} ${BIND9_INCLUDES} \ + ${ISC_INCLUDES} ${LWRES_INCLUDES} + +CDEFINES = -DVERSION=\"${VERSION}\" +CWARNINGS = + +ISCCFGLIBS = ../../lib/isccfg/libisccfg.@A@ +DNSLIBS = ../../lib/dns/libdns.@A@ @DNS_CRYPTO_LIBS@ +BIND9LIBS = ../../lib/bind9/libbind9.@A@ +ISCLIBS = ../../lib/isc/libisc.@A@ +LWRESLIBS = ../../lib/lwres/liblwres.@A@ + +ISCCFGDEPLIBS = ../../lib/isccfg/libisccfg.@A@ +DNSDEPLIBS = ../../lib/dns/libdns.@A@ +BIND9DEPLIBS = ../../lib/bind9/libbind9.@A@ +ISCDEPLIBS = ../../lib/isc/libisc.@A@ +LWRESDEPLIBS = ../../lib/lwres/liblwres.@A@ + +DEPLIBS = ${DNSDEPLIBS} ${BIND9DEPLIBS} ${ISCDEPLIBS} ${ISCCFGDEPLIBS} \ + ${LWRESDEPLIBS} + +LIBS = ${LWRESLIBS} ${DNSLIBS} ${BIND9LIBS} ${ISCLIBS} \ + ${ISCCFGLIBS} @LIBS@ + +SUBDIRS = + +TARGETS = dig@EXEEXT@ host@EXEEXT@ nslookup@EXEEXT@ + +OBJS = dig.@O@ dighost.@O@ host.@O@ nslookup.@O@ + +UOBJS = + +SRCS = dig.c dighost.c host.c nslookup.c + +MANPAGES = dig.1 host.1 nslookup.1 + +HTMLPAGES = dig.html host.html nslookup.html + +MANOBJS = ${MANPAGES} ${HTMLPAGES} + +@BIND9_MAKE_RULES@ + +dig@EXEEXT@: dig.@O@ dighost.@O@ ${UOBJS} ${DEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ + dig.@O@ dighost.@O@ ${UOBJS} ${LIBS} + +host@EXEEXT@: host.@O@ dighost.@O@ ${UOBJS} ${DEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ + host.@O@ dighost.@O@ ${UOBJS} ${LIBS} + +nslookup@EXEEXT@: nslookup.@O@ dighost.@O@ ${UOBJS} ${DEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ + nslookup.@O@ dighost.@O@ ${UOBJS} ${LIBS} + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f ${MANOBJS} + +clean distclean maintainer-clean:: + rm -f ${TARGETS} + +installdirs: + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${bindir} + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man1 + +install:: dig@EXEEXT@ host@EXEEXT@ nslookup@EXEEXT@ installdirs + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} \ + dig@EXEEXT@ ${DESTDIR}${bindir} + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} \ + host@EXEEXT@ ${DESTDIR}${bindir} + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} \ + nslookup@EXEEXT@ ${DESTDIR}${bindir} + for m in ${MANPAGES}; do \ + ${INSTALL_DATA} ${srcdir}/$$m ${DESTDIR}${mandir}/man1; \ + done diff --git a/contrib/bind9/bin/dig/dig.1 b/contrib/bind9/bin/dig/dig.1 new file mode 100644 index 000000000000..f14d9216873b --- /dev/null +++ b/contrib/bind9/bin/dig/dig.1 @@ -0,0 +1,401 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2003 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: dig.1,v 1.14.2.4.2.6 2004/06/23 09:11:01 marka Exp $ +.\" +.TH "DIG" "1" "Jun 30, 2000" "BIND9" "" +.SH NAME +dig \- DNS lookup utility +.SH SYNOPSIS +.sp +\fBdig\fR [ \fB@server\fR ] [ \fB-b \fIaddress\fB\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-f \fIfilename\fB\fR ] [ \fB-k \fIfilename\fB\fR ] [ \fB-p \fIport#\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-x \fIaddr\fB\fR ] [ \fB-y \fIname:key\fB\fR ] [ \fB-4\fR ] [ \fB-6\fR ] [ \fBname\fR ] [ \fBtype\fR ] [ \fBclass\fR ] [ \fBqueryopt\fR\fI...\fR ] +.sp +\fBdig\fR [ \fB-h\fR ] +.sp +\fBdig\fR [ \fBglobal-queryopt\fR\fI...\fR ] [ \fBquery\fR\fI...\fR ] +.SH "DESCRIPTION" +.PP +\fBdig\fR (domain information groper) is a flexible tool +for interrogating DNS name servers. It performs DNS lookups and +displays the answers that are returned from the name server(s) that +were queried. Most DNS administrators use \fBdig\fR to +troubleshoot DNS problems because of its flexibility, ease of use and +clarity of output. Other lookup tools tend to have less functionality +than \fBdig\fR. +.PP +Although \fBdig\fR is normally used with command-line +arguments, it also has a batch mode of operation for reading lookup +requests from a file. A brief summary of its command-line arguments +and options is printed when the \fB-h\fR option is given. +Unlike earlier versions, the BIND9 implementation of +\fBdig\fR allows multiple lookups to be issued from the +command line. +.PP +Unless it is told to query a specific name server, +\fBdig\fR will try each of the servers listed in +\fI/etc/resolv.conf\fR. +.PP +When no command line arguments or options are given, will perform an +NS query for "." (the root). +.PP +It is possible to set per-user defaults for \fBdig\fR via +\fI${HOME}/.digrc\fR. This file is read and any options in it +are applied before the command line arguments. +.SH "SIMPLE USAGE" +.PP +A typical invocation of \fBdig\fR looks like: +.sp +.nf + dig @server name type +.sp +.fi +where: +.TP +\fBserver\fR +is the name or IP address of the name server to query. This can be an IPv4 +address in dotted-decimal notation or an IPv6 +address in colon-delimited notation. When the supplied +\fIserver\fR argument is a hostname, +\fBdig\fR resolves that name before querying that name +server. If no \fIserver\fR argument is provided, +\fBdig\fR consults \fI/etc/resolv.conf\fR +and queries the name servers listed there. The reply from the name +server that responds is displayed. +.TP +\fBname\fR +is the name of the resource record that is to be looked up. +.TP +\fBtype\fR +indicates what type of query is required \(em +ANY, A, MX, SIG, etc. +\fItype\fR can be any valid query type. If no +\fItype\fR argument is supplied, +\fBdig\fR will perform a lookup for an A record. +.SH "OPTIONS" +.PP +The \fB-b\fR option sets the source IP address of the query +to \fIaddress\fR. This must be a valid address on +one of the host's network interfaces or "0.0.0.0" or "::". An optional port +may be specified by appending "#" +.PP +The default query class (IN for internet) is overridden by the +\fB-c\fR option. \fIclass\fR is any valid +class, such as HS for Hesiod records or CH for CHAOSNET records. +.PP +The \fB-f\fR option makes \fBdig \fR operate +in batch mode by reading a list of lookup requests to process from the +file \fIfilename\fR. The file contains a number of +queries, one per line. Each entry in the file should be organised in +the same way they would be presented as queries to +\fBdig\fR using the command-line interface. +.PP +If a non-standard port number is to be queried, the +\fB-p\fR option is used. \fIport#\fR is +the port number that \fBdig\fR will send its queries +instead of the standard DNS port number 53. This option would be used +to test a name server that has been configured to listen for queries +on a non-standard port number. +.PP +The \fB-4\fR option forces \fBdig\fR to only +use IPv4 query transport. The \fB-6\fR option forces +\fBdig\fR to only use IPv6 query transport. +.PP +The \fB-t\fR option sets the query type to +\fItype\fR. It can be any valid query type which is +supported in BIND9. The default query type "A", unless the +\fB-x\fR option is supplied to indicate a reverse lookup. +A zone transfer can be requested by specifying a type of AXFR. When +an incremental zone transfer (IXFR) is required, +\fItype\fR is set to ixfr=N. +The incremental zone transfer will contain the changes made to the zone +since the serial number in the zone's SOA record was +\fIN\fR. +.PP +Reverse lookups - mapping addresses to names - are simplified by the +\fB-x\fR option. \fIaddr\fR is an IPv4 +address in dotted-decimal notation, or a colon-delimited IPv6 address. +When this option is used, there is no need to provide the +\fIname\fR, \fIclass\fR and +\fItype\fR arguments. \fBdig\fR +automatically performs a lookup for a name like +11.12.13.10.in-addr.arpa and sets the query type and +class to PTR and IN respectively. By default, IPv6 addresses are +looked up using nibble format under the IP6.ARPA domain. +To use the older RFC1886 method using the IP6.INT domain +specify the \fB-i\fR option. Bit string labels (RFC2874) +are now experimental and are not attempted. +.PP +To sign the DNS queries sent by \fBdig\fR and their +responses using transaction signatures (TSIG), specify a TSIG key file +using the \fB-k\fR option. You can also specify the TSIG +key itself on the command line using the \fB-y\fR option; +\fIname\fR is the name of the TSIG key and +\fIkey\fR is the actual key. The key is a base-64 +encoded string, typically generated by \fBdnssec-keygen\fR(8). +Caution should be taken when using the \fB-y\fR option on +multi-user systems as the key can be visible in the output from +\fBps\fR(1) or in the shell's history file. When +using TSIG authentication with \fBdig\fR, the name +server that is queried needs to know the key and algorithm that is +being used. In BIND, this is done by providing appropriate +\fBkey\fR and \fBserver\fR statements in +\fInamed.conf\fR. +.SH "QUERY OPTIONS" +.PP +\fBdig\fR provides a number of query options which affect +the way in which lookups are made and the results displayed. Some of +these set or reset flag bits in the query header, some determine which +sections of the answer get printed, and others determine the timeout +and retry strategies. +.PP +Each query option is identified by a keyword preceded by a plus sign +(+). Some keywords set or reset an option. These may be preceded +by the string no to negate the meaning of that keyword. Other +keywords assign values to options like the timeout interval. They +have the form \fB+keyword=value\fR. +The query options are: +.TP +\fB+[no]tcp\fR +Use [do not use] TCP when querying name servers. The default +behaviour is to use UDP unless an AXFR or IXFR query is requested, in +which case a TCP connection is used. +.TP +\fB+[no]vc\fR +Use [do not use] TCP when querying name servers. This alternate +syntax to \fI+[no]tcp\fR is provided for backwards +compatibility. The "vc" stands for "virtual circuit". +.TP +\fB+[no]ignore\fR +Ignore truncation in UDP responses instead of retrying with TCP. By +default, TCP retries are performed. +.TP +\fB+domain=somename\fR +Set the search list to contain the single domain +\fIsomename\fR, as if specified in a +\fBdomain\fR directive in +\fI/etc/resolv.conf\fR, and enable search list +processing as if the \fI+search\fR option were given. +.TP +\fB+[no]search\fR +Use [do not use] the search list defined by the searchlist or domain +directive in \fIresolv.conf\fR (if any). +The search list is not used by default. +.TP +\fB+[no]defname\fR +Deprecated, treated as a synonym for \fI+[no]search\fR +.TP +\fB+[no]aaonly\fR +Sets the "aa" flag in the query. +.TP +\fB+[no]aaflag\fR +A synonym for \fI+[no]aaonly\fR. +.TP +\fB+[no]adflag\fR +Set [do not set] the AD (authentic data) bit in the query. The AD bit +currently has a standard meaning only in responses, not in queries, +but the ability to set the bit in the query is provided for +completeness. +.TP +\fB+[no]cdflag\fR +Set [do not set] the CD (checking disabled) bit in the query. This +requests the server to not perform DNSSEC validation of responses. +.TP +\fB+[no]cl\fR +Display [do not display] the CLASS when printing the record. +.TP +\fB+[no]ttlid\fR +Display [do not display] the TTL when printing the record. +.TP +\fB+[no]recurse\fR +Toggle the setting of the RD (recursion desired) bit in the query. +This bit is set by default, which means \fBdig\fR +normally sends recursive queries. Recursion is automatically disabled +when the \fI+nssearch\fR or +\fI+trace\fR query options are used. +.TP +\fB+[no]nssearch\fR +When this option is set, \fBdig\fR attempts to find the +authoritative name servers for the zone containing the name being +looked up and display the SOA record that each name server has for the +zone. +.TP +\fB+[no]trace\fR +Toggle tracing of the delegation path from the root name servers for +the name being looked up. Tracing is disabled by default. When +tracing is enabled, \fBdig\fR makes iterative queries to +resolve the name being looked up. It will follow referrals from the +root servers, showing the answer from each server that was used to +resolve the lookup. +.TP +\fB+[no]cmd\fR +toggles the printing of the initial comment in the output identifying +the version of \fBdig\fR and the query options that have +been applied. This comment is printed by default. +.TP +\fB+[no]short\fR +Provide a terse answer. The default is to print the answer in a +verbose form. +.TP +\fB+[no]identify\fR +Show [or do not show] the IP address and port number that supplied the +answer when the \fI+short\fR option is enabled. If +short form answers are requested, the default is not to show the +source address and port number of the server that provided the answer. +.TP +\fB+[no]comments\fR +Toggle the display of comment lines in the output. The default is to +print comments. +.TP +\fB+[no]stats\fR +This query option toggles the printing of statistics: when the query +was made, the size of the reply and so on. The default behaviour is +to print the query statistics. +.TP +\fB+[no]qr\fR +Print [do not print] the query as it is sent. +By default, the query is not printed. +.TP +\fB+[no]question\fR +Print [do not print] the question section of a query when an answer is +returned. The default is to print the question section as a comment. +.TP +\fB+[no]answer\fR +Display [do not display] the answer section of a reply. The default +is to display it. +.TP +\fB+[no]authority\fR +Display [do not display] the authority section of a reply. The +default is to display it. +.TP +\fB+[no]additional\fR +Display [do not display] the additional section of a reply. +The default is to display it. +.TP +\fB+[no]all\fR +Set or clear all display flags. +.TP +\fB+time=T\fR +Sets the timeout for a query to +\fIT\fR seconds. The default time out is 5 seconds. +An attempt to set \fIT\fR to less than 1 will result +in a query timeout of 1 second being applied. +.TP +\fB+tries=T\fR +Sets the number of times to try UDP queries to server to +\fIT\fR instead of the default, 3. If +\fIT\fR is less than or equal to zero, the number of +tries is silently rounded up to 1. +.TP +\fB+retry=T\fR +Sets the number of times to retry UDP queries to server to +\fIT\fR instead of the default, 2. Unlike +\fI+tries\fR, this does not include the initial +query. +.TP +\fB+ndots=D\fR +Set the number of dots that have to appear in +\fIname\fR to \fID\fR for it to be +considered absolute. The default value is that defined using the +ndots statement in \fI/etc/resolv.conf\fR, or 1 if no +ndots statement is present. Names with fewer dots are interpreted as +relative names and will be searched for in the domains listed in the +\fBsearch\fR or \fBdomain\fR directive in +\fI/etc/resolv.conf\fR. +.TP +\fB+bufsize=B\fR +Set the UDP message buffer size advertised using EDNS0 to +\fIB\fR bytes. The maximum and minimum sizes of this +buffer are 65535 and 0 respectively. Values outside this range are +rounded up or down appropriately. +.TP +\fB+[no]multiline\fR +Print records like the SOA records in a verbose multi-line +format with human-readable comments. The default is to print +each record on a single line, to facilitate machine parsing +of the \fBdig\fR output. +.TP +\fB+[no]fail\fR +Do not try the next server if you receive a SERVFAIL. The default is +to not try the next server which is the reverse of normal stub resolver +behaviour. +.TP +\fB+[no]besteffort\fR +Attempt to display the contents of messages which are malformed. +The default is to not display malformed answers. +.TP +\fB+[no]dnssec\fR +Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) +in the OPT record in the additional section of the query. +.TP +\fB+[no]sigchase\fR +Chase DNSSEC signature chains. Requires dig be compiled with +-DDIG_SIGCHASE. +.TP +\fB+trusted-key=####\fR +Specify a trusted key to be used with \fB+sigchase\fR. +Requires dig be compiled with -DDIG_SIGCHASE. +.TP +\fB+[no]topdown\fR +When chasing DNSSEC signature chains perform a top down validation. +Requires dig be compiled with -DDIG_SIGCHASE. +.SH "MULTIPLE QUERIES" +.PP +The BIND 9 implementation of \fBdig \fR supports +specifying multiple queries on the command line (in addition to +supporting the \fB-f\fR batch file option). Each of those +queries can be supplied with its own set of flags, options and query +options. +.PP +In this case, each \fIquery\fR argument represent an +individual query in the command-line syntax described above. Each +consists of any of the standard options and flags, the name to be +looked up, an optional query type and class and any query options that +should be applied to that query. +.PP +A global set of query options, which should be applied to all queries, +can also be supplied. These global query options must precede the +first tuple of name, class, type, options, flags, and query options +supplied on the command line. Any global query options (except +the \fB+[no]cmd\fR option) can be +overridden by a query-specific set of query options. For example: +.sp +.nf +dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr +.sp +.fi +shows how \fBdig\fR could be used from the command line +to make three lookups: an ANY query for www.isc.org, a +reverse lookup of 127.0.0.1 and a query for the NS records of +isc.org. +A global query option of \fI+qr\fR is applied, so +that \fBdig\fR shows the initial query it made for each +lookup. The final query has a local query option of +\fI+noqr\fR which means that \fBdig\fR +will not print the initial query when it looks up the NS records for +isc.org. +.SH "FILES" +.PP +\fI/etc/resolv.conf\fR +.PP +\fI${HOME}/.digrc\fR +.SH "SEE ALSO" +.PP +\fBhost\fR(1), +\fBnamed\fR(8), +\fBdnssec-keygen\fR(8), +\fIRFC1035\fR. +.SH "BUGS" +.PP +There are probably too many query options. diff --git a/contrib/bind9/bin/dig/dig.c b/contrib/bind9/bin/dig/dig.c new file mode 100644 index 000000000000..b2c46254d92e --- /dev/null +++ b/contrib/bind9/bin/dig/dig.c @@ -0,0 +1,1671 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dig.c,v 1.157.2.13.2.20 2004/06/23 04:19:40 marka Exp $ */ + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +extern ISC_LIST(dig_lookup_t) lookup_list; +extern dig_serverlist_t server_list; +extern ISC_LIST(dig_searchlist_t) search_list; + +#define ADD_STRING(b, s) { \ + if (strlen(s) >= isc_buffer_availablelength(b)) \ + return (ISC_R_NOSPACE); \ + else \ + isc_buffer_putstr(b, s); \ +} + + +extern isc_boolean_t have_ipv4, have_ipv6, specified_source, + usesearch, qr; +extern in_port_t port; +extern unsigned int timeout; +extern isc_mem_t *mctx; +extern dns_messageid_t id; +extern int sendcount; +extern int ndots; +extern int lookup_counter; +extern int exitcode; +extern isc_sockaddr_t bind_address; +extern char keynametext[MXNAME]; +extern char keyfile[MXNAME]; +extern char keysecret[MXNAME]; +#ifdef DIG_SIGCHASE +extern char trustedkey[MXNAME]; +#endif +extern dns_tsigkey_t *key; +extern isc_boolean_t validated; +extern isc_taskmgr_t *taskmgr; +extern isc_task_t *global_task; +extern isc_boolean_t free_now; +dig_lookup_t *default_lookup = NULL; + +extern isc_boolean_t debugging, memdebugging; +static char *batchname = NULL; +static FILE *batchfp = NULL; +static char *argv0; + +static char domainopt[DNS_NAME_MAXTEXT]; + +static isc_boolean_t short_form = ISC_FALSE, printcmd = ISC_TRUE, + ip6_int = ISC_FALSE, plusquest = ISC_FALSE, pluscomm = ISC_FALSE, + multiline = ISC_FALSE, nottl = ISC_FALSE, noclass = ISC_FALSE; + +static const char *opcodetext[] = { + "QUERY", + "IQUERY", + "STATUS", + "RESERVED3", + "NOTIFY", + "UPDATE", + "RESERVED6", + "RESERVED7", + "RESERVED8", + "RESERVED9", + "RESERVED10", + "RESERVED11", + "RESERVED12", + "RESERVED13", + "RESERVED14", + "RESERVED15" +}; + +static const char *rcodetext[] = { + "NOERROR", + "FORMERR", + "SERVFAIL", + "NXDOMAIN", + "NOTIMP", + "REFUSED", + "YXDOMAIN", + "YXRRSET", + "NXRRSET", + "NOTAUTH", + "NOTZONE", + "RESERVED11", + "RESERVED12", + "RESERVED13", + "RESERVED14", + "RESERVED15", + "BADVERS" +}; + +extern char *progname; + +static void +print_usage(FILE *fp) { + fputs( +"Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}\n" +" {global-d-opt} host [@local-server] {local-d-opt}\n" +" [ host [@local-server] {local-d-opt} [...]]\n", fp); +} + +static void +usage(void) { + print_usage(stderr); + fputs("\nUse \"dig -h\" (or \"dig -h | more\") " + "for complete list of options\n", stderr); + exit(1); +} + +static void +version(void) { + fputs("DiG " VERSION "\n", stderr); +} + +static void +help(void) { + print_usage(stdout); + fputs( +"Where: domain is in the Domain Name System\n" +" q-class is one of (in,hs,ch,...) [default: in]\n" +" q-type is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a]\n" +" (Use ixfr=version for type ixfr)\n" +" q-opt is one of:\n" +" -x dot-notation (shortcut for in-addr lookups)\n" +" -i (IP6.INT reverse IPv6 lookups)\n" +" -f filename (batch mode)\n" +" -b address[#port] (bind to source address/port)\n" +" -p port (specify port number)\n" +" -t type (specify query type)\n" +" -c class (specify query class)\n" +" -k keyfile (specify tsig key file)\n" +" -y name:key (specify named base64 tsig key)\n" +" -4 (use IPv4 query transport only)\n" +" -6 (use IPv6 query transport only)\n" +" d-opt is of the form +keyword[=value], where keyword is:\n" +" +[no]vc (TCP mode)\n" +" +[no]tcp (TCP mode, alternate syntax)\n" +" +time=### (Set query timeout) [5]\n" +" +tries=### (Set number of UDP attempts) [3]\n" +" +retry=### (Set number of UDP retries) [2]\n" +" +domain=### (Set default domainname)\n" +" +bufsize=### (Set EDNS0 Max UDP packet size)\n" +" +ndots=### (Set NDOTS value)\n" +" +[no]search (Set whether to use searchlist)\n" +" +[no]defname (Ditto)\n" +" +[no]recurse (Recursive mode)\n" +" +[no]ignore (Don't revert to TCP for TC responses.)" +"\n" +" +[no]fail (Don't try next server on SERVFAIL)\n" +" +[no]besteffort (Try to parse even illegal messages)\n" +" +[no]aaonly (Set AA flag in query (+[no]aaflag))\n" +" +[no]adflag (Set AD flag in query)\n" +" +[no]cdflag (Set CD flag in query)\n" +" +[no]cl (Control display of class in records)\n" +" +[no]cmd (Control display of command line)\n" +" +[no]comments (Control display of comment lines)\n" +" +[no]question (Control display of question)\n" +" +[no]answer (Control display of answer)\n" +" +[no]authority (Control display of authority)\n" +" +[no]additional (Control display of additional)\n" +" +[no]stats (Control display of statistics)\n" +" +[no]short (Disable everything except short\n" +" form of answer)\n" +" +[no]ttlid (Control display of ttls in records)\n" +" +[no]all (Set or clear all display flags)\n" +" +[no]qr (Print question before sending)\n" +" +[no]nssearch (Search all authoritative nameservers)\n" +" +[no]identify (ID responders in short answers)\n" +" +[no]trace (Trace delegation down from root)\n" +" +[no]dnssec (Request DNSSEC records)\n" +#ifdef DIG_SIGCHASE +" +[no]sigchase (Chase DNSSEC signatures)\n" +" +trusted-key=#### (Trusted Key when chasing DNSSEC sigs)\n" +#if DIG_SIGCHASE_TD +" +[no]topdown (Do DNSSEC validation top down mode)\n" +#endif +#endif +" +[no]multiline (Print records in an expanded format)\n" +" global d-opts and servers (before host name) affect all queries.\n" +" local d-opts and servers (after host name) affect only that lookup.\n" +" -h (print help and exit)\n" +" -v (print version and exit)\n", + stdout); +} + +/* + * Callback from dighost.c to print the received message. + */ +void +received(int bytes, isc_sockaddr_t *from, dig_query_t *query) { + isc_uint64_t diff; + isc_time_t now; + time_t tnow; + char fromtext[ISC_SOCKADDR_FORMATSIZE]; + + isc_sockaddr_format(from, fromtext, sizeof(fromtext)); + + TIME_NOW(&now); + + if (query->lookup->stats && !short_form) { + diff = isc_time_microdiff(&now, &query->time_sent); + printf(";; Query time: %ld msec\n", (long int)diff/1000); + printf(";; SERVER: %s(%s)\n", fromtext, query->servname); + time(&tnow); + printf(";; WHEN: %s", ctime(&tnow)); + if (query->lookup->doing_xfr) { + printf(";; XFR size: %u records (messages %u)\n", + query->rr_count, query->msg_count); + } else { + printf(";; MSG SIZE rcvd: %d\n", bytes); + + } + if (key != NULL) { + if (!validated) + puts(";; WARNING -- Some TSIG could not " + "be validated"); + } + if ((key == NULL) && (keysecret[0] != 0)) { + puts(";; WARNING -- TSIG key was not used."); + } + puts(""); + } else if (query->lookup->identify && !short_form) { + diff = isc_time_microdiff(&now, &query->time_sent); + printf(";; Received %u bytes from %s(%s) in %d ms\n\n", + bytes, fromtext, query->servname, + (int)diff/1000); + } +} + +/* + * Callback from dighost.c to print that it is trying a server. + * Not used in dig. + * XXX print_trying + */ +void +trying(char *frm, dig_lookup_t *lookup) { + UNUSED(frm); + UNUSED(lookup); +} + +/* + * Internal print routine used to print short form replies. + */ +static isc_result_t +say_message(dns_rdata_t *rdata, dig_query_t *query, isc_buffer_t *buf) { + isc_result_t result; + isc_uint64_t diff; + isc_time_t now; + char store[sizeof("12345678901234567890")]; + + if (query->lookup->trace || query->lookup->ns_search_only) { + result = dns_rdatatype_totext(rdata->type, buf); + if (result != ISC_R_SUCCESS) + return (result); + ADD_STRING(buf, " "); + } + result = dns_rdata_totext(rdata, NULL, buf); + check_result(result, "dns_rdata_totext"); + if (query->lookup->identify) { + TIME_NOW(&now); + diff = isc_time_microdiff(&now, &query->time_sent); + ADD_STRING(buf, " from server "); + ADD_STRING(buf, query->servname); + snprintf(store, 19, " in %d ms.", (int)diff/1000); + ADD_STRING(buf, store); + } + ADD_STRING(buf, "\n"); + return (ISC_R_SUCCESS); +} + +/* + * short_form message print handler. Calls above say_message() + */ +static isc_result_t +short_answer(dns_message_t *msg, dns_messagetextflag_t flags, + isc_buffer_t *buf, dig_query_t *query) +{ + dns_name_t *name; + dns_rdataset_t *rdataset; + isc_buffer_t target; + isc_result_t result, loopresult; + dns_name_t empty_name; + char t[4096]; + dns_rdata_t rdata = DNS_RDATA_INIT; + + UNUSED(flags); + + dns_name_init(&empty_name, NULL); + result = dns_message_firstname(msg, DNS_SECTION_ANSWER); + if (result == ISC_R_NOMORE) + return (ISC_R_SUCCESS); + else if (result != ISC_R_SUCCESS) + return (result); + + for (;;) { + name = NULL; + dns_message_currentname(msg, DNS_SECTION_ANSWER, &name); + + isc_buffer_init(&target, t, sizeof(t)); + + for (rdataset = ISC_LIST_HEAD(name->list); + rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) { + loopresult = dns_rdataset_first(rdataset); + while (loopresult == ISC_R_SUCCESS) { + dns_rdataset_current(rdataset, &rdata); + result = say_message(&rdata, query, + buf); + check_result(result, "say_message"); + loopresult = dns_rdataset_next(rdataset); + dns_rdata_reset(&rdata); + } + } + result = dns_message_nextname(msg, DNS_SECTION_ANSWER); + if (result == ISC_R_NOMORE) + break; + else if (result != ISC_R_SUCCESS) + return (result); + } + + return (ISC_R_SUCCESS); +} +#ifdef DIG_SIGCHASE +isc_result_t +printrdataset(dns_name_t *owner_name, dns_rdataset_t *rdataset, + isc_buffer_t *target) +{ + isc_result_t result; + dns_master_style_t *style = NULL; + unsigned int styleflags = 0; + + if (rdataset == NULL || owner_name == NULL || target == NULL) + return(ISC_FALSE); + + styleflags |= DNS_STYLEFLAG_REL_OWNER; + if (nottl) + styleflags |= DNS_STYLEFLAG_NO_TTL; + if (noclass) + styleflags |= DNS_STYLEFLAG_NO_CLASS; + if (multiline) { + styleflags |= DNS_STYLEFLAG_OMIT_OWNER; + styleflags |= DNS_STYLEFLAG_OMIT_CLASS; + styleflags |= DNS_STYLEFLAG_REL_DATA; + styleflags |= DNS_STYLEFLAG_OMIT_TTL; + styleflags |= DNS_STYLEFLAG_TTL; + styleflags |= DNS_STYLEFLAG_MULTILINE; + styleflags |= DNS_STYLEFLAG_COMMENT; + } + if (multiline || (nottl && noclass)) + result = dns_master_stylecreate(&style, styleflags, + 24, 24, 24, 32, 80, 8, mctx); + else if (nottl || noclass) + result = dns_master_stylecreate(&style, styleflags, + 24, 24, 32, 40, 80, 8, mctx); + else + result = dns_master_stylecreate(&style, styleflags, + 24, 32, 40, 48, 80, 8, mctx); + check_result(result, "dns_master_stylecreate"); + + result = dns_master_rdatasettotext(owner_name, rdataset, style, target); + + if (style != NULL) + dns_master_styledestroy(&style, mctx); + + return(result); +} +#endif + +/* + * Callback from dighost.c to print the reply from a server + */ +isc_result_t +printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { + isc_result_t result; + dns_messagetextflag_t flags; + isc_buffer_t *buf = NULL; + unsigned int len = OUTPUTBUF; + dns_master_style_t *style = NULL; + unsigned int styleflags = 0; + + styleflags |= DNS_STYLEFLAG_REL_OWNER; + if (nottl) + styleflags |= DNS_STYLEFLAG_NO_TTL; + if (noclass) + styleflags |= DNS_STYLEFLAG_NO_CLASS; + if (multiline) { + styleflags |= DNS_STYLEFLAG_OMIT_OWNER; + styleflags |= DNS_STYLEFLAG_OMIT_CLASS; + styleflags |= DNS_STYLEFLAG_REL_DATA; + styleflags |= DNS_STYLEFLAG_OMIT_TTL; + styleflags |= DNS_STYLEFLAG_TTL; + styleflags |= DNS_STYLEFLAG_MULTILINE; + styleflags |= DNS_STYLEFLAG_COMMENT; + } + if (multiline || (nottl && noclass)) + result = dns_master_stylecreate(&style, styleflags, + 24, 24, 24, 32, 80, 8, mctx); + else if (nottl || noclass) + result = dns_master_stylecreate(&style, styleflags, + 24, 24, 32, 40, 80, 8, mctx); + else + result = dns_master_stylecreate(&style, styleflags, + 24, 32, 40, 48, 80, 8, mctx); + check_result(result, "dns_master_stylecreate"); + + if (query->lookup->cmdline[0] != 0) { + if (!short_form) + fputs(query->lookup->cmdline, stdout); + query->lookup->cmdline[0]=0; + } + debug("printmessage(%s %s %s)", headers ? "headers" : "noheaders", + query->lookup->comments ? "comments" : "nocomments", + short_form ? "short_form" : "long_form"); + + flags = 0; + if (!headers) { + flags |= DNS_MESSAGETEXTFLAG_NOHEADERS; + flags |= DNS_MESSAGETEXTFLAG_NOCOMMENTS; + } + if (!query->lookup->comments) + flags |= DNS_MESSAGETEXTFLAG_NOCOMMENTS; + + result = ISC_R_SUCCESS; + + result = isc_buffer_allocate(mctx, &buf, len); + check_result(result, "isc_buffer_allocate"); + + if (query->lookup->comments && !short_form) { + if (query->lookup->cmdline[0] != 0) + printf("; %s\n", query->lookup->cmdline); + if (msg == query->lookup->sendmsg) + printf(";; Sending:\n"); + else + printf(";; Got answer:\n"); + + if (headers) { + printf(";; ->>HEADER<<- opcode: %s, status: %s, " + "id: %u\n", + opcodetext[msg->opcode], rcodetext[msg->rcode], + msg->id); + printf(";; flags:"); + if ((msg->flags & DNS_MESSAGEFLAG_QR) != 0) + printf(" qr"); + if ((msg->flags & DNS_MESSAGEFLAG_AA) != 0) + printf(" aa"); + if ((msg->flags & DNS_MESSAGEFLAG_TC) != 0) + printf(" tc"); + if ((msg->flags & DNS_MESSAGEFLAG_RD) != 0) + printf(" rd"); + if ((msg->flags & DNS_MESSAGEFLAG_RA) != 0) + printf(" ra"); + if ((msg->flags & DNS_MESSAGEFLAG_AD) != 0) + printf(" ad"); + if ((msg->flags & DNS_MESSAGEFLAG_CD) != 0) + printf(" cd"); + + printf("; QUERY: %u, ANSWER: %u, " + "AUTHORITY: %u, ADDITIONAL: %u\n", + msg->counts[DNS_SECTION_QUESTION], + msg->counts[DNS_SECTION_ANSWER], + msg->counts[DNS_SECTION_AUTHORITY], + msg->counts[DNS_SECTION_ADDITIONAL]); + } + } + +repopulate_buffer: + + if (query->lookup->comments && headers && !short_form) { + result = dns_message_pseudosectiontotext(msg, + DNS_PSEUDOSECTION_OPT, + style, flags, buf); + if (result == ISC_R_NOSPACE) { +buftoosmall: + len += OUTPUTBUF; + isc_buffer_free(&buf); + result = isc_buffer_allocate(mctx, &buf, len); + if (result == ISC_R_SUCCESS) + goto repopulate_buffer; + else + goto cleanup; + } + check_result(result, + "dns_message_pseudosectiontotext"); + } + + if (query->lookup->section_question && headers) { + if (!short_form) { + result = dns_message_sectiontotext(msg, + DNS_SECTION_QUESTION, + style, flags, buf); + if (result == ISC_R_NOSPACE) + goto buftoosmall; + check_result(result, "dns_message_sectiontotext"); + } + } + if (query->lookup->section_answer) { + if (!short_form) { + result = dns_message_sectiontotext(msg, + DNS_SECTION_ANSWER, + style, flags, buf); + if (result == ISC_R_NOSPACE) + goto buftoosmall; + check_result(result, "dns_message_sectiontotext"); + } else { + result = short_answer(msg, flags, buf, query); + if (result == ISC_R_NOSPACE) + goto buftoosmall; + check_result(result, "short_answer"); + } + } + if (query->lookup->section_authority) { + if (!short_form) { + result = dns_message_sectiontotext(msg, + DNS_SECTION_AUTHORITY, + style, flags, buf); + if (result == ISC_R_NOSPACE) + goto buftoosmall; + check_result(result, "dns_message_sectiontotext"); + } + } + if (query->lookup->section_additional) { + if (!short_form) { + result = dns_message_sectiontotext(msg, + DNS_SECTION_ADDITIONAL, + style, flags, buf); + if (result == ISC_R_NOSPACE) + goto buftoosmall; + check_result(result, "dns_message_sectiontotext"); + /* + * Only print the signature on the first record. + */ + if (headers) { + result = dns_message_pseudosectiontotext( + msg, + DNS_PSEUDOSECTION_TSIG, + style, flags, buf); + if (result == ISC_R_NOSPACE) + goto buftoosmall; + check_result(result, + "dns_message_pseudosectiontotext"); + result = dns_message_pseudosectiontotext( + msg, + DNS_PSEUDOSECTION_SIG0, + style, flags, buf); + if (result == ISC_R_NOSPACE) + goto buftoosmall; + check_result(result, + "dns_message_pseudosectiontotext"); + } + } + } + if (headers && query->lookup->comments && !short_form) + printf("\n"); + + printf("%.*s", (int)isc_buffer_usedlength(buf), + (char *)isc_buffer_base(buf)); + isc_buffer_free(&buf); + +cleanup: + if (style != NULL) + dns_master_styledestroy(&style, mctx); + return (result); +} + +/* + * print the greeting message when the program first starts up. + */ +static void +printgreeting(int argc, char **argv, dig_lookup_t *lookup) { + int i; + int remaining; + static isc_boolean_t first = ISC_TRUE; + char append[MXNAME]; + + if (printcmd) { + lookup->cmdline[sizeof(lookup->cmdline) - 1] = 0; + snprintf(lookup->cmdline, sizeof(lookup->cmdline), + "%s; <<>> DiG " VERSION " <<>>", + first?"\n":""); + i = 1; + while (i < argc) { + snprintf(append, sizeof(append), " %s", argv[i++]); + remaining = sizeof(lookup->cmdline) - + strlen(lookup->cmdline) - 1; + strncat(lookup->cmdline, append, remaining); + } + remaining = sizeof(lookup->cmdline) - + strlen(lookup->cmdline) - 1; + strncat(lookup->cmdline, "\n", remaining); + if (first) { + snprintf(append, sizeof(append), + ";; global options: %s %s\n", + short_form ? "short_form" : "", + printcmd ? "printcmd" : ""); + first = ISC_FALSE; + remaining = sizeof(lookup->cmdline) - + strlen(lookup->cmdline) - 1; + strncat(lookup->cmdline, append, remaining); + } + } +} + +/* + * Reorder an argument list so that server names all come at the end. + * This is a bit of a hack, to allow batch-mode processing to properly + * handle the server options. + */ +static void +reorder_args(int argc, char *argv[]) { + int i, j; + char *ptr; + int end; + + debug("reorder_args()"); + end = argc - 1; + while (argv[end][0] == '@') { + end--; + if (end == 0) + return; + } + debug("arg[end]=%s", argv[end]); + for (i = 1; i < end - 1; i++) { + if (argv[i][0] == '@') { + debug("arg[%d]=%s", i, argv[i]); + ptr = argv[i]; + for (j = i + 1; j < end; j++) { + debug("Moving %s to %d", argv[j], j - 1); + argv[j - 1] = argv[j]; + } + debug("moving %s to end, %d", ptr, end - 1); + argv[end - 1] = ptr; + end--; + if (end < 1) + return; + } + } +} + +static isc_uint32_t +parse_uint(char *arg, const char *desc, isc_uint32_t max) { + isc_result_t result; + isc_uint32_t tmp; + + result = isc_parse_uint32(&tmp, arg, 10); + if (result == ISC_R_SUCCESS && tmp > max) + result = ISC_R_RANGE; + if (result != ISC_R_SUCCESS) + fatal("%s '%s': %s", desc, arg, isc_result_totext(result)); + return (tmp); +} + +/* + * We're not using isc_commandline_parse() here since the command line + * syntax of dig is quite a bit different from that which can be described + * by that routine. + * XXX doc options + */ + +static void +plus_option(char *option, isc_boolean_t is_batchfile, + dig_lookup_t *lookup) +{ + char option_store[256]; + char *cmd, *value, *ptr; + isc_boolean_t state = ISC_TRUE; +#ifdef DIG_SIGCHASE + size_t n; +#endif + + strncpy(option_store, option, sizeof(option_store)); + option_store[sizeof(option_store)-1]=0; + ptr = option_store; + cmd = next_token(&ptr,"="); + if (cmd == NULL) { + printf(";; Invalid option %s\n", option_store); + return; + } + value = ptr; + if (strncasecmp(cmd, "no", 2)==0) { + cmd += 2; + state = ISC_FALSE; + } + +#define FULLCHECK(A) \ + do { \ + size_t _l = strlen(cmd); \ + if (_l >= sizeof(A) || strncasecmp(cmd, A, _l) != 0) \ + goto invalid_option; \ + } while (0) +#define FULLCHECK2(A, B) \ + do { \ + size_t _l = strlen(cmd); \ + if ((_l >= sizeof(A) || strncasecmp(cmd, A, _l) != 0) && \ + (_l >= sizeof(B) || strncasecmp(cmd, B, _l) != 0)) \ + goto invalid_option; \ + } while (0) + + switch (cmd[0]) { + case 'a': + switch (cmd[1]) { + case 'a': /* aaonly / aaflag */ + FULLCHECK2("aaonly", "aaflag"); + lookup->aaonly = state; + break; + case 'd': + switch (cmd[2]) { + case 'd': /* additional */ + FULLCHECK("additional"); + lookup->section_additional = state; + break; + case 'f': /* adflag */ + FULLCHECK("adflag"); + lookup->adflag = state; + break; + default: + goto invalid_option; + } + break; + case 'l': /* all */ + FULLCHECK("all"); + lookup->section_question = state; + lookup->section_authority = state; + lookup->section_answer = state; + lookup->section_additional = state; + lookup->comments = state; + lookup->stats = state; + printcmd = state; + break; + case 'n': /* answer */ + FULLCHECK("answer"); + lookup->section_answer = state; + break; + case 'u': /* authority */ + FULLCHECK("authority"); + lookup->section_authority = state; + break; + default: + goto invalid_option; + } + break; + case 'b': + switch (cmd[1]) { + case 'e':/* besteffort */ + FULLCHECK("besteffort"); + lookup->besteffort = state; + break; + case 'u':/* bufsize */ + FULLCHECK("bufsize"); + if (value == NULL) + goto need_value; + if (!state) + goto invalid_option; + lookup->udpsize = (isc_uint16_t) parse_uint(value, + "buffer size", COMMSIZE); + break; + default: + goto invalid_option; + } + break; + case 'c': + switch (cmd[1]) { + case 'd':/* cdflag */ + FULLCHECK("cdflag"); + lookup->cdflag = state; + break; + case 'l': /* cl */ + FULLCHECK("cl"); + noclass = !state; + break; + case 'm': /* cmd */ + FULLCHECK("cmd"); + printcmd = state; + break; + case 'o': /* comments */ + FULLCHECK("comments"); + lookup->comments = state; + if (lookup == default_lookup) + pluscomm = state; + break; + default: + goto invalid_option; + } + break; + case 'd': + switch (cmd[1]) { + case 'e': /* defname */ + FULLCHECK("defname"); + usesearch = state; + break; + case 'n': /* dnssec */ + FULLCHECK("dnssec"); + lookup->dnssec = state; + break; + case 'o': /* domain */ + FULLCHECK("domain"); + if (value == NULL) + goto need_value; + if (!state) + goto invalid_option; + strncpy(domainopt, value, sizeof(domainopt)); + domainopt[sizeof(domainopt)-1] = '\0'; + break; + default: + goto invalid_option; + } + break; + case 'f': /* fail */ + FULLCHECK("fail"); + lookup->servfail_stops = state; + break; + case 'i': + switch (cmd[1]) { + case 'd': /* identify */ + FULLCHECK("identify"); + lookup->identify = state; + break; + case 'g': /* ignore */ + default: /* Inherets default for compatibility */ + FULLCHECK("ignore"); + lookup->ignore = ISC_TRUE; + } + break; + case 'm': /* multiline */ + FULLCHECK("multiline"); + multiline = state; + break; + case 'n': + switch (cmd[1]) { + case 'd': /* ndots */ + FULLCHECK("ndots"); + if (value == NULL) + goto need_value; + if (!state) + goto invalid_option; + ndots = parse_uint(value, "ndots", MAXNDOTS); + break; + case 's': /* nssearch */ + FULLCHECK("nssearch"); + lookup->ns_search_only = state; + if (state) { + lookup->trace_root = ISC_TRUE; + lookup->recurse = ISC_FALSE; + lookup->identify = ISC_TRUE; + lookup->stats = ISC_FALSE; + lookup->comments = ISC_FALSE; + lookup->section_additional = ISC_FALSE; + lookup->section_authority = ISC_FALSE; + lookup->section_question = ISC_FALSE; + lookup->rdtype = dns_rdatatype_ns; + lookup->rdtypeset = ISC_TRUE; + short_form = ISC_TRUE; + } + break; + default: + goto invalid_option; + } + break; + case 'q': + switch (cmd[1]) { + case 'r': /* qr */ + FULLCHECK("qr"); + qr = state; + break; + case 'u': /* question */ + FULLCHECK("question"); + lookup->section_question = state; + if (lookup == default_lookup) + plusquest = state; + break; + default: + goto invalid_option; + } + break; + case 'r': + switch (cmd[1]) { + case 'e': + switch (cmd[2]) { + case 'c': /* recurse */ + FULLCHECK("recurse"); + lookup->recurse = state; + break; + case 't': /* retry / retries */ + FULLCHECK2("retry", "retries"); + if (value == NULL) + goto need_value; + if (!state) + goto invalid_option; + lookup->retries = parse_uint(value, "retries", + MAXTRIES - 1); + lookup->retries++; + break; + default: + goto invalid_option; + } + break; + default: + goto invalid_option; + } + break; + case 's': + switch (cmd[1]) { + case 'e': /* search */ + FULLCHECK("search"); + usesearch = state; + break; + case 'h': /* short */ + FULLCHECK("short"); + short_form = state; + if (state) { + printcmd = ISC_FALSE; + lookup->section_additional = ISC_FALSE; + lookup->section_answer = ISC_TRUE; + lookup->section_authority = ISC_FALSE; + lookup->section_question = ISC_FALSE; + lookup->comments = ISC_FALSE; + lookup->stats = ISC_FALSE; + } + break; +#ifdef DIG_SIGCHASE + case 'i': /* sigchase */ + FULLCHECK("sigchase"); + lookup->sigchase = state; + if (lookup->sigchase) + lookup->dnssec = ISC_TRUE; + break; +#endif + case 't': /* stats */ + FULLCHECK("stats"); + lookup->stats = state; + break; + default: + goto invalid_option; + } + break; + case 't': + switch (cmd[1]) { + case 'c': /* tcp */ + FULLCHECK("tcp"); + if (!is_batchfile) + lookup->tcp_mode = state; + break; + case 'i': /* timeout */ + FULLCHECK("timeout"); + if (value == NULL) + goto need_value; + if (!state) + goto invalid_option; + timeout = parse_uint(value, "timeout", MAXTIMEOUT); + if (timeout == 0) + timeout = 1; + break; +#if DIG_SIGCHASE_TD + case 'o': /* topdown */ + FULLCHECK("topdown"); + lookup->do_topdown = state; + break; +#endif + case 'r': + switch (cmd[2]) { + case 'a': /* trace */ + FULLCHECK("trace"); + lookup->trace = state; + lookup->trace_root = state; + if (state) { + lookup->recurse = ISC_FALSE; + lookup->identify = ISC_TRUE; + lookup->comments = ISC_FALSE; + lookup->stats = ISC_FALSE; + lookup->section_additional = ISC_FALSE; + lookup->section_authority = ISC_TRUE; + lookup->section_question = ISC_FALSE; + } + break; + case 'i': /* tries */ + FULLCHECK("tries"); + if (value == NULL) + goto need_value; + if (!state) + goto invalid_option; + lookup->retries = parse_uint(value, "tries", + MAXTRIES); + if (lookup->retries == 0) + lookup->retries = 1; + break; +#ifdef DIG_SIGCHASE + case 'u': /* trusted-key */ + if (value == NULL) + goto need_value; + if (!state) + goto invalid_option; + n = strlcpy(trustedkey, ptr, + sizeof(trustedkey)); + if (n >= sizeof(trustedkey)) + fatal("trusted key too large"); + break; +#endif + default: + goto invalid_option; + } + break; + case 't': /* ttlid */ + FULLCHECK("ttlid"); + nottl = !state; + break; + default: + goto invalid_option; + } + break; + case 'v': + FULLCHECK("vc"); + if (!is_batchfile) + lookup->tcp_mode = state; + break; + default: + invalid_option: + need_value: + fprintf(stderr, "Invalid option: +%s\n", + option); + usage(); + } + return; +} + +/* + * ISC_TRUE returned if value was used + */ +static const char *single_dash_opts = "46dhimnv"; +static const char *dash_opts = "46bcdfhikmnptvyx"; +static isc_boolean_t +dash_option(char *option, char *next, dig_lookup_t **lookup, + isc_boolean_t *open_type_class, isc_boolean_t *firstarg, + int argc, char **argv) +{ + char opt, *value, *ptr; + isc_result_t result; + isc_boolean_t value_from_next; + isc_textregion_t tr; + dns_rdatatype_t rdtype; + dns_rdataclass_t rdclass; + char textname[MXNAME]; + struct in_addr in4; + struct in6_addr in6; + in_port_t srcport; + char *hash, *cmd; + + while (strpbrk(option, single_dash_opts) == &option[0]) { + /* + * Since the -[46dhimnv] options do not take an argument, + * account for them (in any number and/or combination) + * if they appear as the first character(s) of a q-opt. + */ + opt = option[0]; + switch (opt) { + case '4': + if (have_ipv4) { + isc_net_disableipv6(); + have_ipv6 = ISC_FALSE; + } else { + fatal("can't find IPv4 networking"); + return (ISC_FALSE); + } + break; + case '6': + if (have_ipv6) { + isc_net_disableipv4(); + have_ipv4 = ISC_FALSE; + } else { + fatal("can't find IPv6 networking"); + return (ISC_FALSE); + } + break; + case 'd': + ptr = strpbrk(&option[1], dash_opts); + if (ptr != &option[1]) { + cmd = option; + FULLCHECK("debug"); + debugging = ISC_TRUE; + return (ISC_FALSE); + } else + debugging = ISC_TRUE; + break; + case 'h': + help(); + exit(0); + break; + case 'i': + ip6_int = ISC_TRUE; + break; + case 'm': /* memdebug */ + /* memdebug is handled in preparse_args() */ + break; + case 'n': + /* deprecated */ + break; + case 'v': + version(); + exit(0); + break; + } + if (strlen(option) > 1U) + option = &option[1]; + else + return (ISC_FALSE); + } + opt = option[0]; + if (strlen(option) > 1U) { + value_from_next = ISC_FALSE; + value = &option[1]; + } else { + value_from_next = ISC_TRUE; + value = next; + } + if (value == NULL) + goto invalid_option; + switch (opt) { + case 'b': + hash = strchr(value, '#'); + if (hash != NULL) { + srcport = (in_port_t) + parse_uint(hash + 1, + "port number", MAXPORT); + *hash = '\0'; + } else + srcport = 0; + if (have_ipv6 && inet_pton(AF_INET6, value, &in6) == 1) { + isc_sockaddr_fromin6(&bind_address, &in6, srcport); + isc_net_disableipv4(); + } else if (have_ipv4 && inet_pton(AF_INET, value, &in4) == 1) { + isc_sockaddr_fromin(&bind_address, &in4, srcport); + isc_net_disableipv6(); + } else { + if (hash != NULL) + *hash = '#'; + fatal("invalid address %s", value); + } + if (hash != NULL) + *hash = '#'; + specified_source = ISC_TRUE; + return (value_from_next); + case 'c': + if ((*lookup)->rdclassset) { + fprintf(stderr, ";; Warning, extra class option\n"); + } + *open_type_class = ISC_FALSE; + tr.base = value; + tr.length = strlen(value); + result = dns_rdataclass_fromtext(&rdclass, + (isc_textregion_t *)&tr); + if (result == ISC_R_SUCCESS) { + (*lookup)->rdclass = rdclass; + (*lookup)->rdclassset = ISC_TRUE; + } else + fprintf(stderr, ";; Warning, ignoring " + "invalid class %s\n", + value); + return (value_from_next); + case 'f': + batchname = value; + return (value_from_next); + case 'k': + strncpy(keyfile, value, sizeof(keyfile)); + keyfile[sizeof(keyfile)-1]=0; + return (value_from_next); + case 'p': + port = (in_port_t) parse_uint(value, "port number", MAXPORT); + return (value_from_next); + case 't': + *open_type_class = ISC_FALSE; + if (strncasecmp(value, "ixfr=", 5) == 0) { + rdtype = dns_rdatatype_ixfr; + result = ISC_R_SUCCESS; + } else { + tr.base = value; + tr.length = strlen(value); + result = dns_rdatatype_fromtext(&rdtype, + (isc_textregion_t *)&tr); + if (result == ISC_R_SUCCESS && + rdtype == dns_rdatatype_ixfr) { + result = DNS_R_UNKNOWN; + } + } + if (result == ISC_R_SUCCESS) { + if ((*lookup)->rdtypeset) { + fprintf(stderr, ";; Warning, " + "extra type option\n"); + } + if (rdtype == dns_rdatatype_ixfr) { + (*lookup)->rdtype = dns_rdatatype_ixfr; + (*lookup)->rdtypeset = ISC_TRUE; + (*lookup)->ixfr_serial = + parse_uint(&value[5], "serial number", + MAXSERIAL); + (*lookup)->section_question = plusquest; + (*lookup)->comments = pluscomm; + } else { + (*lookup)->rdtype = rdtype; + (*lookup)->rdtypeset = ISC_TRUE; + if (rdtype == dns_rdatatype_axfr) { + (*lookup)->section_question = plusquest; + (*lookup)->comments = pluscomm; + } + (*lookup)->ixfr_serial = ISC_FALSE; + } + } else + fprintf(stderr, ";; Warning, ignoring " + "invalid type %s\n", + value); + return (value_from_next); + case 'y': + ptr = next_token(&value,":"); + if (ptr == NULL) { + usage(); + } + strncpy(keynametext, ptr, sizeof(keynametext)); + keynametext[sizeof(keynametext)-1]=0; + ptr = next_token(&value, ""); + if (ptr == NULL) + usage(); + strncpy(keysecret, ptr, sizeof(keysecret)); + keysecret[sizeof(keysecret)-1]=0; + return (value_from_next); + case 'x': + *lookup = clone_lookup(default_lookup, ISC_TRUE); + if (get_reverse(textname, sizeof(textname), value, + ip6_int, ISC_FALSE) == ISC_R_SUCCESS) { + strncpy((*lookup)->textname, textname, + sizeof((*lookup)->textname)); + debug("looking up %s", (*lookup)->textname); + (*lookup)->trace_root = ISC_TF((*lookup)->trace || + (*lookup)->ns_search_only); + (*lookup)->ip6_int = ip6_int; + if (!(*lookup)->rdtypeset) + (*lookup)->rdtype = dns_rdatatype_ptr; + if (!(*lookup)->rdclassset) + (*lookup)->rdclass = dns_rdataclass_in; + (*lookup)->new_search = ISC_TRUE; + if (*lookup && *firstarg) { + printgreeting(argc, argv, *lookup); + *firstarg = ISC_FALSE; + } + ISC_LIST_APPEND(lookup_list, *lookup, link); + } else { + fprintf(stderr, "Invalid IP address %s\n", value); + exit(1); + } + return (value_from_next); + invalid_option: + default: + fprintf(stderr, "Invalid option: -%s\n", option); + usage(); + } + return (ISC_FALSE); +} + +/* + * Because we may be trying to do memory allocation recording, we're going + * to need to parse the arguments for the -m *before* we start the main + * argument parsing routine. + * I'd prefer not to have to do this, but I am not quite sure how else to + * fix the problem. Argument parsing in dig involves memory allocation + * by its nature, so it can't be done in the main argument parser. + */ +static void +preparse_args(int argc, char **argv) { + int rc; + char **rv; + char *option; + + rc = argc; + rv = argv; + for (rc--, rv++; rc > 0; rc--, rv++) { + if (rv[0][0] != '-') + continue; + option = &rv[0][1]; + while (strpbrk(option, single_dash_opts) == &option[0]) { + if (option[0] == 'm') { + memdebugging = ISC_TRUE; + isc_mem_debugging = ISC_MEM_DEBUGTRACE | + ISC_MEM_DEBUGRECORD; + return; + } + option = &option[1]; + } + } +} + +static void +parse_args(isc_boolean_t is_batchfile, isc_boolean_t config_only, + int argc, char **argv) { + isc_result_t result; + isc_textregion_t tr; + isc_boolean_t firstarg = ISC_TRUE; + dig_server_t *srv = NULL; + dig_lookup_t *lookup = NULL; + dns_rdatatype_t rdtype; + dns_rdataclass_t rdclass; + isc_boolean_t open_type_class = ISC_TRUE; + char batchline[MXNAME]; + int bargc; + char *bargv[64]; + int rc; + char **rv; +#ifndef NOPOSIX + char *homedir; + char rcfile[256]; +#endif + char *input; + + /* + * The semantics for parsing the args is a bit complex; if + * we don't have a host yet, make the arg apply globally, + * otherwise make it apply to the latest host. This is + * a bit different than the previous versions, but should + * form a consistent user interface. + * + * First, create a "default lookup" which won't actually be used + * anywhere, except for cloning into new lookups + */ + + debug("parse_args()"); + if (!is_batchfile) { + debug("making new lookup"); + default_lookup = make_empty_lookup(); + +#ifndef NOPOSIX + /* + * Treat ${HOME}/.digrc as a special batchfile + */ + INSIST(batchfp == NULL); + homedir = getenv("HOME"); + if (homedir != NULL) { + unsigned int n; + n = snprintf(rcfile, sizeof(rcfile), "%s/.digrc", + homedir); + if (n < sizeof(rcfile)) + batchfp = fopen(rcfile, "r"); + } + if (batchfp != NULL) { + while (fgets(batchline, sizeof(batchline), + batchfp) != 0) { + debug("config line %s", batchline); + bargc = 1; + input = batchline; + bargv[bargc] = next_token(&input, " \t\r\n"); + while ((bargv[bargc] != NULL) && + (bargc < 62)) { + bargc++; + bargv[bargc] = + next_token(&input, " \t\r\n"); + } + + bargv[0] = argv[0]; + argv0 = argv[0]; + + reorder_args(bargc, (char **)bargv); + parse_args(ISC_TRUE, ISC_TRUE, bargc, + (char **)bargv); + } + fclose(batchfp); + } +#endif + } + + lookup = default_lookup; + + rc = argc; + rv = argv; + for (rc--, rv++; rc > 0; rc--, rv++) { + debug("main parsing %s", rv[0]); + if (strncmp(rv[0], "%", 1) == 0) + break; + if (strncmp(rv[0], "@", 1) == 0) { + srv = make_server(&rv[0][1]); + ISC_LIST_APPEND(lookup->my_server_list, + srv, link); + } else if (rv[0][0] == '+') { + plus_option(&rv[0][1], is_batchfile, + lookup); + } else if (rv[0][0] == '-') { + if (rc <= 1) { + if (dash_option(&rv[0][1], NULL, + &lookup, &open_type_class, + &firstarg, argc, argv)) { + rc--; + rv++; + } + } else { + if (dash_option(&rv[0][1], rv[1], + &lookup, &open_type_class, + &firstarg, argc, argv)) { + rc--; + rv++; + } + } + } else { + /* + * Anything which isn't an option + */ + if (open_type_class) { + if (strncmp(rv[0], "ixfr=", 5) == 0) { + rdtype = dns_rdatatype_ixfr; + result = ISC_R_SUCCESS; + } else { + tr.base = rv[0]; + tr.length = strlen(rv[0]); + result = dns_rdatatype_fromtext(&rdtype, + (isc_textregion_t *)&tr); + if (result == ISC_R_SUCCESS && + rdtype == dns_rdatatype_ixfr) { + result = DNS_R_UNKNOWN; + fprintf(stderr, ";; Warning, " + "ixfr requires a " + "serial number\n"); + continue; + } + } + if (result == ISC_R_SUCCESS) { + if (lookup->rdtypeset) { + fprintf(stderr, ";; Warning, " + "extra type option\n"); + } + if (rdtype == dns_rdatatype_ixfr) { + lookup->rdtype = + dns_rdatatype_ixfr; + lookup->rdtypeset = ISC_TRUE; + lookup->ixfr_serial = + parse_uint(&rv[0][5], + "serial number", + MAXSERIAL); + lookup->section_question = + plusquest; + lookup->comments = pluscomm; + } else { + lookup->rdtype = rdtype; + lookup->rdtypeset = ISC_TRUE; + if (rdtype == + dns_rdatatype_axfr) { + lookup->section_question = + plusquest; + lookup->comments = pluscomm; + } + lookup->ixfr_serial = ISC_FALSE; + } + continue; + } + result = dns_rdataclass_fromtext(&rdclass, + (isc_textregion_t *)&tr); + if (result == ISC_R_SUCCESS) { + if (lookup->rdclassset) { + fprintf(stderr, ";; Warning, " + "extra class option\n"); + } + lookup->rdclass = rdclass; + lookup->rdclassset = ISC_TRUE; + continue; + } + } + if (!config_only) { + lookup = clone_lookup(default_lookup, + ISC_TRUE); + if (firstarg) { + printgreeting(argc, argv, lookup); + firstarg = ISC_FALSE; + } + strncpy(lookup->textname, rv[0], + sizeof(lookup->textname)); + lookup->textname[sizeof(lookup->textname)-1]=0; + lookup->trace_root = ISC_TF(lookup->trace || + lookup->ns_search_only); + lookup->new_search = ISC_TRUE; + ISC_LIST_APPEND(lookup_list, lookup, link); + debug("looking up %s", lookup->textname); + } + /* XXX Error message */ + } + } + /* + * If we have a batchfile, seed the lookup list with the + * first entry, then trust the callback in dighost_shutdown + * to get the rest + */ + if ((batchname != NULL) && !(is_batchfile)) { + if (strcmp(batchname, "-") == 0) + batchfp = stdin; + else + batchfp = fopen(batchname, "r"); + if (batchfp == NULL) { + perror(batchname); + if (exitcode < 8) + exitcode = 8; + fatal("couldn't open specified batch file"); + } + /* XXX Remove code dup from shutdown code */ + next_line: + if (fgets(batchline, sizeof(batchline), batchfp) != 0) { + bargc = 1; + debug("batch line %s", batchline); + if (batchline[0] == '\r' || batchline[0] == '\n' + || batchline[0] == '#' || batchline[0] == ';') + goto next_line; + input = batchline; + bargv[bargc] = next_token(&input, " \t\r\n"); + while ((bargv[bargc] != NULL) && (bargc < 14)) { + bargc++; + bargv[bargc] = next_token(&input, " \t\r\n"); + } + + bargv[0] = argv[0]; + argv0 = argv[0]; + + reorder_args(bargc, (char **)bargv); + parse_args(ISC_TRUE, ISC_FALSE, bargc, (char **)bargv); + } + } + /* + * If no lookup specified, search for root + */ + if ((lookup_list.head == NULL) && !config_only) { + lookup = clone_lookup(default_lookup, ISC_TRUE); + lookup->trace_root = ISC_TF(lookup->trace || + lookup->ns_search_only); + lookup->new_search = ISC_TRUE; + strcpy(lookup->textname, "."); + lookup->rdtype = dns_rdatatype_ns; + lookup->rdtypeset = ISC_TRUE; + if (firstarg) { + printgreeting(argc, argv, lookup); + firstarg = ISC_FALSE; + } + ISC_LIST_APPEND(lookup_list, lookup, link); + } +} + +/* + * Callback from dighost.c to allow program-specific shutdown code. + * Here, we're possibly reading from a batch file, then shutting down + * for real if there's nothing in the batch file to read. + */ +void +dighost_shutdown(void) { + char batchline[MXNAME]; + int bargc; + char *bargv[16]; + char *input; + + + if (batchname == NULL) { + isc_app_shutdown(); + return; + } + + fflush(stdout); + if (feof(batchfp)) { + batchname = NULL; + isc_app_shutdown(); + if (batchfp != stdin) + fclose(batchfp); + return; + } + + if (fgets(batchline, sizeof(batchline), batchfp) != 0) { + debug("batch line %s", batchline); + bargc = 1; + input = batchline; + bargv[bargc] = next_token(&input, " \t\r\n"); + while ((bargv[bargc] != NULL) && (bargc < 14)) { + bargc++; + bargv[bargc] = next_token(&input, " \t\r\n"); + } + + bargv[0] = argv0; + + reorder_args(bargc, (char **)bargv); + parse_args(ISC_TRUE, ISC_FALSE, bargc, (char **)bargv); + start_lookup(); + } else { + batchname = NULL; + if (batchfp != stdin) + fclose(batchfp); + isc_app_shutdown(); + return; + } +} + +int +main(int argc, char **argv) { + isc_result_t result; + dig_server_t *s, *s2; + + ISC_LIST_INIT(lookup_list); + ISC_LIST_INIT(server_list); + ISC_LIST_INIT(search_list); + + debug("main()"); + preparse_args(argc, argv); + progname = argv[0]; + result = isc_app_start(); + check_result(result, "isc_app_start"); + setup_libs(); + parse_args(ISC_FALSE, ISC_FALSE, argc, argv); + setup_system(); + if (domainopt[0] != '\0') { + set_search_domain(domainopt); + usesearch = ISC_TRUE; + } + result = isc_app_onrun(mctx, global_task, onrun_callback, NULL); + check_result(result, "isc_app_onrun"); + isc_app_run(); + s = ISC_LIST_HEAD(default_lookup->my_server_list); + while (s != NULL) { + debug("freeing server %p belonging to %p", + s, default_lookup); + s2 = s; + s = ISC_LIST_NEXT(s, link); + ISC_LIST_DEQUEUE(default_lookup->my_server_list, s2, link); + isc_mem_free(mctx, s2); + } + isc_mem_free(mctx, default_lookup); + if (batchname != NULL) { + if (batchfp != stdin) + fclose(batchfp); + batchname = NULL; + } +#ifdef DIG_SIGCHASE + clean_trustedkey(); +#endif + cancel_all(); + destroy_libs(); + isc_app_finish(); + return (exitcode); +} diff --git a/contrib/bind9/bin/dig/dig.docbook b/contrib/bind9/bin/dig/dig.docbook new file mode 100644 index 000000000000..d22ae87064d0 --- /dev/null +++ b/contrib/bind9/bin/dig/dig.docbook @@ -0,0 +1,611 @@ + + + + + + + + +Jun 30, 2000 + + + +dig +1 +BIND9 + + + +dig +DNS lookup utility + + + + +dig +@server + + + + + + + + + + +name +type +class +queryopt + + + +dig + + + + +dig +global-queryopt +query + + + + +DESCRIPTION + +dig (domain information groper) is a flexible tool +for interrogating DNS name servers. It performs DNS lookups and +displays the answers that are returned from the name server(s) that +were queried. Most DNS administrators use dig to +troubleshoot DNS problems because of its flexibility, ease of use and +clarity of output. Other lookup tools tend to have less functionality +than dig. + + + +Although dig is normally used with command-line +arguments, it also has a batch mode of operation for reading lookup +requests from a file. A brief summary of its command-line arguments +and options is printed when the option is given. +Unlike earlier versions, the BIND9 implementation of +dig allows multiple lookups to be issued from the +command line. + + + +Unless it is told to query a specific name server, +dig will try each of the servers listed in +/etc/resolv.conf. + + + +When no command line arguments or options are given, will perform an +NS query for "." (the root). + + + +It is possible to set per-user defaults for dig via +${HOME}/.digrc. This file is read and any options in it +are applied before the command line arguments. + + + + + +SIMPLE USAGE + + +A typical invocation of dig looks like: + dig @server name type where: + + + +server + +is the name or IP address of the name server to query. This can be an IPv4 +address in dotted-decimal notation or an IPv6 +address in colon-delimited notation. When the supplied +server argument is a hostname, +dig resolves that name before querying that name +server. If no server argument is provided, +dig consults /etc/resolv.conf +and queries the name servers listed there. The reply from the name +server that responds is displayed. + + +name + +is the name of the resource record that is to be looked up. + + +type + +indicates what type of query is required — +ANY, A, MX, SIG, etc. +type can be any valid query type. If no +type argument is supplied, +dig will perform a lookup for an A record. + + + + + + + + +OPTIONS + + +The option sets the source IP address of the query +to address. This must be a valid address on +one of the host's network interfaces or "0.0.0.0" or "::". An optional port +may be specified by appending "#<port>" + + + +The default query class (IN for internet) is overridden by the + option. class is any valid +class, such as HS for Hesiod records or CH for CHAOSNET records. + + + +The option makes dig operate +in batch mode by reading a list of lookup requests to process from the +file filename. The file contains a number of +queries, one per line. Each entry in the file should be organised in +the same way they would be presented as queries to +dig using the command-line interface. + + + +If a non-standard port number is to be queried, the + option is used. port# is +the port number that dig will send its queries +instead of the standard DNS port number 53. This option would be used +to test a name server that has been configured to listen for queries +on a non-standard port number. + + + +The option forces dig to only +use IPv4 query transport. The option forces +dig to only use IPv6 query transport. + + + +The option sets the query type to +type. It can be any valid query type which is +supported in BIND9. The default query type "A", unless the + option is supplied to indicate a reverse lookup. +A zone transfer can be requested by specifying a type of AXFR. When +an incremental zone transfer (IXFR) is required, +type is set to ixfr=N. +The incremental zone transfer will contain the changes made to the zone +since the serial number in the zone's SOA record was +N. + + + +Reverse lookups - mapping addresses to names - are simplified by the + option. addr is an IPv4 +address in dotted-decimal notation, or a colon-delimited IPv6 address. +When this option is used, there is no need to provide the +name, class and +type arguments. dig +automatically performs a lookup for a name like +11.12.13.10.in-addr.arpa and sets the query type and +class to PTR and IN respectively. By default, IPv6 addresses are +looked up using nibble format under the IP6.ARPA domain. +To use the older RFC1886 method using the IP6.INT domain +specify the option. Bit string labels (RFC2874) +are now experimental and are not attempted. + + + +To sign the DNS queries sent by dig and their +responses using transaction signatures (TSIG), specify a TSIG key file +using the option. You can also specify the TSIG +key itself on the command line using the option; +name is the name of the TSIG key and +key is the actual key. The key is a base-64 +encoded string, typically generated by +dnssec-keygen8 +. + +Caution should be taken when using the option on +multi-user systems as the key can be visible in the output from + ps1 + or in the shell's history file. When +using TSIG authentication with dig, the name +server that is queried needs to know the key and algorithm that is +being used. In BIND, this is done by providing appropriate +key and server statements in +named.conf. + + + + + +QUERY OPTIONS + + +dig provides a number of query options which affect +the way in which lookups are made and the results displayed. Some of +these set or reset flag bits in the query header, some determine which +sections of the answer get printed, and others determine the timeout +and retry strategies. + + + +Each query option is identified by a keyword preceded by a plus sign +(+). Some keywords set or reset an option. These may be preceded +by the string no to negate the meaning of that keyword. Other +keywords assign values to options like the timeout interval. They +have the form . +The query options are: + + + + + +Use [do not use] TCP when querying name servers. The default +behaviour is to use UDP unless an AXFR or IXFR query is requested, in +which case a TCP connection is used. + + + + +Use [do not use] TCP when querying name servers. This alternate +syntax to +[no]tcp is provided for backwards +compatibility. The "vc" stands for "virtual circuit". + + + + +Ignore truncation in UDP responses instead of retrying with TCP. By +default, TCP retries are performed. + + + + +Set the search list to contain the single domain +somename, as if specified in a +domain directive in +/etc/resolv.conf, and enable search list +processing as if the +search option were given. + + + + +Use [do not use] the search list defined by the searchlist or domain +directive in resolv.conf (if any). +The search list is not used by default. + + + + +Deprecated, treated as a synonym for +[no]search + + + + +Sets the "aa" flag in the query. + + + + +A synonym for +[no]aaonly. + + + + +Set [do not set] the AD (authentic data) bit in the query. The AD bit +currently has a standard meaning only in responses, not in queries, +but the ability to set the bit in the query is provided for +completeness. + + + + +Set [do not set] the CD (checking disabled) bit in the query. This +requests the server to not perform DNSSEC validation of responses. + + + + +Display [do not display] the CLASS when printing the record. + + + + +Display [do not display] the TTL when printing the record. + + + + +Toggle the setting of the RD (recursion desired) bit in the query. +This bit is set by default, which means dig +normally sends recursive queries. Recursion is automatically disabled +when the +nssearch or ++trace query options are used. + + + + +When this option is set, dig attempts to find the +authoritative name servers for the zone containing the name being +looked up and display the SOA record that each name server has for the +zone. + + + + +Toggle tracing of the delegation path from the root name servers for +the name being looked up. Tracing is disabled by default. When +tracing is enabled, dig makes iterative queries to +resolve the name being looked up. It will follow referrals from the +root servers, showing the answer from each server that was used to +resolve the lookup. + + + + +toggles the printing of the initial comment in the output identifying +the version of dig and the query options that have +been applied. This comment is printed by default. + + + + +Provide a terse answer. The default is to print the answer in a +verbose form. + + + + +Show [or do not show] the IP address and port number that supplied the +answer when the +short option is enabled. If +short form answers are requested, the default is not to show the +source address and port number of the server that provided the answer. + + + + +Toggle the display of comment lines in the output. The default is to +print comments. + + + + +This query option toggles the printing of statistics: when the query +was made, the size of the reply and so on. The default behaviour is +to print the query statistics. + + + + +Print [do not print] the query as it is sent. +By default, the query is not printed. + + + + +Print [do not print] the question section of a query when an answer is +returned. The default is to print the question section as a comment. + + + + +Display [do not display] the answer section of a reply. The default +is to display it. + + + + +Display [do not display] the authority section of a reply. The +default is to display it. + + + + +Display [do not display] the additional section of a reply. +The default is to display it. + + + + +Set or clear all display flags. + + + + + +Sets the timeout for a query to +T seconds. The default time out is 5 seconds. +An attempt to set T to less than 1 will result +in a query timeout of 1 second being applied. + + + + +Sets the number of times to try UDP queries to server to +T instead of the default, 3. If +T is less than or equal to zero, the number of +tries is silently rounded up to 1. + + + + +Sets the number of times to retry UDP queries to server to +T instead of the default, 2. Unlike ++tries, this does not include the initial +query. + + + + +Set the number of dots that have to appear in +name to D for it to be +considered absolute. The default value is that defined using the +ndots statement in /etc/resolv.conf, or 1 if no +ndots statement is present. Names with fewer dots are interpreted as +relative names and will be searched for in the domains listed in the + or directive in +/etc/resolv.conf. + + + + +Set the UDP message buffer size advertised using EDNS0 to +B bytes. The maximum and minimum sizes of this +buffer are 65535 and 0 respectively. Values outside this range are +rounded up or down appropriately. + + + + + +Print records like the SOA records in a verbose multi-line +format with human-readable comments. The default is to print +each record on a single line, to facilitate machine parsing +of the dig output. + + + + +Do not try the next server if you receive a SERVFAIL. The default is +to not try the next server which is the reverse of normal stub resolver +behaviour. + + + + +Attempt to display the contents of messages which are malformed. +The default is to not display malformed answers. + + + + +Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) +in the OPT record in the additional section of the query. + + + + +Chase DNSSEC signature chains. Requires dig be compiled with +-DDIG_SIGCHASE. + + + + +Specify a trusted key to be used with . +Requires dig be compiled with -DDIG_SIGCHASE. + + + + +When chasing DNSSEC signature chains perform a top down validation. +Requires dig be compiled with -DDIG_SIGCHASE. + + + + + + + + + + +MULTIPLE QUERIES + + +The BIND 9 implementation of dig supports +specifying multiple queries on the command line (in addition to +supporting the batch file option). Each of those +queries can be supplied with its own set of flags, options and query +options. + + + +In this case, each query argument represent an +individual query in the command-line syntax described above. Each +consists of any of the standard options and flags, the name to be +looked up, an optional query type and class and any query options that +should be applied to that query. + + + +A global set of query options, which should be applied to all queries, +can also be supplied. These global query options must precede the +first tuple of name, class, type, options, flags, and query options +supplied on the command line. Any global query options (except +the option) can be +overridden by a query-specific set of query options. For example: + +dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr + +shows how dig could be used from the command line +to make three lookups: an ANY query for www.isc.org, a +reverse lookup of 127.0.0.1 and a query for the NS records of +isc.org. + +A global query option of +qr is applied, so +that dig shows the initial query it made for each +lookup. The final query has a local query option of ++noqr which means that dig +will not print the initial query when it looks up the NS records for +isc.org. + + + + + +FILES + +/etc/resolv.conf + + +${HOME}/.digrc + + + + +SEE ALSO + + +host1 +, + +named8 +, + +dnssec-keygen8 +, +RFC1035. + + + + +BUGS + +There are probably too many query options. + + + diff --git a/contrib/bind9/bin/dig/dig.html b/contrib/bind9/bin/dig/dig.html new file mode 100644 index 000000000000..e9e1fd4dc770 --- /dev/null +++ b/contrib/bind9/bin/dig/dig.html @@ -0,0 +1,1174 @@ + + + + + +dig

dig

Name

dig -- DNS lookup utility

Synopsis

dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-p port#] [-t type] [-x addr] [-y name:key] [-4] [-6] [name] [type] [class] [queryopt...]

dig [-h]

dig [global-queryopt...] [query...]

DESCRIPTION

dig (domain information groper) is a flexible tool +for interrogating DNS name servers. It performs DNS lookups and +displays the answers that are returned from the name server(s) that +were queried. Most DNS administrators use dig to +troubleshoot DNS problems because of its flexibility, ease of use and +clarity of output. Other lookup tools tend to have less functionality +than dig.

Although dig is normally used with command-line +arguments, it also has a batch mode of operation for reading lookup +requests from a file. A brief summary of its command-line arguments +and options is printed when the -h option is given. +Unlike earlier versions, the BIND9 implementation of +dig allows multiple lookups to be issued from the +command line.

Unless it is told to query a specific name server, +dig will try each of the servers listed in +/etc/resolv.conf.

When no command line arguments or options are given, will perform an +NS query for "." (the root).

It is possible to set per-user defaults for dig via +${HOME}/.digrc. This file is read and any options in it +are applied before the command line arguments.

SIMPLE USAGE

A typical invocation of dig looks like: +

 dig @server name type
where: + +

server

is the name or IP address of the name server to query. This can be an IPv4 +address in dotted-decimal notation or an IPv6 +address in colon-delimited notation. When the supplied +server argument is a hostname, +dig resolves that name before querying that name +server. If no server argument is provided, +dig consults /etc/resolv.conf +and queries the name servers listed there. The reply from the name +server that responds is displayed.

name

is the name of the resource record that is to be looked up.

type

indicates what type of query is required — +ANY, A, MX, SIG, etc. +type can be any valid query type. If no +type argument is supplied, +dig will perform a lookup for an A record.

OPTIONS

The -b option sets the source IP address of the query +to address. This must be a valid address on +one of the host's network interfaces or "0.0.0.0" or "::". An optional port +may be specified by appending "#<port>"

The default query class (IN for internet) is overridden by the +-c option. class is any valid +class, such as HS for Hesiod records or CH for CHAOSNET records.

The -f option makes dig operate +in batch mode by reading a list of lookup requests to process from the +file filename. The file contains a number of +queries, one per line. Each entry in the file should be organised in +the same way they would be presented as queries to +dig using the command-line interface.

If a non-standard port number is to be queried, the +-p option is used. port# is +the port number that dig will send its queries +instead of the standard DNS port number 53. This option would be used +to test a name server that has been configured to listen for queries +on a non-standard port number.

The -4 option forces dig to only +use IPv4 query transport. The -6 option forces +dig to only use IPv6 query transport.

The -t option sets the query type to +type. It can be any valid query type which is +supported in BIND9. The default query type "A", unless the +-x option is supplied to indicate a reverse lookup. +A zone transfer can be requested by specifying a type of AXFR. When +an incremental zone transfer (IXFR) is required, +type is set to ixfr=N. +The incremental zone transfer will contain the changes made to the zone +since the serial number in the zone's SOA record was +N.

Reverse lookups - mapping addresses to names - are simplified by the +-x option. addr is an IPv4 +address in dotted-decimal notation, or a colon-delimited IPv6 address. +When this option is used, there is no need to provide the +name, class and +type arguments. dig +automatically performs a lookup for a name like +11.12.13.10.in-addr.arpa and sets the query type and +class to PTR and IN respectively. By default, IPv6 addresses are +looked up using nibble format under the IP6.ARPA domain. +To use the older RFC1886 method using the IP6.INT domain +specify the -i option. Bit string labels (RFC2874) +are now experimental and are not attempted.

To sign the DNS queries sent by dig and their +responses using transaction signatures (TSIG), specify a TSIG key file +using the -k option. You can also specify the TSIG +key itself on the command line using the -y option; +name is the name of the TSIG key and +key is the actual key. The key is a base-64 +encoded string, typically generated by dnssec-keygen(8). + +Caution should be taken when using the -y option on +multi-user systems as the key can be visible in the output from +ps(1) or in the shell's history file. When +using TSIG authentication with dig, the name +server that is queried needs to know the key and algorithm that is +being used. In BIND, this is done by providing appropriate +key and server statements in +named.conf.

QUERY OPTIONS

dig provides a number of query options which affect +the way in which lookups are made and the results displayed. Some of +these set or reset flag bits in the query header, some determine which +sections of the answer get printed, and others determine the timeout +and retry strategies.

Each query option is identified by a keyword preceded by a plus sign +(+). Some keywords set or reset an option. These may be preceded +by the string no to negate the meaning of that keyword. Other +keywords assign values to options like the timeout interval. They +have the form +keyword=value. +The query options are: + +

+[no]tcp

Use [do not use] TCP when querying name servers. The default +behaviour is to use UDP unless an AXFR or IXFR query is requested, in +which case a TCP connection is used.

+[no]vc

Use [do not use] TCP when querying name servers. This alternate +syntax to +[no]tcp is provided for backwards +compatibility. The "vc" stands for "virtual circuit".

+[no]ignore

Ignore truncation in UDP responses instead of retrying with TCP. By +default, TCP retries are performed.

+domain=somename

Set the search list to contain the single domain +somename, as if specified in a +domain directive in +/etc/resolv.conf, and enable search list +processing as if the +search option were given.

+[no]search

Use [do not use] the search list defined by the searchlist or domain +directive in resolv.conf (if any). +The search list is not used by default.

+[no]defname

Deprecated, treated as a synonym for +[no]search

+[no]aaonly

Sets the "aa" flag in the query.

+[no]aaflag

A synonym for +[no]aaonly.

+[no]adflag

Set [do not set] the AD (authentic data) bit in the query. The AD bit +currently has a standard meaning only in responses, not in queries, +but the ability to set the bit in the query is provided for +completeness.

+[no]cdflag

Set [do not set] the CD (checking disabled) bit in the query. This +requests the server to not perform DNSSEC validation of responses.

+[no]cl

Display [do not display] the CLASS when printing the record.

+[no]ttlid

Display [do not display] the TTL when printing the record.

+[no]recurse

Toggle the setting of the RD (recursion desired) bit in the query. +This bit is set by default, which means dig +normally sends recursive queries. Recursion is automatically disabled +when the +nssearch or ++trace query options are used.

+[no]nssearch

When this option is set, dig attempts to find the +authoritative name servers for the zone containing the name being +looked up and display the SOA record that each name server has for the +zone.

+[no]trace

Toggle tracing of the delegation path from the root name servers for +the name being looked up. Tracing is disabled by default. When +tracing is enabled, dig makes iterative queries to +resolve the name being looked up. It will follow referrals from the +root servers, showing the answer from each server that was used to +resolve the lookup.

+[no]cmd

toggles the printing of the initial comment in the output identifying +the version of dig and the query options that have +been applied. This comment is printed by default.

+[no]short

Provide a terse answer. The default is to print the answer in a +verbose form.

+[no]identify

Show [or do not show] the IP address and port number that supplied the +answer when the +short option is enabled. If +short form answers are requested, the default is not to show the +source address and port number of the server that provided the answer.

+[no]comments

Toggle the display of comment lines in the output. The default is to +print comments.

+[no]stats

This query option toggles the printing of statistics: when the query +was made, the size of the reply and so on. The default behaviour is +to print the query statistics.

+[no]qr

Print [do not print] the query as it is sent. +By default, the query is not printed.

+[no]question

Print [do not print] the question section of a query when an answer is +returned. The default is to print the question section as a comment.

+[no]answer

Display [do not display] the answer section of a reply. The default +is to display it.

+[no]authority

Display [do not display] the authority section of a reply. The +default is to display it.

+[no]additional

Display [do not display] the additional section of a reply. +The default is to display it.

+[no]all

Set or clear all display flags.

+time=T

Sets the timeout for a query to +T seconds. The default time out is 5 seconds. +An attempt to set T to less than 1 will result +in a query timeout of 1 second being applied.

+tries=T

Sets the number of times to try UDP queries to server to +T instead of the default, 3. If +T is less than or equal to zero, the number of +tries is silently rounded up to 1.

+retry=T

Sets the number of times to retry UDP queries to server to +T instead of the default, 2. Unlike ++tries, this does not include the initial +query.

+ndots=D

Set the number of dots that have to appear in +name to D for it to be +considered absolute. The default value is that defined using the +ndots statement in /etc/resolv.conf, or 1 if no +ndots statement is present. Names with fewer dots are interpreted as +relative names and will be searched for in the domains listed in the +search or domain directive in +/etc/resolv.conf.

+bufsize=B

Set the UDP message buffer size advertised using EDNS0 to +B bytes. The maximum and minimum sizes of this +buffer are 65535 and 0 respectively. Values outside this range are +rounded up or down appropriately.

+[no]multiline

Print records like the SOA records in a verbose multi-line +format with human-readable comments. The default is to print +each record on a single line, to facilitate machine parsing +of the dig output.

+[no]fail

Do not try the next server if you receive a SERVFAIL. The default is +to not try the next server which is the reverse of normal stub resolver +behaviour.

+[no]besteffort

Attempt to display the contents of messages which are malformed. +The default is to not display malformed answers.

+[no]dnssec

Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) +in the OPT record in the additional section of the query.

+[no]sigchase

Chase DNSSEC signature chains. Requires dig be compiled with +-DDIG_SIGCHASE.

+trusted-key=####

Specify a trusted key to be used with +sigchase. +Requires dig be compiled with -DDIG_SIGCHASE.

+[no]topdown

When chasing DNSSEC signature chains perform a top down validation. +Requires dig be compiled with -DDIG_SIGCHASE.

MULTIPLE QUERIES

The BIND 9 implementation of dig supports +specifying multiple queries on the command line (in addition to +supporting the -f batch file option). Each of those +queries can be supplied with its own set of flags, options and query +options.

In this case, each query argument represent an +individual query in the command-line syntax described above. Each +consists of any of the standard options and flags, the name to be +looked up, an optional query type and class and any query options that +should be applied to that query.

A global set of query options, which should be applied to all queries, +can also be supplied. These global query options must precede the +first tuple of name, class, type, options, flags, and query options +supplied on the command line. Any global query options (except +the +[no]cmd option) can be +overridden by a query-specific set of query options. For example: +

dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
+shows how dig could be used from the command line +to make three lookups: an ANY query for www.isc.org, a +reverse lookup of 127.0.0.1 and a query for the NS records of +isc.org. + +A global query option of +qr is applied, so +that dig shows the initial query it made for each +lookup. The final query has a local query option of ++noqr which means that dig +will not print the initial query when it looks up the NS records for +isc.org.

FILES

/etc/resolv.conf

${HOME}/.digrc

SEE ALSO

host(1), +named(8), +dnssec-keygen(8), +RFC1035.

BUGS

There are probably too many query options.

diff --git a/contrib/bind9/bin/dig/dighost.c b/contrib/bind9/bin/dig/dighost.c new file mode 100644 index 000000000000..dd49b5b37877 --- /dev/null +++ b/contrib/bind9/bin/dig/dighost.c @@ -0,0 +1,5074 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dighost.c,v 1.221.2.19.2.14 2004/06/30 23:57:52 marka Exp $ */ + +/* + * Notice to programmers: Do not use this code as an example of how to + * use the ISC library to perform DNS lookups. Dig and Host both operate + * on the request level, since they allow fine-tuning of output and are + * intended as debugging tools. As a result, they perform many of the + * functions which could be better handled using the dns_resolver + * functions in most applications. + */ + +#include +#include +#include +#include +#include + +#include +#ifdef DIG_SIGCHASE +#include +#include +#include +#include +#include +#include +#endif +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#ifdef DIG_SIGCHASE +#include +#endif +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include + +#include + +#if ! defined(NS_INADDRSZ) +#define NS_INADDRSZ 4 +#endif + +#if ! defined(NS_IN6ADDRSZ) +#define NS_IN6ADDRSZ 16 +#endif + +static lwres_context_t *lwctx = NULL; +static lwres_conf_t *lwconf; + +ISC_LIST(dig_lookup_t) lookup_list; +dig_serverlist_t server_list; +ISC_LIST(dig_searchlist_t) search_list; + +isc_boolean_t + have_ipv4 = ISC_FALSE, + have_ipv6 = ISC_FALSE, + specified_source = ISC_FALSE, + free_now = ISC_FALSE, + cancel_now = ISC_FALSE, + usesearch = ISC_FALSE, + qr = ISC_FALSE, + is_dst_up = ISC_FALSE; +in_port_t port = 53; +unsigned int timeout = 0; +isc_mem_t *mctx = NULL; +isc_taskmgr_t *taskmgr = NULL; +isc_task_t *global_task = NULL; +isc_timermgr_t *timermgr = NULL; +isc_socketmgr_t *socketmgr = NULL; +isc_sockaddr_t bind_address; +isc_sockaddr_t bind_any; +int sendcount = 0; +int recvcount = 0; +int sockcount = 0; +int ndots = -1; +int tries = 3; +int lookup_counter = 0; + +/* + * Exit Codes: + * 0 Everything went well, including things like NXDOMAIN + * 1 Usage error + * 7 Got too many RR's or Names + * 8 Couldn't open batch file + * 9 No reply from server + * 10 Internal error + */ +int exitcode = 0; +int fatalexit = 0; +char keynametext[MXNAME]; +char keyfile[MXNAME] = ""; +char keysecret[MXNAME] = ""; +isc_buffer_t *namebuf = NULL; +dns_tsigkey_t *key = NULL; +isc_boolean_t validated = ISC_TRUE; +isc_entropy_t *entp = NULL; +isc_mempool_t *commctx = NULL; +isc_boolean_t debugging = ISC_FALSE; +isc_boolean_t memdebugging = ISC_FALSE; +char *progname = NULL; +isc_mutex_t lookup_lock; +dig_lookup_t *current_lookup = NULL; + +#ifdef DIG_SIGCHASE + +isc_result_t get_trusted_key(isc_mem_t *mctx); +dns_rdataset_t * sigchase_scanname(dns_rdatatype_t type, + dns_rdatatype_t covers, + isc_boolean_t *lookedup, + dns_name_t *rdata_name); +dns_rdataset_t * chase_scanname_section(dns_message_t *msg, + dns_name_t *name, + dns_rdatatype_t type, + dns_rdatatype_t covers, + int section); +isc_result_t advanced_rrsearch(dns_rdataset_t **rdataset, + dns_name_t *name, + dns_rdatatype_t type, + dns_rdatatype_t covers, + isc_boolean_t *lookedup); +isc_result_t sigchase_verify_sig_key(dns_name_t *name, + dns_rdataset_t *rdataset, + dst_key_t* dnsseckey, + dns_rdataset_t *sigrdataset, + isc_mem_t *mctx); +isc_result_t sigchase_verify_sig(dns_name_t *name, + dns_rdataset_t *rdataset, + dns_rdataset_t *keyrdataset, + dns_rdataset_t *sigrdataset, + isc_mem_t *mctx); +isc_result_t sigchase_verify_ds(dns_name_t *name, + dns_rdataset_t *keyrdataset, + dns_rdataset_t *dsrdataset, + isc_mem_t *mctx); +void sigchase(dns_message_t *msg); +void print_rdata(dns_rdata_t *rdata, isc_mem_t *mctx); +void print_rdataset(dns_name_t *name, + dns_rdataset_t *rdataset, isc_mem_t *mctx); +void dup_name(dns_name_t *source, dns_name_t* target, + isc_mem_t *mctx); +void dump_database(void); +void dump_database_section(dns_message_t *msg, int section); +dns_rdataset_t * search_type(dns_name_t *name, dns_rdatatype_t type, + dns_rdatatype_t covers); +isc_result_t contains_trusted_key(dns_name_t *name, + dns_rdataset_t *rdataset, + dns_rdataset_t *sigrdataset, + isc_mem_t *mctx); +void print_type(dns_rdatatype_t type); +isc_result_t prove_nx_domain(dns_message_t * msg, + dns_name_t * name, + dns_name_t * rdata_name, + dns_rdataset_t ** rdataset, + dns_rdataset_t ** sigrdataset); +isc_result_t prove_nx_type(dns_message_t * msg, dns_name_t *name, + dns_rdataset_t *nsec, + dns_rdataclass_t class, + dns_rdatatype_t type, + dns_name_t * rdata_name, + dns_rdataset_t ** rdataset, + dns_rdataset_t ** sigrdataset); +isc_result_t prove_nx(dns_message_t * msg, dns_name_t * name, + dns_rdataclass_t class, + dns_rdatatype_t type, + dns_name_t * rdata_name, + dns_rdataset_t ** rdataset, + dns_rdataset_t ** sigrdataset); +static void nameFromString(const char *str, dns_name_t *p_ret); +int inf_name(dns_name_t * name1, dns_name_t * name2); +isc_result_t opentmpkey(isc_mem_t *mctx, const char *file, + char **tempp, FILE **fp); +isc_result_t removetmpkey(isc_mem_t *mctx, const char *file); +void clean_trustedkey(void ); +void insert_trustedkey(dst_key_t * key); +#if DIG_SIGCHASE_BU +isc_result_t getneededrr(dns_message_t *msg); +void sigchase_bottom_up(dns_message_t *msg); +void sigchase_bu(dns_message_t *msg); +#endif +#if DIG_SIGCHASE_TD +isc_result_t initialization(dns_name_t *name); +isc_result_t prepare_lookup(dns_name_t *name); +isc_result_t grandfather_pb_test(dns_name_t * zone_name, + dns_rdataset_t *sigrdataset); +isc_result_t child_of_zone(dns_name_t *name, + dns_name_t *zone_name, + dns_name_t *child_name); +void sigchase_td(dns_message_t *msg); +#endif +char trustedkey[MXNAME] = ""; + +dns_rdataset_t * chase_rdataset = NULL; +dns_rdataset_t * chase_sigrdataset = NULL; +dns_rdataset_t * chase_dsrdataset = NULL; +dns_rdataset_t * chase_sigdsrdataset = NULL; +dns_rdataset_t * chase_keyrdataset = NULL; +dns_rdataset_t * chase_sigkeyrdataset = NULL; +dns_rdataset_t * chase_nsrdataset = NULL; + +dns_name_t chase_name; /* the query name */ +#if DIG_SIGCHASE_TD +/* + * the current name is the parent name when we follow delegation + */ +dns_name_t chase_current_name; +/* + * the child name is used for delegation (NS DS responses in AUTHORITY section) + */ +dns_name_t chase_authority_name; +#endif +#if DIG_SIGCHASE_BU +dns_name_t chase_signame; +#endif + + +isc_boolean_t chase_siglookedup = ISC_FALSE; +isc_boolean_t chase_keylookedup = ISC_FALSE; +isc_boolean_t chase_sigkeylookedup = ISC_FALSE; +isc_boolean_t chase_dslookedup = ISC_FALSE; +isc_boolean_t chase_sigdslookedup = ISC_FALSE; +#if DIG_SIGCHASE_TD +isc_boolean_t chase_nslookedup = ISC_FALSE; +isc_boolean_t chase_lookedup = ISC_FALSE; + + +isc_boolean_t delegation_follow = ISC_FALSE; +isc_boolean_t grandfather_pb = ISC_FALSE; +isc_boolean_t have_response = ISC_FALSE; +isc_boolean_t have_delegation_ns = ISC_FALSE; +dns_message_t * error_message = NULL; +#endif + +isc_boolean_t dsvalidating = ISC_FALSE; +isc_boolean_t chase_name_dup = ISC_FALSE; + +ISC_LIST(dig_message_t) chase_message_list; +ISC_LIST(dig_message_t) chase_message_list2; + + +#define MAX_TRUSTED_KEY 5 +typedef struct struct_trusted_key_list { + dst_key_t * key[MAX_TRUSTED_KEY]; + int nb_tk; +} struct_tk_list; + +struct_tk_list tk_list = { {NULL, NULL, NULL, NULL, NULL}, 0}; + +#endif + +/* + * Apply and clear locks at the event level in global task. + * Can I get rid of these using shutdown events? XXX + */ +#define LOCK_LOOKUP {\ + debug("lock_lookup %s:%d", __FILE__, __LINE__);\ + check_result(isc_mutex_lock((&lookup_lock)), "isc_mutex_lock");\ + debug("success");\ +} +#define UNLOCK_LOOKUP {\ + debug("unlock_lookup %s:%d", __FILE__, __LINE__);\ + check_result(isc_mutex_unlock((&lookup_lock)),\ + "isc_mutex_unlock");\ +} + +static void +cancel_lookup(dig_lookup_t *lookup); + +static void +recv_done(isc_task_t *task, isc_event_t *event); + +static void +connect_timeout(isc_task_t *task, isc_event_t *event); + +static void +launch_next_query(dig_query_t *query, isc_boolean_t include_question); + + +static void * +mem_alloc(void *arg, size_t size) { + return (isc_mem_get(arg, size)); +} + +static void +mem_free(void *arg, void *mem, size_t size) { + isc_mem_put(arg, mem, size); +} + +char * +next_token(char **stringp, const char *delim) { + char *res; + + do { + res = strsep(stringp, delim); + if (res == NULL) + break; + } while (*res == '\0'); + return (res); +} + +static int +count_dots(char *string) { + char *s; + int i = 0; + + s = string; + while (*s != '\0') { + if (*s == '.') + i++; + s++; + } + return (i); +} + +static void +hex_dump(isc_buffer_t *b) { + unsigned int len; + isc_region_t r; + + isc_buffer_usedregion(b, &r); + + printf("%d bytes\n", r.length); + for (len = 0; len < r.length; len++) { + printf("%02x ", r.base[len]); + if (len % 16 == 15) + printf("\n"); + } + if (len % 16 != 0) + printf("\n"); +} + +/* + * Append 'len' bytes of 'text' at '*p', failing with + * ISC_R_NOSPACE if that would advance p past 'end'. + */ +static isc_result_t +append(const char *text, int len, char **p, char *end) { + if (len > end - *p) + return (ISC_R_NOSPACE); + memcpy(*p, text, len); + *p += len; + return (ISC_R_SUCCESS); +} + +static isc_result_t +reverse_octets(const char *in, char **p, char *end) { + char *dot = strchr(in, '.'); + int len; + if (dot != NULL) { + isc_result_t result; + result = reverse_octets(dot + 1, p, end); + if (result != ISC_R_SUCCESS) + return (result); + result = append(".", 1, p, end); + if (result != ISC_R_SUCCESS) + return (result); + len = dot - in; + } else { + len = strlen(in); + } + return (append(in, len, p, end)); +} + +isc_result_t +get_reverse(char *reverse, size_t len, char *value, isc_boolean_t ip6_int, + isc_boolean_t strict) +{ + int r; + isc_result_t result; + isc_netaddr_t addr; + + addr.family = AF_INET6; + r = inet_pton(AF_INET6, value, &addr.type.in6); + if (r > 0) { + /* This is a valid IPv6 address. */ + dns_fixedname_t fname; + dns_name_t *name; + unsigned int options = 0; + + if (ip6_int) + options |= DNS_BYADDROPT_IPV6INT; + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + result = dns_byaddr_createptrname2(&addr, options, name); + if (result != ISC_R_SUCCESS) + return (result); + dns_name_format(name, reverse, len); + return (ISC_R_SUCCESS); + } else { + /* + * Not a valid IPv6 address. Assume IPv4. + * If 'strict' is not set, construct the + * in-addr.arpa name by blindly reversing + * octets whether or not they look like integers, + * so that this can be used for RFC2317 names + * and such. + */ + char *p = reverse; + char *end = reverse + len; + if (strict && inet_pton(AF_INET, value, &addr.type.in) != 1) + return (DNS_R_BADDOTTEDQUAD); + result = reverse_octets(value, &p, end); + if (result != ISC_R_SUCCESS) + return (result); + /* Append .in-addr.arpa. and a terminating NUL. */ + result = append(".in-addr.arpa.", 15, &p, end); + if (result != ISC_R_SUCCESS) + return (result); + return (ISC_R_SUCCESS); + } +} + +void +fatal(const char *format, ...) { + va_list args; + + fprintf(stderr, "%s: ", progname); + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + fprintf(stderr, "\n"); + if (exitcode < 10) + exitcode = 10; + if (fatalexit != 0) + exitcode = fatalexit; + exit(exitcode); +} + +void +debug(const char *format, ...) { + va_list args; + + if (debugging) { + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + fprintf(stderr, "\n"); + } +} + +void +check_result(isc_result_t result, const char *msg) { + if (result != ISC_R_SUCCESS) { + fatal("%s: %s", msg, isc_result_totext(result)); + } +} + +/* + * Create a server structure, which is part of the lookup structure. + * This is little more than a linked list of servers to query in hopes + * of finding the answer the user is looking for + */ +dig_server_t * +make_server(const char *servname) { + dig_server_t *srv; + + REQUIRE(servname != NULL); + + debug("make_server(%s)", servname); + srv = isc_mem_allocate(mctx, sizeof(struct dig_server)); + if (srv == NULL) + fatal("memory allocation failure in %s:%d", + __FILE__, __LINE__); + strncpy(srv->servername, servname, MXNAME); + srv->servername[MXNAME-1] = 0; + ISC_LINK_INIT(srv, link); + return (srv); +} +static int +addr2af(int lwresaddrtype) +{ + int af = 0; + + switch (lwresaddrtype) { + case LWRES_ADDRTYPE_V4: + af = AF_INET; + break; + + case LWRES_ADDRTYPE_V6: + af = AF_INET6; + break; + } + + return (af); +} +/* + * Create a copy of the server list from the lwres configuration structure. + * The dest list must have already had ISC_LIST_INIT applied. + */ +static void +copy_server_list(lwres_conf_t *confdata, dig_serverlist_t *dest) { + dig_server_t *newsrv; + char tmp[sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255")]; + int af; + int i; + + debug("copy_server_list()"); + for (i = 0; i < confdata->nsnext; i++) { + af = addr2af(confdata->nameservers[i].family); + + lwres_net_ntop(af, confdata->nameservers[i].address, + tmp, sizeof(tmp)); + newsrv = make_server(tmp); + ISC_LINK_INIT(newsrv, link); + ISC_LIST_ENQUEUE(*dest, newsrv, link); + } +} +void +flush_server_list(void) { + dig_server_t *s, *ps; + + debug("flush_server_list()"); + s = ISC_LIST_HEAD(server_list); + while (s != NULL) { + ps = s; + s = ISC_LIST_NEXT(s, link); + ISC_LIST_DEQUEUE(server_list, ps, link); + isc_mem_free(mctx, ps); + } +} +void +set_nameserver(char *opt) { + dig_server_t *srv; + + if (opt == NULL) + return; + + flush_server_list(); + srv = make_server(opt); + if (srv == NULL) + fatal("memory allocation failure"); + ISC_LIST_INITANDAPPEND(server_list, srv, link); +} + +static isc_result_t +add_nameserver(lwres_conf_t *confdata, const char *addr, int af) { + + int i = confdata->nsnext; + + if (confdata->nsnext >= LWRES_CONFMAXNAMESERVERS) + return (ISC_R_FAILURE); + + switch (af) { + case AF_INET: + confdata->nameservers[i].family = LWRES_ADDRTYPE_V4; + confdata->nameservers[i].length = NS_INADDRSZ; + break; + case AF_INET6: + confdata->nameservers[i].family = LWRES_ADDRTYPE_V6; + confdata->nameservers[i].length = NS_IN6ADDRSZ; + break; + default: + return (ISC_R_FAILURE); + } + + if (lwres_net_pton(af, addr, &confdata->nameservers[i].address) == 1) { + confdata->nsnext++; + return (ISC_R_SUCCESS); + } + return (ISC_R_FAILURE); +} + +/* + * Produce a cloned server list. The dest list must have already had + * ISC_LIST_INIT applied. + */ +void +clone_server_list(dig_serverlist_t src, dig_serverlist_t *dest) { + dig_server_t *srv, *newsrv; + + debug("clone_server_list()"); + srv = ISC_LIST_HEAD(src); + while (srv != NULL) { + newsrv = make_server(srv->servername); + ISC_LINK_INIT(newsrv, link); + ISC_LIST_ENQUEUE(*dest, newsrv, link); + srv = ISC_LIST_NEXT(srv, link); + } +} + +/* + * Create an empty lookup structure, which holds all the information needed + * to get an answer to a user's question. This structure contains two + * linked lists: the server list (servers to query) and the query list + * (outstanding queries which have been made to the listed servers). + */ +dig_lookup_t * +make_empty_lookup(void) { + dig_lookup_t *looknew; + + debug("make_empty_lookup()"); + + INSIST(!free_now); + + looknew = isc_mem_allocate(mctx, sizeof(struct dig_lookup)); + if (looknew == NULL) + fatal("memory allocation failure in %s:%d", + __FILE__, __LINE__); + looknew->pending = ISC_TRUE; + looknew->textname[0] = 0; + looknew->cmdline[0] = 0; + looknew->rdtype = dns_rdatatype_a; + looknew->qrdtype = dns_rdatatype_a; + looknew->rdclass = dns_rdataclass_in; + looknew->rdtypeset = ISC_FALSE; + looknew->rdclassset = ISC_FALSE; + looknew->sendspace = NULL; + looknew->sendmsg = NULL; + looknew->name = NULL; + looknew->oname = NULL; + looknew->timer = NULL; + looknew->xfr_q = NULL; + looknew->current_query = NULL; + looknew->doing_xfr = ISC_FALSE; + looknew->ixfr_serial = ISC_FALSE; + looknew->trace = ISC_FALSE; + looknew->trace_root = ISC_FALSE; + looknew->identify = ISC_FALSE; + looknew->identify_previous_line = ISC_FALSE; + looknew->ignore = ISC_FALSE; + looknew->servfail_stops = ISC_TRUE; + looknew->besteffort = ISC_TRUE; + looknew->dnssec = ISC_FALSE; +#ifdef DIG_SIGCHASE + looknew->sigchase = ISC_FALSE; +#if DIG_SIGCHASE_TD + looknew->do_topdown = ISC_FALSE; + looknew->trace_root_sigchase = ISC_FALSE; + looknew->rdtype_sigchaseset = ISC_FALSE; + looknew->rdtype_sigchase = dns_rdatatype_any; + looknew->qrdtype_sigchase = dns_rdatatype_any; + looknew->rdclass_sigchase = dns_rdataclass_in; + looknew->rdclass_sigchaseset = ISC_FALSE; +#endif +#endif + looknew->udpsize = 0; + looknew->recurse = ISC_TRUE; + looknew->aaonly = ISC_FALSE; + looknew->adflag = ISC_FALSE; + looknew->cdflag = ISC_FALSE; + looknew->ns_search_only = ISC_FALSE; + looknew->origin = NULL; + looknew->tsigctx = NULL; + looknew->querysig = NULL; + looknew->retries = tries; + looknew->nsfound = 0; + looknew->tcp_mode = ISC_FALSE; + looknew->ip6_int = ISC_FALSE; + looknew->comments = ISC_TRUE; + looknew->stats = ISC_TRUE; + looknew->section_question = ISC_TRUE; + looknew->section_answer = ISC_TRUE; + looknew->section_authority = ISC_TRUE; + looknew->section_additional = ISC_TRUE; + looknew->new_search = ISC_FALSE; + ISC_LINK_INIT(looknew, link); + ISC_LIST_INIT(looknew->q); + ISC_LIST_INIT(looknew->my_server_list); + return (looknew); +} + +/* + * Clone a lookup, perhaps copying the server list. This does not clone + * the query list, since it will be regenerated by the setup_lookup() + * function, nor does it queue up the new lookup for processing. + * Caution: If you don't clone the servers, you MUST clone the server + * list seperately from somewhere else, or construct it by hand. + */ +dig_lookup_t * +clone_lookup(dig_lookup_t *lookold, isc_boolean_t servers) { + dig_lookup_t *looknew; + + debug("clone_lookup()"); + + INSIST(!free_now); + + looknew = make_empty_lookup(); + INSIST(looknew != NULL); + strncpy(looknew->textname, lookold->textname, MXNAME); +#if DIG_SIGCHASE_TD + strncpy(looknew->textnamesigchase, lookold->textnamesigchase, MXNAME); +#endif + strncpy(looknew->cmdline, lookold->cmdline, MXNAME); + looknew->textname[MXNAME-1] = 0; + looknew->rdtype = lookold->rdtype; + looknew->qrdtype = lookold->qrdtype; + looknew->rdclass = lookold->rdclass; + looknew->rdtypeset = lookold->rdtypeset; + looknew->rdclassset = lookold->rdclassset; + looknew->doing_xfr = lookold->doing_xfr; + looknew->ixfr_serial = lookold->ixfr_serial; + looknew->trace = lookold->trace; + looknew->trace_root = lookold->trace_root; + looknew->identify = lookold->identify; + looknew->identify_previous_line = lookold->identify_previous_line; + looknew->ignore = lookold->ignore; + looknew->servfail_stops = lookold->servfail_stops; + looknew->besteffort = lookold->besteffort; + looknew->dnssec = lookold->dnssec; +#ifdef DIG_SIGCHASE + looknew->sigchase = lookold->sigchase; +#if DIG_SIGCHASE_TD + looknew->do_topdown = lookold->do_topdown; + looknew->trace_root_sigchase = lookold->trace_root_sigchase; + looknew->rdtype_sigchaseset = lookold->rdtype_sigchaseset; + looknew->rdtype_sigchase = lookold->rdtype_sigchase; + looknew->qrdtype_sigchase = lookold->qrdtype_sigchase; + looknew->rdclass_sigchase = lookold->rdclass_sigchase; + looknew->rdclass_sigchaseset = lookold->rdclass_sigchaseset; +#endif +#endif + looknew->udpsize = lookold->udpsize; + looknew->recurse = lookold->recurse; + looknew->aaonly = lookold->aaonly; + looknew->adflag = lookold->adflag; + looknew->cdflag = lookold->cdflag; + looknew->ns_search_only = lookold->ns_search_only; + looknew->tcp_mode = lookold->tcp_mode; + looknew->comments = lookold->comments; + looknew->stats = lookold->stats; + looknew->section_question = lookold->section_question; + looknew->section_answer = lookold->section_answer; + looknew->section_authority = lookold->section_authority; + looknew->section_additional = lookold->section_additional; + looknew->retries = lookold->retries; + looknew->tsigctx = NULL; + + if (servers) + clone_server_list(lookold->my_server_list, + &looknew->my_server_list); + return (looknew); +} + +/* + * Requeue a lookup for further processing, perhaps copying the server + * list. The new lookup structure is returned to the caller, and is + * queued for processing. If servers are not cloned in the requeue, they + * must be added before allowing the current event to complete, since the + * completion of the event may result in the next entry on the lookup + * queue getting run. + */ +dig_lookup_t * +requeue_lookup(dig_lookup_t *lookold, isc_boolean_t servers) { + dig_lookup_t *looknew; + + debug("requeue_lookup()"); + + lookup_counter++; + if (lookup_counter > LOOKUP_LIMIT) + fatal("too many lookups"); + + looknew = clone_lookup(lookold, servers); + INSIST(looknew != NULL); + + debug("before insertion, init@%p -> %p, new@%p -> %p", + lookold, lookold->link.next, looknew, looknew->link.next); + ISC_LIST_PREPEND(lookup_list, looknew, link); + debug("after insertion, init -> %p, new = %p, new -> %p", + lookold, looknew, looknew->link.next); + return (looknew); +} + + +static void +setup_text_key(void) { + isc_result_t result; + dns_name_t keyname; + isc_buffer_t secretbuf; + int secretsize; + unsigned char *secretstore; + + debug("setup_text_key()"); + result = isc_buffer_allocate(mctx, &namebuf, MXNAME); + check_result(result, "isc_buffer_allocate"); + dns_name_init(&keyname, NULL); + check_result(result, "dns_name_init"); + isc_buffer_putstr(namebuf, keynametext); + secretsize = strlen(keysecret) * 3 / 4; + secretstore = isc_mem_allocate(mctx, secretsize); + if (secretstore == NULL) + fatal("memory allocation failure in %s:%d", + __FILE__, __LINE__); + isc_buffer_init(&secretbuf, secretstore, secretsize); + result = isc_base64_decodestring(keysecret, &secretbuf); + if (result != ISC_R_SUCCESS) + goto failure; + + secretsize = isc_buffer_usedlength(&secretbuf); + + result = dns_name_fromtext(&keyname, namebuf, + dns_rootname, ISC_FALSE, + namebuf); + if (result != ISC_R_SUCCESS) + goto failure; + + result = dns_tsigkey_create(&keyname, dns_tsig_hmacmd5_name, + secretstore, secretsize, + ISC_FALSE, NULL, 0, 0, mctx, + NULL, &key); + failure: + if (result != ISC_R_SUCCESS) + printf(";; Couldn't create key %s: %s\n", + keynametext, isc_result_totext(result)); + + isc_mem_free(mctx, secretstore); + dns_name_invalidate(&keyname); + isc_buffer_free(&namebuf); +} + +static void +setup_file_key(void) { + isc_result_t result; + dst_key_t *dstkey = NULL; + + debug("setup_file_key()"); + result = dst_key_fromnamedfile(keyfile, DST_TYPE_PRIVATE | DST_TYPE_KEY, + mctx, &dstkey); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "Couldn't read key from %s: %s\n", + keyfile, isc_result_totext(result)); + goto failure; + } + + result = dns_tsigkey_createfromkey(dst_key_name(dstkey), + dns_tsig_hmacmd5_name, + dstkey, ISC_FALSE, NULL, 0, 0, + mctx, NULL, &key); + if (result != ISC_R_SUCCESS) { + printf(";; Couldn't create key %s: %s\n", + keynametext, isc_result_totext(result)); + goto failure; + } + dstkey = NULL; + failure: + if (dstkey != NULL) + dst_key_free(&dstkey); +} + +static dig_searchlist_t * +make_searchlist_entry(char *domain) { + dig_searchlist_t *search; + search = isc_mem_allocate(mctx, sizeof(*search)); + if (search == NULL) + fatal("memory allocation failure in %s:%d", + __FILE__, __LINE__); + strncpy(search->origin, domain, MXNAME); + search->origin[MXNAME-1] = 0; + ISC_LINK_INIT(search, link); + return (search); +} + +static void +create_search_list(lwres_conf_t *confdata) { + int i; + dig_searchlist_t *search; + + debug("create_search_list()"); + ISC_LIST_INIT(search_list); + + for (i = 0; i < confdata->searchnxt; i++) { + search = make_searchlist_entry(confdata->search[i]); + ISC_LIST_APPEND(search_list, search, link); + } +} + +/* + * Setup the system as a whole, reading key information and resolv.conf + * settings. + */ +void +setup_system(void) { + dig_searchlist_t *domain = NULL; + lwres_result_t lwresult; + + debug("setup_system()"); + + lwresult = lwres_context_create(&lwctx, mctx, mem_alloc, mem_free, 1); + if (lwresult != LWRES_R_SUCCESS) + fatal("lwres_context_create failed"); + + (void)lwres_conf_parse(lwctx, RESOLV_CONF); + lwconf = lwres_conf_get(lwctx); + + /* Make the search list */ + if (lwconf->searchnxt > 0) + create_search_list(lwconf); + else { + /* No search list. Use the domain name if any */ + if (lwconf->domainname != NULL) { + domain = make_searchlist_entry(lwconf->domainname); + ISC_LIST_INITANDAPPEND(search_list, domain, link); + domain = NULL; + } + } + + ndots = lwconf->ndots; + debug("ndots is %d.", ndots); + + /* If we don't find a nameserver fall back to localhost */ + if (lwconf->nsnext == 0) { + if (have_ipv4) { + lwresult = add_nameserver(lwconf, "127.0.0.1", AF_INET); + if (lwresult != ISC_R_SUCCESS) + fatal("add_nameserver failed"); + } + if (have_ipv6) { + lwresult = add_nameserver(lwconf, "::1", AF_INET6); + if (lwresult != ISC_R_SUCCESS) + fatal("add_nameserver failed"); + } + } + + if (ISC_LIST_EMPTY(server_list)) + copy_server_list(lwconf, &server_list); + + if (keyfile[0] != 0) + setup_file_key(); + else if (keysecret[0] != 0) + setup_text_key(); +#ifdef DIG_SIGCHASE + /* Setup the list of messages for +sigchase */ + ISC_LIST_INIT(chase_message_list); + ISC_LIST_INIT(chase_message_list2); + dns_name_init(&chase_name, NULL); +#if DIG_SIGCHASE_TD + dns_name_init(&chase_current_name, NULL); + dns_name_init(&chase_authority_name, NULL); +#endif +#if DIG_SIGCHASE_BU + dns_name_init(&chase_signame, NULL); +#endif + +#endif + +} + +static void +clear_searchlist(void) { + dig_searchlist_t *search; + while ((search = ISC_LIST_HEAD(search_list)) != NULL) { + ISC_LIST_UNLINK(search_list, search, link); + isc_mem_free(mctx, search); + } +} + +/* + * Override the search list derived from resolv.conf by 'domain'. + */ +void +set_search_domain(char *domain) { + dig_searchlist_t *search; + + clear_searchlist(); + search = make_searchlist_entry(domain); + ISC_LIST_APPEND(search_list, search, link); +} + +/* + * Setup the ISC and DNS libraries for use by the system. + */ +void +setup_libs(void) { + isc_result_t result; + + debug("setup_libs()"); + + result = isc_net_probeipv4(); + if (result == ISC_R_SUCCESS) + have_ipv4 = ISC_TRUE; + + result = isc_net_probeipv6(); + if (result == ISC_R_SUCCESS) + have_ipv6 = ISC_TRUE; + if (!have_ipv6 && !have_ipv4) + fatal("can't find either v4 or v6 networking"); + + result = isc_mem_create(0, 0, &mctx); + check_result(result, "isc_mem_create"); + + result = isc_taskmgr_create(mctx, 1, 0, &taskmgr); + check_result(result, "isc_taskmgr_create"); + + result = isc_task_create(taskmgr, 0, &global_task); + check_result(result, "isc_task_create"); + + result = isc_timermgr_create(mctx, &timermgr); + check_result(result, "isc_timermgr_create"); + + result = isc_socketmgr_create(mctx, &socketmgr); + check_result(result, "isc_socketmgr_create"); + + result = isc_entropy_create(mctx, &entp); + check_result(result, "isc_entropy_create"); + + result = dst_lib_init(mctx, entp, 0); + check_result(result, "dst_lib_init"); + is_dst_up = ISC_TRUE; + + result = isc_mempool_create(mctx, COMMSIZE, &commctx); + check_result(result, "isc_mempool_create"); + isc_mempool_setname(commctx, "COMMPOOL"); + /* + * 6 and 2 set as reasonable parameters for 3 or 4 nameserver + * systems. + */ + isc_mempool_setfreemax(commctx, 6); + isc_mempool_setfillcount(commctx, 2); + + result = isc_mutex_init(&lookup_lock); + check_result(result, "isc_mutex_init"); + + dns_result_register(); +} + +/* + * Add EDNS0 option record to a message. Currently, the only supported + * options are UDP buffer size and the DO bit. + */ +static void +add_opt(dns_message_t *msg, isc_uint16_t udpsize, isc_boolean_t dnssec) { + dns_rdataset_t *rdataset = NULL; + dns_rdatalist_t *rdatalist = NULL; + dns_rdata_t *rdata = NULL; + isc_result_t result; + + debug("add_opt()"); + result = dns_message_gettemprdataset(msg, &rdataset); + check_result(result, "dns_message_gettemprdataset"); + dns_rdataset_init(rdataset); + result = dns_message_gettemprdatalist(msg, &rdatalist); + check_result(result, "dns_message_gettemprdatalist"); + result = dns_message_gettemprdata(msg, &rdata); + check_result(result, "dns_message_gettemprdata"); + + debug("setting udp size of %d", udpsize); + rdatalist->type = dns_rdatatype_opt; + rdatalist->covers = 0; + rdatalist->rdclass = udpsize; + rdatalist->ttl = 0; + if (dnssec) + rdatalist->ttl = DNS_MESSAGEEXTFLAG_DO; + rdata->data = NULL; + rdata->length = 0; + ISC_LIST_INIT(rdatalist->rdata); + ISC_LIST_APPEND(rdatalist->rdata, rdata, link); + dns_rdatalist_tordataset(rdatalist, rdataset); + result = dns_message_setopt(msg, rdataset); + check_result(result, "dns_message_setopt"); +} + +/* + * Add a question section to a message, asking for the specified name, + * type, and class. + */ +static void +add_question(dns_message_t *message, dns_name_t *name, + dns_rdataclass_t rdclass, dns_rdatatype_t rdtype) +{ + dns_rdataset_t *rdataset; + isc_result_t result; + + debug("add_question()"); + rdataset = NULL; + result = dns_message_gettemprdataset(message, &rdataset); + check_result(result, "dns_message_gettemprdataset()"); + dns_rdataset_init(rdataset); + dns_rdataset_makequestion(rdataset, rdclass, rdtype); + ISC_LIST_APPEND(name->list, rdataset, link); +} + +/* + * Check if we're done with all the queued lookups, which is true iff + * all sockets, sends, and recvs are accounted for (counters == 0), + * and the lookup list is empty. + * If we are done, pass control back out to dighost_shutdown() (which is + * part of dig.c, host.c, or nslookup.c) to either shutdown the system as + * a whole or reseed the lookup list. + */ +static void +check_if_done(void) { + debug("check_if_done()"); + debug("list %s", ISC_LIST_EMPTY(lookup_list) ? "empty" : "full"); + if (ISC_LIST_EMPTY(lookup_list) && current_lookup == NULL && + sendcount == 0) { + INSIST(sockcount == 0); + INSIST(recvcount == 0); + debug("shutting down"); + dighost_shutdown(); + } +} + +/* + * Clear out a query when we're done with it. WARNING: This routine + * WILL invalidate the query pointer. + */ +static void +clear_query(dig_query_t *query) { + dig_lookup_t *lookup; + + REQUIRE(query != NULL); + + debug("clear_query(%p)", query); + + lookup = query->lookup; + + if (lookup->current_query == query) + lookup->current_query = NULL; + + ISC_LIST_UNLINK(lookup->q, query, link); + if (ISC_LINK_LINKED(&query->recvbuf, link)) + ISC_LIST_DEQUEUE(query->recvlist, &query->recvbuf, + link); + if (ISC_LINK_LINKED(&query->lengthbuf, link)) + ISC_LIST_DEQUEUE(query->lengthlist, &query->lengthbuf, + link); + INSIST(query->recvspace != NULL); + if (query->sock != NULL) { + isc_socket_detach(&query->sock); + sockcount--; + debug("sockcount=%d", sockcount); + } + isc_mempool_put(commctx, query->recvspace); + isc_buffer_invalidate(&query->recvbuf); + isc_buffer_invalidate(&query->lengthbuf); + isc_mem_free(mctx, query); +} + +/* + * Try and clear out a lookup if we're done with it. Return ISC_TRUE if + * the lookup was successfully cleared. If ISC_TRUE is returned, the + * lookup pointer has been invalidated. + */ +static isc_boolean_t +try_clear_lookup(dig_lookup_t *lookup) { + dig_server_t *s; + dig_query_t *q; + void *ptr; + + REQUIRE(lookup != NULL); + + debug("try_clear_lookup(%p)", lookup); + + if (ISC_LIST_HEAD(lookup->q) != NULL) { + if (debugging) { + q = ISC_LIST_HEAD(lookup->q); + while (q != NULL) { + debug("query to %s still pending", + q->servname); + q = ISC_LIST_NEXT(q, link); + } + return (ISC_FALSE); + } + } + /* + * At this point, we know there are no queries on the lookup, + * so can make it go away also. + */ + debug("cleared"); + s = ISC_LIST_HEAD(lookup->my_server_list); + while (s != NULL) { + debug("freeing server %p belonging to %p", + s, lookup); + ptr = s; + s = ISC_LIST_NEXT(s, link); + ISC_LIST_DEQUEUE(lookup->my_server_list, + (dig_server_t *)ptr, link); + isc_mem_free(mctx, ptr); + } + if (lookup->sendmsg != NULL) + dns_message_destroy(&lookup->sendmsg); + if (lookup->querysig != NULL) { + debug("freeing buffer %p", lookup->querysig); + isc_buffer_free(&lookup->querysig); + } + if (lookup->timer != NULL) + isc_timer_detach(&lookup->timer); + if (lookup->sendspace != NULL) + isc_mempool_put(commctx, lookup->sendspace); + + if (lookup->tsigctx != NULL) + dst_context_destroy(&lookup->tsigctx); + + isc_mem_free(mctx, lookup); + return (ISC_TRUE); +} + + +/* + * If we can, start the next lookup in the queue running. + * This assumes that the lookup on the head of the queue hasn't been + * started yet. It also removes the lookup from the head of the queue, + * setting the current_lookup pointer pointing to it. + */ +void +start_lookup(void) { + debug("start_lookup()"); + if (cancel_now) + return; + + /* + * If there's a current lookup running, we really shouldn't get + * here. + */ + INSIST(current_lookup == NULL); + + current_lookup = ISC_LIST_HEAD(lookup_list); + /* + * Put the current lookup somewhere so cancel_all can find it + */ + if (current_lookup != NULL) { + ISC_LIST_DEQUEUE(lookup_list, current_lookup, link); +#if DIG_SIGCHASE_TD + if (current_lookup->do_topdown && + !current_lookup->rdtype_sigchaseset) { + dst_key_t * trustedkey = NULL; + isc_buffer_t *b = NULL; + isc_region_t r; + isc_result_t result; + dns_name_t query_name; + dns_name_t * key_name; + int i; + + result = get_trusted_key(mctx); + if (result != ISC_R_SUCCESS) { + printf("\n;; No trusted key, " + "+sigchase option is disabled\n"); + current_lookup->sigchase = ISC_FALSE; + goto novalidation; + } + dns_name_init(&query_name, NULL); + nameFromString(current_lookup->textname, &query_name); + + for (i = 0; i< tk_list.nb_tk; i++) { + key_name = dst_key_name(tk_list.key[i]); + + if (dns_name_issubdomain(&query_name, + key_name) == ISC_TRUE) + trustedkey = tk_list.key[i]; + /* + * Verifier que la temp est bien la plus basse + * WARNING + */ + } + if (trustedkey == NULL) { + printf("\n;; The queried zone: "); + dns_name_print(&query_name, stdout); + printf(" isn't a subdomain of any Trusted Keys" + ": +sigchase option is disable\n"); + current_lookup->sigchase = ISC_FALSE; + dns_name_free(&query_name, mctx); + goto novalidation; + } + dns_name_free(&query_name, mctx); + + + current_lookup->rdtype_sigchase + = current_lookup->rdtype; + current_lookup->rdtype_sigchaseset + = current_lookup->rdtypeset; + current_lookup->rdtype = dns_rdatatype_ns; + + + current_lookup->qrdtype_sigchase + = current_lookup->qrdtype; + current_lookup->qrdtype = dns_rdatatype_ns; + + current_lookup->rdclass_sigchase + = current_lookup->rdclass; + current_lookup->rdclass_sigchaseset + = current_lookup->rdclassset; + current_lookup->rdclass = dns_rdataclass_in; + + + strncpy(current_lookup->textnamesigchase, + current_lookup->textname, MXNAME); + + current_lookup->trace_root_sigchase = ISC_TRUE; + + result = isc_buffer_allocate(mctx, &b, BUFSIZE); + check_result(result, "isc_buffer_allocate"); + result = dns_name_totext(dst_key_name(trustedkey), + ISC_FALSE, b); + check_result(result, "dns_name_totext"); + isc_buffer_usedregion(b, &r); + r.base[r.length] = '\0'; + strncpy(current_lookup->textname, (char*)r.base, + MXNAME); + isc_buffer_free(&b); + + nameFromString(current_lookup->textnamesigchase, + &chase_name); + + dns_name_init(&chase_authority_name, NULL); + } + novalidation: +#endif + setup_lookup(current_lookup); + do_lookup(current_lookup); + } else { + check_if_done(); + } +} + +/* + * If we can, clear the current lookup and start the next one running. + * This calls try_clear_lookup, so may invalidate the lookup pointer. + */ +static void +check_next_lookup(dig_lookup_t *lookup) { + + INSIST(!free_now); + + debug("check_next_lookup(%p)", lookup); + + if (ISC_LIST_HEAD(lookup->q) != NULL) { + debug("still have a worker"); + return; + } + if (try_clear_lookup(lookup)) { + current_lookup = NULL; + start_lookup(); + } +} + +/* + * Create and queue a new lookup as a followup to the current lookup, + * based on the supplied message and section. This is used in trace and + * name server search modes to start a new lookup using servers from + * NS records in a reply. Returns the number of followup lookups made. + */ +static int +followup_lookup(dns_message_t *msg, dig_query_t *query, dns_section_t section) +{ + dig_lookup_t *lookup = NULL; + dig_server_t *srv = NULL; + dns_rdataset_t *rdataset = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_name_t *name = NULL; + isc_result_t result; + isc_boolean_t success = ISC_FALSE; + int numLookups = 0; + + INSIST(!free_now); + + debug("following up %s", query->lookup->textname); + + for (result = dns_message_firstname(msg, section); + result == ISC_R_SUCCESS; + result = dns_message_nextname(msg, section)) { + name = NULL; + dns_message_currentname(msg, section, &name); + + rdataset = NULL; + result = dns_message_findtype(name, dns_rdatatype_ns, 0, + &rdataset); + if (result != ISC_R_SUCCESS) + continue; + + debug("found NS set"); + + for (result = dns_rdataset_first(rdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(rdataset)) { + char namestr[DNS_NAME_FORMATSIZE]; + dns_rdata_ns_t ns; + + if (query->lookup->trace_root && + query->lookup->nsfound >= MXSERV) + break; + + dns_rdataset_current(rdataset, &rdata); + + query->lookup->nsfound++; + (void)dns_rdata_tostruct(&rdata, &ns, NULL); + dns_name_format(&ns.name, namestr, sizeof(namestr)); + dns_rdata_freestruct(&ns); + + /* Initialize lookup if we've not yet */ + debug("found NS %d %s", numLookups, namestr); + numLookups++; + if (!success) { + success = ISC_TRUE; + lookup_counter++; + lookup = requeue_lookup(query->lookup, + ISC_FALSE); + cancel_lookup(query->lookup); + lookup->doing_xfr = ISC_FALSE; + if (!lookup->trace_root && + section == DNS_SECTION_ANSWER) + lookup->trace = ISC_FALSE; + else + lookup->trace = query->lookup->trace; + lookup->ns_search_only = + query->lookup->ns_search_only; + lookup->trace_root = ISC_FALSE; + } + srv = make_server(namestr); + debug("adding server %s", srv->servername); + ISC_LIST_APPEND(lookup->my_server_list, srv, link); + dns_rdata_reset(&rdata); + } + } + + if (lookup == NULL && + section == DNS_SECTION_ANSWER && + (query->lookup->trace || query->lookup->ns_search_only)) + return (followup_lookup(msg, query, DNS_SECTION_AUTHORITY)); + + return numLookups; +} + +/* + * Create and queue a new lookup using the next origin from the search + * list, read in setup_system(). + * + * Return ISC_TRUE iff there was another searchlist entry. + */ +static isc_boolean_t +next_origin(dns_message_t *msg, dig_query_t *query) { + dig_lookup_t *lookup; + + UNUSED(msg); + + INSIST(!free_now); + + debug("next_origin()"); + debug("following up %s", query->lookup->textname); + + if (!usesearch) + /* + * We're not using a search list, so don't even think + * about finding the next entry. + */ + return (ISC_FALSE); + if (query->lookup->origin == NULL) + /* + * Then we just did rootorg; there's nothing left. + */ + return (ISC_FALSE); + lookup = requeue_lookup(query->lookup, ISC_TRUE); + lookup->origin = ISC_LIST_NEXT(query->lookup->origin, link); + cancel_lookup(query->lookup); + return (ISC_TRUE); +} + +/* + * Insert an SOA record into the sendmessage in a lookup. Used for + * creating IXFR queries. + */ +static void +insert_soa(dig_lookup_t *lookup) { + isc_result_t result; + dns_rdata_soa_t soa; + dns_rdata_t *rdata = NULL; + dns_rdatalist_t *rdatalist = NULL; + dns_rdataset_t *rdataset = NULL; + dns_name_t *soaname = NULL; + + debug("insert_soa()"); + soa.mctx = mctx; + soa.serial = lookup->ixfr_serial; + soa.refresh = 0; + soa.retry = 0; + soa.expire = 0; + soa.minimum = 0; + soa.common.rdclass = lookup->rdclass; + soa.common.rdtype = dns_rdatatype_soa; + + dns_name_init(&soa.origin, NULL); + dns_name_init(&soa.contact, NULL); + + dns_name_clone(dns_rootname, &soa.origin); + dns_name_clone(dns_rootname, &soa.contact); + + isc_buffer_init(&lookup->rdatabuf, lookup->rdatastore, + sizeof(lookup->rdatastore)); + + result = dns_message_gettemprdata(lookup->sendmsg, &rdata); + check_result(result, "dns_message_gettemprdata"); + + result = dns_rdata_fromstruct(rdata, lookup->rdclass, + dns_rdatatype_soa, &soa, + &lookup->rdatabuf); + check_result(result, "isc_rdata_fromstruct"); + + result = dns_message_gettemprdatalist(lookup->sendmsg, &rdatalist); + check_result(result, "dns_message_gettemprdatalist"); + + result = dns_message_gettemprdataset(lookup->sendmsg, &rdataset); + check_result(result, "dns_message_gettemprdataset"); + + dns_rdatalist_init(rdatalist); + rdatalist->type = dns_rdatatype_soa; + rdatalist->rdclass = lookup->rdclass; + rdatalist->covers = 0; + rdatalist->ttl = 0; + ISC_LIST_INIT(rdatalist->rdata); + ISC_LIST_APPEND(rdatalist->rdata, rdata, link); + + dns_rdataset_init(rdataset); + dns_rdatalist_tordataset(rdatalist, rdataset); + + result = dns_message_gettempname(lookup->sendmsg, &soaname); + check_result(result, "dns_message_gettempname"); + dns_name_init(soaname, NULL); + dns_name_clone(lookup->name, soaname); + ISC_LIST_INIT(soaname->list); + ISC_LIST_APPEND(soaname->list, rdataset, link); + dns_message_addname(lookup->sendmsg, soaname, DNS_SECTION_AUTHORITY); +} + +/* + * Setup the supplied lookup structure, making it ready to start sending + * queries to servers. Create and initialize the message to be sent as + * well as the query structures and buffer space for the replies. If the + * server list is empty, clone it from the system default list. + */ +void +setup_lookup(dig_lookup_t *lookup) { + isc_result_t result; + isc_uint32_t id; + int len; + dig_server_t *serv; + dig_query_t *query; + isc_buffer_t b; + dns_compress_t cctx; + char store[MXNAME]; + + REQUIRE(lookup != NULL); + INSIST(!free_now); + + debug("setup_lookup(%p)", lookup); + + result = dns_message_create(mctx, DNS_MESSAGE_INTENTRENDER, + &lookup->sendmsg); + check_result(result, "dns_message_create"); + + if (lookup->new_search) { + debug("resetting lookup counter."); + lookup_counter = 0; + } + + if (ISC_LIST_EMPTY(lookup->my_server_list)) { + debug("cloning server list"); + clone_server_list(server_list, &lookup->my_server_list); + } + result = dns_message_gettempname(lookup->sendmsg, &lookup->name); + check_result(result, "dns_message_gettempname"); + dns_name_init(lookup->name, NULL); + + isc_buffer_init(&lookup->namebuf, lookup->namespace, + sizeof(lookup->namespace)); + isc_buffer_init(&lookup->onamebuf, lookup->onamespace, + sizeof(lookup->onamespace)); + + /* + * If the name has too many dots, force the origin to be NULL + * (which produces an absolute lookup). Otherwise, take the origin + * we have if there's one in the struct already. If it's NULL, + * take the first entry in the searchlist iff either usesearch + * is TRUE or we got a domain line in the resolv.conf file. + */ + /* XXX New search here? */ + if ((count_dots(lookup->textname) >= ndots) || !usesearch) + lookup->origin = NULL; /* Force abs lookup */ + else if (lookup->origin == NULL && lookup->new_search && usesearch) { + lookup->origin = ISC_LIST_HEAD(search_list); + } + if (lookup->origin != NULL) { + debug("trying origin %s", lookup->origin->origin); + result = dns_message_gettempname(lookup->sendmsg, + &lookup->oname); + check_result(result, "dns_message_gettempname"); + dns_name_init(lookup->oname, NULL); + /* XXX Helper funct to conv char* to name? */ + len = strlen(lookup->origin->origin); + isc_buffer_init(&b, lookup->origin->origin, len); + isc_buffer_add(&b, len); + result = dns_name_fromtext(lookup->oname, &b, dns_rootname, + ISC_FALSE, &lookup->onamebuf); + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(lookup->sendmsg, + &lookup->name); + dns_message_puttempname(lookup->sendmsg, + &lookup->oname); + fatal("'%s' is not in legal name syntax (%s)", + lookup->origin->origin, + isc_result_totext(result)); + } + if (lookup->trace && lookup->trace_root) { + dns_name_clone(dns_rootname, lookup->name); + } else { + len = strlen(lookup->textname); + isc_buffer_init(&b, lookup->textname, len); + isc_buffer_add(&b, len); + result = dns_name_fromtext(lookup->name, &b, + lookup->oname, ISC_FALSE, + &lookup->namebuf); + } + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(lookup->sendmsg, + &lookup->name); + dns_message_puttempname(lookup->sendmsg, + &lookup->oname); + fatal("'%s' is not in legal name syntax (%s)", + lookup->textname, isc_result_totext(result)); + } + dns_message_puttempname(lookup->sendmsg, &lookup->oname); + } else { + debug("using root origin"); + if (lookup->trace && lookup->trace_root) + dns_name_clone(dns_rootname, lookup->name); + else { + len = strlen(lookup->textname); + isc_buffer_init(&b, lookup->textname, len); + isc_buffer_add(&b, len); + result = dns_name_fromtext(lookup->name, &b, + dns_rootname, + ISC_FALSE, + &lookup->namebuf); + } + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(lookup->sendmsg, + &lookup->name); + isc_buffer_init(&b, store, MXNAME); + fatal("'%s' is not a legal name " + "(%s)", lookup->textname, + isc_result_totext(result)); + } + } + dns_name_format(lookup->name, store, sizeof(store)); + trying(store, lookup); + INSIST(dns_name_isabsolute(lookup->name)); + + isc_random_get(&id); + lookup->sendmsg->id = (unsigned short)id & 0xFFFF; + lookup->sendmsg->opcode = dns_opcode_query; + lookup->msgcounter = 0; + /* + * If this is a trace request, completely disallow recursion, since + * it's meaningless for traces. + */ + if (lookup->trace || (lookup->ns_search_only && !lookup->trace_root)) + lookup->recurse = ISC_FALSE; + + if (lookup->recurse && + lookup->rdtype != dns_rdatatype_axfr && + lookup->rdtype != dns_rdatatype_ixfr) { + debug("recursive query"); + lookup->sendmsg->flags |= DNS_MESSAGEFLAG_RD; + } + + /* XXX aaflag */ + if (lookup->aaonly) { + debug("AA query"); + lookup->sendmsg->flags |= DNS_MESSAGEFLAG_AA; + } + + if (lookup->adflag) { + debug("AD query"); + lookup->sendmsg->flags |= DNS_MESSAGEFLAG_AD; + } + + if (lookup->cdflag) { + debug("CD query"); + lookup->sendmsg->flags |= DNS_MESSAGEFLAG_CD; + } + + dns_message_addname(lookup->sendmsg, lookup->name, + DNS_SECTION_QUESTION); + + if (lookup->trace && lookup->trace_root) { + lookup->qrdtype = lookup->rdtype; + lookup->rdtype = dns_rdatatype_ns; + } + + if ((lookup->rdtype == dns_rdatatype_axfr) || + (lookup->rdtype == dns_rdatatype_ixfr)) { + lookup->doing_xfr = ISC_TRUE; + /* + * Force TCP mode if we're doing an xfr. + * XXX UDP ixfr's would be useful + */ + lookup->tcp_mode = ISC_TRUE; + } + + add_question(lookup->sendmsg, lookup->name, lookup->rdclass, + lookup->rdtype); + + /* add_soa */ + if (lookup->rdtype == dns_rdatatype_ixfr) + insert_soa(lookup); + + /* XXX Insist this? */ + lookup->tsigctx = NULL; + lookup->querysig = NULL; + if (key != NULL) { + debug("initializing keys"); + result = dns_message_settsigkey(lookup->sendmsg, key); + check_result(result, "dns_message_settsigkey"); + } + + lookup->sendspace = isc_mempool_get(commctx); + if (lookup->sendspace == NULL) + fatal("memory allocation failure"); + + result = dns_compress_init(&cctx, -1, mctx); + check_result(result, "dns_compress_init"); + + debug("starting to render the message"); + isc_buffer_init(&lookup->sendbuf, lookup->sendspace, COMMSIZE); + result = dns_message_renderbegin(lookup->sendmsg, &cctx, + &lookup->sendbuf); + check_result(result, "dns_message_renderbegin"); + if (lookup->udpsize > 0 || lookup->dnssec) { + if (lookup->udpsize == 0) + lookup->udpsize = 2048; + add_opt(lookup->sendmsg, lookup->udpsize, lookup->dnssec); + } + + result = dns_message_rendersection(lookup->sendmsg, + DNS_SECTION_QUESTION, 0); + check_result(result, "dns_message_rendersection"); + result = dns_message_rendersection(lookup->sendmsg, + DNS_SECTION_AUTHORITY, 0); + check_result(result, "dns_message_rendersection"); + result = dns_message_renderend(lookup->sendmsg); + check_result(result, "dns_message_renderend"); + debug("done rendering"); + + dns_compress_invalidate(&cctx); + + /* + * Force TCP mode if the request is larger than 512 bytes. + */ + if (isc_buffer_usedlength(&lookup->sendbuf) > 512) + lookup->tcp_mode = ISC_TRUE; + + lookup->pending = ISC_FALSE; + + for (serv = ISC_LIST_HEAD(lookup->my_server_list); + serv != NULL; + serv = ISC_LIST_NEXT(serv, link)) { + query = isc_mem_allocate(mctx, sizeof(dig_query_t)); + if (query == NULL) + fatal("memory allocation failure in %s:%d", + __FILE__, __LINE__); + debug("create query %p linked to lookup %p", + query, lookup); + query->lookup = lookup; + query->waiting_connect = ISC_FALSE; + query->recv_made = ISC_FALSE; + query->first_pass = ISC_TRUE; + query->first_soa_rcvd = ISC_FALSE; + query->second_rr_rcvd = ISC_FALSE; + query->first_repeat_rcvd = ISC_FALSE; + query->warn_id = ISC_TRUE; + query->first_rr_serial = 0; + query->second_rr_serial = 0; + query->servname = serv->servername; + query->rr_count = 0; + query->msg_count = 0; + ISC_LINK_INIT(query, link); + ISC_LIST_INIT(query->recvlist); + ISC_LIST_INIT(query->lengthlist); + query->sock = NULL; + query->recvspace = isc_mempool_get(commctx); + if (query->recvspace == NULL) + fatal("memory allocation failure"); + + isc_buffer_init(&query->recvbuf, query->recvspace, COMMSIZE); + isc_buffer_init(&query->lengthbuf, query->lengthspace, 2); + isc_buffer_init(&query->slbuf, query->slspace, 2); + + ISC_LINK_INIT(query, link); + ISC_LIST_ENQUEUE(lookup->q, query, link); + } + /* XXX qrflag, print_query, etc... */ + if (!ISC_LIST_EMPTY(lookup->q) && qr) { + printmessage(ISC_LIST_HEAD(lookup->q), lookup->sendmsg, + ISC_TRUE); + } +} + +/* + * Event handler for send completion. Track send counter, and clear out + * the query if the send was canceled. + */ +static void +send_done(isc_task_t *_task, isc_event_t *event) { + REQUIRE(event->ev_type == ISC_SOCKEVENT_SENDDONE); + + UNUSED(_task); + + LOCK_LOOKUP; + + isc_event_free(&event); + + debug("send_done()"); + sendcount--; + debug("sendcount=%d", sendcount); + INSIST(sendcount >= 0); + check_if_done(); + UNLOCK_LOOKUP; +} + +/* + * Cancel a lookup, sending isc_socket_cancel() requests to all outstanding + * IO sockets. The cancel handlers should take care of cleaning up the + * query and lookup structures + */ +static void +cancel_lookup(dig_lookup_t *lookup) { + dig_query_t *query, *next; + + debug("cancel_lookup()"); + query = ISC_LIST_HEAD(lookup->q); + while (query != NULL) { + next = ISC_LIST_NEXT(query, link); + if (query->sock != NULL) { + isc_socket_cancel(query->sock, global_task, + ISC_SOCKCANCEL_ALL); + check_if_done(); + } else { + clear_query(query); + } + query = next; + } + if (lookup->timer != NULL) + isc_timer_detach(&lookup->timer); + lookup->pending = ISC_FALSE; + lookup->retries = 0; +} + +static void +bringup_timer(dig_query_t *query, unsigned int default_timeout) { + dig_lookup_t *l; + unsigned int local_timeout; + isc_result_t result; + + debug("bringup_timer()"); + /* + * If the timer already exists, that means we're calling this + * a second time (for a retry). Don't need to recreate it, + * just reset it. + */ + l = query->lookup; + if (ISC_LIST_NEXT(query, link) != NULL) + local_timeout = SERVER_TIMEOUT; + else { + if (timeout == 0) { + local_timeout = default_timeout; + } else + local_timeout = timeout; + } + debug("have local timeout of %d", local_timeout); + isc_interval_set(&l->interval, local_timeout, 0); + if (l->timer != NULL) + isc_timer_detach(&l->timer); + result = isc_timer_create(timermgr, + isc_timertype_once, + NULL, + &l->interval, + global_task, + connect_timeout, + l, &l->timer); + check_result(result, "isc_timer_create"); +} + +static void +connect_done(isc_task_t *task, isc_event_t *event); + +/* + * Unlike send_udp, this can't be called multiple times with the same + * query. When we retry TCP, we requeue the whole lookup, which should + * start anew. + */ +static void +send_tcp_connect(dig_query_t *query) { + isc_result_t result; + dig_query_t *next; + dig_lookup_t *l; + + debug("send_tcp_connect(%p)", query); + + l = query->lookup; + query->waiting_connect = ISC_TRUE; + query->lookup->current_query = query; + get_address(query->servname, port, &query->sockaddr); + + if (specified_source && + (isc_sockaddr_pf(&query->sockaddr) != + isc_sockaddr_pf(&bind_address))) { + printf(";; Skipping server %s, incompatible " + "address family\n", query->servname); + query->waiting_connect = ISC_FALSE; + next = ISC_LIST_NEXT(query, link); + l = query->lookup; + clear_query(query); + if (next == NULL) { + printf(";; No acceptable nameservers\n"); + check_next_lookup(l); + return; + } + send_tcp_connect(next); + return; + } + INSIST(query->sock == NULL); + result = isc_socket_create(socketmgr, + isc_sockaddr_pf(&query->sockaddr), + isc_sockettype_tcp, &query->sock); + check_result(result, "isc_socket_create"); + sockcount++; + debug("sockcount=%d", sockcount); + if (specified_source) + result = isc_socket_bind(query->sock, &bind_address); + else { + if ((isc_sockaddr_pf(&query->sockaddr) == AF_INET) && + have_ipv4) + isc_sockaddr_any(&bind_any); + else + isc_sockaddr_any6(&bind_any); + result = isc_socket_bind(query->sock, &bind_any); + } + check_result(result, "isc_socket_bind"); + bringup_timer(query, TCP_TIMEOUT); + result = isc_socket_connect(query->sock, &query->sockaddr, + global_task, connect_done, query); + check_result(result, "isc_socket_connect"); + /* + * If we're at the endgame of a nameserver search, we need to + * immediately bring up all the queries. Do it here. + */ + if (l->ns_search_only && !l->trace_root) { + debug("sending next, since searching"); + next = ISC_LIST_NEXT(query, link); + if (next != NULL) + send_tcp_connect(next); + } +} + +/* + * Send a UDP packet to the remote nameserver, possible starting the + * recv action as well. Also make sure that the timer is running and + * is properly reset. + */ +static void +send_udp(dig_query_t *query) { + dig_lookup_t *l = NULL; + dig_query_t *next; + isc_result_t result; + + debug("send_udp(%p)", query); + + l = query->lookup; + bringup_timer(query, UDP_TIMEOUT); + l->current_query = query; + debug("working on lookup %p, query %p", + query->lookup, query); + if (!query->recv_made) { + /* XXX Check the sense of this, need assertion? */ + query->waiting_connect = ISC_FALSE; + get_address(query->servname, port, &query->sockaddr); + + result = isc_socket_create(socketmgr, + isc_sockaddr_pf(&query->sockaddr), + isc_sockettype_udp, &query->sock); + check_result(result, "isc_socket_create"); + sockcount++; + debug("sockcount=%d", sockcount); + if (specified_source) { + result = isc_socket_bind(query->sock, &bind_address); + } else { + isc_sockaddr_anyofpf(&bind_any, + isc_sockaddr_pf(&query->sockaddr)); + result = isc_socket_bind(query->sock, &bind_any); + } + check_result(result, "isc_socket_bind"); + + query->recv_made = ISC_TRUE; + ISC_LINK_INIT(&query->recvbuf, link); + ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, + link); + debug("recving with lookup=%p, query=%p, sock=%p", + query->lookup, query, + query->sock); + result = isc_socket_recvv(query->sock, + &query->recvlist, 1, + global_task, recv_done, + query); + check_result(result, "isc_socket_recvv"); + recvcount++; + debug("recvcount=%d", recvcount); + } + ISC_LIST_INIT(query->sendlist); + ISC_LINK_INIT(&l->sendbuf, link); + ISC_LIST_ENQUEUE(query->sendlist, &l->sendbuf, + link); + debug("sending a request"); + TIME_NOW(&query->time_sent); + INSIST(query->sock != NULL); + result = isc_socket_sendtov(query->sock, &query->sendlist, + global_task, send_done, query, + &query->sockaddr, NULL); + check_result(result, "isc_socket_sendtov"); + sendcount++; + /* + * If we're at the endgame of a nameserver search, we need to + * immediately bring up all the queries. Do it here. + */ + if (l->ns_search_only && !l->trace_root) { + debug("sending next, since searching"); + next = ISC_LIST_NEXT(query, link); + if (next != NULL) + send_udp(next); + } +} + +/* + * IO timeout handler, used for both connect and recv timeouts. If + * retries are still allowed, either resend the UDP packet or queue a + * new TCP lookup. Otherwise, cancel the lookup. + */ +static void +connect_timeout(isc_task_t *task, isc_event_t *event) { + dig_lookup_t *l = NULL, *n; + dig_query_t *query = NULL, *cq; + + UNUSED(task); + REQUIRE(event->ev_type == ISC_TIMEREVENT_IDLE); + + debug("connect_timeout()"); + + LOCK_LOOKUP; + l = event->ev_arg; + query = l->current_query; + isc_event_free(&event); + + INSIST(!free_now); + + if ((query != NULL) && (query->lookup->current_query != NULL) && + (ISC_LIST_NEXT(query->lookup->current_query, link) != NULL)) { + debug("trying next server..."); + cq = query->lookup->current_query; + if (!l->tcp_mode) + send_udp(ISC_LIST_NEXT(cq, link)); + else + send_tcp_connect(ISC_LIST_NEXT(cq, link)); + UNLOCK_LOOKUP; + return; + } + + if (l->retries > 1) { + if (!l->tcp_mode) { + l->retries--; + debug("resending UDP request to first server"); + send_udp(ISC_LIST_HEAD(l->q)); + } else { + debug("making new TCP request, %d tries left", + l->retries); + l->retries--; + n = requeue_lookup(l, ISC_TRUE); + cancel_lookup(l); + check_next_lookup(l); + } + } else { + fputs(l->cmdline, stdout); + printf(";; connection timed out; no servers could be " + "reached\n"); + cancel_lookup(l); + check_next_lookup(l); + if (exitcode < 9) + exitcode = 9; + } + UNLOCK_LOOKUP; +} + +/* + * Event handler for the TCP recv which gets the length header of TCP + * packets. Start the next recv of length bytes. + */ +static void +tcp_length_done(isc_task_t *task, isc_event_t *event) { + isc_socketevent_t *sevent; + isc_buffer_t *b = NULL; + isc_result_t result; + dig_query_t *query = NULL; + dig_lookup_t *l; + isc_uint16_t length; + + REQUIRE(event->ev_type == ISC_SOCKEVENT_RECVDONE); + INSIST(!free_now); + + UNUSED(task); + + debug("tcp_length_done()"); + + LOCK_LOOKUP; + sevent = (isc_socketevent_t *)event; + query = event->ev_arg; + + recvcount--; + INSIST(recvcount >= 0); + + if (sevent->result == ISC_R_CANCELED) { + isc_event_free(&event); + l = query->lookup; + clear_query(query); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } + if (sevent->result != ISC_R_SUCCESS) { + char sockstr[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_format(&query->sockaddr, sockstr, + sizeof(sockstr)); + printf(";; communications error to %s: %s\n", + sockstr, isc_result_totext(sevent->result)); + l = query->lookup; + isc_socket_detach(&query->sock); + sockcount--; + debug("sockcount=%d", sockcount); + INSIST(sockcount >= 0); + isc_event_free(&event); + clear_query(query); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } + b = ISC_LIST_HEAD(sevent->bufferlist); + ISC_LIST_DEQUEUE(sevent->bufferlist, &query->lengthbuf, link); + length = isc_buffer_getuint16(b); + if (length == 0) { + isc_event_free(&event); + launch_next_query(query, ISC_FALSE); + UNLOCK_LOOKUP; + return; + } + + /* + * Even though the buffer was already init'ed, we need + * to redo it now, to force the length we want. + */ + isc_buffer_invalidate(&query->recvbuf); + isc_buffer_init(&query->recvbuf, query->recvspace, length); + ENSURE(ISC_LIST_EMPTY(query->recvlist)); + ISC_LINK_INIT(&query->recvbuf, link); + ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link); + debug("recving with lookup=%p, query=%p", + query->lookup, query); + result = isc_socket_recvv(query->sock, &query->recvlist, length, task, + recv_done, query); + check_result(result, "isc_socket_recvv"); + recvcount++; + debug("resubmitted recv request with length %d, recvcount=%d", + length, recvcount); + isc_event_free(&event); + UNLOCK_LOOKUP; +} + +/* + * For transfers that involve multiple recvs (XFR's in particular), + * launch the next recv. + */ +static void +launch_next_query(dig_query_t *query, isc_boolean_t include_question) { + isc_result_t result; + dig_lookup_t *l; + + INSIST(!free_now); + + debug("launch_next_query()"); + + if (!query->lookup->pending) { + debug("ignoring launch_next_query because !pending"); + isc_socket_detach(&query->sock); + sockcount--; + debug("sockcount=%d", sockcount); + INSIST(sockcount >= 0); + query->waiting_connect = ISC_FALSE; + l = query->lookup; + clear_query(query); + check_next_lookup(l); + return; + } + + isc_buffer_clear(&query->slbuf); + isc_buffer_clear(&query->lengthbuf); + isc_buffer_putuint16(&query->slbuf, + (isc_uint16_t) query->lookup->sendbuf.used); + ISC_LIST_INIT(query->sendlist); + ISC_LINK_INIT(&query->slbuf, link); + ISC_LIST_ENQUEUE(query->sendlist, &query->slbuf, link); + if (include_question) { + ISC_LINK_INIT(&query->lookup->sendbuf, link); + ISC_LIST_ENQUEUE(query->sendlist, &query->lookup->sendbuf, + link); + } + ISC_LINK_INIT(&query->lengthbuf, link); + ISC_LIST_ENQUEUE(query->lengthlist, &query->lengthbuf, link); + + result = isc_socket_recvv(query->sock, &query->lengthlist, 0, + global_task, tcp_length_done, query); + check_result(result, "isc_socket_recvv"); + recvcount++; + debug("recvcount=%d", recvcount); + if (!query->first_soa_rcvd) { + debug("sending a request in launch_next_query"); + TIME_NOW(&query->time_sent); + result = isc_socket_sendv(query->sock, &query->sendlist, + global_task, send_done, query); + check_result(result, "isc_socket_sendv"); + sendcount++; + debug("sendcount=%d", sendcount); + } + query->waiting_connect = ISC_FALSE; +#if 0 + check_next_lookup(query->lookup); +#endif + return; +} + +/* + * Event handler for TCP connect complete. Make sure the connection was + * successful, then pass into launch_next_query to actually send the + * question. + */ +static void +connect_done(isc_task_t *task, isc_event_t *event) { + isc_socketevent_t *sevent = NULL; + dig_query_t *query = NULL, *next; + dig_lookup_t *l; + + UNUSED(task); + + REQUIRE(event->ev_type == ISC_SOCKEVENT_CONNECT); + INSIST(!free_now); + + debug("connect_done()"); + + LOCK_LOOKUP; + sevent = (isc_socketevent_t *)event; + query = sevent->ev_arg; + + INSIST(query->waiting_connect); + + query->waiting_connect = ISC_FALSE; + + if (sevent->result == ISC_R_CANCELED) { + debug("in cancel handler"); + isc_socket_detach(&query->sock); + sockcount--; + INSIST(sockcount >= 0); + debug("sockcount=%d", sockcount); + query->waiting_connect = ISC_FALSE; + isc_event_free(&event); + l = query->lookup; + clear_query(query); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } + if (sevent->result != ISC_R_SUCCESS) { + char sockstr[ISC_SOCKADDR_FORMATSIZE]; + + debug("unsuccessful connection: %s", + isc_result_totext(sevent->result)); + isc_sockaddr_format(&query->sockaddr, sockstr, + sizeof(sockstr)); + if (sevent->result != ISC_R_CANCELED) + printf(";; Connection to %s(%s) for %s failed: " + "%s.\n", sockstr, + query->servname, query->lookup->textname, + isc_result_totext(sevent->result)); + isc_socket_detach(&query->sock); + sockcount--; + INSIST(sockcount >= 0); + /* XXX Clean up exitcodes */ + if (exitcode < 9) + exitcode = 9; + debug("sockcount=%d", sockcount); + query->waiting_connect = ISC_FALSE; + isc_event_free(&event); + l = query->lookup; + if (l->current_query != NULL) + next = ISC_LIST_NEXT(l->current_query, link); + else + next = NULL; + clear_query(query); + if (next != NULL) { + bringup_timer(next, TCP_TIMEOUT); + send_tcp_connect(next); + } else { + check_next_lookup(l); + } + UNLOCK_LOOKUP; + return; + } + launch_next_query(query, ISC_TRUE); + isc_event_free(&event); + UNLOCK_LOOKUP; +} + +/* + * Check if the ongoing XFR needs more data before it's complete, using + * the semantics of IXFR and AXFR protocols. Much of the complexity of + * this routine comes from determining when an IXFR is complete. + * ISC_FALSE means more data is on the way, and the recv has been issued. + */ +static isc_boolean_t +check_for_more_data(dig_query_t *query, dns_message_t *msg, + isc_socketevent_t *sevent) +{ + dns_rdataset_t *rdataset = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdata_soa_t soa; + isc_uint32_t serial; + isc_result_t result; + + debug("check_for_more_data()"); + + /* + * By the time we're in this routine, we know we're doing + * either an AXFR or IXFR. If there's no second_rr_type, + * then we don't yet know which kind of answer we got back + * from the server. Here, we're going to walk through the + * rr's in the message, acting as necessary whenever we hit + * an SOA rr. + */ + + query->msg_count++; + result = dns_message_firstname(msg, DNS_SECTION_ANSWER); + if (result != ISC_R_SUCCESS) { + puts("; Transfer failed."); + return (ISC_TRUE); + } + do { + dns_name_t *name; + name = NULL; + dns_message_currentname(msg, DNS_SECTION_ANSWER, + &name); + for (rdataset = ISC_LIST_HEAD(name->list); + rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) { + result = dns_rdataset_first(rdataset); + if (result != ISC_R_SUCCESS) + continue; + do { + query->rr_count++; + dns_rdata_reset(&rdata); + dns_rdataset_current(rdataset, &rdata); + /* + * If this is the first rr, make sure + * it's an SOA + */ + if ((!query->first_soa_rcvd) && + (rdata.type != dns_rdatatype_soa)) { + puts("; Transfer failed. " + "Didn't start with " + "SOA answer."); + return (ISC_TRUE); + } + if ((!query->second_rr_rcvd) && + (rdata.type != dns_rdatatype_soa)) { + query->second_rr_rcvd = ISC_TRUE; + query->second_rr_serial = 0; + debug("got the second rr as nonsoa"); + goto next_rdata; + } + + /* + * If the record is anything except an SOA + * now, just continue on... + */ + if (rdata.type != dns_rdatatype_soa) + goto next_rdata; + /* Now we have an SOA. Work with it. */ + debug("got an SOA"); + (void)dns_rdata_tostruct(&rdata, &soa, NULL); + serial = soa.serial; + dns_rdata_freestruct(&soa); + if (!query->first_soa_rcvd) { + query->first_soa_rcvd = ISC_TRUE; + query->first_rr_serial = serial; + debug("this is the first %d", + query->lookup->ixfr_serial); + if (query->lookup->ixfr_serial >= + serial) + goto doexit; + goto next_rdata; + } + if (query->lookup->rdtype == + dns_rdatatype_axfr) { + debug("doing axfr, got second SOA"); + goto doexit; + } + if (!query->second_rr_rcvd) { + if (query->first_rr_serial == serial) { + debug("doing ixfr, got " + "empty zone"); + goto doexit; + } + debug("this is the second %d", + query->lookup->ixfr_serial); + query->second_rr_rcvd = ISC_TRUE; + query->second_rr_serial = serial; + goto next_rdata; + } + if (query->second_rr_serial == 0) { + /* + * If the second RR was a non-SOA + * record, and we're getting any + * other SOA, then this is an + * AXFR, and we're done. + */ + debug("done, since axfr"); + goto doexit; + } + /* + * If we get to this point, we're doing an + * IXFR and have to start really looking + * at serial numbers. + */ + if (query->first_rr_serial == serial) { + debug("got a match for ixfr"); + if (!query->first_repeat_rcvd) { + query->first_repeat_rcvd = + ISC_TRUE; + goto next_rdata; + } + debug("done with ixfr"); + goto doexit; + } + debug("meaningless soa %d", serial); + next_rdata: + result = dns_rdataset_next(rdataset); + } while (result == ISC_R_SUCCESS); + } + result = dns_message_nextname(msg, DNS_SECTION_ANSWER); + } while (result == ISC_R_SUCCESS); + launch_next_query(query, ISC_FALSE); + return (ISC_FALSE); + doexit: + received(sevent->n, &sevent->address, query); + return (ISC_TRUE); +} + +/* + * Event handler for recv complete. Perform whatever actions are necessary, + * based on the specifics of the user's request. + */ +static void +recv_done(isc_task_t *task, isc_event_t *event) { + isc_socketevent_t *sevent = NULL; + dig_query_t *query = NULL; + isc_buffer_t *b = NULL; + dns_message_t *msg = NULL; +#ifdef DIG_SIGCHASE + dig_message_t *chase_msg = NULL; + dig_message_t *chase_msg2 = NULL; +#endif + isc_result_t result; + dig_lookup_t *n, *l; + isc_boolean_t docancel = ISC_FALSE; + isc_boolean_t match = ISC_TRUE; + unsigned int parseflags; + dns_messageid_t id; + unsigned int msgflags; +#ifdef DIG_SIGCHASE + isc_result_t do_sigchase = ISC_FALSE; + + dns_message_t *msg_temp = NULL; + isc_region_t r; + isc_buffer_t *buf = NULL; +#endif + + UNUSED(task); + INSIST(!free_now); + + debug("recv_done()"); + + LOCK_LOOKUP; + recvcount--; + debug("recvcount=%d", recvcount); + INSIST(recvcount >= 0); + + query = event->ev_arg; + debug("lookup=%p, query=%p", query->lookup, query); + + l = query->lookup; + + REQUIRE(event->ev_type == ISC_SOCKEVENT_RECVDONE); + sevent = (isc_socketevent_t *)event; + + if ((l->tcp_mode) && (l->timer != NULL)) + isc_timer_touch(l->timer); + if ((!l->pending && !l->ns_search_only) || cancel_now) { + debug("no longer pending. Got %s", + isc_result_totext(sevent->result)); + query->waiting_connect = ISC_FALSE; + + isc_event_free(&event); + clear_query(query); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } + + if (sevent->result != ISC_R_SUCCESS) { + if (sevent->result == ISC_R_CANCELED) { + debug("in recv cancel handler"); + query->waiting_connect = ISC_FALSE; + } else { + printf(";; communications error: %s\n", + isc_result_totext(sevent->result)); + isc_socket_detach(&query->sock); + sockcount--; + debug("sockcount=%d", sockcount); + INSIST(sockcount >= 0); + } + isc_event_free(&event); + clear_query(query); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } + + b = ISC_LIST_HEAD(sevent->bufferlist); + ISC_LIST_DEQUEUE(sevent->bufferlist, &query->recvbuf, link); + + if (!l->tcp_mode && + !isc_sockaddr_equal(&sevent->address, &query->sockaddr)) { + char buf1[ISC_SOCKADDR_FORMATSIZE]; + char buf2[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_t any; + + if (isc_sockaddr_pf(&query->sockaddr) == AF_INET) + isc_sockaddr_any(&any); + else + isc_sockaddr_any6(&any); + + /* + * We don't expect a match when the packet is + * sent to 0.0.0.0, :: or to a multicast addresses. + * XXXMPA broadcast needs to be handled here as well. + */ + if ((!isc_sockaddr_eqaddr(&query->sockaddr, &any) && + !isc_sockaddr_ismulticast(&query->sockaddr)) || + isc_sockaddr_getport(&query->sockaddr) != + isc_sockaddr_getport(&sevent->address)) { + isc_sockaddr_format(&sevent->address, buf1, + sizeof(buf1)); + isc_sockaddr_format(&query->sockaddr, buf2, + sizeof(buf2)); + printf(";; reply from unexpected source: %s," + " expected %s\n", buf1, buf2); + match = ISC_FALSE; + } + } + + result = dns_message_peekheader(b, &id, &msgflags); + if (result != ISC_R_SUCCESS || l->sendmsg->id != id) { + match = ISC_FALSE; + if (l->tcp_mode) { + isc_boolean_t fail = ISC_TRUE; + if (result == ISC_R_SUCCESS) { + if (!query->first_soa_rcvd || + query->warn_id) + printf(";; %s: ID mismatch: " + "expected ID %u, got %u\n", + query->first_soa_rcvd ? + "WARNING" : "ERROR", + l->sendmsg->id, id); + if (query->first_soa_rcvd) + fail = ISC_FALSE; + query->warn_id = ISC_FALSE; + } else + printf(";; ERROR: short " + "(< header size) message\n"); + if (fail) { + isc_event_free(&event); + clear_query(query); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } + match = ISC_TRUE; + } else if (result == ISC_R_SUCCESS) + printf(";; Warning: ID mismatch: " + "expected ID %u, got %u\n", l->sendmsg->id, id); + else + printf(";; Warning: short " + "(< header size) message received\n"); + } + + if (!match) { + isc_buffer_invalidate(&query->recvbuf); + isc_buffer_init(&query->recvbuf, query->recvspace, COMMSIZE); + ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link); + result = isc_socket_recvv(query->sock, &query->recvlist, 1, + global_task, recv_done, query); + check_result(result, "isc_socket_recvv"); + recvcount++; + isc_event_free(&event); + UNLOCK_LOOKUP; + return; + } + + result = dns_message_create(mctx, DNS_MESSAGE_INTENTPARSE, &msg); + check_result(result, "dns_message_create"); + + if (key != NULL) { + if (l->querysig == NULL) { + debug("getting initial querysig"); + result = dns_message_getquerytsig(l->sendmsg, mctx, + &l->querysig); + check_result(result, "dns_message_getquerytsig"); + } + result = dns_message_setquerytsig(msg, l->querysig); + check_result(result, "dns_message_setquerytsig"); + result = dns_message_settsigkey(msg, key); + check_result(result, "dns_message_settsigkey"); + msg->tsigctx = l->tsigctx; + l->tsigctx = NULL; + if (l->msgcounter != 0) + msg->tcp_continuation = 1; + l->msgcounter++; + } + + debug("before parse starts"); + parseflags = DNS_MESSAGEPARSE_PRESERVEORDER; +#ifdef DIG_SIGCHASE + if (!l->sigchase) { + do_sigchase = ISC_FALSE; + } else { + parseflags = 0; + do_sigchase = ISC_TRUE; + } +#endif + if (l->besteffort) { + parseflags |= DNS_MESSAGEPARSE_BESTEFFORT; + parseflags |= DNS_MESSAGEPARSE_IGNORETRUNCATION; + } + result = dns_message_parse(msg, b, parseflags); + if (result == DNS_R_RECOVERABLE) { + printf(";; Warning: Message parser reports malformed " + "message packet.\n"); + result = ISC_R_SUCCESS; + } + if (result != ISC_R_SUCCESS) { + printf(";; Got bad packet: %s\n", isc_result_totext(result)); + hex_dump(b); + query->waiting_connect = ISC_FALSE; + dns_message_destroy(&msg); + isc_event_free(&event); + clear_query(query); + cancel_lookup(l); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } + if ((msg->flags & DNS_MESSAGEFLAG_TC) != 0 + && !l->ignore && !l->tcp_mode) { + printf(";; Truncated, retrying in TCP mode.\n"); + n = requeue_lookup(l, ISC_TRUE); + n->tcp_mode = ISC_TRUE; + n->origin = query->lookup->origin; + dns_message_destroy(&msg); + isc_event_free(&event); + clear_query(query); + cancel_lookup(l); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } + if (msg->rcode == dns_rcode_servfail && !l->servfail_stops) { + dig_query_t *next = ISC_LIST_NEXT(query, link); + if (l->current_query == query) + l->current_query = NULL; + if (next != NULL) { + debug("sending query %p\n", next); + if (l->tcp_mode) + send_tcp_connect(next); + else + send_udp(next); + } + /* + * If our query is at the head of the list and there + * is no next, we're the only one left, so fall + * through to print the message. + */ + if ((ISC_LIST_HEAD(l->q) != query) || + (ISC_LIST_NEXT(query, link) != NULL)) { + printf(";; Got SERVFAIL reply from %s, " + "trying next server\n", + query->servname); + clear_query(query); + check_next_lookup(l); + dns_message_destroy(&msg); + isc_event_free(&event); + UNLOCK_LOOKUP; + return; + } + } + + if (key != NULL) { + result = dns_tsig_verify(&query->recvbuf, msg, NULL, NULL); + if (result != ISC_R_SUCCESS) { + printf(";; Couldn't verify signature: %s\n", + isc_result_totext(result)); + validated = ISC_FALSE; + } + l->tsigctx = msg->tsigctx; + msg->tsigctx = NULL; + if (l->querysig != NULL) { + debug("freeing querysig buffer %p", l->querysig); + isc_buffer_free(&l->querysig); + } + result = dns_message_getquerytsig(msg, mctx, &l->querysig); + check_result(result,"dns_message_getquerytsig"); + } + + debug("after parse"); + if (l->doing_xfr && l->xfr_q == NULL) { + l->xfr_q = query; + /* + * Once we are in the XFR message, increase + * the timeout to much longer, so brief network + * outages won't cause the XFR to abort + */ + if (timeout != INT_MAX && l->timer != NULL) { + unsigned int local_timeout; + + if (timeout == 0) { + if (l->tcp_mode) + local_timeout = TCP_TIMEOUT * 4; + else + local_timeout = UDP_TIMEOUT * 4; + } else { + if (timeout < (INT_MAX / 4)) + local_timeout = timeout * 4; + else + local_timeout = INT_MAX; + } + debug("have local timeout of %d", local_timeout); + isc_interval_set(&l->interval, local_timeout, 0); + result = isc_timer_reset(l->timer, + isc_timertype_once, + NULL, + &l->interval, + ISC_FALSE); + check_result(result, "isc_timer_reset"); + } + } + + if (!l->doing_xfr || l->xfr_q == query) { +#ifdef DIG_SIGCHASE + int count = 0; +#endif + if (msg->rcode != dns_rcode_noerror && l->origin != NULL) { + if (!next_origin(msg, query)) { + printmessage(query, msg, ISC_TRUE); + received(b->used, &sevent->address, query); + } + } else if (!l->trace && !l->ns_search_only) { +#ifdef DIG_SIGCHASE + if (!do_sigchase) +#endif + printmessage(query, msg, ISC_TRUE); + } else if (l->trace) { + int n = 0; +#ifdef DIG_SIGCHASE + count = msg->counts[DNS_SECTION_ANSWER]; +#else + int count = msg->counts[DNS_SECTION_ANSWER]; +#endif + + debug("in TRACE code"); + if (!l->ns_search_only) + printmessage(query, msg, ISC_TRUE); + + l->rdtype = l->qrdtype; + if (l->trace_root || (l->ns_search_only && count > 0)) { + if (!l->trace_root) + l->rdtype = dns_rdatatype_soa; + n = followup_lookup(msg, query, + DNS_SECTION_ANSWER); + l->trace_root = ISC_FALSE; + } else if (count == 0) + n = followup_lookup(msg, query, + DNS_SECTION_AUTHORITY); + if (n == 0) + docancel = ISC_TRUE; + } else { + debug("in NSSEARCH code"); + + if (l->trace_root) { + /* + * This is the initial NS query. + */ + int n; + + l->rdtype = dns_rdatatype_soa; + n = followup_lookup(msg, query, + DNS_SECTION_ANSWER); + if (n == 0) + docancel = ISC_TRUE; + l->trace_root = ISC_FALSE; + } else +#ifdef DIG_SIGCHASE + if (!do_sigchase) +#endif + printmessage(query, msg, ISC_TRUE); + } +#ifdef DIG_SIGCHASE + if ( do_sigchase) { + chase_msg = isc_mem_allocate(mctx, + sizeof(dig_message_t)); + if (chase_msg == NULL) { + fatal("Memory allocation failure in %s:%d", + __FILE__, __LINE__); + } + ISC_LIST_INITANDAPPEND(chase_message_list, chase_msg, + link); + if (dns_message_create(mctx, DNS_MESSAGE_INTENTPARSE, + &msg_temp) != ISC_R_SUCCESS) { + fatal("dns_message_create in %s:%d", + __FILE__, __LINE__); + } + + isc_buffer_usedregion(b, &r); + result = isc_buffer_allocate(mctx, &buf, r.length); + + check_result(result, "isc_buffer_allocate"); + result = isc_buffer_copyregion(buf, &r); + check_result(result, "isc_buffer_copyregion"); + + result = dns_message_parse(msg_temp, buf, 0); + + isc_buffer_free(&buf); + chase_msg->msg = msg_temp; + + chase_msg2 = isc_mem_allocate(mctx, + sizeof(dig_message_t)); + if (chase_msg2 == NULL) { + fatal("Memory allocation failure in %s:%d", + __FILE__, __LINE__); + } + ISC_LIST_INITANDAPPEND(chase_message_list2, chase_msg2, + link); + chase_msg2->msg = msg; + } +#endif + + } + +#ifdef DIG_SIGCHASE + if (l->sigchase && ISC_LIST_EMPTY(lookup_list) ) { + sigchase(msg_temp); + } +#endif + + if (l->pending) + debug("still pending."); + if (l->doing_xfr) { + if (query != l->xfr_q) { + dns_message_destroy(&msg); + isc_event_free(&event); + query->waiting_connect = ISC_FALSE; + UNLOCK_LOOKUP; + return; + } + if (!docancel) + docancel = check_for_more_data(query, msg, sevent); + if (docancel) { + dns_message_destroy(&msg); + clear_query(query); + cancel_lookup(l); + check_next_lookup(l); + } + } else { + + if (msg->rcode == dns_rcode_noerror || l->origin == NULL) { + +#ifdef DIG_SIGCHASE + if (!l->sigchase) +#endif + received(b->used, &sevent->address, query); + } + + if (!query->lookup->ns_search_only) + query->lookup->pending = ISC_FALSE; + if (!query->lookup->ns_search_only || + query->lookup->trace_root || docancel) { +#ifdef DIG_SIGCHASE + if (!do_sigchase) +#endif + dns_message_destroy(&msg); + + cancel_lookup(l); + } + clear_query(query); + check_next_lookup(l); + } + if (msg != NULL) { +#ifdef DIG_SIGCHASE + if (do_sigchase) + msg = NULL; + else +#endif + dns_message_destroy(&msg); + } + isc_event_free(&event); + UNLOCK_LOOKUP; +} + +/* + * Turn a name into an address, using system-supplied routines. This is + * used in looking up server names, etc... and needs to use system-supplied + * routines, since they may be using a non-DNS system for these lookups. + */ +void +get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr) { + int count; + isc_result_t result; + + isc_app_block(); + result = bind9_getaddresses(host, port, sockaddr, 1, &count); + isc_app_unblock(); + if (result != ISC_R_SUCCESS) + fatal("couldn't get address for '%s': %s", + host, isc_result_totext(result)); + INSIST(count == 1); +} + +/* + * Initiate either a TCP or UDP lookup + */ +void +do_lookup(dig_lookup_t *lookup) { + + REQUIRE(lookup != NULL); + + debug("do_lookup()"); + lookup->pending = ISC_TRUE; + if (lookup->tcp_mode) + send_tcp_connect(ISC_LIST_HEAD(lookup->q)); + else + send_udp(ISC_LIST_HEAD(lookup->q)); +} + +/* + * Start everything in action upon task startup. + */ +void +onrun_callback(isc_task_t *task, isc_event_t *event) { + UNUSED(task); + + isc_event_free(&event); + LOCK_LOOKUP; + start_lookup(); + UNLOCK_LOOKUP; +} + +/* + * Make everything on the lookup queue go away. Mainly used by the + * SIGINT handler. + */ +void +cancel_all(void) { + dig_lookup_t *l, *n; + dig_query_t *q, *nq; + + debug("cancel_all()"); + + LOCK_LOOKUP; + if (free_now) { + UNLOCK_LOOKUP; + return; + } + cancel_now = ISC_TRUE; + if (current_lookup != NULL) { + if (current_lookup->timer != NULL) + isc_timer_detach(¤t_lookup->timer); + q = ISC_LIST_HEAD(current_lookup->q); + while (q != NULL) { + debug("cancelling query %p, belonging to %p", + q, current_lookup); + nq = ISC_LIST_NEXT(q, link); + if (q->sock != NULL) { + isc_socket_cancel(q->sock, NULL, + ISC_SOCKCANCEL_ALL); + } else { + clear_query(q); + } + q = nq; + } + } + l = ISC_LIST_HEAD(lookup_list); + while (l != NULL) { + n = ISC_LIST_NEXT(l, link); + ISC_LIST_DEQUEUE(lookup_list, l, link); + try_clear_lookup(l); + l = n; + } + UNLOCK_LOOKUP; +} + +/* + * Destroy all of the libs we are using, and get everything ready for a + * clean shutdown. + */ +void +destroy_libs(void) { +#ifdef DIG_SIGCHASE + void * ptr; + dig_message_t *chase_msg; +#endif + + debug("destroy_libs()"); + if (global_task != NULL) { + debug("freeing task"); + isc_task_detach(&global_task); + } + /* + * The taskmgr_destroy() call blocks until all events are cleared + * from the task. + */ + if (taskmgr != NULL) { + debug("freeing taskmgr"); + isc_taskmgr_destroy(&taskmgr); + } + LOCK_LOOKUP; + REQUIRE(sockcount == 0); + REQUIRE(recvcount == 0); + REQUIRE(sendcount == 0); + + INSIST(ISC_LIST_HEAD(lookup_list) == NULL); + INSIST(current_lookup == NULL); + INSIST(!free_now); + + free_now = ISC_TRUE; + + lwres_conf_clear(lwctx); + lwres_context_destroy(&lwctx); + + flush_server_list(); + + clear_searchlist(); + if (commctx != NULL) { + debug("freeing commctx"); + isc_mempool_destroy(&commctx); + } + if (socketmgr != NULL) { + debug("freeing socketmgr"); + isc_socketmgr_destroy(&socketmgr); + } + if (timermgr != NULL) { + debug("freeing timermgr"); + isc_timermgr_destroy(&timermgr); + } + if (key != NULL) { + debug("freeing key %p", key); + dns_tsigkey_detach(&key); + } + if (namebuf != NULL) + isc_buffer_free(&namebuf); + + if (is_dst_up) { + debug("destroy DST lib"); + dst_lib_destroy(); + is_dst_up = ISC_FALSE; + } + if (entp != NULL) { + debug("detach from entropy"); + isc_entropy_detach(&entp); + } + + UNLOCK_LOOKUP; + DESTROYLOCK(&lookup_lock); +#ifdef DIG_SIGCHASE + + debug("Destroy the messages kept for sigchase"); + /* Destroy the messages kept for sigchase */ + chase_msg = ISC_LIST_HEAD(chase_message_list); + + while (chase_msg != NULL) { + INSIST(chase_msg->msg != NULL); + dns_message_destroy(&(chase_msg->msg)); + ptr = chase_msg; + chase_msg = ISC_LIST_NEXT(chase_msg, link); + isc_mem_free(mctx, ptr); + } + + chase_msg = ISC_LIST_HEAD(chase_message_list2); + + while (chase_msg != NULL) { + INSIST(chase_msg->msg != NULL); + dns_message_destroy(&(chase_msg->msg)); + ptr = chase_msg; + chase_msg = ISC_LIST_NEXT(chase_msg, link); + isc_mem_free(mctx, ptr); + } + if (dns_name_dynamic(&chase_name)) + dns_name_free(&chase_name, mctx); +#if DIG_SIGCHASE_TD + if (dns_name_dynamic(&chase_current_name)) + dns_name_free(&chase_current_name, mctx); + if (dns_name_dynamic(&chase_authority_name)) + dns_name_free(&chase_authority_name, mctx); +#endif +#if DIG_SIGCHASE_BU + if (dns_name_dynamic(&chase_signame)) + dns_name_free(&chase_signame, mctx); +#endif + + debug("Destroy memory"); + +#endif + if (memdebugging != 0) + isc_mem_stats(mctx, stderr); + if (mctx != NULL) + isc_mem_destroy(&mctx); +} + + + + +#ifdef DIG_SIGCHASE +void +print_type(dns_rdatatype_t type) +{ + isc_buffer_t * b = NULL; + isc_result_t result; + isc_region_t r; + + result = isc_buffer_allocate(mctx, &b, 4000); + check_result(result, "isc_buffer_allocate"); + + result = dns_rdatatype_totext(type, b); + check_result(result, "print_type"); + + isc_buffer_usedregion(b, &r); + r.base[r.length] = '\0'; + + printf("%s", r.base); + + isc_buffer_free(&b); +} + + +void +dump_database_section( dns_message_t *msg, int section) +{ + dns_name_t *msg_name=NULL; + + dns_rdataset_t *rdataset; + + do { + dns_message_currentname(msg, section, &msg_name); + + for (rdataset = ISC_LIST_HEAD(msg_name->list); rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) { + dns_name_print(msg_name, stdout); + printf("\n"); + print_rdataset(msg_name, rdataset, mctx); + printf("end\n"); + } + msg_name = NULL; + } while ( dns_message_nextname(msg, section) == ISC_R_SUCCESS); +} + + +void dump_database(void) +{ + dig_message_t * msg; + + for (msg = ISC_LIST_HEAD(chase_message_list); msg != NULL; + msg = ISC_LIST_NEXT(msg, link)) { + if (dns_message_firstname(msg->msg, DNS_SECTION_ANSWER) + == ISC_R_SUCCESS) + dump_database_section(msg->msg, DNS_SECTION_ANSWER); + + if (dns_message_firstname(msg->msg, DNS_SECTION_AUTHORITY) + == ISC_R_SUCCESS) + dump_database_section(msg->msg, DNS_SECTION_AUTHORITY); + + if (dns_message_firstname(msg->msg, DNS_SECTION_ADDITIONAL) + == ISC_R_SUCCESS) + dump_database_section(msg->msg, DNS_SECTION_ADDITIONAL); + } +} + + +dns_rdataset_t * search_type(dns_name_t *name, + dns_rdatatype_t type, + dns_rdatatype_t covers) +{ + dns_rdataset_t *rdataset; + dns_rdata_sig_t siginfo; + dns_rdata_t sigrdata; + isc_result_t result; + + for (rdataset = ISC_LIST_HEAD(name->list); rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) { + if (type == dns_rdatatype_any) { + if (rdataset->type != dns_rdatatype_rrsig) + return rdataset; + } + else if ((type == dns_rdatatype_rrsig) && + (rdataset->type == dns_rdatatype_rrsig)) { + dns_rdata_init(&sigrdata); + result = dns_rdataset_first(rdataset); + check_result(result, "empty rdataset"); + dns_rdataset_current(rdataset, &sigrdata); + result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL); + check_result(result, "sigrdata tostruct siginfo"); + + if ((siginfo.covered == covers) || + (covers == dns_rdatatype_any)) { + dns_rdata_reset(&sigrdata); + dns_rdata_freestruct(&siginfo); + return rdataset; + } + dns_rdata_reset(&sigrdata); + dns_rdata_freestruct(&siginfo); + } + else if (rdataset->type == type) + return rdataset; + } + return NULL; +} + +dns_rdataset_t * +chase_scanname_section(dns_message_t *msg, + dns_name_t *name, + dns_rdatatype_t type, + dns_rdatatype_t covers, + int section) +{ + dns_rdataset_t *rdataset; + dns_name_t *msg_name = NULL; + + do { + dns_message_currentname(msg, section, &msg_name); + if (dns_name_compare(msg_name, name) == 0) { + rdataset = search_type(msg_name, type, covers); + if ( rdataset != NULL) + return rdataset; + } + msg_name = NULL; + } while ( dns_message_nextname(msg, section) == ISC_R_SUCCESS); + + return(NULL); +} + + +dns_rdataset_t * +chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) +{ + dns_rdataset_t *rdataset = NULL; + dig_message_t * msg; + + for (msg = ISC_LIST_HEAD(chase_message_list2); msg != NULL; + msg = ISC_LIST_NEXT(msg, link)) { + if (dns_message_firstname(msg->msg, DNS_SECTION_ANSWER) + == ISC_R_SUCCESS) + rdataset = chase_scanname_section(msg->msg, name, + type, covers, + DNS_SECTION_ANSWER); + if (rdataset != NULL) + return rdataset; + if (dns_message_firstname(msg->msg, DNS_SECTION_AUTHORITY) + == ISC_R_SUCCESS) + rdataset = + chase_scanname_section(msg->msg, name, + type, covers, + DNS_SECTION_AUTHORITY); + if (rdataset != NULL) + return rdataset; + if (dns_message_firstname(msg->msg, DNS_SECTION_ADDITIONAL) + == ISC_R_SUCCESS) + rdataset = + chase_scanname_section(msg->msg, name, type, + covers, + DNS_SECTION_ADDITIONAL); + if (rdataset != NULL) + return rdataset; + } + + return NULL; +} + +dns_rdataset_t * +sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers, + isc_boolean_t * lookedup, + dns_name_t *rdata_name ) +{ + dig_lookup_t *lookup; + isc_buffer_t *b = NULL; + isc_region_t r; + isc_result_t result; + dns_rdataset_t * temp; + dns_rdatatype_t querytype; + + if ((temp=chase_scanname(rdata_name, type, covers))!=NULL) { + return(temp); + } + + if (*lookedup == ISC_TRUE) { + return(NULL); + } + + lookup = clone_lookup(current_lookup, ISC_TRUE); + lookup->trace_root = ISC_FALSE; + lookup->new_search = ISC_TRUE; + + result = isc_buffer_allocate(mctx, &b, BUFSIZE); + check_result(result, "isc_buffer_allocate"); + result = dns_name_totext(rdata_name, ISC_FALSE, b); + check_result(result, "dns_name_totext"); + isc_buffer_usedregion(b, &r); + r.base[r.length] = '\0'; + strcpy(lookup->textname, (char*)r.base); + isc_buffer_free(&b); + + if (type == dns_rdatatype_rrsig) + querytype = covers; + else + querytype = type; + if (querytype == 0 || querytype == 255) { + printf("Error in the queried type: %d\n", querytype); + return(NULL); + } + + lookup->rdtype = querytype; + lookup->rdtypeset = ISC_TRUE; + lookup->qrdtype = querytype; + *lookedup = ISC_TRUE; + + ISC_LIST_APPEND(lookup_list, lookup, link); + printf("\n\nLaunch a query to find a RRset of type "); + print_type(type); + printf(" for zone: %s\n", lookup->textname); + return(NULL); +} + +void +insert_trustedkey(dst_key_t * key) +{ + if (key == NULL) + return; + if (tk_list.nb_tk >= MAX_TRUSTED_KEY) + return; + + tk_list.key[tk_list.nb_tk++] = key; + return; +} + +void +clean_trustedkey() +{ + int i = 0; + + for (i= 0; i < MAX_TRUSTED_KEY; i++) { + if (tk_list.key[i] != NULL) { + dst_key_free(&tk_list.key[i]); + tk_list.key[i] = NULL; + } + else + break; + } + tk_list.nb_tk = 0; + return; +} + +char alphnum[] = + "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; + +isc_result_t +removetmpkey(isc_mem_t *mctx, const char *file) +{ + char *tempnamekey = NULL; + int tempnamekeylen; + isc_result_t result; + + tempnamekeylen = strlen(file)+10; + + tempnamekey = isc_mem_allocate(mctx, tempnamekeylen); + if (tempnamekey == NULL) + return (ISC_R_NOMEMORY); + + memset(tempnamekey, 0, tempnamekeylen); + + strcat(tempnamekey, file); + strcat(tempnamekey,".key"); + isc_file_remove(tempnamekey); + + result = isc_file_remove(tempnamekey); + isc_mem_free(mctx, tempnamekey); + return(result); +} + +isc_result_t +opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) { + FILE *f = NULL; + isc_result_t result; + char *tempname = NULL; + char *tempnamekey = NULL; + int tempnamelen; + int tempnamekeylen; + char *x; + char *cp; + isc_uint32_t which; + + while (1) { + tempnamelen = strlen(file) + 20; + tempname = isc_mem_allocate(mctx, tempnamelen); + if (tempname == NULL) + return (ISC_R_NOMEMORY); + memset(tempname, 0, tempnamelen); + + result = isc_file_mktemplate(file, tempname, tempnamelen); + if (result != ISC_R_SUCCESS) + goto cleanup; + + cp = tempname; + while (*cp != '\0') + cp++; + if (cp == tempname) { + isc_mem_free(mctx, tempname); + return (ISC_R_FAILURE); + } + + x = cp--; + while (cp >= tempname && *cp == 'X') { + isc_random_get(&which); + *cp = alphnum[which % (sizeof(alphnum) - 1)]; + x = cp--; + } + + tempnamekeylen = tempnamelen+5; + tempnamekey = isc_mem_allocate(mctx, tempnamekeylen); + if (tempnamekey == NULL) + return (ISC_R_NOMEMORY); + + memset(tempnamekey, 0, tempnamekeylen); + strncpy(tempnamekey, tempname, tempnamelen); + strcat(tempnamekey ,".key"); + + + if (isc_file_exists(tempnamekey)) { + isc_mem_free(mctx, tempnamekey); + isc_mem_free(mctx, tempname); + continue; + } + + if ((f = fopen(tempnamekey, "w")) == NULL) { + printf("get_trusted_key(): trusted key not found %s\n", + tempnamekey); + return ISC_R_FAILURE; + } + break; + } + isc_mem_free(mctx, tempnamekey); + *tempp = tempname; + *fp = f; + return (ISC_R_SUCCESS); + + cleanup: + isc_mem_free(mctx, tempname); + + return (result); +} + + +isc_result_t +get_trusted_key(isc_mem_t *mctx) +{ + isc_result_t result; + const char * filename = NULL; + char * filetemp =NULL; + char buf[1500]; + FILE *fp , *fptemp; + dst_key_t * key = NULL; + + result = isc_file_exists(trustedkey); + if (result != ISC_TRUE) { + result = isc_file_exists("/etc/trusted-key.key"); + if (result != ISC_TRUE) { + result = isc_file_exists("./trusted-key.key"); + if (result != ISC_TRUE) + return ISC_R_FAILURE; + else + filename = "./trusted-key.key"; + } + else + filename = "/etc/trusted-key.key"; + } + else + filename = trustedkey; + + if (filename == NULL) { + printf("No trusted key\n"); + return ISC_R_FAILURE; + } + + if ((fp = fopen(filename, "r")) == NULL) { + printf("get_trusted_key(): trusted key not found %s\n", + filename); + return ISC_R_FAILURE; + } + while (fgets(buf, 1500, fp) != NULL) { + result = opentmpkey(mctx,"tmp_file", &filetemp, &fptemp); + if (result != ISC_R_SUCCESS) { + fclose(fp); + return ISC_R_FAILURE; + } + if (fputs(buf, fptemp)<0) { + fclose(fp); + fclose(fptemp); + return ISC_R_FAILURE; + } + fclose(fptemp); + result = dst_key_fromnamedfile(filetemp, DST_TYPE_PUBLIC | + DST_TYPE_KEY, mctx, &key); + removetmpkey(mctx, filetemp); + isc_mem_free(mctx, filetemp); + if (result != ISC_R_SUCCESS ) { + fclose(fp); + return ISC_R_FAILURE; + } + insert_trustedkey(key); +#if 0 + dst_key_tofile(key, DST_TYPE_PUBLIC,"/tmp"); +#endif + key = NULL; + } + return ISC_R_SUCCESS; +} + + +static void +nameFromString(const char *str, dns_name_t *p_ret) { + size_t len = strlen(str); + isc_result_t result; + isc_buffer_t buffer; + dns_fixedname_t fixedname; + + REQUIRE(p_ret != NULL); + REQUIRE(str != NULL); + + isc_buffer_init(&buffer, str, len); + isc_buffer_add(&buffer, len); + + dns_fixedname_init(&fixedname); + result = dns_name_fromtext(dns_fixedname_name(&fixedname), &buffer, + dns_rootname, ISC_TRUE, NULL); + check_result(result, "nameFromString"); + + if (dns_name_dynamic(p_ret)) + dns_name_free(p_ret, mctx); + + result = dns_name_dup(dns_fixedname_name(&fixedname), mctx, p_ret); + check_result(result, "nameFromString"); +} + + +#if DIG_SIGCHASE_TD +isc_result_t +prepare_lookup(dns_name_t *name) +{ + isc_result_t result; + dig_lookup_t * lookup = NULL; + dig_server_t *s; + void *ptr; + + lookup = clone_lookup(current_lookup, ISC_TRUE); + lookup->trace_root = ISC_FALSE; + lookup->new_search = ISC_TRUE; + lookup->trace_root_sigchase = ISC_FALSE; + + strncpy(lookup->textname, lookup->textnamesigchase, MXNAME); + + lookup->rdtype = lookup->rdtype_sigchase; + lookup->rdtypeset = ISC_TRUE; + lookup->qrdtype = lookup->qrdtype_sigchase; + + s = ISC_LIST_HEAD(lookup->my_server_list); + while (s != NULL) { + debug("freeing server %p belonging to %p", + s, lookup); + ptr = s; + s = ISC_LIST_NEXT(s, link); + ISC_LIST_DEQUEUE(lookup->my_server_list, + (dig_server_t *)ptr, link); + isc_mem_free(mctx, ptr); + } + + + for (result = dns_rdataset_first(chase_nsrdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(chase_nsrdataset)) { + char namestr[DNS_NAME_FORMATSIZE]; + dns_rdata_ns_t ns; + dns_rdata_t rdata = DNS_RDATA_INIT; + dig_server_t * srv = NULL; +#define __FOLLOW_GLUE__ +#ifdef __FOLLOW_GLUE__ + isc_buffer_t * b = NULL; + isc_result_t result; + isc_region_t r; + dns_rdataset_t * rdataset =NULL; + isc_boolean_t true = ISC_TRUE; +#endif + + memset(namestr, 0, DNS_NAME_FORMATSIZE); + + dns_rdataset_current(chase_nsrdataset, &rdata); + + (void)dns_rdata_tostruct(&rdata, &ns, NULL); + + + +#ifdef __FOLLOW_GLUE__ + + result = advanced_rrsearch(&rdataset, &ns.name, + dns_rdatatype_aaaa, + dns_rdatatype_any, &true); + if (result == ISC_R_SUCCESS) { + for (result = dns_rdataset_first(rdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(rdataset)) { + dns_rdata_t aaaa = DNS_RDATA_INIT; + dns_rdataset_current(rdataset, &aaaa); + + result = isc_buffer_allocate(mctx, &b, 80); + check_result(result, "isc_buffer_allocate"); + + dns_rdata_totext(&aaaa, &ns.name, b); + isc_buffer_usedregion(b, &r); + r.base[r.length] = '\0'; + strncpy(namestr, (char*)r.base, + DNS_NAME_FORMATSIZE); + isc_buffer_free(&b); + dns_rdata_reset(&aaaa); + + + srv = make_server(namestr); + + ISC_LIST_APPEND(lookup->my_server_list, + srv, link); + } + } + + rdataset = NULL; + result = advanced_rrsearch(&rdataset, &ns.name, dns_rdatatype_a, + dns_rdatatype_any, &true); + if (result == ISC_R_SUCCESS) { + for (result = dns_rdataset_first(rdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(rdataset)) { + dns_rdata_t a = DNS_RDATA_INIT; + dns_rdataset_current(rdataset, &a); + + result = isc_buffer_allocate(mctx, &b, 80); + check_result(result, "isc_buffer_allocate"); + + dns_rdata_totext(&a, &ns.name, b); + isc_buffer_usedregion(b, &r); + r.base[r.length] = '\0'; + strncpy(namestr, (char*)r.base, + DNS_NAME_FORMATSIZE); + isc_buffer_free(&b); + dns_rdata_reset(&a); + printf("ns name: %s\n", namestr); + + + srv = make_server(namestr); + + ISC_LIST_APPEND(lookup->my_server_list, + srv, link); + } + } +#else + + dns_name_format(&ns.name, namestr, sizeof(namestr)); + printf("ns name: "); + dns_name_print(&ns.name, stdout); + printf("\n"); + srv = make_server(namestr); + + ISC_LIST_APPEND(lookup->my_server_list, srv, link); + +#endif + dns_rdata_freestruct(&ns); + dns_rdata_reset(&rdata); + + } + + ISC_LIST_APPEND(lookup_list, lookup, link); + printf("\nLaunch a query to find a RRset of type "); + print_type(lookup->rdtype); + printf(" for zone: %s", lookup->textname); + printf(" with nameservers:"); + printf("\n"); + print_rdataset(name, chase_nsrdataset, mctx); + return ISC_R_SUCCESS; +} + + +isc_result_t +child_of_zone(dns_name_t * name, dns_name_t * zone_name, + dns_name_t * child_name) +{ + dns_namereln_t name_reln; + int orderp; + unsigned int nlabelsp; + + name_reln = dns_name_fullcompare(name, zone_name, &orderp, &nlabelsp); + if ( (name_reln != dns_namereln_subdomain) || + (dns_name_countlabels(name) <= + dns_name_countlabels(zone_name) +1)) { + printf("\n;; ERROR : "); + dns_name_print(name, stdout); + printf(" is not a subdomain of: "); + dns_name_print(zone_name, stdout); + printf(" FAILED\n\n"); + return ISC_R_FAILURE; + } + + dns_name_getlabelsequence(name, + dns_name_countlabels(name) - + dns_name_countlabels(zone_name) -1, + dns_name_countlabels(zone_name) +1, + child_name); + return ISC_R_SUCCESS; +} + +isc_result_t +grandfather_pb_test(dns_name_t * zone_name, dns_rdataset_t * sigrdataset) +{ + isc_result_t result; + dns_rdata_t sigrdata; + dns_rdata_sig_t siginfo; + + result = dns_rdataset_first(sigrdataset); + check_result(result, "empty RRSIG dataset"); + dns_rdata_init(&sigrdata); + + do { + dns_rdataset_current(sigrdataset, &sigrdata); + + result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL); + check_result(result, "sigrdata tostruct siginfo"); + + if (dns_name_compare(&siginfo.signer, zone_name) == 0) { + dns_rdata_freestruct(&siginfo); + dns_rdata_reset(&sigrdata); + return ISC_R_SUCCESS; + } + + dns_rdata_freestruct(&siginfo); + + } while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS); + + dns_rdata_reset(&sigrdata); + + return ISC_R_FAILURE; +} + + +isc_result_t +initialization(dns_name_t * name) +{ + isc_result_t result; + isc_boolean_t true = ISC_TRUE; + + chase_nsrdataset = NULL; + result = advanced_rrsearch(&chase_nsrdataset, name, dns_rdatatype_ns, + dns_rdatatype_any, &true); + if (result != ISC_R_SUCCESS) { + printf("\n;; NS RRset is missing to continue validation:" + " FAILED\n\n"); + return ISC_R_FAILURE; + } + INSIST(chase_nsrdataset != NULL); + prepare_lookup(name); + + dup_name(name, &chase_current_name, mctx); + + return ISC_R_SUCCESS; +} +#endif + +void +print_rdataset(dns_name_t * name, dns_rdataset_t *rdataset, isc_mem_t *mctx) +{ + isc_buffer_t * b = NULL; + isc_result_t result; + isc_region_t r; + + result = isc_buffer_allocate(mctx, &b, 9000); + check_result(result, "isc_buffer_allocate"); + + printrdataset(name, rdataset, b); + + isc_buffer_usedregion(b, &r); + r.base[r.length] = '\0'; + + + printf("%s\n", r.base); + + isc_buffer_free(&b); +} + + +void +dup_name(dns_name_t *source, dns_name_t *target, isc_mem_t *mctx) { + isc_result_t result; + + if (dns_name_dynamic(target)) + dns_name_free(target, mctx); + result = dns_name_dup(source, mctx, target); + check_result(result, "dns_name_dup"); +} + +/* + * + * take a DNSKEY RRset and the RRSIG RRset corresponding in parameter + * return ISC_R_SUCCESS if the DNSKEY RRset contains a trusted_key + * and the RRset is valid + * return ISC_R_NOTFOUND if not contains trusted key + or if the RRset isn't valid + * return ISC_R_FAILURE if problem + * + */ +isc_result_t +contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset, + dns_rdataset_t *sigrdataset, + isc_mem_t *mctx) +{ + isc_result_t result; + dns_rdata_t rdata; + dst_key_t * trustedKey = NULL; + dst_key_t * dnsseckey = NULL; + int i; + + if (name == NULL || rdataset == NULL) { + return ISC_R_FAILURE; + } + + result = dns_rdataset_first(rdataset); + check_result(result, "empty rdataset"); + dns_rdata_init(&rdata); + + do { + dns_rdataset_current(rdataset, &rdata); + INSIST(rdata.type == dns_rdatatype_dnskey); + + result = dns_dnssec_keyfromrdata(name, &rdata, + mctx, &dnsseckey); + check_result(result, "dns_dnssec_keyfromrdata"); + + + for (i = 0; i< tk_list.nb_tk; i++) { + if (dst_key_compare(tk_list.key[i], dnsseckey) + == ISC_TRUE) { + dns_rdata_reset(&rdata); + + printf(";; Ok, find a Trusted Key in the " + "DNSKEY RRset: %d\n", + dst_key_id(dnsseckey)); + if (sigchase_verify_sig_key(name, rdataset, + dnsseckey, + sigrdataset, + mctx) + == ISC_R_SUCCESS) { + dst_key_free(&dnsseckey); + dnsseckey = NULL; + return ISC_R_SUCCESS; + } + } + } + + dns_rdata_reset(&rdata); + if (dnsseckey != NULL) + dst_key_free(&dnsseckey); + } while (dns_rdataset_next(rdataset) == ISC_R_SUCCESS); + + if (trustedKey != NULL) + dst_key_free(&trustedKey); + trustedKey = NULL; + + return ISC_R_NOTFOUND; +} + +isc_result_t +sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset, + dns_rdataset_t *keyrdataset, + dns_rdataset_t *sigrdataset, + isc_mem_t *mctx) +{ + isc_result_t result; + dns_rdata_t keyrdata; + dst_key_t * dnsseckey = NULL; + + result = dns_rdataset_first(keyrdataset); + check_result(result, "empty DNSKEY dataset"); + dns_rdata_init(&keyrdata); + + do { + dns_rdataset_current(keyrdataset, &keyrdata); + INSIST(keyrdata.type == dns_rdatatype_dnskey); + + result = dns_dnssec_keyfromrdata(name, &keyrdata, + mctx, &dnsseckey); + check_result(result, "dns_dnssec_keyfromrdata"); + + result = sigchase_verify_sig_key(name, rdataset, dnsseckey, + sigrdataset, mctx); + if (result == ISC_R_SUCCESS) { + dns_rdata_reset(&keyrdata); + dst_key_free(&dnsseckey); + return(ISC_R_SUCCESS); + } + dst_key_free(&dnsseckey); + } while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS); + + dns_rdata_reset(&keyrdata); + + return ISC_R_NOTFOUND; +} + +isc_result_t +sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset, + dst_key_t* dnsseckey, + dns_rdataset_t *sigrdataset, isc_mem_t *mctx) +{ + isc_result_t result; + dns_rdata_t sigrdata; + dns_rdata_sig_t siginfo; + + result = dns_rdataset_first(sigrdataset); + check_result(result, "empty RRSIG dataset"); + dns_rdata_init(&sigrdata); + + do { + dns_rdataset_current(sigrdataset, &sigrdata); + + result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL); + check_result(result, "sigrdata tostruct siginfo"); + + /* + * Test if the id of the DNSKEY is + * the id of the DNSKEY signer's + */ + if (siginfo.keyid == dst_key_id(dnsseckey)) { + + result = dns_rdataset_first(rdataset); + check_result(result, "empty DS dataset"); + + result = dns_dnssec_verify(name, rdataset, dnsseckey, + ISC_FALSE, mctx, &sigrdata); + + printf(";; VERIFYING "); + print_type(rdataset->type); + printf(" RRset for "); + dns_name_print(name, stdout); + printf(" with DNSKEY:%d: %s\n", dst_key_id(dnsseckey), + isc_result_totext(result)); + + if (result == ISC_R_SUCCESS) { + dns_rdata_reset(&sigrdata); + return result; + } + } + dns_rdata_freestruct(&siginfo); + + } while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS); + + dns_rdata_reset(&sigrdata); + + return ISC_R_NOTFOUND; +} + + +isc_result_t +sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, + dns_rdataset_t *dsrdataset, isc_mem_t *mctx) +{ + isc_result_t result; + dns_rdata_t keyrdata; + dns_rdata_t newdsrdata; + dns_rdata_t dsrdata; + dns_rdata_ds_t dsinfo; + dst_key_t* dnsseckey = NULL; + unsigned char dsbuf[DNS_DS_BUFFERSIZE]; + + result = dns_rdataset_first(dsrdataset); + check_result(result, "empty DSset dataset"); + dns_rdata_init(&dsrdata); + do { + dns_rdataset_current(dsrdataset, &dsrdata); + + result = dns_rdata_tostruct(&dsrdata, &dsinfo, NULL); + check_result(result, "dns_rdata_tostruct for DS"); + + result = dns_rdataset_first(keyrdataset); + check_result(result, "empty KEY dataset"); + dns_rdata_init(&keyrdata); + + do { + dns_rdataset_current(keyrdataset, &keyrdata); + INSIST(keyrdata.type == dns_rdatatype_dnskey); + + result = dns_dnssec_keyfromrdata(name, &keyrdata, + mctx, &dnsseckey); + check_result(result, "dns_dnssec_keyfromrdata"); + + /* + * Test if the id of the DNSKEY is the + * id of DNSKEY referenced by the DS + */ + if (dsinfo.key_tag == dst_key_id(dnsseckey)) { + dns_rdata_init(&newdsrdata); + + result = dns_ds_buildrdata(name, &keyrdata, + dsinfo.digest_type, + dsbuf, &newdsrdata); + dns_rdata_freestruct(&dsinfo); + + if (result != ISC_R_SUCCESS) { + dns_rdata_reset(&keyrdata); + dns_rdata_reset(&newdsrdata); + dns_rdata_reset(&dsrdata); + dst_key_free(&dnsseckey); + dns_rdata_freestruct(&dsinfo); + printf("Oops: impossible to build" + " new DS rdata\n"); + return result; + } + + + if (dns_rdata_compare(&dsrdata, + &newdsrdata) == 0) { + printf(";; OK a DS valids a DNSKEY" + " in the RRset\n"); + printf(";; Now verify that this" + " DNSKEY validates the " + "DNSKEY RRset\n"); + + result = sigchase_verify_sig_key(name, + keyrdataset, + dnsseckey, + chase_sigkeyrdataset, + mctx); + if (result == ISC_R_SUCCESS) { + dns_rdata_reset(&keyrdata); + dns_rdata_reset(&newdsrdata); + dns_rdata_reset(&dsrdata); + dst_key_free(&dnsseckey); + + return result; + } + } + else { + printf(";; This DS is NOT the DS for" + " the chasing KEY: FAILED\n"); + } + + dns_rdata_reset(&newdsrdata); + } + dst_key_free(&dnsseckey); + dnsseckey = NULL; + } while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS); + dns_rdata_reset(&keyrdata); + + } while (dns_rdataset_next(chase_dsrdataset) == ISC_R_SUCCESS); +#if 0 + dns_rdata_reset(&dsrdata); WARNING +#endif + + return ISC_R_NOTFOUND; +} + +/* + * + * take a pointer on a rdataset in parameter and try to resolv it. + * the searched rrset is a rrset on 'name' with type 'type' + * (and if the type is a rrsig the signature cover 'covers'). + * the lookedup is to known if you have already done the query on the net. + * ISC_R_SUCCESS: if we found the rrset + * ISC_R_NOTFOUND: we do not found the rrset in cache + * and we do a query on the net + * ISC_R_FAILURE: rrset not found + */ +isc_result_t +advanced_rrsearch(dns_rdataset_t **rdataset, dns_name_t * name, + dns_rdatatype_t type, + dns_rdatatype_t covers, + isc_boolean_t *lookedup) +{ + isc_boolean_t tmplookedup; + + INSIST(rdataset != NULL); + + if (*rdataset != NULL) + return(ISC_R_SUCCESS); + + tmplookedup = *lookedup; + if ((*rdataset = sigchase_scanname(type, covers, + lookedup, name)) == NULL) { + if (tmplookedup) + return (ISC_R_FAILURE); + return (ISC_R_NOTFOUND); + } + *lookedup = ISC_FALSE; + return(ISC_R_SUCCESS); +} + + + +#if DIG_SIGCHASE_TD +void +sigchase_td(dns_message_t * msg) +{ + isc_result_t result; + dns_name_t * name = NULL; + isc_boolean_t have_answer = ISC_FALSE; + + isc_boolean_t true = ISC_TRUE; + + if ((result = dns_message_firstname(msg, DNS_SECTION_ANSWER)) + == ISC_R_SUCCESS) { + dns_message_currentname(msg, DNS_SECTION_ANSWER, &name); + if (current_lookup->trace_root_sigchase) { + initialization(name); + return; + } + have_answer = true; + } + else { + if (!current_lookup->trace_root_sigchase) { + result = dns_message_firstname(msg, + DNS_SECTION_AUTHORITY); + if (result == ISC_R_SUCCESS) + dns_message_currentname(msg, + DNS_SECTION_AUTHORITY, + &name); + chase_nsrdataset + = chase_scanname_section(msg, name, + dns_rdatatype_ns, + dns_rdatatype_any, + DNS_SECTION_AUTHORITY); + dup_name(name, &chase_authority_name, mctx); + if (chase_nsrdataset != NULL) { + have_delegation_ns = ISC_TRUE; + printf("no response but there is a delegation" + " in authority section:"); + dns_name_print(name, stdout); + printf("\n"); + } + else { + printf("no response and no delegation in " + "authority section but a reference" + " to: "); + dns_name_print(name, stdout); + printf("\n"); + error_message = msg; + } + } + else { + printf(";; NO ANSWERS: %s\n", + isc_result_totext(result)); + dns_name_free(&chase_name, mctx); + clean_trustedkey(); + return; + } + } + + + if (have_answer) { + chase_rdataset + = chase_scanname_section(msg, &chase_name, + current_lookup + ->rdtype_sigchase, + dns_rdatatype_any, + DNS_SECTION_ANSWER); + if (chase_rdataset != NULL) + have_response = ISC_TRUE; + } + + result = advanced_rrsearch(&chase_keyrdataset, + &chase_current_name, + dns_rdatatype_dnskey, + dns_rdatatype_any, + &chase_keylookedup); + if (result == ISC_R_FAILURE) { + printf("\n;; DNSKEY is missing to continue validation:" + " FAILED\n\n"); + goto cleanandgo; + } + if (result == ISC_R_NOTFOUND) + return; + INSIST(chase_keyrdataset != NULL); + printf("\n;; DNSKEYset:\n"); + print_rdataset(&chase_current_name , chase_keyrdataset, mctx); + + + result = advanced_rrsearch(&chase_sigkeyrdataset, + &chase_current_name, + dns_rdatatype_rrsig, + dns_rdatatype_dnskey, + &chase_sigkeylookedup); + if (result == ISC_R_FAILURE) { + printf("\n;; RRSIG of DNSKEY is missing to continue validation:" + " FAILED\n\n"); + goto cleanandgo; + } + if (result == ISC_R_NOTFOUND) + return; + INSIST(chase_sigkeyrdataset != NULL); + printf("\n;; RRSIG of the DNSKEYset:\n"); + print_rdataset(&chase_current_name , chase_sigkeyrdataset, mctx); + + + if (!chase_dslookedup && !chase_nslookedup) { + if (!delegation_follow) { + result = contains_trusted_key(&chase_current_name, + chase_keyrdataset, + chase_sigkeyrdataset, + mctx); + } + else { + INSIST(chase_dsrdataset != NULL); + INSIST(chase_sigdsrdataset != NULL); + result = sigchase_verify_ds(&chase_current_name, + chase_keyrdataset, + chase_dsrdataset, + mctx); + } + + if (result != ISC_R_SUCCESS) { + printf("\n;; chain of trust can't be validated:" + " FAILED\n\n"); + goto cleanandgo; + } + else { + chase_dsrdataset = NULL; + chase_sigdsrdataset = NULL; + } + } + + if (have_response || (!have_delegation_ns && !have_response)) { + /* test if it's a grand father case */ + + if (have_response) { + result = advanced_rrsearch(&chase_sigrdataset, + &chase_name, + dns_rdatatype_rrsig, + current_lookup + ->rdtype_sigchase, + &true); + if (result == ISC_R_FAILURE) { + printf("\n;; RRset is missing to continue" + " validation SHOULD NOT APPEND:" + " FAILED\n\n"); + goto cleanandgo; + } + + } + else { + result = advanced_rrsearch(&chase_sigrdataset, + &chase_authority_name, + dns_rdatatype_rrsig, + dns_rdatatype_any, + &true); + if (result == ISC_R_FAILURE) { + printf("\n;; RRSIG is missing to continue" + " validation SHOULD NOT APPEND:" + " FAILED\n\n"); + goto cleanandgo; + } + } + result = grandfather_pb_test(&chase_current_name, + chase_sigrdataset); + if (result != ISC_R_SUCCESS) { + dns_name_t tmp_name; + + printf("\n;; We are in a Grand Father Problem:" + " See 2.2.1 in RFC 3568\n"); + chase_rdataset = NULL; + chase_sigrdataset = NULL; + have_response = ISC_FALSE; + have_delegation_ns = ISC_FALSE; + + dns_name_init(&tmp_name, NULL); + result = child_of_zone(&chase_name, &chase_current_name, + &tmp_name); + if (dns_name_dynamic(&chase_authority_name)) + dns_name_free( &chase_authority_name, mctx); + dup_name(&tmp_name, &chase_authority_name, mctx); + printf(";; and we try to continue chain of trust" + " validation of the zone: "); + dns_name_print(&chase_authority_name, stdout); + printf("\n"); + have_delegation_ns = ISC_TRUE; + } + else { + if (have_response) + goto finalstep; + else + chase_sigrdataset = NULL; + } + } + + if (have_delegation_ns) { + chase_nsrdataset = NULL; + result = advanced_rrsearch(&chase_nsrdataset, + &chase_authority_name, + dns_rdatatype_ns, + dns_rdatatype_any, + &chase_nslookedup); + if (result == ISC_R_FAILURE) { + printf("\n;;NSset is missing to continue validation:" + " FAILED\n\n"); + goto cleanandgo; + } + if (result == ISC_R_NOTFOUND) { + return; + } + INSIST(chase_nsrdataset != NULL); + + result = advanced_rrsearch(&chase_dsrdataset, + &chase_authority_name, + dns_rdatatype_ds, + dns_rdatatype_any, + &chase_dslookedup); + if (result == ISC_R_FAILURE) { + printf("\n;; DSset is missing to continue validation:" + " FAILED\n\n"); + goto cleanandgo; + } + if (result == ISC_R_NOTFOUND) + return; + INSIST(chase_dsrdataset != NULL); + printf("\n;; DSset:\n"); + print_rdataset(&chase_authority_name , chase_dsrdataset, mctx); + + result = advanced_rrsearch(&chase_sigdsrdataset, + &chase_authority_name, + dns_rdatatype_rrsig, + dns_rdatatype_ds, + &true); + if (result != ISC_R_SUCCESS) { + printf("\n;; DSset is missing to continue validation:" + " FAILED\n\n"); + goto cleanandgo; + } + printf("\n;; RRSIGset of DSset\n"); + print_rdataset(&chase_authority_name, + chase_sigdsrdataset, mctx); + INSIST(chase_sigdsrdataset != NULL); + + result = sigchase_verify_sig(&chase_authority_name, + chase_dsrdataset, + chase_keyrdataset, + chase_sigdsrdataset, mctx); + if (result != ISC_R_SUCCESS) { + printf("\n;; Impossible to verify the DSset:" + " FAILED\n\n"); + goto cleanandgo; + } + chase_keyrdataset = NULL; + chase_sigkeyrdataset = NULL; + + + prepare_lookup(&chase_authority_name); + + have_response = ISC_FALSE; + have_delegation_ns = ISC_FALSE; + delegation_follow = ISC_TRUE; + error_message = NULL; + dup_name(&chase_authority_name, &chase_current_name, mctx); + dns_name_free(&chase_authority_name, mctx); + return; + } + + + if (error_message != NULL) { + dns_rdataset_t * rdataset; + dns_rdataset_t * sigrdataset; + dns_name_t rdata_name; + isc_result_t ret = ISC_R_FAILURE; + + dns_name_init(&rdata_name, NULL); + result = prove_nx(error_message, &chase_name, + current_lookup->rdclass_sigchase, + current_lookup->rdtype_sigchase, &rdata_name, + &rdataset, &sigrdataset); + if (&rdata_name == NULL || rdataset == NULL || + sigrdataset == NULL) { + printf("\n;; Impossible to verify the non-existence," + " the NSEC RRset can't be validated:" + " FAILED\n\n"); + goto cleanandgo; + } + ret = sigchase_verify_sig(&rdata_name, rdataset, + chase_keyrdataset, + sigrdataset, mctx); + if (ret != ISC_R_SUCCESS) { + dns_name_free(&rdata_name, mctx); + printf("\n;; Impossible to verify the NSEC RR to prove" + " the non-existence : FAILED\n\n"); + goto cleanandgo; + } + dns_name_free(&rdata_name, mctx); + if (result != ISC_R_SUCCESS) { + printf("\n;; Impossible to verify the non-existence:" + " FAILED\n\n"); + goto cleanandgo; + } + else { + printf("\n;; OK the query doesn't have response but" + " we have validate this fact : SUCCESS\n\n"); + goto cleanandgo; + } + } + + cleanandgo: + printf(";; cleanandgo \n"); + if (dns_name_dynamic(&chase_current_name)) + dns_name_free(&chase_current_name, mctx); + if (dns_name_dynamic(&chase_authority_name)) + dns_name_free(&chase_authority_name, mctx); + clean_trustedkey(); + return; + + finalstep : + result = advanced_rrsearch(&chase_rdataset, &chase_name, + current_lookup->rdtype_sigchase, + dns_rdatatype_any , + &true); + if (result == ISC_R_FAILURE) { + printf("\n;; RRsig of RRset is missing to continue validation" + " SHOULD NOT APPEND: FAILED\n\n"); + goto cleanandgo; + } + result = sigchase_verify_sig(&chase_name, chase_rdataset, + chase_keyrdataset, + chase_sigrdataset, mctx); + if (result != ISC_R_SUCCESS) { + printf("\n;; Impossible to verify the RRset : FAILED\n\n"); + /* + printf("RRset:\n"); + print_rdataset(&chase_name , chase_rdataset, mctx); + printf("DNSKEYset:\n"); + print_rdataset(&chase_name , chase_keyrdataset, mctx); + printf("RRSIG of RRset:\n"); + print_rdataset(&chase_name , chase_sigrdataset, mctx); + printf("\n"); + */ + goto cleanandgo; + } + else { + printf("\n;; The Answer:\n"); + print_rdataset(&chase_name , chase_rdataset, mctx); + + printf("\n;; FINISH : we have validate the DNSSEC chain" + " of trust: SUCCESS\n\n"); + goto cleanandgo; + } +} + +#endif + + +#if DIG_SIGCHASE_BU + +isc_result_t +getneededrr(dns_message_t *msg) +{ + isc_result_t result; + dns_name_t *name = NULL; + dns_rdata_t sigrdata; + dns_rdata_sig_t siginfo; + isc_boolean_t true = ISC_TRUE; + + if ((result = dns_message_firstname(msg, DNS_SECTION_ANSWER)) + != ISC_R_SUCCESS) { + printf(";; NO ANSWERS: %s\n", isc_result_totext(result)); + + if (chase_name.ndata == NULL) { + return ISC_R_ADDRNOTAVAIL; + } + } + else { + dns_message_currentname(msg, DNS_SECTION_ANSWER, &name); + } + + /* What do we chase? */ + if (chase_rdataset == NULL) { + result = advanced_rrsearch(&chase_rdataset, name, + dns_rdatatype_any, + dns_rdatatype_any, &true); + if (result != ISC_R_SUCCESS) { + printf("\n;; No Answers: Validation FAILED\n\n"); + return ISC_R_NOTFOUND; + } + dup_name(name, &chase_name, mctx); + printf(";; RRset to chase:\n"); + print_rdataset(&chase_name, chase_rdataset, mctx); + } + INSIST(chase_rdataset != NULL); + + + if (chase_sigrdataset == NULL) { + result = advanced_rrsearch(&chase_sigrdataset, name, + dns_rdatatype_rrsig, + chase_rdataset->type, + &chase_siglookedup); + if (result == ISC_R_FAILURE) { + printf("\n;; RRSIG is missing for continue validation:" + " FAILED\n\n"); + if (dns_name_dynamic(&chase_name)) + dns_name_free(&chase_name, mctx); + return ISC_R_NOTFOUND; + } + if (result == ISC_R_NOTFOUND) { + return(ISC_R_NOTFOUND); + } + printf("\n;; RRSIG of the RRset to chase:\n"); + print_rdataset(&chase_name, chase_sigrdataset, mctx); + } + INSIST(chase_sigrdataset != NULL); + + + /* first find the DNSKEY name */ + result = dns_rdataset_first(chase_sigrdataset); + check_result(result, "empty RRSIG dataset"); + dns_rdata_init(&sigrdata); + dns_rdataset_current(chase_sigrdataset, &sigrdata); + result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL); + check_result(result, "sigrdata tostruct siginfo"); + dup_name(&siginfo.signer, &chase_signame, mctx); + dns_rdata_freestruct(&siginfo); + dns_rdata_reset(&sigrdata); + + /* Do we have a key? */ + if (chase_keyrdataset == NULL) { + result = advanced_rrsearch(&chase_keyrdataset, + &chase_signame, + dns_rdatatype_dnskey, + dns_rdatatype_any, + &chase_keylookedup); + if (result == ISC_R_FAILURE) { + printf("\n;; DNSKEY is missing to continue validation:" + " FAILED\n\n"); + dns_name_free(&chase_signame, mctx); + if (dns_name_dynamic(&chase_name)) + dns_name_free(&chase_name, mctx); + return ISC_R_NOTFOUND; + } + if (result == ISC_R_NOTFOUND) { + dns_name_free(&chase_signame, mctx); + return(ISC_R_NOTFOUND); + } + printf("\n;; DNSKEYset that signs the RRset to chase:\n"); + print_rdataset(&chase_signame, chase_keyrdataset, mctx); + } + INSIST(chase_keyrdataset != NULL); + + if (chase_sigkeyrdataset == NULL) { + result = advanced_rrsearch(&chase_sigkeyrdataset, + &chase_signame, + dns_rdatatype_rrsig, + dns_rdatatype_dnskey, + &chase_sigkeylookedup); + if (result == ISC_R_FAILURE) { + printf("\n;; RRSIG for DNSKEY is missing to continue" + " validation : FAILED\n\n"); + dns_name_free(&chase_signame, mctx); + if (dns_name_dynamic(&chase_name)) + dns_name_free(&chase_name, mctx); + return ISC_R_NOTFOUND; + } + if (result == ISC_R_NOTFOUND) { + dns_name_free(&chase_signame, mctx); + return(ISC_R_NOTFOUND); + } + printf("\n;; RRSIG of the DNSKEYset that signs the " + "RRset to chase:\n"); + print_rdataset(&chase_signame, chase_sigkeyrdataset, mctx); + } + INSIST(chase_sigkeyrdataset != NULL); + + + if (chase_dsrdataset == NULL) { + result = advanced_rrsearch(&chase_dsrdataset, &chase_signame, + dns_rdatatype_ds, + dns_rdatatype_any, + &chase_dslookedup); + if (result == ISC_R_FAILURE) { + printf("\n;; WARNING There is no DS for the zone: "); + dns_name_print(&chase_signame, stdout); + printf("\n"); + } + if (result == ISC_R_NOTFOUND) { + dns_name_free(&chase_signame, mctx); + return(ISC_R_NOTFOUND); + } + if (chase_dsrdataset != NULL) { + printf("\n;; DSset of the DNSKEYset\n"); + print_rdataset(&chase_signame, chase_dsrdataset, mctx); + } + } + + if (chase_dsrdataset != NULL) { + /* + * if there is no RRSIG of DS, + * we don't want to search on the network + */ + result = advanced_rrsearch(&chase_sigdsrdataset, + &chase_signame, + dns_rdatatype_rrsig, + dns_rdatatype_ds, &true); + if (result == ISC_R_FAILURE) { + printf(";; WARNING : NO RRSIG DS : RRSIG DS" + " should come with DS\n"); + /* + * We continue even the DS couldn't be validated, + * because the DNSKEY could be a Trusted Key. + */ + chase_dsrdataset = NULL; + } + else { + printf("\n;; RRSIG of the DSset of the DNSKEYset\n"); + print_rdataset(&chase_signame, chase_sigdsrdataset, + mctx); + } + } + return(1); +} + + + +void +sigchase_bu(dns_message_t *msg) +{ + isc_result_t result; + int ret; + + if (tk_list.nb_tk == 0) { + result = get_trusted_key(mctx); + if (result != ISC_R_SUCCESS) { + printf("No trusted keys present\n"); + return; + } + } + + + ret = getneededrr(msg); + if (ret == ISC_R_NOTFOUND) + return; + + if (ret == ISC_R_ADDRNOTAVAIL) { + /* We have no response */ + dns_rdataset_t * rdataset; + dns_rdataset_t * sigrdataset; + dns_name_t rdata_name; + dns_name_t query_name; + + + dns_name_init(&query_name, NULL); + nameFromString(current_lookup->textname, &query_name); + + result = prove_nx(msg, &query_name, current_lookup->rdclass, + current_lookup->rdtype, &rdata_name, + &rdataset, &sigrdataset); + dns_name_free(&query_name, mctx); + if (&rdata_name == NULL || rdataset == NULL || + sigrdataset == NULL) { + printf("\n;; Impossible to verify the Non-existence," + " the NSEC RRset can't be validated: " + "FAILED\n\n"); + clean_trustedkey(); + return; + } + + if (result != ISC_R_SUCCESS) { + printf("\n No Answers and impossible to prove the" + " unsecurity : Validation FAILED\n\n"); + clean_trustedkey(); + return; + } + printf(";; An NSEC prove the non-existence of a answers," + " Now we want validate this NSEC\n"); + + dup_name(&rdata_name, &chase_name, mctx); + dns_name_free(&rdata_name, mctx); + chase_rdataset = rdataset; + chase_sigrdataset = sigrdataset; + chase_keyrdataset = NULL; + chase_sigkeyrdataset = NULL; + chase_dsrdataset = NULL; + chase_sigdsrdataset = NULL; + chase_siglookedup = ISC_FALSE; + chase_keylookedup = ISC_FALSE; + chase_dslookedup = ISC_FALSE; + chase_sigdslookedup = ISC_FALSE; + sigchase(msg); + clean_trustedkey(); + return; + } + + + printf("\n\n\n;; WE HAVE MATERIAL, WE NOW DO VALIDATION\n"); + + result = sigchase_verify_sig(&chase_name, chase_rdataset, + chase_keyrdataset, + chase_sigrdataset, mctx); + if (result != ISC_R_SUCCESS) { + dns_name_free(&chase_name, mctx); + dns_name_free(&chase_signame, mctx); + printf(";; No DNSKEY is valid to check the RRSIG" + " of the RRset: FAILED\n"); + clean_trustedkey(); + return; + } + printf(";; OK We found DNSKEY (or more) to validate the RRset\n"); + + result = contains_trusted_key(&chase_signame, chase_keyrdataset, + chase_sigkeyrdataset, mctx); + if (result == ISC_R_SUCCESS) { + dns_name_free(&chase_name, mctx); + dns_name_free(&chase_signame, mctx); + printf("\n;; Ok this DNSKEY is a Trusted Key," + " DNSSEC validation is ok: SUCCESS\n\n"); + clean_trustedkey(); + return; + } + + printf(";; Now, we are going to validate this DNSKEY by the DS\n"); + + if (chase_dsrdataset == NULL) { + dns_name_free(&chase_name, mctx); + dns_name_free(&chase_signame, mctx); + printf(";; the DNSKEY isn't trusted-key and there isn't" + " DS to validate the DNSKEY: FAILED\n"); + clean_trustedkey(); + return; + } + + result = sigchase_verify_ds(&chase_signame, chase_keyrdataset, + chase_dsrdataset, mctx); + if (result != ISC_R_SUCCESS) { + dns_name_free(&chase_signame, mctx); + dns_name_free(&chase_name, mctx); + printf(";; ERROR no DS validates a DNSKEY in the" + " DNSKEY RRset: FAILED\n"); + clean_trustedkey(); + return; + } + else + printf(";; OK this DNSKEY (validated by the DS) validates" + " the RRset of the DNSKEYs, thus the DNSKEY validates" + " the RRset\n"); + INSIST(chase_sigdsrdataset != NULL); + + dup_name(&chase_signame, &chase_name, mctx); + dns_name_free(&chase_signame, mctx); + chase_rdataset = chase_dsrdataset; + chase_sigrdataset = chase_sigdsrdataset; + chase_keyrdataset = NULL; + chase_sigkeyrdataset = NULL; + chase_dsrdataset = NULL; + chase_sigdsrdataset = NULL; + chase_siglookedup = chase_keylookedup = ISC_FALSE; + chase_dslookedup = chase_sigdslookedup = ISC_FALSE; + + printf(";; Now, we want to validate the DS : recursive call\n"); + sigchase(msg); + return; +} +#endif + +void +sigchase(dns_message_t * msg) +{ +#if DIG_SIGCHASE_TD + if (current_lookup->do_topdown) { + sigchase_td(msg); + return; + } +#endif +#if DIG_SIGCHASE_BU + sigchase_bu(msg); + return; +#endif +} + + +/* + * return 1 if name1 < name2 + * 0 if name1 == name2 + * -1 if name1 > name2 + * and -2 if problem + */ +int +inf_name(dns_name_t * name1, dns_name_t * name2) +{ + dns_label_t label1; + dns_label_t label2; + unsigned int nblabel1; + unsigned int nblabel2; + int min_lum_label; + int i; + int ret = -2; + + nblabel1 = dns_name_countlabels(name1); + nblabel2 = dns_name_countlabels(name2); + + if (nblabel1 >= nblabel2) + min_lum_label = nblabel2; + else + min_lum_label = nblabel1; + + + for (i=1 ; i < min_lum_label; i++) { + dns_name_getlabel(name1, nblabel1 -1 - i, &label1); + dns_name_getlabel(name2, nblabel2 -1 - i, &label2); + if ((ret = isc_region_compare(&label1, &label2)) != 0) { + if (ret <0 ) + return -1; + else if (ret >0 ) + return 1; + } + } + if (nblabel1 == nblabel2) + return 0; + + if (nblabel1 < nblabel2) + return -1; + else + return 1; +} + +/** + * + * + * + */ +isc_result_t +prove_nx_domain(dns_message_t *msg, + dns_name_t *name, + dns_name_t *rdata_name, + dns_rdataset_t ** rdataset, + dns_rdataset_t **sigrdataset) +{ + isc_result_t ret = ISC_R_FAILURE; + isc_result_t result = ISC_R_NOTFOUND; + dns_rdataset_t * nsecset = NULL; + dns_rdataset_t * signsecset = NULL ; + dns_rdata_t nsec = DNS_RDATA_INIT; + dns_name_t * nsecname = NULL; + dns_rdata_nsec_t nsecstruct; + + if ((result = dns_message_firstname(msg, DNS_SECTION_AUTHORITY)) + != ISC_R_SUCCESS) { + printf(";; nothing in authority section : impossible to" + " validate the non-existence : FAILED\n"); + return(ISC_R_FAILURE); + } + + do { + dns_message_currentname(msg, DNS_SECTION_AUTHORITY, &nsecname); + nsecset = search_type(nsecname, dns_rdatatype_nsec, + dns_rdatatype_any); + if (nsecset == NULL) + continue; + + printf("There is a NSEC for this zone in the" + " AUTHORITY section:\n"); + print_rdataset(nsecname, nsecset, mctx); + + for (result = dns_rdataset_first(nsecset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(nsecset)) { + dns_rdataset_current(nsecset, &nsec); + + + signsecset + = chase_scanname_section(msg, nsecname, + dns_rdatatype_rrsig, + dns_rdatatype_nsec, + DNS_SECTION_AUTHORITY); + if (signsecset == NULL) { + printf(";; no RRSIG NSEC in authority section:" + " impossible to validate the " + "non-existence: FAILED\n"); + return(ISC_R_FAILURE); + } + + ret = dns_rdata_tostruct(&nsec, &nsecstruct, NULL); + check_result(ret,"dns_rdata_tostruct"); + + if ((inf_name(nsecname, &nsecstruct.next) == 1 && + inf_name(name, &nsecstruct.next) == 1) || + (inf_name(name, nsecname) == 1 && + inf_name(&nsecstruct.next, name) == 1)) { + dns_rdata_freestruct(&nsecstruct); + *rdataset = nsecset; + *sigrdataset = signsecset; + dup_name(nsecname, rdata_name, mctx); + + return ISC_R_SUCCESS; + } + + dns_rdata_freestruct(&nsecstruct); + } + nsecname = NULL; + } while (dns_message_nextname(msg, DNS_SECTION_AUTHORITY) + == ISC_R_SUCCESS); + + *rdataset = NULL; + *sigrdataset = NULL; + rdata_name = NULL; + return(ISC_R_FAILURE); +} + +/** + * + * + * + * + * + */ +isc_result_t +prove_nx_type(dns_message_t * msg, + dns_name_t *name, + dns_rdataset_t *nsecset, + dns_rdataclass_t class, + dns_rdatatype_t type, + dns_name_t * rdata_name, + dns_rdataset_t ** rdataset, + dns_rdataset_t ** sigrdataset) +{ + isc_result_t ret; + dns_rdataset_t * signsecset; + dns_rdata_t nsec = DNS_RDATA_INIT; + + UNUSED(class); + UNUSED(rdata_name); + + ret = dns_rdataset_first(nsecset); + check_result(ret,"dns_rdataset_first"); + + dns_rdataset_current(nsecset, &nsec); + + ret = dns_nsec_typepresent(&nsec, type); + if (ret == ISC_R_SUCCESS) + printf("OK the NSEC said that the type doesn't exist \n"); + + signsecset = chase_scanname_section(msg, name, + dns_rdatatype_rrsig, + dns_rdatatype_nsec, + DNS_SECTION_AUTHORITY); + if (signsecset == NULL) { + printf("There isn't RRSIG NSEC for the zone \n"); + return ISC_R_FAILURE; + } + *rdataset = nsecset; + *sigrdataset = signsecset; + + return (ret); +} + +/** + * + * + * + * + */ +isc_result_t +prove_nx(dns_message_t * msg, + dns_name_t * name, + dns_rdataclass_t class, + dns_rdatatype_t type, + dns_name_t * rdata_name, + dns_rdataset_t ** rdataset, + dns_rdataset_t ** sigrdataset) +{ + isc_result_t ret; + dns_rdataset_t * nsecset = NULL; + + + printf("We want to prove the non-existance of a type of rdata %d" + " or of the zone: \n", type); + + if ((ret = dns_message_firstname(msg, DNS_SECTION_AUTHORITY)) + != ISC_R_SUCCESS) { + printf(";; nothing in authority section : impossible to" + " validate the non-existence : FAILED\n"); + return(ISC_R_FAILURE); + } + + nsecset = chase_scanname_section(msg, name, dns_rdatatype_nsec, + dns_rdatatype_any, + DNS_SECTION_AUTHORITY); + if (nsecset != NULL) { + printf("We have a NSEC for this zone :OK\n"); + ret = prove_nx_type(msg, name, nsecset, class, + type, rdata_name, rdataset, + sigrdataset); + if (ret != ISC_R_SUCCESS) { + printf("prove_nx: ERROR type exist\n"); + return(ret); + } else { + printf("prove_nx: OK type does not exist\n"); + return(ISC_R_SUCCESS); + } + } else { + printf("there is no NSEC for this zone: validating " + "that the zone doesn't exist\n"); + ret = prove_nx_domain(msg, name, rdata_name, + rdataset, sigrdataset); + return(ret); + } + /* Never get here */ +} +#endif diff --git a/contrib/bind9/bin/dig/host.1 b/contrib/bind9/bin/dig/host.1 new file mode 100644 index 000000000000..c93ab184b57b --- /dev/null +++ b/contrib/bind9/bin/dig/host.1 @@ -0,0 +1,136 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2002 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: host.1,v 1.11.2.1.4.4 2004/04/13 04:11:03 marka Exp $ +.\" +.TH "HOST" "1" "Jun 30, 2000" "BIND9" "" +.SH NAME +host \- DNS lookup utility +.SH SYNOPSIS +.sp +\fBhost\fR [ \fB-aCdlnrTwv\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-N \fIndots\fB\fR ] [ \fB-R \fInumber\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-W \fIwait\fB\fR ] [ \fB-4\fR ] [ \fB-6\fR ] \fBname\fR [ \fBserver\fR ] +.SH "DESCRIPTION" +.PP +\fBhost\fR +is a simple utility for performing DNS lookups. +It is normally used to convert names to IP addresses and vice versa. +When no arguments or options are given, +\fBhost\fR +prints a short summary of its command line arguments and options. +.PP +\fIname\fR is the domain name that is to be looked +up. It can also be a dotted-decimal IPv4 address or a colon-delimited +IPv6 address, in which case \fBhost\fR will by default +perform a reverse lookup for that address. +\fIserver\fR is an optional argument which is either +the name or IP address of the name server that \fBhost\fR +should query instead of the server or servers listed in +\fI/etc/resolv.conf\fR. +.PP +The \fB-a\fR (all) option is equivalent to setting the +\fB-v\fR option and asking \fBhost\fR to make +a query of type ANY. +.PP +When the \fB-C\fR option is used, \fBhost\fR +will attempt to display the SOA records for zone +\fIname\fR from all the listed authoritative name +servers for that zone. The list of name servers is defined by the NS +records that are found for the zone. +.PP +The \fB-c\fR option instructs to make a DNS query of class +\fIclass\fR. This can be used to lookup Hesiod or +Chaosnet class resource records. The default class is IN (Internet). +.PP +Verbose output is generated by \fBhost\fR when the +\fB-d\fR or \fB-v\fR option is used. The two +options are equivalent. They have been provided for backwards +compatibility. In previous versions, the \fB-d\fR option +switched on debugging traces and \fB-v\fR enabled verbose +output. +.PP +List mode is selected by the \fB-l\fR option. This makes +\fBhost\fR perform a zone transfer for zone +\fIname\fR. Transfer the zone printing out the NS, PTR +and address records (A/AAAA). If combined with \fB-a\fR +all records will be printed. +.PP +The \fB-i\fR +option specifies that reverse lookups of IPv6 addresses should +use the IP6.INT domain as defined in RFC1886. +The default is to use IP6.ARPA. +.PP +The \fB-N\fR option sets the number of dots that have to be +in \fIname\fR for it to be considered absolute. The +default value is that defined using the ndots statement in +\fI/etc/resolv.conf\fR, or 1 if no ndots statement is +present. Names with fewer dots are interpreted as relative names and +will be searched for in the domains listed in the \fBsearch\fR +or \fBdomain\fR directive in +\fI/etc/resolv.conf\fR. +.PP +The number of UDP retries for a lookup can be changed with the +\fB-R\fR option. \fInumber\fR indicates +how many times \fBhost\fR will repeat a query that does +not get answered. The default number of retries is 1. If +\fInumber\fR is negative or zero, the number of +retries will default to 1. +.PP +Non-recursive queries can be made via the \fB-r\fR option. +Setting this option clears the \fBRD\fR \(em recursion +desired \(em bit in the query which \fBhost\fR makes. +This should mean that the name server receiving the query will not +attempt to resolve \fIname\fR. The +\fB-r\fR option enables \fBhost\fR to mimic +the behaviour of a name server by making non-recursive queries and +expecting to receive answers to those queries that are usually +referrals to other name servers. +.PP +By default \fBhost\fR uses UDP when making queries. The +\fB-T\fR option makes it use a TCP connection when querying +the name server. TCP will be automatically selected for queries that +require it, such as zone transfer (AXFR) requests. +.PP +The \fB-4\fR option forces \fBhost\fR to only +use IPv4 query transport. The \fB-6\fR option forces +\fBhost\fR to only use IPv6 query transport. +.PP +The \fB-t\fR option is used to select the query type. +\fItype\fR can be any recognised query type: CNAME, +NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, +\fBhost\fR automatically selects an appropriate query +type. By default it looks for A records, but if the +\fB-C\fR option was given, queries will be made for SOA +records, and if \fIname\fR is a dotted-decimal IPv4 +address or colon-delimited IPv6 address, \fBhost\fR will +query for PTR records. If a query type of IXFR is chosen the starting +serial number can be specified by appending an equal followed by the +starting serial number (e.g. -t IXFR=12345678). +.PP +The time to wait for a reply can be controlled through the +\fB-W\fR and \fB-w\fR options. The +\fB-W\fR option makes \fBhost\fR wait for +\fIwait\fR seconds. If \fIwait\fR +is less than one, the wait interval is set to one second. When the +\fB-w\fR option is used, \fBhost\fR will +effectively wait forever for a reply. The time to wait for a response +will be set to the number of seconds given by the hardware's maximum +value for an integer quantity. +.SH "FILES" +.PP +\fI/etc/resolv.conf\fR +.SH "SEE ALSO" +.PP +\fBdig\fR(1), +\fBnamed\fR(8). diff --git a/contrib/bind9/bin/dig/host.c b/contrib/bind9/bin/dig/host.c new file mode 100644 index 000000000000..53d781282346 --- /dev/null +++ b/contrib/bind9/bin/dig/host.c @@ -0,0 +1,754 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: host.c,v 1.76.2.5.2.9 2004/04/13 03:00:06 marka Exp $ */ + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +extern ISC_LIST(dig_lookup_t) lookup_list; +extern dig_serverlist_t server_list; +extern ISC_LIST(dig_searchlist_t) search_list; + +extern isc_boolean_t have_ipv4, have_ipv6; +extern isc_boolean_t usesearch; +extern isc_boolean_t debugging; +extern unsigned int timeout; +extern isc_mem_t *mctx; +extern int ndots; +extern int tries; +extern char *progname; +extern isc_task_t *global_task; +extern int fatalexit; + +static isc_boolean_t short_form = ISC_TRUE, listed_server = ISC_FALSE; +static isc_boolean_t default_lookups = ISC_TRUE; +static int seen_error = -1; +static isc_boolean_t list_addresses = ISC_TRUE; +static dns_rdatatype_t list_type = dns_rdatatype_a; + +static const char *opcodetext[] = { + "QUERY", + "IQUERY", + "STATUS", + "RESERVED3", + "NOTIFY", + "UPDATE", + "RESERVED6", + "RESERVED7", + "RESERVED8", + "RESERVED9", + "RESERVED10", + "RESERVED11", + "RESERVED12", + "RESERVED13", + "RESERVED14", + "RESERVED15" +}; + +static const char *rcodetext[] = { + "NOERROR", + "FORMERR", + "SERVFAIL", + "NXDOMAIN", + "NOTIMP", + "REFUSED", + "YXDOMAIN", + "YXRRSET", + "NXRRSET", + "NOTAUTH", + "NOTZONE", + "RESERVED11", + "RESERVED12", + "RESERVED13", + "RESERVED14", + "RESERVED15", + "BADVERS" +}; + +struct rtype { + unsigned int type; + const char *text; +}; + +struct rtype rtypes[] = { + { 1, "has address" }, + { 2, "name server" }, + { 5, "is an alias for" }, + { 11, "has well known services" }, + { 12, "domain name pointer" }, + { 13, "host information" }, + { 15, "mail is handled by" }, + { 16, "descriptive text" }, + { 19, "x25 address" }, + { 20, "ISDN address" }, + { 24, "has signature" }, + { 25, "has key" }, + { 28, "has IPv6 address" }, + { 29, "location" }, + { 0, NULL } +}; + +static void +show_usage(void) { + fputs( +"Usage: host [-aCdlriTwv] [-c class] [-N ndots] [-t type] [-W time]\n" +" [-R number] hostname [server]\n" +" -a is equivalent to -v -t *\n" +" -c specifies query class for non-IN data\n" +" -C compares SOA records on authoritative nameservers\n" +" -d is equivalent to -v\n" +" -l lists all hosts in a domain, using AXFR\n" +" -i IP6.INT reverse lookups\n" +" -N changes the number of dots allowed before root lookup is done\n" +" -r disables recursive processing\n" +" -R specifies number of retries for UDP packets\n" +" -t specifies the query type\n" +" -T enables TCP/IP mode\n" +" -v enables verbose output\n" +" -w specifies to wait forever for a reply\n" +" -W specifies how long to wait for a reply\n" +" -4 use IPv4 query transport only\n" +" -6 use IPv6 query transport only\n", stderr); + exit(1); +} + +void +dighost_shutdown(void) { + isc_app_shutdown(); +} + +void +received(int bytes, isc_sockaddr_t *from, dig_query_t *query) { + isc_time_t now; + int diff; + + if (!short_form) { + char fromtext[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_format(from, fromtext, sizeof(fromtext)); + TIME_NOW(&now); + diff = (int) isc_time_microdiff(&now, &query->time_sent); + printf("Received %u bytes from %s in %d ms\n", + bytes, fromtext, diff/1000); + } +} + +void +trying(char *frm, dig_lookup_t *lookup) { + UNUSED(lookup); + + if (!short_form) + printf("Trying \"%s\"\n", frm); +} + +static void +say_message(dns_name_t *name, const char *msg, dns_rdata_t *rdata, + dig_query_t *query) +{ + isc_buffer_t *b = NULL; + char namestr[DNS_NAME_FORMATSIZE]; + isc_region_t r; + isc_result_t result; + unsigned int bufsize = BUFSIZ; + + dns_name_format(name, namestr, sizeof(namestr)); + retry: + result = isc_buffer_allocate(mctx, &b, bufsize); + check_result(result, "isc_buffer_allocate"); + result = dns_rdata_totext(rdata, NULL, b); + if (result == ISC_R_NOSPACE) { + isc_buffer_free(&b); + bufsize *= 2; + goto retry; + } + check_result(result, "dns_rdata_totext"); + isc_buffer_usedregion(b, &r); + if (query->lookup->identify_previous_line) { + printf("Nameserver %s:\n\t", + query->servname); + } + printf("%s %s %.*s", namestr, + msg, (int)r.length, (char *)r.base); + if (query->lookup->identify) { + printf(" on server %s", query->servname); + } + printf("\n"); + isc_buffer_free(&b); +} +#ifdef DIG_SIGCHASE +/* Just for compatibility : not use in host program */ +isc_result_t +printrdataset(dns_name_t *owner_name, dns_rdataset_t *rdataset, + isc_buffer_t *target) +{ + UNUSED(owner_name); + UNUSED(rdataset); + UNUSED(target); + return(ISC_FALSE); +} +#endif +static isc_result_t +printsection(dns_message_t *msg, dns_section_t sectionid, + const char *section_name, isc_boolean_t headers, + dig_query_t *query) +{ + dns_name_t *name, *print_name; + dns_rdataset_t *rdataset; + dns_rdata_t rdata = DNS_RDATA_INIT; + isc_buffer_t target; + isc_result_t result, loopresult; + isc_region_t r; + dns_name_t empty_name; + char t[4096]; + isc_boolean_t first; + isc_boolean_t no_rdata; + + if (sectionid == DNS_SECTION_QUESTION) + no_rdata = ISC_TRUE; + else + no_rdata = ISC_FALSE; + + if (headers) + printf(";; %s SECTION:\n", section_name); + + dns_name_init(&empty_name, NULL); + + result = dns_message_firstname(msg, sectionid); + if (result == ISC_R_NOMORE) + return (ISC_R_SUCCESS); + else if (result != ISC_R_SUCCESS) + return (result); + + for (;;) { + name = NULL; + dns_message_currentname(msg, sectionid, &name); + + isc_buffer_init(&target, t, sizeof(t)); + first = ISC_TRUE; + print_name = name; + + for (rdataset = ISC_LIST_HEAD(name->list); + rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) { + if (query->lookup->rdtype == dns_rdatatype_axfr && + !((!list_addresses && + (list_type == dns_rdatatype_any || + rdataset->type == list_type)) || + (list_addresses && + (rdataset->type == dns_rdatatype_a || + rdataset->type == dns_rdatatype_aaaa || + rdataset->type == dns_rdatatype_ns || + rdataset->type == dns_rdatatype_ptr)))) + continue; + if (!short_form) { + result = dns_rdataset_totext(rdataset, + print_name, + ISC_FALSE, + no_rdata, + &target); + if (result != ISC_R_SUCCESS) + return (result); +#ifdef USEINITALWS + if (first) { + print_name = &empty_name; + first = ISC_FALSE; + } +#else + UNUSED(first); /* Shut up compiler. */ +#endif + } else { + loopresult = dns_rdataset_first(rdataset); + while (loopresult == ISC_R_SUCCESS) { + struct rtype *t; + const char *rtt; + char typebuf[DNS_RDATATYPE_FORMATSIZE]; + char typebuf2[DNS_RDATATYPE_FORMATSIZE + + 20]; + dns_rdataset_current(rdataset, &rdata); + + for (t = rtypes; t->text != NULL; t++) { + if (t->type == rdata.type) { + rtt = t->text; + goto found; + } + } + + dns_rdatatype_format(rdata.type, + typebuf, + sizeof(typebuf)); + snprintf(typebuf2, sizeof(typebuf2), + "has %s record", typebuf); + rtt = typebuf2; + found: + say_message(print_name, rtt, + &rdata, query); + dns_rdata_reset(&rdata); + loopresult = + dns_rdataset_next(rdataset); + } + } + } + if (!short_form) { + isc_buffer_usedregion(&target, &r); + if (no_rdata) + printf(";%.*s", (int)r.length, + (char *)r.base); + else + printf("%.*s", (int)r.length, (char *)r.base); + } + + result = dns_message_nextname(msg, sectionid); + if (result == ISC_R_NOMORE) + break; + else if (result != ISC_R_SUCCESS) + return (result); + } + + return (ISC_R_SUCCESS); +} + +static isc_result_t +printrdata(dns_message_t *msg, dns_rdataset_t *rdataset, dns_name_t *owner, + const char *set_name, isc_boolean_t headers) +{ + isc_buffer_t target; + isc_result_t result; + isc_region_t r; + char t[4096]; + + UNUSED(msg); + if (headers) + printf(";; %s SECTION:\n", set_name); + + isc_buffer_init(&target, t, sizeof(t)); + + result = dns_rdataset_totext(rdataset, owner, ISC_FALSE, ISC_FALSE, + &target); + if (result != ISC_R_SUCCESS) + return (result); + isc_buffer_usedregion(&target, &r); + printf("%.*s", (int)r.length, (char *)r.base); + + return (ISC_R_SUCCESS); +} + +isc_result_t +printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { + isc_boolean_t did_flag = ISC_FALSE; + dns_rdataset_t *opt, *tsig = NULL; + dns_name_t *tsigname; + isc_result_t result = ISC_R_SUCCESS; + int force_error; + + UNUSED(headers); + + /* + * We get called multiple times. + * Preserve any existing error status. + */ + force_error = (seen_error == 1) ? 1 : 0; + seen_error = 1; + if (listed_server) { + char sockstr[ISC_SOCKADDR_FORMATSIZE]; + + printf("Using domain server:\n"); + printf("Name: %s\n", query->servname); + isc_sockaddr_format(&query->sockaddr, sockstr, + sizeof(sockstr)); + printf("Address: %s\n", sockstr); + printf("Aliases: \n\n"); + } + + if (msg->rcode != 0) { + char namestr[DNS_NAME_FORMATSIZE]; + dns_name_format(query->lookup->name, namestr, sizeof(namestr)); + printf("Host %s not found: %d(%s)\n", namestr, + msg->rcode, rcodetext[msg->rcode]); + return (ISC_R_SUCCESS); + } + + if (default_lookups && query->lookup->rdtype == dns_rdatatype_a) { + char namestr[DNS_NAME_FORMATSIZE]; + dig_lookup_t *lookup; + + /* Add AAAA and MX lookups. */ + + dns_name_format(query->lookup->name, namestr, sizeof(namestr)); + lookup = clone_lookup(query->lookup, ISC_FALSE); + if (lookup != NULL) { + strncpy(lookup->textname, namestr, + sizeof(lookup->textname)); + lookup->textname[sizeof(lookup->textname)-1] = 0; + lookup->rdtype = dns_rdatatype_aaaa; + lookup->rdtypeset = ISC_TRUE; + lookup->origin = NULL; + lookup->retries = tries; + ISC_LIST_APPEND(lookup_list, lookup, link); + } + lookup = clone_lookup(query->lookup, ISC_FALSE); + if (lookup != NULL) { + strncpy(lookup->textname, namestr, + sizeof(lookup->textname)); + lookup->textname[sizeof(lookup->textname)-1] = 0; + lookup->rdtype = dns_rdatatype_mx; + lookup->rdtypeset = ISC_TRUE; + lookup->origin = NULL; + lookup->retries = tries; + ISC_LIST_APPEND(lookup_list, lookup, link); + } + } + + if (!short_form) { + printf(";; ->>HEADER<<- opcode: %s, status: %s, id: %u\n", + opcodetext[msg->opcode], rcodetext[msg->rcode], + msg->id); + printf(";; flags: "); + if ((msg->flags & DNS_MESSAGEFLAG_QR) != 0) { + printf("qr"); + did_flag = ISC_TRUE; + } + if ((msg->flags & DNS_MESSAGEFLAG_AA) != 0) { + printf("%saa", did_flag ? " " : ""); + did_flag = ISC_TRUE; + } + if ((msg->flags & DNS_MESSAGEFLAG_TC) != 0) { + printf("%stc", did_flag ? " " : ""); + did_flag = ISC_TRUE; + } + if ((msg->flags & DNS_MESSAGEFLAG_RD) != 0) { + printf("%srd", did_flag ? " " : ""); + did_flag = ISC_TRUE; + } + if ((msg->flags & DNS_MESSAGEFLAG_RA) != 0) { + printf("%sra", did_flag ? " " : ""); + did_flag = ISC_TRUE; + } + if ((msg->flags & DNS_MESSAGEFLAG_AD) != 0) { + printf("%sad", did_flag ? " " : ""); + did_flag = ISC_TRUE; + } + if ((msg->flags & DNS_MESSAGEFLAG_CD) != 0) { + printf("%scd", did_flag ? " " : ""); + did_flag = ISC_TRUE; + } + printf("; QUERY: %u, ANSWER: %u, " + "AUTHORITY: %u, ADDITIONAL: %u\n", + msg->counts[DNS_SECTION_QUESTION], + msg->counts[DNS_SECTION_ANSWER], + msg->counts[DNS_SECTION_AUTHORITY], + msg->counts[DNS_SECTION_ADDITIONAL]); + opt = dns_message_getopt(msg); + if (opt != NULL) + printf(";; EDNS: version: %u, udp=%u\n", + (unsigned int)((opt->ttl & 0x00ff0000) >> 16), + (unsigned int)opt->rdclass); + tsigname = NULL; + tsig = dns_message_gettsig(msg, &tsigname); + if (tsig != NULL) + printf(";; PSEUDOSECTIONS: TSIG\n"); + } + if (! ISC_LIST_EMPTY(msg->sections[DNS_SECTION_QUESTION]) && + !short_form) { + printf("\n"); + result = printsection(msg, DNS_SECTION_QUESTION, "QUESTION", + ISC_TRUE, query); + if (result != ISC_R_SUCCESS) + return (result); + } + if (! ISC_LIST_EMPTY(msg->sections[DNS_SECTION_ANSWER])) { + if (!short_form) + printf("\n"); + result = printsection(msg, DNS_SECTION_ANSWER, "ANSWER", + ISC_TF(!short_form), query); + if (result != ISC_R_SUCCESS) + return (result); + } + + if (! ISC_LIST_EMPTY(msg->sections[DNS_SECTION_AUTHORITY]) && + !short_form) { + printf("\n"); + result = printsection(msg, DNS_SECTION_AUTHORITY, "AUTHORITY", + ISC_TRUE, query); + if (result != ISC_R_SUCCESS) + return (result); + } + if (! ISC_LIST_EMPTY(msg->sections[DNS_SECTION_ADDITIONAL]) && + !short_form) { + printf("\n"); + result = printsection(msg, DNS_SECTION_ADDITIONAL, + "ADDITIONAL", ISC_TRUE, query); + if (result != ISC_R_SUCCESS) + return (result); + } + if ((tsig != NULL) && !short_form) { + printf("\n"); + result = printrdata(msg, tsig, tsigname, + "PSEUDOSECTION TSIG", ISC_TRUE); + if (result != ISC_R_SUCCESS) + return (result); + } + if (!short_form) + printf("\n"); + + if (short_form && !default_lookups && + ISC_LIST_EMPTY(msg->sections[DNS_SECTION_ANSWER])) { + char namestr[DNS_NAME_FORMATSIZE]; + char typestr[DNS_RDATATYPE_FORMATSIZE]; + dns_name_format(query->lookup->name, namestr, sizeof(namestr)); + dns_rdatatype_format(query->lookup->rdtype, typestr, + sizeof(typestr)); + printf("%s has no %s record\n", namestr, typestr); + } + seen_error = force_error; + return (result); +} + +static void +parse_args(isc_boolean_t is_batchfile, int argc, char **argv) { + char hostname[MXNAME]; + dig_lookup_t *lookup; + int c; + char store[MXNAME]; + isc_textregion_t tr; + isc_result_t result = ISC_R_SUCCESS; + dns_rdatatype_t rdtype; + dns_rdataclass_t rdclass; + isc_uint32_t serial = 0; + + UNUSED(is_batchfile); + + lookup = make_empty_lookup(); + + while ((c = isc_commandline_parse(argc, argv, "lvwrdt:c:aTCN:R:W:Dni46")) + != EOF) { + switch (c) { + case 'l': + lookup->tcp_mode = ISC_TRUE; + lookup->rdtype = dns_rdatatype_axfr; + lookup->rdtypeset = ISC_TRUE; + fatalexit = 3; + break; + case 'v': + case 'd': + short_form = ISC_FALSE; + break; + case 'r': + lookup->recurse = ISC_FALSE; + break; + case 't': + if (strncasecmp(isc_commandline_argument, + "ixfr=", 5) == 0) { + rdtype = dns_rdatatype_ixfr; + /* XXXMPA add error checking */ + serial = strtoul(isc_commandline_argument + 5, + NULL, 10); + result = ISC_R_SUCCESS; + } else { + tr.base = isc_commandline_argument; + tr.length = strlen(isc_commandline_argument); + result = dns_rdatatype_fromtext(&rdtype, + (isc_textregion_t *)&tr); + } + + if (result != ISC_R_SUCCESS) { + fatalexit = 2; + fatal("invalid type: %s\n", + isc_commandline_argument); + } + if (!lookup->rdtypeset || + lookup->rdtype != dns_rdatatype_axfr) + lookup->rdtype = rdtype; + lookup->rdtypeset = ISC_TRUE; + if (rdtype == dns_rdatatype_axfr) { + /* -l -t any -v */ + list_type = dns_rdatatype_any; + short_form = ISC_FALSE; + lookup->tcp_mode = ISC_TRUE; + } else if (rdtype == dns_rdatatype_ixfr) { + lookup->ixfr_serial = serial; + list_type = rdtype; + } else + list_type = rdtype; + list_addresses = ISC_FALSE; + break; + case 'c': + tr.base = isc_commandline_argument; + tr.length = strlen(isc_commandline_argument); + result = dns_rdataclass_fromtext(&rdclass, + (isc_textregion_t *)&tr); + + if (result != ISC_R_SUCCESS) { + fatalexit = 2; + fatal("invalid class: %s\n", + isc_commandline_argument); + } else { + lookup->rdclass = rdclass; + lookup->rdclassset = ISC_TRUE; + } + default_lookups = ISC_FALSE; + break; + case 'a': + if (!lookup->rdtypeset || + lookup->rdtype != dns_rdatatype_axfr) + lookup->rdtype = dns_rdatatype_any; + list_type = dns_rdatatype_any; + list_addresses = ISC_FALSE; + lookup->rdtypeset = ISC_TRUE; + short_form = ISC_FALSE; + default_lookups = ISC_FALSE; + break; + case 'i': + lookup->ip6_int = ISC_TRUE; + break; + case 'n': + /* deprecated */ + break; + case 'w': + /* + * The timer routines are coded such that + * timeout==MAXINT doesn't enable the timer + */ + timeout = INT_MAX; + break; + case 'W': + timeout = atoi(isc_commandline_argument); + if (timeout < 1) + timeout = 1; + break; + case 'R': + tries = atoi(isc_commandline_argument) + 1; + if (tries < 2) + tries = 2; + break; + case 'T': + lookup->tcp_mode = ISC_TRUE; + break; + case 'C': + debug("showing all SOAs"); + lookup->rdtype = dns_rdatatype_ns; + lookup->rdtypeset = ISC_TRUE; + lookup->rdclass = dns_rdataclass_in; + lookup->rdclassset = ISC_TRUE; + lookup->ns_search_only = ISC_TRUE; + lookup->trace_root = ISC_TRUE; + lookup->identify_previous_line = ISC_TRUE; + default_lookups = ISC_FALSE; + break; + case 'N': + debug("setting NDOTS to %s", + isc_commandline_argument); + ndots = atoi(isc_commandline_argument); + break; + case 'D': + debugging = ISC_TRUE; + break; + case '4': + if (have_ipv4) { + isc_net_disableipv6(); + have_ipv6 = ISC_FALSE; + } else + fatal("can't find IPv4 networking"); + break; + case '6': + if (have_ipv6) { + isc_net_disableipv4(); + have_ipv4 = ISC_FALSE; + } else + fatal("can't find IPv6 networking"); + break; + } + } + + lookup->retries = tries; + + if (isc_commandline_index >= argc) + show_usage(); + + strncpy(hostname, argv[isc_commandline_index], sizeof(hostname)); + hostname[sizeof(hostname)-1]=0; + if (argc > isc_commandline_index + 1) { + set_nameserver(argv[isc_commandline_index+1]); + debug("server is %s", argv[isc_commandline_index+1]); + listed_server = ISC_TRUE; + } + + lookup->pending = ISC_FALSE; + if (get_reverse(store, sizeof(store), hostname, + lookup->ip6_int, ISC_TRUE) == ISC_R_SUCCESS) { + strncpy(lookup->textname, store, sizeof(lookup->textname)); + lookup->textname[sizeof(lookup->textname)-1] = 0; + lookup->rdtype = dns_rdatatype_ptr; + lookup->rdtypeset = ISC_TRUE; + default_lookups = ISC_FALSE; + } else { + strncpy(lookup->textname, hostname, sizeof(lookup->textname)); + lookup->textname[sizeof(lookup->textname)-1]=0; + } + lookup->new_search = ISC_TRUE; + ISC_LIST_APPEND(lookup_list, lookup, link); + + usesearch = ISC_TRUE; +} + +int +main(int argc, char **argv) { + isc_result_t result; + + tries = 2; + + ISC_LIST_INIT(lookup_list); + ISC_LIST_INIT(server_list); + ISC_LIST_INIT(search_list); + + fatalexit = 1; + + debug("main()"); + progname = argv[0]; + result = isc_app_start(); + check_result(result, "isc_app_start"); + setup_libs(); + parse_args(ISC_FALSE, argc, argv); + setup_system(); + result = isc_app_onrun(mctx, global_task, onrun_callback, NULL); + check_result(result, "isc_app_onrun"); + isc_app_run(); + cancel_all(); + destroy_libs(); + isc_app_finish(); + return ((seen_error == 0) ? 0 : 1); +} + diff --git a/contrib/bind9/bin/dig/host.docbook b/contrib/bind9/bin/dig/host.docbook new file mode 100644 index 000000000000..561f7c4397d2 --- /dev/null +++ b/contrib/bind9/bin/dig/host.docbook @@ -0,0 +1,212 @@ + + + + + + + + +Jun 30, 2000 + + + +host +1 +BIND9 + + + +host +DNS lookup utility + + + + + host + + + + + + + + + name + server + + + + +DESCRIPTION + +host +is a simple utility for performing DNS lookups. +It is normally used to convert names to IP addresses and vice versa. +When no arguments or options are given, +host +prints a short summary of its command line arguments and options. + + + +name is the domain name that is to be looked +up. It can also be a dotted-decimal IPv4 address or a colon-delimited +IPv6 address, in which case host will by default +perform a reverse lookup for that address. +server is an optional argument which is either +the name or IP address of the name server that host +should query instead of the server or servers listed in +/etc/resolv.conf. + + + +The (all) option is equivalent to setting the + option and asking host to make +a query of type ANY. + + + +When the option is used, host +will attempt to display the SOA records for zone +name from all the listed authoritative name +servers for that zone. The list of name servers is defined by the NS +records that are found for the zone. + + + +The option instructs to make a DNS query of class +class. This can be used to lookup Hesiod or +Chaosnet class resource records. The default class is IN (Internet). + + + +Verbose output is generated by host when the + or option is used. The two +options are equivalent. They have been provided for backwards +compatibility. In previous versions, the option +switched on debugging traces and enabled verbose +output. + + + +List mode is selected by the option. This makes +host perform a zone transfer for zone +name. Transfer the zone printing out the NS, PTR +and address records (A/AAAA). If combined with +all records will be printed. + + + +The +option specifies that reverse lookups of IPv6 addresses should +use the IP6.INT domain as defined in RFC1886. +The default is to use IP6.ARPA. + + + +The option sets the number of dots that have to be +in name for it to be considered absolute. The +default value is that defined using the ndots statement in +/etc/resolv.conf, or 1 if no ndots statement is +present. Names with fewer dots are interpreted as relative names and +will be searched for in the domains listed in the search +or domain directive in +/etc/resolv.conf. + + + +The number of UDP retries for a lookup can be changed with the + option. number indicates +how many times host will repeat a query that does +not get answered. The default number of retries is 1. If +number is negative or zero, the number of +retries will default to 1. + + + +Non-recursive queries can be made via the option. +Setting this option clears the RD — recursion +desired — bit in the query which host makes. +This should mean that the name server receiving the query will not +attempt to resolve name. The + option enables host to mimic +the behaviour of a name server by making non-recursive queries and +expecting to receive answers to those queries that are usually +referrals to other name servers. + + + +By default host uses UDP when making queries. The + option makes it use a TCP connection when querying +the name server. TCP will be automatically selected for queries that +require it, such as zone transfer (AXFR) requests. + + + +The option forces host to only +use IPv4 query transport. The option forces +host to only use IPv6 query transport. + + + +The option is used to select the query type. +type can be any recognised query type: CNAME, +NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, +host automatically selects an appropriate query +type. By default it looks for A records, but if the + option was given, queries will be made for SOA +records, and if name is a dotted-decimal IPv4 +address or colon-delimited IPv6 address, host will +query for PTR records. If a query type of IXFR is chosen the starting +serial number can be specified by appending an equal followed by the +starting serial number (e.g. -t IXFR=12345678). + + + +The time to wait for a reply can be controlled through the + and options. The + option makes host wait for +wait seconds. If wait +is less than one, the wait interval is set to one second. When the + option is used, host will +effectively wait forever for a reply. The time to wait for a response +will be set to the number of seconds given by the hardware's maximum +value for an integer quantity. + + + + + +FILES + +/etc/resolv.conf + + + + +SEE ALSO + + +dig1 +, + +named8 +. + + + + diff --git a/contrib/bind9/bin/dig/host.html b/contrib/bind9/bin/dig/host.html new file mode 100644 index 000000000000..fb011c033b9e --- /dev/null +++ b/contrib/bind9/bin/dig/host.html @@ -0,0 +1,434 @@ + + + + + +host

host

Name

host -- DNS lookup utility

Synopsis

host [-aCdlnrTwv] [-c class] [-N ndots] [-R number] [-t type] [-W wait] [-4] [-6] {name} [server]

DESCRIPTION

host +is a simple utility for performing DNS lookups. +It is normally used to convert names to IP addresses and vice versa. +When no arguments or options are given, +host +prints a short summary of its command line arguments and options.

name is the domain name that is to be looked +up. It can also be a dotted-decimal IPv4 address or a colon-delimited +IPv6 address, in which case host will by default +perform a reverse lookup for that address. +server is an optional argument which is either +the name or IP address of the name server that host +should query instead of the server or servers listed in +/etc/resolv.conf.

The -a (all) option is equivalent to setting the +-v option and asking host to make +a query of type ANY.

When the -C option is used, host +will attempt to display the SOA records for zone +name from all the listed authoritative name +servers for that zone. The list of name servers is defined by the NS +records that are found for the zone.

The -c option instructs to make a DNS query of class +class. This can be used to lookup Hesiod or +Chaosnet class resource records. The default class is IN (Internet).

Verbose output is generated by host when the +-d or -v option is used. The two +options are equivalent. They have been provided for backwards +compatibility. In previous versions, the -d option +switched on debugging traces and -v enabled verbose +output.

List mode is selected by the -l option. This makes +host perform a zone transfer for zone +name. Transfer the zone printing out the NS, PTR +and address records (A/AAAA). If combined with -a +all records will be printed.

The -i +option specifies that reverse lookups of IPv6 addresses should +use the IP6.INT domain as defined in RFC1886. +The default is to use IP6.ARPA.

The -N option sets the number of dots that have to be +in name for it to be considered absolute. The +default value is that defined using the ndots statement in +/etc/resolv.conf, or 1 if no ndots statement is +present. Names with fewer dots are interpreted as relative names and +will be searched for in the domains listed in the search +or domain directive in +/etc/resolv.conf.

The number of UDP retries for a lookup can be changed with the +-R option. number indicates +how many times host will repeat a query that does +not get answered. The default number of retries is 1. If +number is negative or zero, the number of +retries will default to 1.

Non-recursive queries can be made via the -r option. +Setting this option clears the RD — recursion +desired — bit in the query which host makes. +This should mean that the name server receiving the query will not +attempt to resolve name. The +-r option enables host to mimic +the behaviour of a name server by making non-recursive queries and +expecting to receive answers to those queries that are usually +referrals to other name servers.

By default host uses UDP when making queries. The +-T option makes it use a TCP connection when querying +the name server. TCP will be automatically selected for queries that +require it, such as zone transfer (AXFR) requests.

The -4 option forces host to only +use IPv4 query transport. The -6 option forces +host to only use IPv6 query transport.

The -t option is used to select the query type. +type can be any recognised query type: CNAME, +NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, +host automatically selects an appropriate query +type. By default it looks for A records, but if the +-C option was given, queries will be made for SOA +records, and if name is a dotted-decimal IPv4 +address or colon-delimited IPv6 address, host will +query for PTR records. If a query type of IXFR is chosen the starting +serial number can be specified by appending an equal followed by the +starting serial number (e.g. -t IXFR=12345678).

The time to wait for a reply can be controlled through the +-W and -w options. The +-W option makes host wait for +wait seconds. If wait +is less than one, the wait interval is set to one second. When the +-w option is used, host will +effectively wait forever for a reply. The time to wait for a response +will be set to the number of seconds given by the hardware's maximum +value for an integer quantity.

FILES

/etc/resolv.conf

SEE ALSO

dig(1), +named(8).

diff --git a/contrib/bind9/bin/dig/include/dig/dig.h b/contrib/bind9/bin/dig/include/dig/dig.h new file mode 100644 index 000000000000..12e1e21dfd55 --- /dev/null +++ b/contrib/bind9/bin/dig/include/dig/dig.h @@ -0,0 +1,343 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dig.h,v 1.71.2.6.2.6 2004/06/19 02:30:12 sra Exp $ */ + +#ifndef DIG_H +#define DIG_H + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define MXSERV 6 +#define MXNAME (DNS_NAME_MAXTEXT+1) +#define MXRD 32 +#define BUFSIZE 512 +#define COMMSIZE 0xffff +#ifndef RESOLV_CONF +#define RESOLV_CONF "/etc/resolv.conf" +#endif +#define OUTPUTBUF 32767 +#define MAXRRLIMIT 0xffffffff +#define MAXTIMEOUT 0xffff +#define MAXTRIES 0xffffffff +#define MAXNDOTS 0xffff +#define MAXPORT 0xffff +#define MAXSERIAL 0xffffffff + +/* + * Default timeout values + */ +#define TCP_TIMEOUT 10 +#define UDP_TIMEOUT 5 + +#define SERVER_TIMEOUT 1 + +#define LOOKUP_LIMIT 64 +/* + * Lookup_limit is just a limiter, keeping too many lookups from being + * created. It's job is mainly to prevent the program from running away + * in a tight loop of constant lookups. It's value is arbitrary. + */ + +#define ROOTNS 1 +/* + * Set the number of root servers to ask for information when running in + * trace mode. + * XXXMWS -- trace mode is currently semi-broken, and this number *MUST* + * be 1. + */ + +/* + * Defaults for the sigchase suboptions. Consolidated here because + * these control the layout of dig_lookup_t (among other things). + */ +#ifdef DIG_SIGCHASE +#ifndef DIG_SIGCHASE_BU +#define DIG_SIGCHASE_BU 1 +#endif +#ifndef DIG_SIGCHASE_TD +#define DIG_SIGCHASE_TD 1 +#endif +#endif + +ISC_LANG_BEGINDECLS + +typedef struct dig_lookup dig_lookup_t; +typedef struct dig_query dig_query_t; +typedef struct dig_server dig_server_t; +#ifdef DIG_SIGCHASE +typedef struct dig_message dig_message_t; +#endif +typedef ISC_LIST(dig_server_t) dig_serverlist_t; +typedef struct dig_searchlist dig_searchlist_t; + +struct dig_lookup { + isc_boolean_t + pending, /* Pending a successful answer */ + waiting_connect, + doing_xfr, + ns_search_only, /* dig +nssearch, host -C */ + identify, /* Append an "on server " message */ + identify_previous_line, /* Prepend a "Nameserver :" + message, with newline and tab */ + ignore, + recurse, + aaonly, + adflag, + cdflag, + trace, /* dig +trace */ + trace_root, /* initial query for either +trace or +nssearch */ + tcp_mode, + ip6_int, + comments, + stats, + section_question, + section_answer, + section_authority, + section_additional, + servfail_stops, + new_search, + besteffort, + dnssec; +#ifdef DIG_SIGCHASE +isc_boolean_t sigchase; +#if DIG_SIGCHASE_TD + isc_boolean_t do_topdown, + trace_root_sigchase, + rdtype_sigchaseset, + rdclass_sigchaseset; + /* Name we are going to validate RRset */ + char textnamesigchase[MXNAME]; +#endif +#endif + + char textname[MXNAME]; /* Name we're going to be looking up */ + char cmdline[MXNAME]; + dns_rdatatype_t rdtype; + dns_rdatatype_t qrdtype; +#if DIG_SIGCHASE_TD + dns_rdatatype_t rdtype_sigchase; + dns_rdatatype_t qrdtype_sigchase; + dns_rdataclass_t rdclass_sigchase; +#endif + dns_rdataclass_t rdclass; + isc_boolean_t rdtypeset; + isc_boolean_t rdclassset; + char namespace[BUFSIZE]; + char onamespace[BUFSIZE]; + isc_buffer_t namebuf; + isc_buffer_t onamebuf; + isc_buffer_t sendbuf; + char *sendspace; + dns_name_t *name; + isc_timer_t *timer; + isc_interval_t interval; + dns_message_t *sendmsg; + dns_name_t *oname; + ISC_LINK(dig_lookup_t) link; + ISC_LIST(dig_query_t) q; + dig_query_t *current_query; + dig_serverlist_t my_server_list; + dig_searchlist_t *origin; + dig_query_t *xfr_q; + isc_uint32_t retries; + int nsfound; + isc_uint16_t udpsize; + isc_uint32_t ixfr_serial; + isc_buffer_t rdatabuf; + char rdatastore[MXNAME]; + dst_context_t *tsigctx; + isc_buffer_t *querysig; + isc_uint32_t msgcounter; +}; + +struct dig_query { + dig_lookup_t *lookup; + isc_boolean_t waiting_connect, + first_pass, + first_soa_rcvd, + second_rr_rcvd, + first_repeat_rcvd, + recv_made, + warn_id; + isc_uint32_t first_rr_serial; + isc_uint32_t second_rr_serial; + isc_uint32_t msg_count; + isc_uint32_t rr_count; + char *servname; + isc_bufferlist_t sendlist, + recvlist, + lengthlist; + isc_buffer_t recvbuf, + lengthbuf, + slbuf; + char *recvspace, + lengthspace[4], + slspace[4]; + isc_socket_t *sock; + ISC_LINK(dig_query_t) link; + isc_sockaddr_t sockaddr; + isc_time_t time_sent; +}; + +struct dig_server { + char servername[MXNAME]; + ISC_LINK(dig_server_t) link; +}; + +struct dig_searchlist { + char origin[MXNAME]; + ISC_LINK(dig_searchlist_t) link; +}; +#ifdef DIG_SIGCHASE +struct dig_message { + dns_message_t *msg; + ISC_LINK(dig_message_t) link; +}; +#endif +/* + * Routines in dighost.c. + */ +void +get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr); + +isc_result_t +get_reverse(char *reverse, size_t len, char *value, isc_boolean_t ip6_int, + isc_boolean_t strict); + +void +fatal(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +void +debug(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +void +check_result(isc_result_t result, const char *msg); + +void +setup_lookup(dig_lookup_t *lookup); + +void +do_lookup(dig_lookup_t *lookup); + +void +start_lookup(void); + +void +onrun_callback(isc_task_t *task, isc_event_t *event); + +int +dhmain(int argc, char **argv); + +void +setup_libs(void); + +void +setup_system(void); + +dig_lookup_t * +requeue_lookup(dig_lookup_t *lookold, isc_boolean_t servers); + +dig_lookup_t * +make_empty_lookup(void); + +dig_lookup_t * +clone_lookup(dig_lookup_t *lookold, isc_boolean_t servers); + +dig_server_t * +make_server(const char *servname); + +void +flush_server_list(void); + +void +set_nameserver(char *opt); + +void +clone_server_list(dig_serverlist_t src, + dig_serverlist_t *dest); + +void +cancel_all(void); + +void +destroy_libs(void); + +void +set_search_domain(char *domain); + +#ifdef DIG_SIGCHASE +void +clean_trustedkey(void); +#endif + +/* + * Routines to be defined in dig.c, host.c, and nslookup.c. + */ +#ifdef DIG_SIGCHASE +isc_result_t +printrdataset(dns_name_t *owner_name, dns_rdataset_t *rdataset, + isc_buffer_t *target); +#endif + +isc_result_t +printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers); +/* + * Print the final result of the lookup. + */ + +void +received(int bytes, isc_sockaddr_t *from, dig_query_t *query); +/* + * Print a message about where and when the response + * was received from, like the final comment in the + * output of "dig". + */ + +void +trying(char *frm, dig_lookup_t *lookup); + +void +dighost_shutdown(void); + +char * +next_token(char **stringp, const char *delim); + +#ifdef DIG_SIGCHASE +/* Chasing functions */ +dns_rdataset_t * +chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers); +void +chase_sig(dns_message_t *msg); +#endif + +ISC_LANG_ENDDECLS + +#endif diff --git a/contrib/bind9/bin/dig/nslookup.1 b/contrib/bind9/bin/dig/nslookup.1 new file mode 100644 index 000000000000..71aa8a131e4a --- /dev/null +++ b/contrib/bind9/bin/dig/nslookup.1 @@ -0,0 +1,192 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: nslookup.1,v 1.1.6.2 2004/08/20 02:29:39 marka Exp $ +.\" +.TH "NSLOOKUP" "1" "Jun 30, 2000" "BIND9" "" +.SH NAME +nslookup \- query Internet name servers interactively +.SH SYNOPSIS +.sp +\fBnslookup\fR [ \fB-option\fR ] [ \fBname | -\fR ] [ \fBserver\fR ] +.SH "DESCRIPTION" +.PP +\fBNslookup\fR +is a program to query Internet domain name servers. \fBNslookup\fR +has two modes: interactive and non-interactive. Interactive mode allows +the user to query name servers for information about various hosts and +domains or to print a list of hosts in a domain. Non-interactive mode is +used to print just the name and requested information for a host or +domain. +.SH "ARGUMENTS" +.PP +Interactive mode is entered in the following cases: +.IP 1. +when no arguments are given (the default name server will be used) +.IP 2. +when the first argument is a hyphen (-) and the second argument is +the host name or Internet address of a name server. +.PP +Non-interactive mode is used when the name or Internet address of the +host to be looked up is given as the first argument. The optional second +argument specifies the host name or address of a name server. +.PP +Options can also be specified on the command line if they precede the +arguments and are prefixed with a hyphen. For example, to +change the default query type to host information, and the initial timeout to 10 seconds, type: +.PP +.sp +.nf +nslookup -query=hinfo -timeout=10 +.sp +.fi +.SH "INTERACTIVE COMMANDS" +.TP +\fBhost [server]\fR +Look up information for host using the current default server or +using server, if specified. If host is an Internet address and +the query type is A or PTR, the name of the host is returned. +If host is a name and does not have a trailing period, the +search list is used to qualify the name. + +To look up a host not in the current domain, append a period to +the name. +.TP +\fBserver \fIdomain\fB\fR +.TP +\fBlserver \fIdomain\fB\fR +Change the default server to \fIdomain\fR; lserver uses the initial +server to look up information about \fIdomain\fR, while server uses +the current default server. If an authoritative answer can't be +found, the names of servers that might have the answer are +returned. +.TP +\fBroot\fR +not implemented +.TP +\fBfinger\fR +not implemented +.TP +\fBls\fR +not implemented +.TP +\fBview\fR +not implemented +.TP +\fBhelp\fR +not implemented +.TP +\fB?\fR +not implemented +.TP +\fBexit\fR +Exits the program. +.TP +\fBset \fIkeyword[=value]\fB\fR +This command is used to change state information that affects +the lookups. Valid keywords are: +.RS +.TP +\fBall\fR +Prints the current values of the frequently used +options to \fBset\fR. Information about the current default +server and host is also printed. +.TP +\fBclass=\fIvalue\fB\fR +Change the query class to one of: +.RS +.TP +\fBIN\fR +the Internet class +.TP +\fBCH\fR +the Chaos class +.TP +\fBHS\fR +the Hesiod class +.TP +\fBANY\fR +wildcard +.RE +.PP +The class specifies the protocol group of the information. + +(Default = IN; abbreviation = cl) +.TP +\fB\fI[no]\fBdebug\fR +Turn debugging mode on. A lot more information is +printed about the packet sent to the server and the +resulting answer. + +(Default = nodebug; abbreviation = [no]deb) +.TP +\fB\fI[no]\fBd2\fR +Turn debugging mode on. A lot more information is +printed about the packet sent to the server and the +resulting answer. + +(Default = nod2) +.TP +\fBdomain=\fIname\fB\fR +Sets the search list to \fIname\fR. +.TP +\fB\fI[no]\fBsearch\fR +If the lookup request contains at least one period but +doesn't end with a trailing period, append the domain +names in the domain search list to the request until an +answer is received. + +(Default = search) +.TP +\fBport=\fIvalue\fB\fR +Change the default TCP/UDP name server port to \fIvalue\fR. + +(Default = 53; abbreviation = po) +.TP +\fBquerytype=\fIvalue\fB\fR +.TP +\fBtype=\fIvalue\fB\fR +Change the top of the information query. + +(Default = A; abbreviations = q, ty) +.TP +\fB\fI[no]\fBrecurse\fR +Tell the name server to query other servers if it does not have the +information. + +(Default = recurse; abbreviation = [no]rec) +.TP +\fBretry=\fInumber\fB\fR +Set the number of retries to number. +.TP +\fBtimeout=\fInumber\fB\fR +Change the initial timeout interval for waiting for a +reply to number seconds. +.TP +\fB\fI[no]\fBvc\fR +Always use a virtual circuit when sending requests to the server. + +(Default = novc) +.RE +.SH "FILES" +.PP +\fI/etc/resolv.conf\fR +.SH "SEE ALSO" +.PP +\fBdig\fR(1), +\fBhost\fR(1), +\fBnamed\fR(8). +.SH "AUTHOR" +.PP +Andrew Cherenson diff --git a/contrib/bind9/bin/dig/nslookup.c b/contrib/bind9/bin/dig/nslookup.c new file mode 100644 index 000000000000..a616baefa129 --- /dev/null +++ b/contrib/bind9/bin/dig/nslookup.c @@ -0,0 +1,887 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: nslookup.c,v 1.90.2.4.2.7 2004/08/18 23:25:58 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +extern ISC_LIST(dig_lookup_t) lookup_list; +extern dig_serverlist_t server_list; +extern ISC_LIST(dig_searchlist_t) search_list; + +extern isc_boolean_t usesearch, debugging; +extern in_port_t port; +extern unsigned int timeout; +extern isc_mem_t *mctx; +extern int tries; +extern int lookup_counter; +extern isc_task_t *global_task; +extern char *progname; + +static isc_boolean_t short_form = ISC_TRUE, + tcpmode = ISC_FALSE, + identify = ISC_FALSE, stats = ISC_TRUE, + comments = ISC_TRUE, section_question = ISC_TRUE, + section_answer = ISC_TRUE, section_authority = ISC_TRUE, + section_additional = ISC_TRUE, recurse = ISC_TRUE, + aaonly = ISC_FALSE; +static isc_boolean_t in_use = ISC_FALSE; +static char defclass[MXRD] = "IN"; +static char deftype[MXRD] = "A"; +static isc_event_t *global_event = NULL; + +static char domainopt[DNS_NAME_MAXTEXT]; + +static const char *rcodetext[] = { + "NOERROR", + "FORMERR", + "SERVFAIL", + "NXDOMAIN", + "NOTIMP", + "REFUSED", + "YXDOMAIN", + "YXRRSET", + "NXRRSET", + "NOTAUTH", + "NOTZONE", + "RESERVED11", + "RESERVED12", + "RESERVED13", + "RESERVED14", + "RESERVED15", + "BADVERS" +}; + +static const char *rtypetext[] = { + "rtype_0 = ", /* 0 */ + "internet address = ", /* 1 */ + "nameserver = ", /* 2 */ + "md = ", /* 3 */ + "mf = ", /* 4 */ + "canonical name = ", /* 5 */ + "soa = ", /* 6 */ + "mb = ", /* 7 */ + "mg = ", /* 8 */ + "mr = ", /* 9 */ + "rtype_10 = ", /* 10 */ + "protocol = ", /* 11 */ + "name = ", /* 12 */ + "hinfo = ", /* 13 */ + "minfo = ", /* 14 */ + "mail exchanger = ", /* 15 */ + "text = ", /* 16 */ + "rp = ", /* 17 */ + "afsdb = ", /* 18 */ + "x25 address = ", /* 19 */ + "isdn address = ", /* 20 */ + "rt = ", /* 21 */ + "nsap = ", /* 22 */ + "nsap_ptr = ", /* 23 */ + "signature = ", /* 24 */ + "key = ", /* 25 */ + "px = ", /* 26 */ + "gpos = ", /* 27 */ + "has AAAA address ", /* 28 */ + "loc = ", /* 29 */ + "next = ", /* 30 */ + "rtype_31 = ", /* 31 */ + "rtype_32 = ", /* 32 */ + "service = ", /* 33 */ + "rtype_34 = ", /* 34 */ + "naptr = ", /* 35 */ + "kx = ", /* 36 */ + "cert = ", /* 37 */ + "v6 address = ", /* 38 */ + "dname = ", /* 39 */ + "rtype_40 = ", /* 40 */ + "optional = " /* 41 */ +}; + +#define N_KNOWN_RRTYPES (sizeof(rtypetext) / sizeof(rtypetext[0])) + +static void flush_lookup_list(void); +static void getinput(isc_task_t *task, isc_event_t *event); + +void +dighost_shutdown(void) { + isc_event_t *event = global_event; + + flush_lookup_list(); + debug("dighost_shutdown()"); + + if (!in_use) { + isc_app_shutdown(); + return; + } + + isc_task_send(global_task, &event); +} + +static void +printsoa(dns_rdata_t *rdata) { + dns_rdata_soa_t soa; + isc_result_t result; + char namebuf[DNS_NAME_FORMATSIZE]; + + result = dns_rdata_tostruct(rdata, &soa, NULL); + check_result(result, "dns_rdata_tostruct"); + + dns_name_format(&soa.origin, namebuf, sizeof(namebuf)); + printf("\torigin = %s\n", namebuf); + dns_name_format(&soa.contact, namebuf, sizeof(namebuf)); + printf("\tmail addr = %s\n", namebuf); + printf("\tserial = %u\n", soa.serial); + printf("\trefresh = %u\n", soa.refresh); + printf("\tretry = %u\n", soa.retry); + printf("\texpire = %u\n", soa.expire); + printf("\tminimum = %u\n", soa.minimum); + dns_rdata_freestruct(&soa); +} + +static void +printa(dns_rdata_t *rdata) { + isc_result_t result; + char text[sizeof("255.255.255.255")]; + isc_buffer_t b; + + isc_buffer_init(&b, text, sizeof(text)); + result = dns_rdata_totext(rdata, NULL, &b); + check_result(result, "dns_rdata_totext"); + printf("Address: %.*s\n", (int)isc_buffer_usedlength(&b), + (char *)isc_buffer_base(&b)); +} +#ifdef DIG_SIGCHASE +/* Just for compatibility : not use in host program */ +isc_result_t +printrdataset(dns_name_t *owner_name, dns_rdataset_t *rdataset, + isc_buffer_t *target) +{ + UNUSED(owner_name); + UNUSED(rdataset); + UNUSED(target); + return(ISC_FALSE); +} +#endif +static void +printrdata(dns_rdata_t *rdata) { + isc_result_t result; + isc_buffer_t *b = NULL; + unsigned int size = 1024; + isc_boolean_t done = ISC_FALSE; + + if (rdata->type < N_KNOWN_RRTYPES) + printf("%s", rtypetext[rdata->type]); + else + printf("rdata_%d = ", rdata->type); + + while (!done) { + result = isc_buffer_allocate(mctx, &b, size); + if (result != ISC_R_SUCCESS) + check_result(result, "isc_buffer_allocate"); + result = dns_rdata_totext(rdata, NULL, b); + if (result == ISC_R_SUCCESS) { + printf("%.*s\n", (int)isc_buffer_usedlength(b), + (char *)isc_buffer_base(b)); + done = ISC_TRUE; + } else if (result != ISC_R_NOSPACE) + check_result(result, "dns_rdata_totext"); + isc_buffer_free(&b); + size *= 2; + } +} + +static isc_result_t +printsection(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers, + dns_section_t section) { + isc_result_t result, loopresult; + dns_name_t *name; + dns_rdataset_t *rdataset = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + char namebuf[DNS_NAME_FORMATSIZE]; + + UNUSED(query); + UNUSED(headers); + + debug("printsection()"); + + result = dns_message_firstname(msg, section); + if (result == ISC_R_NOMORE) + return (ISC_R_SUCCESS); + else if (result != ISC_R_SUCCESS) + return (result); + for (;;) { + name = NULL; + dns_message_currentname(msg, section, + &name); + for (rdataset = ISC_LIST_HEAD(name->list); + rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) { + loopresult = dns_rdataset_first(rdataset); + while (loopresult == ISC_R_SUCCESS) { + dns_rdataset_current(rdataset, &rdata); + switch (rdata.type) { + case dns_rdatatype_a: + if (section != DNS_SECTION_ANSWER) + goto def_short_section; + dns_name_format(name, namebuf, + sizeof(namebuf)); + printf("Name:\t%s\n", namebuf); + printa(&rdata); + break; + case dns_rdatatype_soa: + dns_name_format(name, namebuf, + sizeof(namebuf)); + printf("%s\n", namebuf); + printsoa(&rdata); + break; + default: + def_short_section: + dns_name_format(name, namebuf, + sizeof(namebuf)); + printf("%s\t", namebuf); + printrdata(&rdata); + break; + } + dns_rdata_reset(&rdata); + loopresult = dns_rdataset_next(rdataset); + } + } + result = dns_message_nextname(msg, section); + if (result == ISC_R_NOMORE) + break; + else if (result != ISC_R_SUCCESS) { + return (result); + } + } + return (ISC_R_SUCCESS); +} + +static isc_result_t +detailsection(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers, + dns_section_t section) { + isc_result_t result, loopresult; + dns_name_t *name; + dns_rdataset_t *rdataset = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + char namebuf[DNS_NAME_FORMATSIZE]; + + UNUSED(query); + + debug("detailsection()"); + + if (headers) { + switch (section) { + case DNS_SECTION_QUESTION: + puts(" QUESTIONS:"); + break; + case DNS_SECTION_ANSWER: + puts(" ANSWERS:"); + break; + case DNS_SECTION_AUTHORITY: + puts(" AUTHORITY RECORDS:"); + break; + case DNS_SECTION_ADDITIONAL: + puts(" ADDITIONAL RECORDS:"); + break; + } + } + + result = dns_message_firstname(msg, section); + if (result == ISC_R_NOMORE) + return (ISC_R_SUCCESS); + else if (result != ISC_R_SUCCESS) + return (result); + for (;;) { + name = NULL; + dns_message_currentname(msg, section, + &name); + for (rdataset = ISC_LIST_HEAD(name->list); + rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) { + if (section == DNS_SECTION_QUESTION) { + dns_name_format(name, namebuf, + sizeof(namebuf)); + printf("\t%s, ", namebuf); + dns_rdatatype_format(rdataset->type, + namebuf, + sizeof(namebuf)); + printf("type = %s, ", namebuf); + dns_rdataclass_format(rdataset->rdclass, + namebuf, + sizeof(namebuf)); + printf("class = %s\n", namebuf); + } + loopresult = dns_rdataset_first(rdataset); + while (loopresult == ISC_R_SUCCESS) { + dns_rdataset_current(rdataset, &rdata); + + dns_name_format(name, namebuf, + sizeof(namebuf)); + printf(" -> %s\n", namebuf); + + switch (rdata.type) { + case dns_rdatatype_soa: + printsoa(&rdata); + break; + default: + printf("\t"); + printrdata(&rdata); + } + dns_rdata_reset(&rdata); + loopresult = dns_rdataset_next(rdataset); + } + } + result = dns_message_nextname(msg, section); + if (result == ISC_R_NOMORE) + break; + else if (result != ISC_R_SUCCESS) { + return (result); + } + } + return (ISC_R_SUCCESS); +} + +void +received(int bytes, isc_sockaddr_t *from, dig_query_t *query) +{ + UNUSED(bytes); + UNUSED(from); + UNUSED(query); +} + +void +trying(char *frm, dig_lookup_t *lookup) { + UNUSED(frm); + UNUSED(lookup); + +} + +isc_result_t +printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { + char servtext[ISC_SOCKADDR_FORMATSIZE]; + + debug("printmessage()"); + + isc_sockaddr_format(&query->sockaddr, servtext, sizeof(servtext)); + printf("Server:\t\t%s\n", query->servname); + printf("Address:\t%s\n", servtext); + + puts(""); + + if (!short_form) { + isc_boolean_t headers = ISC_TRUE; + puts("------------"); + /* detailheader(query, msg);*/ + detailsection(query, msg, headers, DNS_SECTION_QUESTION); + detailsection(query, msg, headers, DNS_SECTION_ANSWER); + detailsection(query, msg, headers, DNS_SECTION_AUTHORITY); + detailsection(query, msg, headers, DNS_SECTION_ADDITIONAL); + puts("------------"); + } + + if (msg->rcode != 0) { + char nametext[DNS_NAME_FORMATSIZE]; + dns_name_format(query->lookup->name, + nametext, sizeof(nametext)); + printf("** server can't find %s: %s\n", nametext, + rcodetext[msg->rcode]); + debug("returning with rcode == 0"); + return (ISC_R_SUCCESS); + } + + if ((msg->flags & DNS_MESSAGEFLAG_AA) == 0) + puts("Non-authoritative answer:"); + if (!ISC_LIST_EMPTY(msg->sections[DNS_SECTION_ANSWER])) + printsection(query, msg, headers, DNS_SECTION_ANSWER); + else + printf("*** Can't find %s: No answer\n", + query->lookup->textname); + + if (((msg->flags & DNS_MESSAGEFLAG_AA) == 0) && + (query->lookup->rdtype != dns_rdatatype_a)) { + puts("\nAuthoritative answers can be found from:"); + printsection(query, msg, headers, + DNS_SECTION_AUTHORITY); + printsection(query, msg, headers, + DNS_SECTION_ADDITIONAL); + } + return (ISC_R_SUCCESS); +} + +static void +show_settings(isc_boolean_t full, isc_boolean_t serv_only) { + dig_server_t *srv; + isc_sockaddr_t sockaddr; + dig_searchlist_t *listent; + + srv = ISC_LIST_HEAD(server_list); + + while (srv != NULL) { + char sockstr[ISC_SOCKADDR_FORMATSIZE]; + + get_address(srv->servername, port, &sockaddr); + isc_sockaddr_format(&sockaddr, sockstr, sizeof(sockstr)); + printf("Default server: %s\nAddress: %s\n", + srv->servername, sockstr); + if (!full) + return; + srv = ISC_LIST_NEXT(srv, link); + } + if (serv_only) + return; + printf("\nSet options:\n"); + printf(" %s\t\t\t%s\t\t%s\n", + tcpmode ? "vc" : "novc", + short_form ? "nodebug" : "debug", + debugging ? "d2" : "nod2"); + printf(" %s\t\t%s\n", + usesearch ? "search" : "nosearch", + recurse ? "recurse" : "norecurse"); + printf(" timeout = %d\t\tretry = %d\tport = %d\n", + timeout, tries, port); + printf(" querytype = %-8s\tclass = %s\n", deftype, defclass); + printf(" srchlist = "); + for (listent = ISC_LIST_HEAD(search_list); + listent != NULL; + listent = ISC_LIST_NEXT(listent, link)) { + printf("%s", listent->origin); + if (ISC_LIST_NEXT(listent, link) != NULL) + printf("/"); + } + printf("\n"); +} + +static isc_boolean_t +testtype(char *typetext) { + isc_result_t result; + isc_textregion_t tr; + dns_rdatatype_t rdtype; + + tr.base = typetext; + tr.length = strlen(typetext); + result = dns_rdatatype_fromtext(&rdtype, &tr); + if (result == ISC_R_SUCCESS) + return (ISC_TRUE); + else { + printf("unknown query type: %s\n", typetext); + return (ISC_FALSE); + } +} + +static isc_boolean_t +testclass(char *typetext) { + isc_result_t result; + isc_textregion_t tr; + dns_rdataclass_t rdclass; + + tr.base = typetext; + tr.length = strlen(typetext); + result = dns_rdataclass_fromtext(&rdclass, &tr); + if (result == ISC_R_SUCCESS) + return (ISC_TRUE); + else { + printf("unknown query class: %s\n", typetext); + return (ISC_FALSE); + } +} + +static void +safecpy(char *dest, char *src, int size) { + strncpy(dest, src, size); + dest[size-1] = 0; +} + +static isc_result_t +parse_uint(isc_uint32_t *uip, const char *value, isc_uint32_t max, + const char *desc) { + isc_uint32_t n; + isc_result_t result = isc_parse_uint32(&n, value, 10); + if (result == ISC_R_SUCCESS && n > max) + result = ISC_R_RANGE; + if (result != ISC_R_SUCCESS) { + printf("invalid %s '%s': %s\n", desc, + value, isc_result_totext(result)); + return result; + } + *uip = n; + return (ISC_R_SUCCESS); +} + +static void +set_port(const char *value) { + isc_uint32_t n; + isc_result_t result = parse_uint(&n, value, 65535, "port"); + if (result == ISC_R_SUCCESS) + port = (isc_uint16_t) n; +} + +static void +set_timeout(const char *value) { + isc_uint32_t n; + isc_result_t result = parse_uint(&n, value, UINT_MAX, "timeout"); + if (result == ISC_R_SUCCESS) + timeout = n; +} + +static void +set_tries(const char *value) { + isc_uint32_t n; + isc_result_t result = parse_uint(&n, value, INT_MAX, "tries"); + if (result == ISC_R_SUCCESS) + tries = n; +} + +static void +setoption(char *opt) { + if (strncasecmp(opt, "all", 4) == 0) { + show_settings(ISC_TRUE, ISC_FALSE); + } else if (strncasecmp(opt, "class=", 6) == 0) { + if (testclass(&opt[6])) + safecpy(defclass, &opt[6], sizeof(defclass)); + } else if (strncasecmp(opt, "cl=", 3) == 0) { + if (testclass(&opt[3])) + safecpy(defclass, &opt[3], sizeof(defclass)); + } else if (strncasecmp(opt, "type=", 5) == 0) { + if (testtype(&opt[5])) + safecpy(deftype, &opt[5], sizeof(deftype)); + } else if (strncasecmp(opt, "ty=", 3) == 0) { + if (testtype(&opt[3])) + safecpy(deftype, &opt[3], sizeof(deftype)); + } else if (strncasecmp(opt, "querytype=", 10) == 0) { + if (testtype(&opt[10])) + safecpy(deftype, &opt[10], sizeof(deftype)); + } else if (strncasecmp(opt, "query=", 6) == 0) { + if (testtype(&opt[6])) + safecpy(deftype, &opt[6], sizeof(deftype)); + } else if (strncasecmp(opt, "qu=", 3) == 0) { + if (testtype(&opt[3])) + safecpy(deftype, &opt[3], sizeof(deftype)); + } else if (strncasecmp(opt, "q=", 2) == 0) { + if (testtype(&opt[2])) + safecpy(deftype, &opt[2], sizeof(deftype)); + } else if (strncasecmp(opt, "domain=", 7) == 0) { + safecpy(domainopt, &opt[7], sizeof(domainopt)); + set_search_domain(domainopt); + usesearch = ISC_TRUE; + } else if (strncasecmp(opt, "do=", 3) == 0) { + safecpy(domainopt, &opt[3], sizeof(domainopt)); + set_search_domain(domainopt); + usesearch = ISC_TRUE; + } else if (strncasecmp(opt, "port=", 5) == 0) { + set_port(&opt[5]); + } else if (strncasecmp(opt, "po=", 3) == 0) { + set_port(&opt[3]); + } else if (strncasecmp(opt, "timeout=", 8) == 0) { + set_timeout(&opt[8]); + } else if (strncasecmp(opt, "t=", 2) == 0) { + set_timeout(&opt[2]); + } else if (strncasecmp(opt, "rec", 3) == 0) { + recurse = ISC_TRUE; + } else if (strncasecmp(opt, "norec", 5) == 0) { + recurse = ISC_FALSE; + } else if (strncasecmp(opt, "retry=", 6) == 0) { + set_tries(&opt[6]); + } else if (strncasecmp(opt, "ret=", 4) == 0) { + set_tries(&opt[4]); + } else if (strncasecmp(opt, "def", 3) == 0) { + usesearch = ISC_TRUE; + } else if (strncasecmp(opt, "nodef", 5) == 0) { + usesearch = ISC_FALSE; + } else if (strncasecmp(opt, "vc", 3) == 0) { + tcpmode = ISC_TRUE; + } else if (strncasecmp(opt, "novc", 5) == 0) { + tcpmode = ISC_FALSE; + } else if (strncasecmp(opt, "deb", 3) == 0) { + short_form = ISC_FALSE; + } else if (strncasecmp(opt, "nodeb", 5) == 0) { + short_form = ISC_TRUE; + } else if (strncasecmp(opt, "d2", 2) == 0) { + debugging = ISC_TRUE; + } else if (strncasecmp(opt, "nod2", 4) == 0) { + debugging = ISC_FALSE; + } else if (strncasecmp(opt, "search", 3) == 0) { + usesearch = ISC_TRUE; + } else if (strncasecmp(opt, "nosearch", 5) == 0) { + usesearch = ISC_FALSE; + } else if (strncasecmp(opt, "sil", 3) == 0) { + /* deprecation_msg = ISC_FALSE; */ + } else { + printf("*** Invalid option: %s\n", opt); + } +} + +static void +addlookup(char *opt) { + dig_lookup_t *lookup; + isc_result_t result; + isc_textregion_t tr; + dns_rdatatype_t rdtype; + dns_rdataclass_t rdclass; + char store[MXNAME]; + + debug("addlookup()"); + tr.base = deftype; + tr.length = strlen(deftype); + result = dns_rdatatype_fromtext(&rdtype, &tr); + if (result != ISC_R_SUCCESS) { + printf("unknown query type: %s\n", deftype); + rdclass = dns_rdatatype_a; + } + tr.base = defclass; + tr.length = strlen(defclass); + result = dns_rdataclass_fromtext(&rdclass, &tr); + if (result != ISC_R_SUCCESS) { + printf("unknown query class: %s\n", defclass); + rdclass = dns_rdataclass_in; + } + lookup = make_empty_lookup(); + if (get_reverse(store, sizeof(store), opt, lookup->ip6_int, ISC_TRUE) + == ISC_R_SUCCESS) { + safecpy(lookup->textname, store, sizeof(lookup->textname)); + lookup->rdtype = dns_rdatatype_ptr; + lookup->rdtypeset = ISC_TRUE; + } else { + safecpy(lookup->textname, opt, sizeof(lookup->textname)); + lookup->rdtype = rdtype; + lookup->rdtypeset = ISC_TRUE; + } + lookup->rdclass = rdclass; + lookup->rdclassset = ISC_TRUE; + lookup->trace = ISC_FALSE; + lookup->trace_root = lookup->trace; + lookup->ns_search_only = ISC_FALSE; + lookup->identify = identify; + lookup->recurse = recurse; + lookup->aaonly = aaonly; + lookup->retries = tries; + lookup->udpsize = 0; + lookup->comments = comments; + lookup->tcp_mode = tcpmode; + lookup->stats = stats; + lookup->section_question = section_question; + lookup->section_answer = section_answer; + lookup->section_authority = section_authority; + lookup->section_additional = section_additional; + lookup->new_search = ISC_TRUE; + ISC_LIST_INIT(lookup->q); + ISC_LINK_INIT(lookup, link); + ISC_LIST_APPEND(lookup_list, lookup, link); + lookup->origin = NULL; + ISC_LIST_INIT(lookup->my_server_list); + debug("looking up %s", lookup->textname); +} + +static void +get_next_command(void) { + char *buf; + char *ptr, *arg; + char *input; + + fflush(stdout); + buf = isc_mem_allocate(mctx, COMMSIZE); + if (buf == NULL) + fatal("memory allocation failure"); + fputs("> ", stderr); + isc_app_block(); + ptr = fgets(buf, COMMSIZE, stdin); + isc_app_unblock(); + if (ptr == NULL) { + in_use = ISC_FALSE; + goto cleanup; + } + input = buf; + ptr = next_token(&input, " \t\r\n"); + if (ptr == NULL) + goto cleanup; + arg = next_token(&input, " \t\r\n"); + if ((strcasecmp(ptr, "set") == 0) && + (arg != NULL)) + setoption(arg); + else if ((strcasecmp(ptr, "server") == 0) || + (strcasecmp(ptr, "lserver") == 0)) { + set_nameserver(arg); + show_settings(ISC_TRUE, ISC_TRUE); + } else if (strcasecmp(ptr, "exit") == 0) { + in_use = ISC_FALSE; + goto cleanup; + } else if (strcasecmp(ptr, "help") == 0 || + strcasecmp(ptr, "?") == 0) { + printf("The '%s' command is not yet implemented.\n", ptr); + goto cleanup; + } else if (strcasecmp(ptr, "finger") == 0 || + strcasecmp(ptr, "root") == 0 || + strcasecmp(ptr, "ls") == 0 || + strcasecmp(ptr, "view") == 0) { + printf("The '%s' command is not implemented.\n", ptr); + goto cleanup; + } else + addlookup(ptr); + cleanup: + isc_mem_free(mctx, buf); +} + +static void +parse_args(int argc, char **argv) { + isc_boolean_t have_lookup = ISC_FALSE; + + usesearch = ISC_TRUE; + for (argc--, argv++; argc > 0; argc--, argv++) { + debug("main parsing %s", argv[0]); + if (argv[0][0] == '-') { + if (argv[0][1] != 0) + setoption(&argv[0][1]); + else + have_lookup = ISC_TRUE; + } else { + if (!have_lookup) { + have_lookup = ISC_TRUE; + in_use = ISC_TRUE; + addlookup(argv[0]); + } + else + set_nameserver(argv[0]); + } + } +} + +static void +flush_lookup_list(void) { + dig_lookup_t *l, *lp; + dig_query_t *q, *qp; + dig_server_t *s, *sp; + + lookup_counter = 0; + l = ISC_LIST_HEAD(lookup_list); + while (l != NULL) { + q = ISC_LIST_HEAD(l->q); + while (q != NULL) { + if (q->sock != NULL) { + isc_socket_cancel(q->sock, NULL, + ISC_SOCKCANCEL_ALL); + isc_socket_detach(&q->sock); + } + if (ISC_LINK_LINKED(&q->recvbuf, link)) + ISC_LIST_DEQUEUE(q->recvlist, &q->recvbuf, + link); + if (ISC_LINK_LINKED(&q->lengthbuf, link)) + ISC_LIST_DEQUEUE(q->lengthlist, &q->lengthbuf, + link); + isc_buffer_invalidate(&q->recvbuf); + isc_buffer_invalidate(&q->lengthbuf); + qp = q; + q = ISC_LIST_NEXT(q, link); + ISC_LIST_DEQUEUE(l->q, qp, link); + isc_mem_free(mctx, qp); + } + s = ISC_LIST_HEAD(l->my_server_list); + while (s != NULL) { + sp = s; + s = ISC_LIST_NEXT(s, link); + ISC_LIST_DEQUEUE(l->my_server_list, sp, link); + isc_mem_free(mctx, sp); + + } + if (l->sendmsg != NULL) + dns_message_destroy(&l->sendmsg); + if (l->timer != NULL) + isc_timer_detach(&l->timer); + lp = l; + l = ISC_LIST_NEXT(l, link); + ISC_LIST_DEQUEUE(lookup_list, lp, link); + isc_mem_free(mctx, lp); + } +} + +static void +getinput(isc_task_t *task, isc_event_t *event) { + UNUSED(task); + if (global_event == NULL) + global_event = event; + while (in_use) { + get_next_command(); + if (ISC_LIST_HEAD(lookup_list) != NULL) { + start_lookup(); + return; + } + } + isc_app_shutdown(); +} + +int +main(int argc, char **argv) { + isc_result_t result; + + ISC_LIST_INIT(lookup_list); + ISC_LIST_INIT(server_list); + ISC_LIST_INIT(search_list); + + result = isc_app_start(); + check_result(result, "isc_app_start"); + + setup_libs(); + progname = argv[0]; + + parse_args(argc, argv); + + setup_system(); + if (domainopt[0] != '\0') + set_search_domain(domainopt); + if (in_use) + result = isc_app_onrun(mctx, global_task, onrun_callback, + NULL); + else + result = isc_app_onrun(mctx, global_task, getinput, NULL); + check_result(result, "isc_app_onrun"); + in_use = ISC_TF(!in_use); + + (void)isc_app_run(); + + puts(""); + debug("done, and starting to shut down"); + if (global_event != NULL) + isc_event_free(&global_event); + cancel_all(); + destroy_libs(); + isc_app_finish(); + + return (0); +} diff --git a/contrib/bind9/bin/dig/nslookup.docbook b/contrib/bind9/bin/dig/nslookup.docbook new file mode 100644 index 000000000000..134e5b32ec41 --- /dev/null +++ b/contrib/bind9/bin/dig/nslookup.docbook @@ -0,0 +1,320 @@ + + + + + + + + + + +Jun 30, 2000 + + + +nslookup +1 +BIND9 + + + +nslookup +query Internet name servers interactively + + + + + nslookup + + name | - + server + + + + +DESCRIPTION + +Nslookup +is a program to query Internet domain name servers. Nslookup +has two modes: interactive and non-interactive. Interactive mode allows +the user to query name servers for information about various hosts and +domains or to print a list of hosts in a domain. Non-interactive mode is +used to print just the name and requested information for a host or +domain. + + + + +ARGUMENTS + +Interactive mode is entered in the following cases: + + + +when no arguments are given (the default name server will be used) + + + + +when the first argument is a hyphen (-) and the second argument is +the host name or Internet address of a name server. + + + + + + +Non-interactive mode is used when the name or Internet address of the +host to be looked up is given as the first argument. The optional second +argument specifies the host name or address of a name server. + + + +Options can also be specified on the command line if they precede the +arguments and are prefixed with a hyphen. For example, to +change the default query type to host information, and the initial timeout to 10 seconds, type: + + +nslookup -query=hinfo -timeout=10 + + + + + + + +INTERACTIVE COMMANDS + +host server + +Look up information for host using the current default server or +using server, if specified. If host is an Internet address and +the query type is A or PTR, the name of the host is returned. +If host is a name and does not have a trailing period, the +search list is used to qualify the name. + + + +To look up a host not in the current domain, append a period to +the name. + + +server domain + +lserver domain + +Change the default server to domain; lserver uses the initial +server to look up information about domain, while server uses +the current default server. If an authoritative answer can't be +found, the names of servers that might have the answer are +returned. + + +root +not implemented + +finger +not implemented + +ls +not implemented + +view +not implemented + +help +not implemented + +? +not implemented + +exit +Exits the program. + +set keyword=value +This command is used to change state information that affects +the lookups. Valid keywords are: + + all + + Prints the current values of the frequently used + options to set. Information about the current default + server and host is also printed. + + + + + class=value + + Change the query class to one of: + + IN + the Internet class + CH + the Chaos class + HS + the Hesiod class + ANY + wildcard + + The class specifies the protocol group of the information. + + (Default = IN; abbreviation = cl) + + + + nodebug + + Turn debugging mode on. A lot more information is + printed about the packet sent to the server and the + resulting answer. + + (Default = nodebug; abbreviation = nodeb) + + + nod2 + + Turn debugging mode on. A lot more information is + printed about the packet sent to the server and the + resulting answer. + + (Default = nod2) + + + domain=name + + Sets the search list to name. + + + nosearch + + If the lookup request contains at least one period but + doesn't end with a trailing period, append the domain + names in the domain search list to the request until an + answer is received. + + (Default = search) + + + port=value + + Change the default TCP/UDP name server port to value. + + (Default = 53; abbreviation = po) + + + querytype=value + + + type=value + + Change the top of the information query. + + (Default = A; abbreviations = q, ty) + + + norecurse + + Tell the name server to query other servers if it does not have the + information. + + (Default = recurse; abbreviation = [no]rec) + + + retry=number + + Set the number of retries to number. + + + timeout=number + + Change the initial timeout interval for waiting for a + reply to number seconds. + + + novc + + Always use a virtual circuit when sending requests to the server. + + (Default = novc) + + + + + + + + +FILES + +/etc/resolv.conf + + + + +SEE ALSO + + +dig1 +, + +host1 +, + +named8 +. + + + + +Author + +Andrew Cherenson + + + diff --git a/contrib/bind9/bin/dig/nslookup.html b/contrib/bind9/bin/dig/nslookup.html new file mode 100644 index 000000000000..e353377e8f03 --- /dev/null +++ b/contrib/bind9/bin/dig/nslookup.html @@ -0,0 +1,617 @@ + + + + + +nslookup

nslookup

Name

nslookup -- query Internet name servers interactively

Synopsis

nslookup [-option] [name | -] [server]

DESCRIPTION

Nslookup +is a program to query Internet domain name servers. Nslookup +has two modes: interactive and non-interactive. Interactive mode allows +the user to query name servers for information about various hosts and +domains or to print a list of hosts in a domain. Non-interactive mode is +used to print just the name and requested information for a host or +domain.

ARGUMENTS

Interactive mode is entered in the following cases: +

  1. when no arguments are given (the default name server will be used)

  2. when the first argument is a hyphen (-) and the second argument is +the host name or Internet address of a name server.

Non-interactive mode is used when the name or Internet address of the +host to be looked up is given as the first argument. The optional second +argument specifies the host name or address of a name server.

Options can also be specified on the command line if they precede the +arguments and are prefixed with a hyphen. For example, to +change the default query type to host information, and the initial timeout to 10 seconds, type: +

nslookup -query=hinfo  -timeout=10

INTERACTIVE COMMANDS

host [server]

Look up information for host using the current default server or +using server, if specified. If host is an Internet address and +the query type is A or PTR, the name of the host is returned. +If host is a name and does not have a trailing period, the +search list is used to qualify the name.

To look up a host not in the current domain, append a period to +the name.

server domain

lserver domain

Change the default server to domain; lserver uses the initial +server to look up information about domain, while server uses +the current default server. If an authoritative answer can't be +found, the names of servers that might have the answer are +returned.

root

not implemented

finger

not implemented

ls

not implemented

view

not implemented

help

not implemented

?

not implemented

exit

Exits the program.

set keyword[=value]

This command is used to change state information that affects +the lookups. Valid keywords are: +

all

Prints the current values of the frequently used + options to set. Information about the current default + server and host is also printed. +

class=value

Change the query class to one of: +

IN

the Internet class

CH

the Chaos class

HS

the Hesiod class

ANY

wildcard

+ The class specifies the protocol group of the information. +

(Default = IN; abbreviation = cl) +

[no]debug

Turn debugging mode on. A lot more information is + printed about the packet sent to the server and the + resulting answer. +

(Default = nodebug; abbreviation = [no]deb) +

[no]d2

Turn debugging mode on. A lot more information is + printed about the packet sent to the server and the + resulting answer. +

(Default = nod2) +

domain=name

Sets the search list to name. +

[no]search

If the lookup request contains at least one period but + doesn't end with a trailing period, append the domain + names in the domain search list to the request until an + answer is received. +

(Default = search) +

port=value

Change the default TCP/UDP name server port to value. +

(Default = 53; abbreviation = po) +

querytype=value

type=value

Change the top of the information query. +

(Default = A; abbreviations = q, ty) +

[no]recurse

Tell the name server to query other servers if it does not have the + information. +

(Default = recurse; abbreviation = [no]rec) +

retry=number

Set the number of retries to number. +

timeout=number

Change the initial timeout interval for waiting for a + reply to number seconds. +

[no]vc

Always use a virtual circuit when sending requests to the server. +

(Default = novc) +

FILES

/etc/resolv.conf

SEE ALSO

dig(1), +host(1), +named(8).

Author

Andrew Cherenson

diff --git a/contrib/bind9/bin/dnssec/Makefile.in b/contrib/bind9/bin/dnssec/Makefile.in new file mode 100644 index 000000000000..993c54e4067f --- /dev/null +++ b/contrib/bind9/bin/dnssec/Makefile.in @@ -0,0 +1,82 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000-2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.19.12.9 2004/07/20 07:01:48 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_VERSION@ + +@BIND9_MAKE_INCLUDES@ + +CINCLUDES = ${DNS_INCLUDES} ${ISC_INCLUDES} + +CDEFINES = -DVERSION=\"${VERSION}\" +CWARNINGS = + +DNSLIBS = ../../lib/dns/libdns.@A@ @DNS_CRYPTO_LIBS@ +ISCLIBS = ../../lib/isc/libisc.@A@ + +DNSDEPLIBS = ../../lib/dns/libdns.@A@ +ISCDEPLIBS = ../../lib/isc/libisc.@A@ + +DEPLIBS = ${DNSDEPLIBS} ${ISCDEPLIBS} + +LIBS = ${DNSLIBS} ${ISCLIBS} @LIBS@ + +# Alphabetically +TARGETS = dnssec-keygen@EXEEXT@ dnssec-signzone@EXEEXT@ + +OBJS = dnssectool.@O@ + +SRCS = dnssec-keygen.c dnssec-signzone.c dnssectool.c + +MANPAGES = dnssec-keygen.8 dnssec-signzone.8 + +HTMLPAGES = dnssec-keygen.html dnssec-signzone.html + +MANOBJS = ${MANPAGES} ${HTMLPAGES} + +@BIND9_MAKE_RULES@ + +dnssec-keygen@EXEEXT@: dnssec-keygen.@O@ ${OBJS} ${DEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ + dnssec-keygen.@O@ ${OBJS} ${LIBS} + +dnssec-signzone.@O@: dnssec-signzone.c + ${LIBTOOL_MODE_COMPILE} ${PURIFY} ${CC} ${ALL_CFLAGS} -c $< + +dnssec-signzone@EXEEXT@: dnssec-signzone.@O@ ${OBJS} ${DEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ + dnssec-signzone.@O@ ${OBJS} ${LIBS} + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f ${MANOBJS} + +installdirs: + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${sbindir} + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man8 + +install:: ${TARGETS} installdirs + for t in ${TARGETS}; do ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} $$t ${DESTDIR}${sbindir}; done + for m in ${MANPAGES}; do ${INSTALL_DATA} ${srcdir}/$$m ${DESTDIR}${mandir}/man8; done + +clean distclean:: + rm -f ${TARGETS} + diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.8 b/contrib/bind9/bin/dnssec/dnssec-keygen.8 new file mode 100644 index 000000000000..235c26ea32f9 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-keygen.8 @@ -0,0 +1,174 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2003 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: dnssec-keygen.8,v 1.19.12.5 2004/06/11 02:32:45 marka Exp $ +.\" +.TH "DNSSEC-KEYGEN" "8" "June 30, 2000" "BIND9" "" +.SH NAME +dnssec-keygen \- DNSSEC key generation tool +.SH SYNOPSIS +.sp +\fBdnssec-keygen\fR \fB-a \fIalgorithm\fB\fR \fB-b \fIkeysize\fB\fR \fB-n \fInametype\fB\fR [ \fB-c \fIclass\fB\fR ] [ \fB-e\fR ] [ \fB-f \fIflag\fB\fR ] [ \fB-g \fIgenerator\fB\fR ] [ \fB-h\fR ] [ \fB-k\fR ] [ \fB-p \fIprotocol\fB\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstrength\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-v \fIlevel\fB\fR ] \fBname\fR +.SH "DESCRIPTION" +.PP +\fBdnssec-keygen\fR generates keys for DNSSEC +(Secure DNS), as defined in RFC 2535 and RFC . It can also generate +keys for use with TSIG (Transaction Signatures), as +defined in RFC 2845. +.SH "OPTIONS" +.TP +\fB-a \fIalgorithm\fB\fR +Selects the cryptographic algorithm. The value of +\fBalgorithm\fR must be one of RSAMD5 (RSA) or RSASHA1, +DSA, DH (Diffie Hellman), or HMAC-MD5. These values +are case insensitive. + +Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, +and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. + +Note 2: HMAC-MD5 and DH automatically set the -k flag. +.TP +\fB-b \fIkeysize\fB\fR +Specifies the number of bits in the key. The choice of key +size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between +512 and 2048 bits. Diffie Hellman keys must be between +128 and 4096 bits. DSA keys must be between 512 and 1024 +bits and an exact multiple of 64. HMAC-MD5 keys must be +between 1 and 512 bits. +.TP +\fB-n \fInametype\fB\fR +Specifies the owner type of the key. The value of +\fBnametype\fR must either be ZONE (for a DNSSEC +zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), +USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are +case insensitive. +.TP +\fB-c \fIclass\fB\fR +Indicates that the DNS record containing the key should have +the specified class. If not specified, class IN is used. +.TP +\fB-e\fR +If generating an RSAMD5/RSASHA1 key, use a large exponent. +.TP +\fB-f \fIflag\fB\fR +Set the specified flag in the flag field of the KEY/DNSKEY record. +The only recognized flag is KSK (Key Signing Key) DNSKEY. +.TP +\fB-g \fIgenerator\fB\fR +If generating a Diffie Hellman key, use this generator. +Allowed values are 2 and 5. If no generator +is specified, a known prime from RFC 2539 will be used +if possible; otherwise the default is 2. +.TP +\fB-h\fR +Prints a short summary of the options and arguments to +\fBdnssec-keygen\fR. +.TP +\fB-k\fR +Generate KEY records rather than DNSKEY records. +.TP +\fB-p \fIprotocol\fB\fR +Sets the protocol value for the generated key. The protocol +is a number between 0 and 255. The default is 3 (DNSSEC). +Other possible values for this argument are listed in +RFC 2535 and its successors. +.TP +\fB-r \fIrandomdev\fB\fR +Specifies the source of randomness. If the operating +system does not provide a \fI/dev/random\fR +or equivalent device, the default source of randomness +is keyboard input. \fIrandomdev\fR specifies +the name of a character device or file containing random +data to be used instead of the default. The special value +\fIkeyboard\fR indicates that keyboard +input should be used. +.TP +\fB-s \fIstrength\fB\fR +Specifies the strength value of the key. The strength is +a number between 0 and 15, and currently has no defined +purpose in DNSSEC. +.TP +\fB-t \fItype\fB\fR +Indicates the use of the key. \fBtype\fR must be +one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default +is AUTHCONF. AUTH refers to the ability to authenticate +data, and CONF the ability to encrypt data. +.TP +\fB-v \fIlevel\fB\fR +Sets the debugging level. +.SH "GENERATED KEYS" +.PP +When \fBdnssec-keygen\fR completes successfully, +it prints a string of the form \fIKnnnn.+aaa+iiiii\fR +to the standard output. This is an identification string for +the key it has generated. These strings can be used as arguments +to \fBdnssec-makekeyset\fR. +.TP 0.2i +\(bu +\fInnnn\fR is the key name. +.TP 0.2i +\(bu +\fIaaa\fR is the numeric representation of the +algorithm. +.TP 0.2i +\(bu +\fIiiiii\fR is the key identifier (or footprint). +.PP +\fBdnssec-keygen\fR creates two file, with names based +on the printed string. \fIKnnnn.+aaa+iiiii.key\fR +contains the public key, and +\fIKnnnn.+aaa+iiiii.private\fR contains the private +key. +.PP +.PP +The \fI.key\fR file contains a DNS KEY record that +can be inserted into a zone file (directly or with a $INCLUDE +statement). +.PP +.PP +The \fI.private\fR file contains algorithm specific +fields. For obvious security reasons, this file does not have +general read permission. +.PP +.PP +Both \fI.key\fR and \fI.private\fR +files are generated for symmetric encryption algorithm such as +HMAC-MD5, even though the public and private key are equivalent. +.PP +.SH "EXAMPLE" +.PP +To generate a 768-bit DSA key for the domain +\fBexample.com\fR, the following command would be +issued: +.PP +\fBdnssec-keygen -a DSA -b 768 -n ZONE example.com\fR +.PP +The command would print a string of the form: +.PP +\fBKexample.com.+003+26160\fR +.PP +In this example, \fBdnssec-keygen\fR creates +the files \fIKexample.com.+003+26160.key\fR and +\fIKexample.com.+003+26160.private\fR +.SH "SEE ALSO" +.PP +\fBdnssec-signzone\fR(8), +\fIBIND 9 Administrator Reference Manual\fR, +\fIRFC 2535\fR, +\fIRFC 2845\fR, +\fIRFC 2539\fR. +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.c b/contrib/bind9/bin/dnssec/dnssec-keygen.c new file mode 100644 index 000000000000..7feaf7c3d977 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-keygen.c @@ -0,0 +1,415 @@ +/* + * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Portions Copyright (C) 2000-2003 Internet Software Consortium. + * Portions Copyright (C) 1995-2000 by Network Associates, Inc. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC AND NETWORK ASSOCIATES DISCLAIMS + * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE + * FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR + * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dnssec-keygen.c,v 1.48.2.1.10.11 2004/06/11 01:17:34 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "dnssectool.h" + +#define MAX_RSA 4096 /* should be long enough... */ + +const char *program = "dnssec-keygen"; +int verbose; + +static const char *algs = "RSA | RSAMD5 | DH | DSA | RSASHA1 | HMAC-MD5"; + +static isc_boolean_t +dsa_size_ok(int size) { + return (ISC_TF(size >= 512 && size <= 1024 && size % 64 == 0)); +} + +static void +usage(void) { + fprintf(stderr, "Usage:\n"); + fprintf(stderr, " %s -a alg -b bits -n type [options] name\n\n", + program); + fprintf(stderr, "Version: %s\n", VERSION); + fprintf(stderr, "Required options:\n"); + fprintf(stderr, " -a algorithm: %s\n", algs); + fprintf(stderr, " -b key size, in bits:\n"); + fprintf(stderr, " RSAMD5:\t\t[512..%d]\n", MAX_RSA); + fprintf(stderr, " RSASHA1:\t\t[512..%d]\n", MAX_RSA); + fprintf(stderr, " DH:\t\t[128..4096]\n"); + fprintf(stderr, " DSA:\t\t[512..1024] and divisible by 64\n"); + fprintf(stderr, " HMAC-MD5:\t[1..512]\n"); + fprintf(stderr, " -n nametype: ZONE | HOST | ENTITY | USER | OTHER\n"); + fprintf(stderr, " name: owner of the key\n"); + fprintf(stderr, "Other options:\n"); + fprintf(stderr, " -c (default: IN)\n"); + fprintf(stderr, " -e use large exponent (RSAMD5/RSASHA1 only)\n"); + fprintf(stderr, " -f keyflag: KSK\n"); + fprintf(stderr, " -g use specified generator " + "(DH only)\n"); + fprintf(stderr, " -t : " + "AUTHCONF | NOAUTHCONF | NOAUTH | NOCONF " + "(default: AUTHCONF)\n"); + fprintf(stderr, " -p : " + "default: 3 [dnssec]\n"); + fprintf(stderr, " -s strength value this key signs DNS " + "records with (default: 0)\n"); + fprintf(stderr, " -r : a file containing random data\n"); + fprintf(stderr, " -v \n"); + fprintf(stderr, " -k : generate a TYPE=KEY key\n"); + fprintf(stderr, "Output:\n"); + fprintf(stderr, " K++.key, " + "K++.private\n"); + + exit (-1); +} + +int +main(int argc, char **argv) { + char *algname = NULL, *nametype = NULL, *type = NULL; + char *classname = NULL; + char *endp; + dst_key_t *key = NULL, *oldkey; + dns_fixedname_t fname; + dns_name_t *name; + isc_uint16_t flags = 0, ksk = 0; + dns_secalg_t alg; + isc_boolean_t conflict = ISC_FALSE, null_key = ISC_FALSE; + isc_mem_t *mctx = NULL; + int ch, rsa_exp = 0, generator = 0, param = 0; + int protocol = -1, size = -1, signatory = 0; + isc_result_t ret; + isc_textregion_t r; + char filename[255]; + isc_buffer_t buf; + isc_log_t *log = NULL; + isc_entropy_t *ectx = NULL; + dns_rdataclass_t rdclass; + int options = DST_TYPE_PRIVATE | DST_TYPE_PUBLIC; + + if (argc == 1) + usage(); + + RUNTIME_CHECK(isc_mem_create(0, 0, &mctx) == ISC_R_SUCCESS); + + dns_result_register(); + + while ((ch = isc_commandline_parse(argc, argv, + "a:b:c:ef:g:kn:t:p:s:r:v:h")) != -1) + { + switch (ch) { + case 'a': + algname = isc_commandline_argument; + break; + case 'b': + size = strtol(isc_commandline_argument, &endp, 10); + if (*endp != '\0' || size < 0) + fatal("-b requires a non-negative number"); + break; + case 'c': + classname = isc_commandline_argument; + break; + case 'e': + rsa_exp = 1; + break; + case 'f': + if (strcasecmp(isc_commandline_argument, "KSK") == 0) + ksk = DNS_KEYFLAG_KSK; + else + fatal("unknown flag '%s'", + isc_commandline_argument); + break; + case 'g': + generator = strtol(isc_commandline_argument, + &endp, 10); + if (*endp != '\0' || generator <= 0) + fatal("-g requires a positive number"); + break; + case 'k': + options |= DST_TYPE_KEY; + break; + case 'n': + nametype = isc_commandline_argument; + break; + case 't': + type = isc_commandline_argument; + break; + case 'p': + protocol = strtol(isc_commandline_argument, &endp, 10); + if (*endp != '\0' || protocol < 0 || protocol > 255) + fatal("-p must be followed by a number " + "[0..255]"); + break; + case 's': + signatory = strtol(isc_commandline_argument, + &endp, 10); + if (*endp != '\0' || signatory < 0 || signatory > 15) + fatal("-s must be followed by a number " + "[0..15]"); + break; + case 'r': + setup_entropy(mctx, isc_commandline_argument, &ectx); + break; + case 'v': + endp = NULL; + verbose = strtol(isc_commandline_argument, &endp, 0); + if (*endp != '\0') + fatal("-v must be followed by a number"); + break; + + case 'h': + usage(); + default: + fprintf(stderr, "%s: invalid argument -%c\n", + program, ch); + usage(); + } + } + + if (ectx == NULL) + setup_entropy(mctx, NULL, &ectx); + ret = dst_lib_init(mctx, ectx, + ISC_ENTROPY_BLOCKING | ISC_ENTROPY_GOODONLY); + if (ret != ISC_R_SUCCESS) + fatal("could not initialize dst"); + + setup_logging(verbose, mctx, &log); + + if (argc < isc_commandline_index + 1) + fatal("the key name was not specified"); + if (argc > isc_commandline_index + 1) + fatal("extraneous arguments"); + + if (algname == NULL) + fatal("no algorithm was specified"); + if (strcasecmp(algname, "HMAC-MD5") == 0) { + options |= DST_TYPE_KEY; + alg = DST_ALG_HMACMD5; + } else { + r.base = algname; + r.length = strlen(algname); + ret = dns_secalg_fromtext(&alg, &r); + if (ret != ISC_R_SUCCESS) + fatal("unknown algorithm %s", algname); + if (alg == DST_ALG_DH) + options |= DST_TYPE_KEY; + } + + if (type != NULL && (options & DST_TYPE_KEY) != 0) { + if (strcasecmp(type, "NOAUTH") == 0) + flags |= DNS_KEYTYPE_NOAUTH; + else if (strcasecmp(type, "NOCONF") == 0) + flags |= DNS_KEYTYPE_NOCONF; + else if (strcasecmp(type, "NOAUTHCONF") == 0) { + flags |= (DNS_KEYTYPE_NOAUTH | DNS_KEYTYPE_NOCONF); + if (size < 0) + size = 0; + } + else if (strcasecmp(type, "AUTHCONF") == 0) + /* nothing */; + else + fatal("invalid type %s", type); + } + + if (size < 0) + fatal("key size not specified (-b option)"); + + switch (alg) { + case DNS_KEYALG_RSAMD5: + case DNS_KEYALG_RSASHA1: + if (size != 0 && (size < 512 || size > MAX_RSA)) + fatal("RSA key size %d out of range", size); + break; + case DNS_KEYALG_DH: + if (size != 0 && (size < 128 || size > 4096)) + fatal("DH key size %d out of range", size); + break; + case DNS_KEYALG_DSA: + if (size != 0 && !dsa_size_ok(size)) + fatal("invalid DSS key size: %d", size); + break; + case DST_ALG_HMACMD5: + if (size < 1 || size > 512) + fatal("HMAC-MD5 key size %d out of range", size); + break; + } + + if (!(alg == DNS_KEYALG_RSAMD5 || alg == DNS_KEYALG_RSASHA1) && + rsa_exp != 0) + fatal("specified RSA exponent for a non-RSA key"); + + if (alg != DNS_KEYALG_DH && generator != 0) + fatal("specified DH generator for a non-DH key"); + + if (nametype == NULL) + fatal("no nametype specified"); + if (strcasecmp(nametype, "zone") == 0) + flags |= DNS_KEYOWNER_ZONE; + else if ((options & DST_TYPE_KEY) != 0) { /* KEY */ + if (strcasecmp(nametype, "host") == 0 || + strcasecmp(nametype, "entity") == 0) + flags |= DNS_KEYOWNER_ENTITY; + else if (strcasecmp(nametype, "user") == 0) + flags |= DNS_KEYOWNER_USER; + else + fatal("invalid KEY nametype %s", nametype); + } else if (strcasecmp(nametype, "other") != 0) /* DNSKEY */ + fatal("invalid DNSKEY nametype %s", nametype); + + rdclass = strtoclass(classname); + + if ((options & DST_TYPE_KEY) != 0) /* KEY */ + flags |= signatory; + else if ((flags & DNS_KEYOWNER_ZONE) != 0) /* DNSKEY */ + flags |= ksk; + + if (protocol == -1) + protocol = DNS_KEYPROTO_DNSSEC; + else if ((options & DST_TYPE_KEY) == 0 && + protocol != DNS_KEYPROTO_DNSSEC) + fatal("invalid DNSKEY protocol: %d", protocol); + + if ((flags & DNS_KEYFLAG_TYPEMASK) == DNS_KEYTYPE_NOKEY) { + if (size > 0) + fatal("specified null key with non-zero size"); + if ((flags & DNS_KEYFLAG_SIGNATORYMASK) != 0) + fatal("specified null key with signing authority"); + } + + if ((flags & DNS_KEYFLAG_OWNERMASK) == DNS_KEYOWNER_ZONE && + (alg == DNS_KEYALG_DH || alg == DST_ALG_HMACMD5)) + fatal("a key with algorithm '%s' cannot be a zone key", + algname); + + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + isc_buffer_init(&buf, argv[isc_commandline_index], + strlen(argv[isc_commandline_index])); + isc_buffer_add(&buf, strlen(argv[isc_commandline_index])); + ret = dns_name_fromtext(name, &buf, dns_rootname, ISC_FALSE, NULL); + if (ret != ISC_R_SUCCESS) + fatal("invalid key name %s: %s", argv[isc_commandline_index], + isc_result_totext(ret)); + + switch(alg) { + case DNS_KEYALG_RSAMD5: + case DNS_KEYALG_RSASHA1: + param = rsa_exp; + break; + case DNS_KEYALG_DH: + param = generator; + break; + case DNS_KEYALG_DSA: + case DST_ALG_HMACMD5: + param = 0; + break; + } + + if ((flags & DNS_KEYFLAG_TYPEMASK) == DNS_KEYTYPE_NOKEY) + null_key = ISC_TRUE; + + isc_buffer_init(&buf, filename, sizeof(filename) - 1); + + do { + conflict = ISC_FALSE; + oldkey = NULL; + + /* generate the key */ + ret = dst_key_generate(name, alg, size, param, flags, protocol, + rdclass, mctx, &key); + isc_entropy_stopcallbacksources(ectx); + + if (ret != ISC_R_SUCCESS) { + char namestr[DNS_NAME_FORMATSIZE]; + char algstr[ALG_FORMATSIZE]; + dns_name_format(name, namestr, sizeof(namestr)); + alg_format(alg, algstr, sizeof(algstr)); + fatal("failed to generate key %s/%s: %s\n", + namestr, algstr, isc_result_totext(ret)); + exit(-1); + } + + /* + * Try to read a key with the same name, alg and id from disk. + * If there is one we must continue generating a new one + * unless we were asked to generate a null key, in which + * case we return failure. + */ + ret = dst_key_fromfile(name, dst_key_id(key), alg, + DST_TYPE_PRIVATE, NULL, mctx, &oldkey); + /* do not overwrite an existing key */ + if (ret == ISC_R_SUCCESS) { + dst_key_free(&oldkey); + conflict = ISC_TRUE; + if (null_key) + break; + } + if (conflict == ISC_TRUE) { + if (verbose > 0) { + isc_buffer_clear(&buf); + ret = dst_key_buildfilename(key, 0, NULL, &buf); + fprintf(stderr, + "%s: %s already exists, " + "generating a new key\n", + program, filename); + } + dst_key_free(&key); + } + + } while (conflict == ISC_TRUE); + + if (conflict) + fatal("cannot generate a null key when a key with id 0 " + "already exists"); + + ret = dst_key_tofile(key, options, NULL); + if (ret != ISC_R_SUCCESS) { + char keystr[KEY_FORMATSIZE]; + key_format(key, keystr, sizeof(keystr)); + fatal("failed to write key %s: %s\n", keystr, + isc_result_totext(ret)); + } + + isc_buffer_clear(&buf); + ret = dst_key_buildfilename(key, 0, NULL, &buf); + printf("%s\n", filename); + dst_key_free(&key); + + cleanup_logging(&log); + cleanup_entropy(&ectx); + dst_lib_destroy(); + if (verbose > 10) + isc_mem_stats(mctx, stdout); + isc_mem_destroy(&mctx); + + return (0); +} diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.docbook b/contrib/bind9/bin/dnssec/dnssec-keygen.docbook new file mode 100644 index 000000000000..a2034d9e8049 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-keygen.docbook @@ -0,0 +1,342 @@ + + + + + + + + June 30, 2000 + + + + dnssec-keygen + 8 + BIND9 + + + + dnssec-keygen + DNSSEC key generation tool + + + + + dnssec-keygen + -a algorithm + -b keysize + -n nametype + + + + + + + + + + + + name + + + + + DESCRIPTION + + dnssec-keygen generates keys for DNSSEC + (Secure DNS), as defined in RFC 2535 and RFC <TBA\>. It can also generate + keys for use with TSIG (Transaction Signatures), as + defined in RFC 2845. + + + + + OPTIONS + + + + -a algorithm + + + Selects the cryptographic algorithm. The value of + must be one of RSAMD5 (RSA) or RSASHA1, + DSA, DH (Diffie Hellman), or HMAC-MD5. These values + are case insensitive. + + + Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, + and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. + + + Note 2: HMAC-MD5 and DH automatically set the -k flag. + + + + + + -b keysize + + + Specifies the number of bits in the key. The choice of key + size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between + 512 and 2048 bits. Diffie Hellman keys must be between + 128 and 4096 bits. DSA keys must be between 512 and 1024 + bits and an exact multiple of 64. HMAC-MD5 keys must be + between 1 and 512 bits. + + + + + + -n nametype + + + Specifies the owner type of the key. The value of + must either be ZONE (for a DNSSEC + zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), + USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are + case insensitive. + + + + + + -c class + + + Indicates that the DNS record containing the key should have + the specified class. If not specified, class IN is used. + + + + + + -e + + + If generating an RSAMD5/RSASHA1 key, use a large exponent. + + + + + + -f flag + + + Set the specified flag in the flag field of the KEY/DNSKEY record. + The only recognized flag is KSK (Key Signing Key) DNSKEY. + + + + + + -g generator + + + If generating a Diffie Hellman key, use this generator. + Allowed values are 2 and 5. If no generator + is specified, a known prime from RFC 2539 will be used + if possible; otherwise the default is 2. + + + + + + -h + + + Prints a short summary of the options and arguments to + dnssec-keygen. + + + + + + -k + + + Generate KEY records rather than DNSKEY records. + + + + + + -p protocol + + + Sets the protocol value for the generated key. The protocol + is a number between 0 and 255. The default is 3 (DNSSEC). + Other possible values for this argument are listed in + RFC 2535 and its successors. + + + + + + -r randomdev + + + Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. + + + + + + -s strength + + + Specifies the strength value of the key. The strength is + a number between 0 and 15, and currently has no defined + purpose in DNSSEC. + + + + + + -t type + + + Indicates the use of the key. must be + one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default + is AUTHCONF. AUTH refers to the ability to authenticate + data, and CONF the ability to encrypt data. + + + + + + -v level + + + Sets the debugging level. + + + + + + + + + GENERATED KEYS + + When dnssec-keygen completes successfully, + it prints a string of the form Knnnn.+aaa+iiiii + to the standard output. This is an identification string for + the key it has generated. These strings can be used as arguments + to dnssec-makekeyset. + + + + + nnnn is the key name. + + + + + aaa is the numeric representation of the + algorithm. + + + + + iiiii is the key identifier (or footprint). + + + + + dnssec-keygen creates two file, with names based + on the printed string. Knnnn.+aaa+iiiii.key + contains the public key, and + Knnnn.+aaa+iiiii.private contains the private + key. + + + The .key file contains a DNS KEY record that + can be inserted into a zone file (directly or with a $INCLUDE + statement). + + + The .private file contains algorithm specific + fields. For obvious security reasons, this file does not have + general read permission. + + + Both .key and .private + files are generated for symmetric encryption algorithm such as + HMAC-MD5, even though the public and private key are equivalent. + + + + + EXAMPLE + + To generate a 768-bit DSA key for the domain + example.com, the following command would be + issued: + + + dnssec-keygen -a DSA -b 768 -n ZONE example.com + + + The command would print a string of the form: + + + Kexample.com.+003+26160 + + + In this example, dnssec-keygen creates + the files Kexample.com.+003+26160.key and + Kexample.com.+003+26160.private + + + + + SEE ALSO + + + dnssec-signzone + 8 + , + BIND 9 Administrator Reference Manual, + RFC 2535, + RFC 2845, + RFC 2539. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.html b/contrib/bind9/bin/dnssec/dnssec-keygen.html new file mode 100644 index 000000000000..734c914ba617 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-keygen.html @@ -0,0 +1,544 @@ + + + + + +dnssec-keygen

dnssec-keygen

Name

dnssec-keygen -- DNSSEC key generation tool

Synopsis

dnssec-keygen {-a algorithm} {-b keysize} {-n nametype} [-c class] [-e] [-f flag] [-g generator] [-h] [-k] [-p protocol] [-r randomdev] [-s strength] [-t type] [-v level] {name}

DESCRIPTION

dnssec-keygen generates keys for DNSSEC + (Secure DNS), as defined in RFC 2535 and RFC <TBA\>. It can also generate + keys for use with TSIG (Transaction Signatures), as + defined in RFC 2845. +

OPTIONS

-a algorithm

Selects the cryptographic algorithm. The value of + algorithm must be one of RSAMD5 (RSA) or RSASHA1, + DSA, DH (Diffie Hellman), or HMAC-MD5. These values + are case insensitive. +

Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, + and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. +

Note 2: HMAC-MD5 and DH automatically set the -k flag. +

-b keysize

Specifies the number of bits in the key. The choice of key + size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between + 512 and 2048 bits. Diffie Hellman keys must be between + 128 and 4096 bits. DSA keys must be between 512 and 1024 + bits and an exact multiple of 64. HMAC-MD5 keys must be + between 1 and 512 bits. +

-n nametype

Specifies the owner type of the key. The value of + nametype must either be ZONE (for a DNSSEC + zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), + USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are + case insensitive. +

-c class

Indicates that the DNS record containing the key should have + the specified class. If not specified, class IN is used. +

-e

If generating an RSAMD5/RSASHA1 key, use a large exponent. +

-f flag

Set the specified flag in the flag field of the KEY/DNSKEY record. + The only recognized flag is KSK (Key Signing Key) DNSKEY. +

-g generator

If generating a Diffie Hellman key, use this generator. + Allowed values are 2 and 5. If no generator + is specified, a known prime from RFC 2539 will be used + if possible; otherwise the default is 2. +

-h

Prints a short summary of the options and arguments to + dnssec-keygen. +

-k

Generate KEY records rather than DNSKEY records. +

-p protocol

Sets the protocol value for the generated key. The protocol + is a number between 0 and 255. The default is 3 (DNSSEC). + Other possible values for this argument are listed in + RFC 2535 and its successors. +

-r randomdev

Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. +

-s strength

Specifies the strength value of the key. The strength is + a number between 0 and 15, and currently has no defined + purpose in DNSSEC. +

-t type

Indicates the use of the key. type must be + one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default + is AUTHCONF. AUTH refers to the ability to authenticate + data, and CONF the ability to encrypt data. +

-v level

Sets the debugging level. +

GENERATED KEYS

When dnssec-keygen completes successfully, + it prints a string of the form Knnnn.+aaa+iiiii + to the standard output. This is an identification string for + the key it has generated. These strings can be used as arguments + to dnssec-makekeyset. +

  • nnnn is the key name. +

  • aaa is the numeric representation of the + algorithm. +

  • iiiii is the key identifier (or footprint). +

dnssec-keygen creates two file, with names based + on the printed string. Knnnn.+aaa+iiiii.key + contains the public key, and + Knnnn.+aaa+iiiii.private contains the private + key. +

The .key file contains a DNS KEY record that + can be inserted into a zone file (directly or with a $INCLUDE + statement). +

The .private file contains algorithm specific + fields. For obvious security reasons, this file does not have + general read permission. +

Both .key and .private + files are generated for symmetric encryption algorithm such as + HMAC-MD5, even though the public and private key are equivalent. +

EXAMPLE

To generate a 768-bit DSA key for the domain + example.com, the following command would be + issued: +

dnssec-keygen -a DSA -b 768 -n ZONE example.com +

The command would print a string of the form: +

Kexample.com.+003+26160 +

In this example, dnssec-keygen creates + the files Kexample.com.+003+26160.key and + Kexample.com.+003+26160.private +

SEE ALSO

dnssec-signzone(8), + BIND 9 Administrator Reference Manual, + RFC 2535, + RFC 2845, + RFC 2539. +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.8 b/contrib/bind9/bin/dnssec/dnssec-makekeyset.8 new file mode 100644 index 000000000000..0189b31e62e5 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-makekeyset.8 @@ -0,0 +1,113 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: dnssec-makekeyset.8,v 1.16.2.2.4.1 2004/03/06 07:41:39 marka Exp $ +.\" +.TH "DNSSEC-MAKEKEYSET" "8" "June 30, 2000" "BIND9" "" +.SH NAME +dnssec-makekeyset \- DNSSEC zone signing tool +.SH SYNOPSIS +.sp +\fBdnssec-makekeyset\fR [ \fB-a\fR ] [ \fB-s \fIstart-time\fB\fR ] [ \fB-e \fIend-time\fB\fR ] [ \fB-h\fR ] [ \fB-p\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-t\fIttl\fB\fR ] [ \fB-v \fIlevel\fB\fR ] \fBkey\fR\fI...\fR +.SH "DESCRIPTION" +.PP +\fBdnssec-makekeyset\fR generates a key set from one +or more keys created by \fBdnssec-keygen\fR. It creates +a file containing a KEY record for each key, and self-signs the key +set with each zone key. The output file is of the form +\fIkeyset-nnnn.\fR, where \fInnnn\fR +is the zone name. +.SH "OPTIONS" +.TP +\fB-a\fR +Verify all generated signatures. +.TP +\fB-s \fIstart-time\fB\fR +Specify the date and time when the generated SIG records +become valid. This can be either an absolute or relative +time. An absolute start time is indicated by a number +in YYYYMMDDHHMMSS notation; 20000530144500 denotes +14:45:00 UTC on May 30th, 2000. A relative start time is +indicated by +N, which is N seconds from the current time. +If no \fBstart-time\fR is specified, the current +time is used. +.TP +\fB-e \fIend-time\fB\fR +Specify the date and time when the generated SIG records +expire. As with \fBstart-time\fR, an absolute +time is indicated in YYYYMMDDHHMMSS notation. A time relative +to the start time is indicated with +N, which is N seconds from +the start time. A time relative to the current time is +indicated with now+N. If no \fBend-time\fR is +specified, 30 days from the start time is used as a default. +.TP +\fB-h\fR +Prints a short summary of the options and arguments to +\fBdnssec-makekeyset\fR. +.TP +\fB-p\fR +Use pseudo-random data when signing the zone. This is faster, +but less secure, than using real random data. This option +may be useful when signing large zones or when the entropy +source is limited. +.TP +\fB-r \fIrandomdev\fB\fR +Specifies the source of randomness. If the operating +system does not provide a \fI/dev/random\fR +or equivalent device, the default source of randomness +is keyboard input. \fIrandomdev\fR specifies +the name of a character device or file containing random +data to be used instead of the default. The special value +\fIkeyboard\fR indicates that keyboard +input should be used. +.TP +\fB-t \fIttl\fB\fR +Specify the TTL (time to live) of the KEY and SIG records. +The default is 3600 seconds. +.TP +\fB-v \fIlevel\fB\fR +Sets the debugging level. +.TP +\fBkey\fR +The list of keys to be included in the keyset file. These keys +are expressed in the form \fIKnnnn.+aaa+iiiii\fR +as generated by \fBdnssec-keygen\fR. +.SH "EXAMPLE" +.PP +The following command generates a keyset containing the DSA key for +\fBexample.com\fR generated in the +\fBdnssec-keygen\fR man page. +.PP +\fBdnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160\fR +.PP +In this example, \fBdnssec-makekeyset\fR creates +the file \fIkeyset-example.com.\fR. This file +contains the specified key and a self-generated signature. +.PP +The DNS administrator for \fBexample.com\fR could +send \fIkeyset-example.com.\fR to the DNS +administrator for \fB.com\fR for signing, if the +\&.com zone is DNSSEC-aware and the administrators of the two zones +have some mechanism for authenticating each other and exchanging +the keys and signatures securely. +.SH "SEE ALSO" +.PP +\fBdnssec-keygen\fR(8), +\fBdnssec-signkey\fR(8), +\fIBIND 9 Administrator Reference Manual\fR, +\fIRFC 2535\fR. +.SH "AUTHOR" +.PP +Internet Software Consortium diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.c b/contrib/bind9/bin/dnssec/dnssec-makekeyset.c new file mode 100644 index 000000000000..c8224ed3888f --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-makekeyset.c @@ -0,0 +1,401 @@ +/* + * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Portions Copyright (C) 2000-2003 Internet Software Consortium. + * Portions Copyright (C) 1995-2000 by Network Associates, Inc. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC AND NETWORK ASSOCIATES DISCLAIMS + * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE + * FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR + * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dnssec-makekeyset.c,v 1.52.2.1.10.7 2004/08/28 06:25:27 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "dnssectool.h" + +const char *program = "dnssec-makekeyset"; +int verbose; + +typedef struct keynode keynode_t; +struct keynode { + dst_key_t *key; + ISC_LINK(keynode_t) link; +}; +typedef ISC_LIST(keynode_t) keylist_t; + +static isc_stdtime_t starttime = 0, endtime = 0, now; +static int ttl = -1; + +static isc_mem_t *mctx = NULL; +static isc_entropy_t *ectx = NULL; + +static keylist_t keylist; + +static void +usage(void) { + fprintf(stderr, "Usage:\n"); + fprintf(stderr, "\t%s [options] keys\n", program); + + fprintf(stderr, "\n"); + + fprintf(stderr, "Version: %s\n", VERSION); + + fprintf(stderr, "Options: (default value in parenthesis) \n"); + fprintf(stderr, "\t-a\n"); + fprintf(stderr, "\t\tverify generated signatures\n"); + fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n"); + fprintf(stderr, "\t\tSIG start time - absolute|offset (now)\n"); + fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n"); + fprintf(stderr, "\t\tSIG end time - " + "absolute|from start|from now (now + 30 days)\n"); + fprintf(stderr, "\t-t ttl\n"); + fprintf(stderr, "\t-p\n"); + fprintf(stderr, "\t\tuse pseudorandom data (faster but less secure)\n"); + fprintf(stderr, "\t-r randomdev:\n"); + fprintf(stderr, "\t\ta file containing random data\n"); + fprintf(stderr, "\t-v level:\n"); + fprintf(stderr, "\t\tverbose level (0)\n"); + + fprintf(stderr, "\n"); + + fprintf(stderr, "keys:\n"); + fprintf(stderr, "\tkeyfile (Kname+alg+tag)\n"); + + fprintf(stderr, "\n"); + + fprintf(stderr, "Output:\n"); + fprintf(stderr, "\tkeyset (keyset-)\n"); + exit(0); +} + +static isc_boolean_t +zonekey_on_list(dst_key_t *key) { + keynode_t *keynode; + for (keynode = ISC_LIST_HEAD(keylist); + keynode != NULL; + keynode = ISC_LIST_NEXT(keynode, link)) + { + if (dst_key_compare(keynode->key, key)) + return (ISC_TRUE); + } + return (ISC_FALSE); +} + +int +main(int argc, char *argv[]) { + int i, ch; + char *startstr = NULL, *endstr = NULL; + dns_fixedname_t fdomain; + dns_name_t *domain = NULL; + char *output = NULL; + char *endp; + unsigned char data[65536]; + dns_db_t *db; + dns_dbversion_t *version; + dns_diff_t diff; + dns_difftuple_t *tuple; + dns_fixedname_t tname; + dst_key_t *key = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdataset_t rdataset; + dns_rdataclass_t rdclass; + isc_result_t result; + isc_buffer_t b; + isc_region_t r; + isc_log_t *log = NULL; + keynode_t *keynode; + unsigned int eflags; + isc_boolean_t pseudorandom = ISC_FALSE; + isc_boolean_t tryverify = ISC_FALSE; + + result = isc_mem_create(0, 0, &mctx); + if (result != ISC_R_SUCCESS) + fatal("failed to create memory context: %s", + isc_result_totext(result)); + + dns_result_register(); + + while ((ch = isc_commandline_parse(argc, argv, "as:e:t:r:v:ph")) != -1) + { + switch (ch) { + case 'a': + tryverify = ISC_TRUE; + break; + case 's': + startstr = isc_commandline_argument; + break; + + case 'e': + endstr = isc_commandline_argument; + break; + + case 't': + endp = NULL; + ttl = strtol(isc_commandline_argument, &endp, 0); + if (*endp != '\0') + fatal("TTL must be numeric"); + break; + + case 'r': + setup_entropy(mctx, isc_commandline_argument, &ectx); + break; + + case 'v': + endp = NULL; + verbose = strtol(isc_commandline_argument, &endp, 0); + if (*endp != '\0') + fatal("verbose level must be numeric"); + break; + + case 'p': + pseudorandom = ISC_TRUE; + break; + + case 'h': + default: + usage(); + + } + } + + argc -= isc_commandline_index; + argv += isc_commandline_index; + + if (argc < 1) + usage(); + + if (ectx == NULL) + setup_entropy(mctx, NULL, &ectx); + eflags = ISC_ENTROPY_BLOCKING; + if (!pseudorandom) + eflags |= ISC_ENTROPY_GOODONLY; + result = dst_lib_init(mctx, ectx, eflags); + if (result != ISC_R_SUCCESS) + fatal("could not initialize dst: %s", + isc_result_totext(result)); + + isc_stdtime_get(&now); + + if (startstr != NULL) + starttime = strtotime(startstr, now, now); + else + starttime = now; + + if (endstr != NULL) + endtime = strtotime(endstr, now, starttime); + else + endtime = starttime + (30 * 24 * 60 * 60); + + if (ttl == -1) { + ttl = 3600; + fprintf(stderr, "%s: TTL not specified, assuming 3600\n", + program); + } + + setup_logging(verbose, mctx, &log); + + dns_diff_init(mctx, &diff); + rdclass = 0; + + ISC_LIST_INIT(keylist); + + for (i = 0; i < argc; i++) { + char namestr[DNS_NAME_FORMATSIZE]; + isc_buffer_t namebuf; + + key = NULL; + result = dst_key_fromnamedfile(argv[i], DST_TYPE_PUBLIC, + mctx, &key); + if (result != ISC_R_SUCCESS) + fatal("error loading key from %s: %s", argv[i], + isc_result_totext(result)); + if (rdclass == 0) + rdclass = dst_key_class(key); + + isc_buffer_init(&namebuf, namestr, sizeof(namestr)); + result = dns_name_tofilenametext(dst_key_name(key), + ISC_FALSE, + &namebuf); + check_result(result, "dns_name_tofilenametext"); + isc_buffer_putuint8(&namebuf, 0); + + if (domain == NULL) { + dns_fixedname_init(&fdomain); + domain = dns_fixedname_name(&fdomain); + dns_name_copy(dst_key_name(key), domain, NULL); + } else if (!dns_name_equal(domain, dst_key_name(key))) { + char str[DNS_NAME_FORMATSIZE]; + dns_name_format(domain, str, sizeof(str)); + fatal("all keys must have the same owner - %s " + "and %s do not match", str, namestr); + } + + if (output == NULL) { + output = isc_mem_allocate(mctx, + strlen("keyset-") + + strlen(namestr) + 1); + if (output == NULL) + fatal("out of memory"); + sprintf(output, "keyset-%s", namestr); + } + + if (dst_key_iszonekey(key)) { + dst_key_t *zonekey = NULL; + result = dst_key_fromnamedfile(argv[i], + DST_TYPE_PUBLIC | + DST_TYPE_PRIVATE, + mctx, &zonekey); + if (result != ISC_R_SUCCESS) + fatal("failed to read private key %s: %s", + argv[i], isc_result_totext(result)); + if (!zonekey_on_list(zonekey)) { + keynode = isc_mem_get(mctx, sizeof(keynode_t)); + if (keynode == NULL) + fatal("out of memory"); + keynode->key = zonekey; + ISC_LIST_INITANDAPPEND(keylist, keynode, link); + } else + dst_key_free(&zonekey); + } + dns_rdata_reset(&rdata); + isc_buffer_init(&b, data, sizeof(data)); + result = dst_key_todns(key, &b); + dst_key_free(&key); + if (result != ISC_R_SUCCESS) + fatal("failed to convert key %s to a DNS KEY: %s", + argv[i], isc_result_totext(result)); + isc_buffer_usedregion(&b, &r); + dns_rdata_fromregion(&rdata, rdclass, dns_rdatatype_dnskey, &r); + tuple = NULL; + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, + domain, ttl, &rdata, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(&diff, &tuple); + } + + db = NULL; + result = dns_db_create(mctx, "rbt", dns_rootname, dns_dbtype_zone, + rdclass, 0, NULL, &db); + if (result != ISC_R_SUCCESS) + fatal("failed to create a database"); + + version = NULL; + dns_db_newversion(db, &version); + + result = dns_diff_apply(&diff, db, version); + check_result(result, "dns_diff_apply"); + dns_diff_clear(&diff); + + dns_fixedname_init(&tname); + dns_rdataset_init(&rdataset); + result = dns_db_find(db, domain, version, dns_rdatatype_dnskey, 0, 0, + NULL, dns_fixedname_name(&tname), &rdataset, + NULL); + check_result(result, "dns_db_find"); + + if (ISC_LIST_EMPTY(keylist)) + fprintf(stderr, + "%s: no private zone key found; not self-signing\n", + program); + for (keynode = ISC_LIST_HEAD(keylist); + keynode != NULL; + keynode = ISC_LIST_NEXT(keynode, link)) + { + dns_rdata_reset(&rdata); + isc_buffer_init(&b, data, sizeof(data)); + result = dns_dnssec_sign(domain, &rdataset, keynode->key, + &starttime, &endtime, mctx, &b, + &rdata); + isc_entropy_stopcallbacksources(ectx); + if (result != ISC_R_SUCCESS) { + char keystr[KEY_FORMATSIZE]; + key_format(keynode->key, keystr, sizeof(keystr)); + fatal("failed to sign keyset with key %s: %s", + keystr, isc_result_totext(result)); + } + if (tryverify) { + result = dns_dnssec_verify(domain, &rdataset, + keynode->key, ISC_TRUE, + mctx, &rdata); + if (result != ISC_R_SUCCESS) { + char keystr[KEY_FORMATSIZE]; + key_format(keynode->key, keystr, sizeof(keystr)); + fatal("signature from key '%s' failed to " + "verify: %s", + keystr, isc_result_totext(result)); + } + } + tuple = NULL; + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, + domain, ttl, &rdata, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(&diff, &tuple); + } + + result = dns_diff_apply(&diff, db, version); + check_result(result, "dns_diff_apply"); + dns_diff_clear(&diff); + + dns_rdataset_disassociate(&rdataset); + + dns_db_closeversion(db, &version, ISC_TRUE); + result = dns_db_dump(db, version, output); + if (result != ISC_R_SUCCESS) { + char domainstr[DNS_NAME_FORMATSIZE]; + dns_name_format(domain, domainstr, sizeof(domainstr)); + fatal("failed to write database for %s to %s", + domainstr, output); + } + + printf("%s\n", output); + + dns_db_detach(&db); + + while (!ISC_LIST_EMPTY(keylist)) { + keynode = ISC_LIST_HEAD(keylist); + ISC_LIST_UNLINK(keylist, keynode, link); + dst_key_free(&keynode->key); + isc_mem_put(mctx, keynode, sizeof(keynode_t)); + } + + cleanup_logging(&log); + cleanup_entropy(&ectx); + + isc_mem_free(mctx, output); + dst_lib_destroy(); + if (verbose > 10) + isc_mem_stats(mctx, stdout); + isc_mem_destroy(&mctx); + return (0); +} diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook b/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook new file mode 100644 index 000000000000..07327481550b --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook @@ -0,0 +1,233 @@ + + + + + + + + June 30, 2000 + + + + dnssec-makekeyset + 8 + BIND9 + + + + dnssec-makekeyset + DNSSEC zone signing tool + + + + + dnssec-makekeyset + + + + + + + ttl + + key + + + + + DESCRIPTION + + dnssec-makekeyset generates a key set from one + or more keys created by dnssec-keygen. It creates + a file containing a KEY record for each key, and self-signs the key + set with each zone key. The output file is of the form + keyset-nnnn., where nnnn + is the zone name. + + + + + OPTIONS + + + + -a + + + Verify all generated signatures. + + + + + + -s start-time + + + Specify the date and time when the generated SIG records + become valid. This can be either an absolute or relative + time. An absolute start time is indicated by a number + in YYYYMMDDHHMMSS notation; 20000530144500 denotes + 14:45:00 UTC on May 30th, 2000. A relative start time is + indicated by +N, which is N seconds from the current time. + If no is specified, the current + time is used. + + + + + + -e end-time + + + Specify the date and time when the generated SIG records + expire. As with , an absolute + time is indicated in YYYYMMDDHHMMSS notation. A time relative + to the start time is indicated with +N, which is N seconds from + the start time. A time relative to the current time is + indicated with now+N. If no is + specified, 30 days from the start time is used as a default. + + + + + + -h + + + Prints a short summary of the options and arguments to + dnssec-makekeyset. + + + + + + -p + + + Use pseudo-random data when signing the zone. This is faster, + but less secure, than using real random data. This option + may be useful when signing large zones or when the entropy + source is limited. + + + + + + -r randomdev + + + Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. + + + + + + -t ttl + + + Specify the TTL (time to live) of the KEY and SIG records. + The default is 3600 seconds. + + + + + + -v level + + + Sets the debugging level. + + + + + + key + + + The list of keys to be included in the keyset file. These keys + are expressed in the form Knnnn.+aaa+iiiii + as generated by dnssec-keygen. + + + + + + + + + EXAMPLE + + The following command generates a keyset containing the DSA key for + example.com generated in the + dnssec-keygen man page. + + + dnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160 + + + In this example, dnssec-makekeyset creates + the file keyset-example.com.. This file + contains the specified key and a self-generated signature. + + + The DNS administrator for example.com could + send keyset-example.com. to the DNS + administrator for .com for signing, if the + .com zone is DNSSEC-aware and the administrators of the two zones + have some mechanism for authenticating each other and exchanging + the keys and signatures securely. + + + + + SEE ALSO + + + dnssec-keygen + 8 + , + + dnssec-signkey + 8 + , + BIND 9 Administrator Reference Manual, + RFC 2535. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.html b/contrib/bind9/bin/dnssec/dnssec-makekeyset.html new file mode 100644 index 000000000000..48f1d4a59e11 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-makekeyset.html @@ -0,0 +1,407 @@ + + + + +dnssec-makekeyset

dnssec-makekeyset

Name

dnssec-makekeyset -- DNSSEC zone signing tool

Synopsis

dnssec-makekeyset [-a] [-s start-time] [-e end-time] [-h] [-p] [-r randomdev] [-tttl] [-v level] {key...}

DESCRIPTION

dnssec-makekeyset generates a key set from one + or more keys created by dnssec-keygen. It creates + a file containing a KEY record for each key, and self-signs the key + set with each zone key. The output file is of the form + keyset-nnnn., where nnnn + is the zone name. +

OPTIONS

-a

Verify all generated signatures. +

-s start-time

Specify the date and time when the generated SIG records + become valid. This can be either an absolute or relative + time. An absolute start time is indicated by a number + in YYYYMMDDHHMMSS notation; 20000530144500 denotes + 14:45:00 UTC on May 30th, 2000. A relative start time is + indicated by +N, which is N seconds from the current time. + If no start-time is specified, the current + time is used. +

-e end-time

Specify the date and time when the generated SIG records + expire. As with start-time, an absolute + time is indicated in YYYYMMDDHHMMSS notation. A time relative + to the start time is indicated with +N, which is N seconds from + the start time. A time relative to the current time is + indicated with now+N. If no end-time is + specified, 30 days from the start time is used as a default. +

-h

Prints a short summary of the options and arguments to + dnssec-makekeyset. +

-p

Use pseudo-random data when signing the zone. This is faster, + but less secure, than using real random data. This option + may be useful when signing large zones or when the entropy + source is limited. +

-r randomdev

Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. +

-t ttl

Specify the TTL (time to live) of the KEY and SIG records. + The default is 3600 seconds. +

-v level

Sets the debugging level. +

key

The list of keys to be included in the keyset file. These keys + are expressed in the form Knnnn.+aaa+iiiii + as generated by dnssec-keygen. +

EXAMPLE

The following command generates a keyset containing the DSA key for + example.com generated in the + dnssec-keygen man page. +

dnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160 +

In this example, dnssec-makekeyset creates + the file keyset-example.com.. This file + contains the specified key and a self-generated signature. +

The DNS administrator for example.com could + send keyset-example.com. to the DNS + administrator for .com for signing, if the + .com zone is DNSSEC-aware and the administrators of the two zones + have some mechanism for authenticating each other and exchanging + the keys and signatures securely. +

SEE ALSO

dnssec-keygen(8), + dnssec-signkey(8), + BIND 9 Administrator Reference Manual, + RFC 2535. +

AUTHOR

Internet Software Consortium +

diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.8 b/contrib/bind9/bin/dnssec/dnssec-signkey.8 new file mode 100644 index 000000000000..ea2818bdfe21 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-signkey.8 @@ -0,0 +1,108 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: dnssec-signkey.8,v 1.18.2.1.4.1 2004/03/06 07:41:39 marka Exp $ +.\" +.TH "DNSSEC-SIGNKEY" "8" "June 30, 2000" "BIND9" "" +.SH NAME +dnssec-signkey \- DNSSEC key set signing tool +.SH SYNOPSIS +.sp +\fBdnssec-signkey\fR [ \fB-a\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-s \fIstart-time\fB\fR ] [ \fB-e \fIend-time\fB\fR ] [ \fB-h\fR ] [ \fB-p\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-v \fIlevel\fB\fR ] \fBkeyset\fR \fBkey\fR\fI...\fR +.SH "DESCRIPTION" +.PP +\fBdnssec-signkey\fR signs a keyset. Typically +the keyset will be for a child zone, and will have been generated +by \fBdnssec-makekeyset\fR. The child zone's keyset +is signed with the zone keys for its parent zone. The output file +is of the form \fIsignedkey-nnnn.\fR, where +\fInnnn\fR is the zone name. +.SH "OPTIONS" +.TP +\fB-a\fR +Verify all generated signatures. +.TP +\fB-c \fIclass\fB\fR +Specifies the DNS class of the key sets. +.TP +\fB-s \fIstart-time\fB\fR +Specify the date and time when the generated SIG records +become valid. This can be either an absolute or relative +time. An absolute start time is indicated by a number +in YYYYMMDDHHMMSS notation; 20000530144500 denotes +14:45:00 UTC on May 30th, 2000. A relative start time is +indicated by +N, which is N seconds from the current time. +If no \fBstart-time\fR is specified, the current +time is used. +.TP +\fB-e \fIend-time\fB\fR +Specify the date and time when the generated SIG records +expire. As with \fBstart-time\fR, an absolute +time is indicated in YYYYMMDDHHMMSS notation. A time relative +to the start time is indicated with +N, which is N seconds from +the start time. A time relative to the current time is +indicated with now+N. If no \fBend-time\fR is +specified, 30 days from the start time is used as a default. +.TP +\fB-h\fR +Prints a short summary of the options and arguments to +\fBdnssec-signkey\fR. +.TP +\fB-p\fR +Use pseudo-random data when signing the zone. This is faster, +but less secure, than using real random data. This option +may be useful when signing large zones or when the entropy +source is limited. +.TP +\fB-r \fIrandomdev\fB\fR +Specifies the source of randomness. If the operating +system does not provide a \fI/dev/random\fR +or equivalent device, the default source of randomness +is keyboard input. \fIrandomdev\fR specifies +the name of a character device or file containing random +data to be used instead of the default. The special value +\fIkeyboard\fR indicates that keyboard +input should be used. +.TP +\fB-v \fIlevel\fB\fR +Sets the debugging level. +.TP +\fBkeyset\fR +The file containing the child's keyset. +.TP +\fBkey\fR +The keys used to sign the child's keyset. +.SH "EXAMPLE" +.PP +The DNS administrator for a DNSSEC-aware \fB.com\fR +zone would use the following command to sign the +\fIkeyset\fR file for \fBexample.com\fR +created by \fBdnssec-makekeyset\fR with a key generated +by \fBdnssec-keygen\fR: +.PP +\fBdnssec-signkey keyset-example.com. Kcom.+003+51944\fR +.PP +In this example, \fBdnssec-signkey\fR creates +the file \fIsignedkey-example.com.\fR, which +contains the \fBexample.com\fR keys and the +signatures by the \fB.com\fR keys. +.SH "SEE ALSO" +.PP +\fBdnssec-keygen\fR(8), +\fBdnssec-makekeyset\fR(8), +\fBdnssec-signzone\fR(8). +.SH "AUTHOR" +.PP +Internet Software Consortium diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.c b/contrib/bind9/bin/dnssec/dnssec-signkey.c new file mode 100644 index 000000000000..fd8b0fd322b5 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-signkey.c @@ -0,0 +1,448 @@ +/* + * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Portions Copyright (C) 2000-2003 Internet Software Consortium. + * Portions Copyright (C) 1995-2000 by Network Associates, Inc. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC AND NETWORK ASSOCIATES DISCLAIMS + * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE + * FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR + * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dnssec-signkey.c,v 1.50.2.2.2.7 2004/08/28 06:25:28 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "dnssectool.h" + +const char *program = "dnssec-signkey"; +int verbose; + +typedef struct keynode keynode_t; +struct keynode { + dst_key_t *key; + isc_boolean_t verified; + ISC_LINK(keynode_t) link; +}; +typedef ISC_LIST(keynode_t) keylist_t; + +static isc_stdtime_t starttime = 0, endtime = 0, now; + +static isc_mem_t *mctx = NULL; +static isc_entropy_t *ectx = NULL; +static keylist_t keylist; + +static void +usage(void) { + fprintf(stderr, "Usage:\n"); + fprintf(stderr, "\t%s [options] keyset keys\n", program); + + fprintf(stderr, "\n"); + + fprintf(stderr, "Version: %s\n", VERSION); + + fprintf(stderr, "Options: (default value in parenthesis) \n"); + fprintf(stderr, "\t-a\n"); + fprintf(stderr, "\t\tverify generated signatures\n"); + fprintf(stderr, "\t-c class (IN)\n"); + fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n"); + fprintf(stderr, "\t\tSIG start time - absolute|offset (from keyset)\n"); + fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n"); + fprintf(stderr, "\t\tSIG end time - absolute|from start|from now " + "(from keyset)\n"); + fprintf(stderr, "\t-v level:\n"); + fprintf(stderr, "\t\tverbose level (0)\n"); + fprintf(stderr, "\t-p\n"); + fprintf(stderr, "\t\tuse pseudorandom data (faster but less secure)\n"); + fprintf(stderr, "\t-r randomdev:\n"); + fprintf(stderr, "\t\ta file containing random data\n"); + + fprintf(stderr, "\n"); + + fprintf(stderr, "keyset:\n"); + fprintf(stderr, "\tfile with keyset to be signed (keyset-)\n"); + fprintf(stderr, "keys:\n"); + fprintf(stderr, "\tkeyfile (Kname+alg+tag)\n"); + + fprintf(stderr, "\n"); + fprintf(stderr, "Output:\n"); + fprintf(stderr, "\tsigned keyset (signedkey-)\n"); + exit(0); +} + +static void +loadkeys(dns_name_t *name, dns_rdataset_t *rdataset) { + dst_key_t *key; + dns_rdata_t rdata = DNS_RDATA_INIT; + keynode_t *keynode; + isc_result_t result; + + ISC_LIST_INIT(keylist); + result = dns_rdataset_first(rdataset); + check_result(result, "dns_rdataset_first"); + for (; result == ISC_R_SUCCESS; result = dns_rdataset_next(rdataset)) { + dns_rdata_reset(&rdata); + dns_rdataset_current(rdataset, &rdata); + key = NULL; + result = dns_dnssec_keyfromrdata(name, &rdata, mctx, &key); + if (result != ISC_R_SUCCESS) + continue; + if (!dst_key_iszonekey(key)) { + dst_key_free(&key); + continue; + } + keynode = isc_mem_get(mctx, sizeof(keynode_t)); + if (keynode == NULL) + fatal("out of memory"); + keynode->key = key; + keynode->verified = ISC_FALSE; + ISC_LIST_INITANDAPPEND(keylist, keynode, link); + } + if (result != ISC_R_NOMORE) + fatal("failure traversing key list"); +} + +static dst_key_t * +findkey(dns_rdata_rrsig_t *sig) { + keynode_t *keynode; + for (keynode = ISC_LIST_HEAD(keylist); + keynode != NULL; + keynode = ISC_LIST_NEXT(keynode, link)) + { + if (dst_key_id(keynode->key) == sig->keyid && + dst_key_alg(keynode->key) == sig->algorithm) { + keynode->verified = ISC_TRUE; + return (keynode->key); + } + } + fatal("signature generated by non-zone or missing key"); + return (NULL); +} + +int +main(int argc, char *argv[]) { + int i, ch; + char *startstr = NULL, *endstr = NULL, *classname = NULL; + char tdomain[1025]; + dns_fixedname_t fdomain; + dns_name_t *domain; + char *output = NULL; + char *endp; + unsigned char data[65536]; + dns_db_t *db; + dns_dbnode_t *node; + dns_dbversion_t *version; + dns_diff_t diff; + dns_difftuple_t *tuple; + dns_dbiterator_t *dbiter; + dns_rdatasetiter_t *rdsiter; + dst_key_t *key = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdata_t sigrdata = DNS_RDATA_INIT; + dns_rdataset_t rdataset, sigrdataset; + dns_rdata_rrsig_t sig; + isc_result_t result; + isc_buffer_t b; + isc_log_t *log = NULL; + keynode_t *keynode; + isc_boolean_t pseudorandom = ISC_FALSE; + unsigned int eflags; + dns_rdataclass_t rdclass; + isc_boolean_t tryverify = ISC_FALSE; + isc_boolean_t settime = ISC_FALSE; + + result = isc_mem_create(0, 0, &mctx); + check_result(result, "isc_mem_create()"); + + dns_result_register(); + + while ((ch = isc_commandline_parse(argc, argv, "ac:s:e:pr:v:h")) != -1) + { + switch (ch) { + case 'a': + tryverify = ISC_TRUE; + break; + case 'c': + classname = isc_commandline_argument; + break; + + case 's': + startstr = isc_commandline_argument; + break; + + case 'e': + endstr = isc_commandline_argument; + break; + + case 'p': + pseudorandom = ISC_TRUE; + break; + + case 'r': + setup_entropy(mctx, isc_commandline_argument, &ectx); + break; + + case 'v': + endp = NULL; + verbose = strtol(isc_commandline_argument, &endp, 0); + if (*endp != '\0') + fatal("verbose level must be numeric"); + break; + + case 'h': + default: + usage(); + + } + } + + argc -= isc_commandline_index; + argv += isc_commandline_index; + + if (argc < 2) + usage(); + + rdclass = strtoclass(classname); + + if (ectx == NULL) + setup_entropy(mctx, NULL, &ectx); + eflags = ISC_ENTROPY_BLOCKING; + if (!pseudorandom) + eflags |= ISC_ENTROPY_GOODONLY; + result = dst_lib_init(mctx, ectx, eflags); + if (result != ISC_R_SUCCESS) + fatal("could not initialize dst: %s", + isc_result_totext(result)); + + isc_stdtime_get(&now); + + if ((startstr == NULL || endstr == NULL) && + !(startstr == NULL && endstr == NULL)) + fatal("if -s or -e is specified, both must be"); + + if (startstr != NULL) { + starttime = strtotime(startstr, now, now); + endtime = strtotime(endstr, now, starttime); + settime = ISC_TRUE; + } + + setup_logging(verbose, mctx, &log); + + if (strlen(argv[0]) < 8U || strncmp(argv[0], "keyset-", 7) != 0) + fatal("keyset file '%s' must start with keyset-", argv[0]); + + db = NULL; + result = dns_db_create(mctx, "rbt", dns_rootname, dns_dbtype_zone, + rdclass, 0, NULL, &db); + check_result(result, "dns_db_create()"); + + result = dns_db_load(db, argv[0]); + if (result != ISC_R_SUCCESS && result != DNS_R_SEENINCLUDE) + fatal("failed to load database from '%s': %s", argv[0], + isc_result_totext(result)); + + dns_fixedname_init(&fdomain); + domain = dns_fixedname_name(&fdomain); + + dbiter = NULL; + result = dns_db_createiterator(db, ISC_FALSE, &dbiter); + check_result(result, "dns_db_createiterator()"); + + result = dns_dbiterator_first(dbiter); + check_result(result, "dns_dbiterator_first()"); + while (result == ISC_R_SUCCESS) { + node = NULL; + dns_dbiterator_current(dbiter, &node, domain); + rdsiter = NULL; + result = dns_db_allrdatasets(db, node, NULL, 0, &rdsiter); + check_result(result, "dns_db_allrdatasets()"); + result = dns_rdatasetiter_first(rdsiter); + dns_rdatasetiter_destroy(&rdsiter); + if (result == ISC_R_SUCCESS) + break; + dns_db_detachnode(db, &node); + result = dns_dbiterator_next(dbiter); + } + dns_dbiterator_destroy(&dbiter); + if (result != ISC_R_SUCCESS) + fatal("failed to find data in keyset file"); + + isc_buffer_init(&b, tdomain, sizeof(tdomain) - 1); + result = dns_name_tofilenametext(domain, ISC_FALSE, &b); + check_result(result, "dns_name_tofilenametext()"); + isc_buffer_putuint8(&b, 0); + + output = isc_mem_allocate(mctx, + strlen("signedkey-") + strlen(tdomain) + 1); + if (output == NULL) + fatal("out of memory"); + sprintf(output, "signedkey-%s", tdomain); + + version = NULL; + dns_db_newversion(db, &version); + + dns_rdataset_init(&rdataset); + dns_rdataset_init(&sigrdataset); + result = dns_db_findrdataset(db, node, version, dns_rdatatype_dnskey, 0, + 0, &rdataset, &sigrdataset); + if (result != ISC_R_SUCCESS) { + char domainstr[DNS_NAME_FORMATSIZE]; + dns_name_format(domain, domainstr, sizeof(domainstr)); + fatal("failed to find rdataset '%s KEY': %s", + domainstr, isc_result_totext(result)); + } + + loadkeys(domain, &rdataset); + + dns_diff_init(mctx, &diff); + + if (!dns_rdataset_isassociated(&sigrdataset)) + fatal("no SIG KEY set present"); + + result = dns_rdataset_first(&sigrdataset); + check_result(result, "dns_rdataset_first()"); + do { + dns_rdataset_current(&sigrdataset, &sigrdata); + result = dns_rdata_tostruct(&sigrdata, &sig, mctx); + check_result(result, "dns_rdata_tostruct()"); + key = findkey(&sig); + result = dns_dnssec_verify(domain, &rdataset, key, + ISC_TRUE, mctx, &sigrdata); + if (result != ISC_R_SUCCESS) { + char keystr[KEY_FORMATSIZE]; + key_format(key, keystr, sizeof(keystr)); + fatal("signature by key '%s' did not verify: %s", + keystr, isc_result_totext(result)); + } + if (!settime) { + starttime = sig.timesigned; + endtime = sig.timeexpire; + settime = ISC_TRUE; + } + dns_rdata_freestruct(&sig); + dns_rdata_reset(&sigrdata); + result = dns_rdataset_next(&sigrdataset); + } while (result == ISC_R_SUCCESS); + + for (keynode = ISC_LIST_HEAD(keylist); + keynode != NULL; + keynode = ISC_LIST_NEXT(keynode, link)) + if (!keynode->verified) + fatal("not all zone keys self signed the key set"); + + argc -= 1; + argv += 1; + + for (i = 0; i < argc; i++) { + key = NULL; + result = dst_key_fromnamedfile(argv[i], + DST_TYPE_PUBLIC | + DST_TYPE_PRIVATE, + mctx, &key); + if (result != ISC_R_SUCCESS) + fatal("failed to read key %s from disk: %s", + argv[i], isc_result_totext(result)); + + dns_rdata_reset(&rdata); + isc_buffer_init(&b, data, sizeof(data)); + result = dns_dnssec_sign(domain, &rdataset, key, + &starttime, &endtime, + mctx, &b, &rdata); + isc_entropy_stopcallbacksources(ectx); + if (result != ISC_R_SUCCESS) { + char keystr[KEY_FORMATSIZE]; + key_format(key, keystr, sizeof(keystr)); + fatal("key '%s' failed to sign data: %s", + keystr, isc_result_totext(result)); + } + if (tryverify) { + result = dns_dnssec_verify(domain, &rdataset, key, + ISC_TRUE, mctx, &rdata); + if (result != ISC_R_SUCCESS) { + char keystr[KEY_FORMATSIZE]; + key_format(key, keystr, sizeof(keystr)); + fatal("signature from key '%s' failed to " + "verify: %s", + keystr, isc_result_totext(result)); + } + } + tuple = NULL; + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, + domain, rdataset.ttl, + &rdata, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(&diff, &tuple); + dst_key_free(&key); + } + + result = dns_db_deleterdataset(db, node, version, dns_rdatatype_rrsig, + dns_rdatatype_dnskey); + check_result(result, "dns_db_deleterdataset"); + + result = dns_diff_apply(&diff, db, version); + check_result(result, "dns_diff_apply"); + dns_diff_clear(&diff); + + dns_db_detachnode(db, &node); + dns_db_closeversion(db, &version, ISC_TRUE); + result = dns_db_dump(db, version, output); + if (result != ISC_R_SUCCESS) + fatal("failed to write database to '%s': %s", + output, isc_result_totext(result)); + + printf("%s\n", output); + + dns_rdataset_disassociate(&rdataset); + dns_rdataset_disassociate(&sigrdataset); + + dns_db_detach(&db); + + while (!ISC_LIST_EMPTY(keylist)) { + keynode = ISC_LIST_HEAD(keylist); + ISC_LIST_UNLINK(keylist, keynode, link); + dst_key_free(&keynode->key); + isc_mem_put(mctx, keynode, sizeof(keynode_t)); + } + + cleanup_logging(&log); + + isc_mem_free(mctx, output); + cleanup_entropy(&ectx); + dst_lib_destroy(); + if (verbose > 10) + isc_mem_stats(mctx, stdout); + isc_mem_destroy(&mctx); + return (0); +} diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.docbook b/contrib/bind9/bin/dnssec/dnssec-signkey.docbook new file mode 100644 index 000000000000..8258a3da7102 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-signkey.docbook @@ -0,0 +1,237 @@ + + + + + + + + June 30, 2000 + + + + dnssec-signkey + 8 + BIND9 + + + + dnssec-signkey + DNSSEC key set signing tool + + + + + dnssec-signkey + + + + + + + + + keyset + key + + + + + DESCRIPTION + + dnssec-signkey signs a keyset. Typically + the keyset will be for a child zone, and will have been generated + by dnssec-makekeyset. The child zone's keyset + is signed with the zone keys for its parent zone. The output file + is of the form signedkey-nnnn., where + nnnn is the zone name. + + + + + OPTIONS + + + + -a + + + Verify all generated signatures. + + + + + + -c class + + + Specifies the DNS class of the key sets. + + + + + + -s start-time + + + Specify the date and time when the generated SIG records + become valid. This can be either an absolute or relative + time. An absolute start time is indicated by a number + in YYYYMMDDHHMMSS notation; 20000530144500 denotes + 14:45:00 UTC on May 30th, 2000. A relative start time is + indicated by +N, which is N seconds from the current time. + If no is specified, the current + time is used. + + + + + + -e end-time + + + Specify the date and time when the generated SIG records + expire. As with , an absolute + time is indicated in YYYYMMDDHHMMSS notation. A time relative + to the start time is indicated with +N, which is N seconds from + the start time. A time relative to the current time is + indicated with now+N. If no is + specified, 30 days from the start time is used as a default. + + + + + + -h + + + Prints a short summary of the options and arguments to + dnssec-signkey. + + + + + + -p + + + Use pseudo-random data when signing the zone. This is faster, + but less secure, than using real random data. This option + may be useful when signing large zones or when the entropy + source is limited. + + + + + + -r randomdev + + + Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. + + + + + + -v level + + + Sets the debugging level. + + + + + + keyset + + + The file containing the child's keyset. + + + + + + key + + + The keys used to sign the child's keyset. + + + + + + + + + EXAMPLE + + The DNS administrator for a DNSSEC-aware .com + zone would use the following command to sign the + keyset file for example.com + created by dnssec-makekeyset with a key generated + by dnssec-keygen: + + + dnssec-signkey keyset-example.com. Kcom.+003+51944 + + + In this example, dnssec-signkey creates + the file signedkey-example.com., which + contains the example.com keys and the + signatures by the .com keys. + + + + + SEE ALSO + + + dnssec-keygen + 8 + , + + dnssec-makekeyset + 8 + , + + dnssec-signzone + 8 + . + + + + + AUTHOR + + Internet Systems Consortium + + + + + + diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.html b/contrib/bind9/bin/dnssec/dnssec-signkey.html new file mode 100644 index 000000000000..8cbf1fc736a3 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-signkey.html @@ -0,0 +1,407 @@ + + + + +dnssec-signkey

dnssec-signkey

Name

dnssec-signkey -- DNSSEC key set signing tool

Synopsis

dnssec-signkey [-a] [-c class] [-s start-time] [-e end-time] [-h] [-p] [-r randomdev] [-v level] {keyset} {key...}

DESCRIPTION

dnssec-signkey signs a keyset. Typically + the keyset will be for a child zone, and will have been generated + by dnssec-makekeyset. The child zone's keyset + is signed with the zone keys for its parent zone. The output file + is of the form signedkey-nnnn., where + nnnn is the zone name. +

OPTIONS

-a

Verify all generated signatures. +

-c class

Specifies the DNS class of the key sets. +

-s start-time

Specify the date and time when the generated SIG records + become valid. This can be either an absolute or relative + time. An absolute start time is indicated by a number + in YYYYMMDDHHMMSS notation; 20000530144500 denotes + 14:45:00 UTC on May 30th, 2000. A relative start time is + indicated by +N, which is N seconds from the current time. + If no start-time is specified, the current + time is used. +

-e end-time

Specify the date and time when the generated SIG records + expire. As with start-time, an absolute + time is indicated in YYYYMMDDHHMMSS notation. A time relative + to the start time is indicated with +N, which is N seconds from + the start time. A time relative to the current time is + indicated with now+N. If no end-time is + specified, 30 days from the start time is used as a default. +

-h

Prints a short summary of the options and arguments to + dnssec-signkey. +

-p

Use pseudo-random data when signing the zone. This is faster, + but less secure, than using real random data. This option + may be useful when signing large zones or when the entropy + source is limited. +

-r randomdev

Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. +

-v level

Sets the debugging level. +

keyset

The file containing the child's keyset. +

key

The keys used to sign the child's keyset. +

EXAMPLE

The DNS administrator for a DNSSEC-aware .com + zone would use the following command to sign the + keyset file for example.com + created by dnssec-makekeyset with a key generated + by dnssec-keygen: +

dnssec-signkey keyset-example.com. Kcom.+003+51944 +

In this example, dnssec-signkey creates + the file signedkey-example.com., which + contains the example.com keys and the + signatures by the .com keys. +

SEE ALSO

dnssec-keygen(8), + dnssec-makekeyset(8), + dnssec-signzone(8). +

AUTHOR

Internet Software Consortium +

diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.8 b/contrib/bind9/bin/dnssec/dnssec-signzone.8 new file mode 100644 index 000000000000..a1795b8001a2 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-signzone.8 @@ -0,0 +1,167 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2003 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: dnssec-signzone.8,v 1.23.2.1.4.6 2004/06/11 02:32:46 marka Exp $ +.\" +.TH "DNSSEC-SIGNZONE" "8" "June 30, 2000" "BIND9" "" +.SH NAME +dnssec-signzone \- DNSSEC zone signing tool +.SH SYNOPSIS +.sp +\fBdnssec-signzone\fR [ \fB-a\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-d \fIdirectory\fB\fR ] [ \fB-e \fIend-time\fB\fR ] [ \fB-f \fIoutput-file\fB\fR ] [ \fB-g\fR ] [ \fB-h\fR ] [ \fB-k \fIkey\fB\fR ] [ \fB-l \fIdomain\fB\fR ] [ \fB-i \fIinterval\fB\fR ] [ \fB-n \fInthreads\fB\fR ] [ \fB-o \fIorigin\fB\fR ] [ \fB-p\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstart-time\fB\fR ] [ \fB-t\fR ] [ \fB-v \fIlevel\fB\fR ] [ \fB-z\fR ] \fBzonefile\fR [ \fBkey\fR\fI...\fR ] +.SH "DESCRIPTION" +.PP +\fBdnssec-signzone\fR signs a zone. It generates +NSEC and RRSIG records and produces a signed version of the +zone. The security status of delegations from the signed zone +(that is, whether the child zones are secure or not) is +determined by the presence or absence of a +\fIkeyset\fR file for each child zone. +.SH "OPTIONS" +.TP +\fB-a\fR +Verify all generated signatures. +.TP +\fB-c \fIclass\fB\fR +Specifies the DNS class of the zone. +.TP +\fB-k \fIkey\fB\fR +Treat specified key as a key signing key ignoring any +key flags. This option may be specified multiple times. +.TP +\fB-l \fIdomain\fB\fR +Generate a DLV set in addition to the key (DNSKEY) and DS sets. +The domain is appended to the name of the records. +.TP +\fB-d \fIdirectory\fB\fR +Look for \fIkeyset\fR files in +\fBdirectory\fR as the directory +.TP +\fB-g\fR +Generate DS records for child zones from keyset files. +Existing DS records will be removed. +.TP +\fB-s \fIstart-time\fB\fR +Specify the date and time when the generated RRSIG records +become valid. This can be either an absolute or relative +time. An absolute start time is indicated by a number +in YYYYMMDDHHMMSS notation; 20000530144500 denotes +14:45:00 UTC on May 30th, 2000. A relative start time is +indicated by +N, which is N seconds from the current time. +If no \fBstart-time\fR is specified, the current +time minus 1 hour (to allow for clock skew) is used. +.TP +\fB-e \fIend-time\fB\fR +Specify the date and time when the generated RRSIG records +expire. As with \fBstart-time\fR, an absolute +time is indicated in YYYYMMDDHHMMSS notation. A time relative +to the start time is indicated with +N, which is N seconds from +the start time. A time relative to the current time is +indicated with now+N. If no \fBend-time\fR is +specified, 30 days from the start time is used as a default. +.TP +\fB-f \fIoutput-file\fB\fR +The name of the output file containing the signed zone. The +default is to append \fI.signed\fR to the +input file. +.TP +\fB-h\fR +Prints a short summary of the options and arguments to +\fBdnssec-signzone\fR. +.TP +\fB-i \fIinterval\fB\fR +When a previously signed zone is passed as input, records +may be resigned. The \fBinterval\fR option +specifies the cycle interval as an offset from the current +time (in seconds). If a RRSIG record expires after the +cycle interval, it is retained. Otherwise, it is considered +to be expiring soon, and it will be replaced. + +The default cycle interval is one quarter of the difference +between the signature end and start times. So if neither +\fBend-time\fR or \fBstart-time\fR +are specified, \fBdnssec-signzone\fR generates +signatures that are valid for 30 days, with a cycle +interval of 7.5 days. Therefore, if any existing RRSIG records +are due to expire in less than 7.5 days, they would be +replaced. +.TP +\fB-n \fIncpus\fB\fR +Specifies the number of threads to use. By default, one +thread is started for each detected CPU. +.TP +\fB-o \fIorigin\fB\fR +The zone origin. If not specified, the name of the zone file +is assumed to be the origin. +.TP +\fB-p\fR +Use pseudo-random data when signing the zone. This is faster, +but less secure, than using real random data. This option +may be useful when signing large zones or when the entropy +source is limited. +.TP +\fB-r \fIrandomdev\fB\fR +Specifies the source of randomness. If the operating +system does not provide a \fI/dev/random\fR +or equivalent device, the default source of randomness +is keyboard input. \fIrandomdev\fR specifies +the name of a character device or file containing random +data to be used instead of the default. The special value +\fIkeyboard\fR indicates that keyboard +input should be used. +.TP +\fB-t\fR +Print statistics at completion. +.TP +\fB-v \fIlevel\fB\fR +Sets the debugging level. +.TP +\fB-z\fR +Ignore KSK flag on key when determining what to sign. +.TP +\fBzonefile\fR +The file containing the zone to be signed. +Sets the debugging level. +.TP +\fBkey\fR +The keys used to sign the zone. If no keys are specified, the +default all zone keys that have private key files in the +current directory. +.SH "EXAMPLE" +.PP +The following command signs the \fBexample.com\fR +zone with the DSA key generated in the \fBdnssec-keygen\fR +man page. The zone's keys must be in the zone. If there are +\fIkeyset\fR files associated with child zones, +they must be in the current directory. +\fBexample.com\fR, the following command would be +issued: +.PP +\fBdnssec-signzone -o example.com db.example.com Kexample.com.+003+26160\fR +.PP +The command would print a string of the form: +.PP +In this example, \fBdnssec-signzone\fR creates +the file \fIdb.example.com.signed\fR. This file +should be referenced in a zone statement in a +\fInamed.conf\fR file. +.SH "SEE ALSO" +.PP +\fBdnssec-keygen\fR(8), +\fIBIND 9 Administrator Reference Manual\fR, +\fIRFC 2535\fR. +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.c b/contrib/bind9/bin/dnssec/dnssec-signzone.c new file mode 100644 index 000000000000..096cd30508ab --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-signzone.c @@ -0,0 +1,2102 @@ +/* + * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Portions Copyright (C) 1999-2003 Internet Software Consortium. + * Portions Copyright (C) 1995-2000 by Network Associates, Inc. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC AND NETWORK ASSOCIATES DISCLAIMS + * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE + * FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR + * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dnssec-signzone.c,v 1.139.2.2.4.16 2004/08/28 06:25:29 marka Exp $ */ + +#include + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "dnssectool.h" + +const char *program = "dnssec-signzone"; +int verbose; + +#define BUFSIZE 2048 +#define MAXDSKEYS 8 + +typedef struct signer_key_struct signer_key_t; + +struct signer_key_struct { + dst_key_t *key; + isc_boolean_t issigningkey; + isc_boolean_t isdsk; + isc_boolean_t isksk; + unsigned int position; + ISC_LINK(signer_key_t) link; +}; + +#define SIGNER_EVENTCLASS ISC_EVENTCLASS(0x4453) +#define SIGNER_EVENT_WRITE (SIGNER_EVENTCLASS + 0) +#define SIGNER_EVENT_WORK (SIGNER_EVENTCLASS + 1) + +typedef struct signer_event sevent_t; +struct signer_event { + ISC_EVENT_COMMON(sevent_t); + dns_fixedname_t *fname; + dns_dbnode_t *node; +}; + +static ISC_LIST(signer_key_t) keylist; +static unsigned int keycount = 0; +static isc_stdtime_t starttime = 0, endtime = 0, now; +static int cycle = -1; +static isc_boolean_t tryverify = ISC_FALSE; +static isc_boolean_t printstats = ISC_FALSE; +static isc_mem_t *mctx = NULL; +static isc_entropy_t *ectx = NULL; +static dns_ttl_t zonettl; +static FILE *fp; +static char *tempfile = NULL; +static const dns_master_style_t *masterstyle; +static unsigned int nsigned = 0, nretained = 0, ndropped = 0; +static unsigned int nverified = 0, nverifyfailed = 0; +static const char *directory; +static isc_mutex_t namelock, statslock; +static isc_taskmgr_t *taskmgr = NULL; +static dns_db_t *gdb; /* The database */ +static dns_dbversion_t *gversion; /* The database version */ +static dns_dbiterator_t *gdbiter; /* The database iterator */ +static dns_rdataclass_t gclass; /* The class */ +static dns_name_t *gorigin; /* The database origin */ +static isc_task_t *master = NULL; +static unsigned int ntasks = 0; +static isc_boolean_t shuttingdown = ISC_FALSE, finished = ISC_FALSE; +static unsigned int assigned = 0, completed = 0; +static isc_boolean_t nokeys = ISC_FALSE; +static isc_boolean_t removefile = ISC_FALSE; +static isc_boolean_t generateds = ISC_FALSE; +static isc_boolean_t ignoreksk = ISC_FALSE; +static dns_name_t *dlv = NULL; +static dns_fixedname_t dlv_fixed; +static dns_master_style_t *dsstyle = NULL; + +#define INCSTAT(counter) \ + if (printstats) { \ + LOCK(&statslock); \ + counter++; \ + UNLOCK(&statslock); \ + } + +static void +sign(isc_task_t *task, isc_event_t *event); + + +static inline void +set_bit(unsigned char *array, unsigned int index, unsigned int bit) { + unsigned int shift, mask; + + shift = 7 - (index % 8); + mask = 1 << shift; + + if (bit != 0) + array[index / 8] |= mask; + else + array[index / 8] &= (~mask & 0xFF); +} + +static void +dumpnode(dns_name_t *name, dns_dbnode_t *node) { + isc_result_t result; + + result = dns_master_dumpnodetostream(mctx, gdb, gversion, node, name, + masterstyle, fp); + check_result(result, "dns_master_dumpnodetostream"); +} + +static void +dumpdb(dns_db_t *db) { + dns_dbiterator_t *dbiter = NULL; + dns_dbnode_t *node; + dns_fixedname_t fname; + dns_name_t *name; + isc_result_t result; + + dbiter = NULL; + result = dns_db_createiterator(db, ISC_FALSE, &dbiter); + check_result(result, "dns_db_createiterator()"); + + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + node = NULL; + + for (result = dns_dbiterator_first(dbiter); + result == ISC_R_SUCCESS; + result = dns_dbiterator_next(dbiter)) + { + result = dns_dbiterator_current(dbiter, &node, name); + check_result(result, "dns_dbiterator_current()"); + dumpnode(name, node); + dns_db_detachnode(db, &node); + } + if (result != ISC_R_NOMORE) + fatal("iterating database: %s", isc_result_totext(result)); + + dns_dbiterator_destroy(&dbiter); +} + +static signer_key_t * +newkeystruct(dst_key_t *dstkey, isc_boolean_t signwithkey) { + signer_key_t *key; + + key = isc_mem_get(mctx, sizeof(signer_key_t)); + if (key == NULL) + fatal("out of memory"); + key->key = dstkey; + if ((dst_key_flags(dstkey) & DNS_KEYFLAG_KSK) != 0) { + key->issigningkey = signwithkey; + key->isksk = ISC_TRUE; + key->isdsk = ISC_FALSE; + } else { + key->issigningkey = signwithkey; + key->isksk = ISC_FALSE; + key->isdsk = ISC_TRUE; + } + key->position = keycount++; + ISC_LINK_INIT(key, link); + return (key); +} + +static void +signwithkey(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdata_t *rdata, + dst_key_t *key, isc_buffer_t *b) +{ + isc_result_t result; + + result = dns_dnssec_sign(name, rdataset, key, &starttime, &endtime, + mctx, b, rdata); + isc_entropy_stopcallbacksources(ectx); + if (result != ISC_R_SUCCESS) { + char keystr[KEY_FORMATSIZE]; + key_format(key, keystr, sizeof(keystr)); + fatal("dnskey '%s' failed to sign data: %s", + keystr, isc_result_totext(result)); + } + INCSTAT(nsigned); + + if (tryverify) { + result = dns_dnssec_verify(name, rdataset, key, + ISC_TRUE, mctx, rdata); + if (result == ISC_R_SUCCESS) { + vbprintf(3, "\tsignature verified\n"); + INCSTAT(nverified); + } else { + vbprintf(3, "\tsignature failed to verify\n"); + INCSTAT(nverifyfailed); + } + } +} + +static inline isc_boolean_t +issigningkey(signer_key_t *key) { + return (key->issigningkey); +} + +static inline isc_boolean_t +iszonekey(signer_key_t *key) { + return (ISC_TF(dns_name_equal(dst_key_name(key->key), gorigin) && + dst_key_iszonekey(key->key))); +} + +/* + * Finds the key that generated a RRSIG, if possible. First look at the keys + * that we've loaded already, and then see if there's a key on disk. + */ +static signer_key_t * +keythatsigned(dns_rdata_rrsig_t *rrsig) { + isc_result_t result; + dst_key_t *pubkey = NULL, *privkey = NULL; + signer_key_t *key; + + key = ISC_LIST_HEAD(keylist); + while (key != NULL) { + if (rrsig->keyid == dst_key_id(key->key) && + rrsig->algorithm == dst_key_alg(key->key) && + dns_name_equal(&rrsig->signer, dst_key_name(key->key))) + return key; + key = ISC_LIST_NEXT(key, link); + } + + result = dst_key_fromfile(&rrsig->signer, rrsig->keyid, + rrsig->algorithm, DST_TYPE_PUBLIC, + NULL, mctx, &pubkey); + if (result != ISC_R_SUCCESS) + return (NULL); + + result = dst_key_fromfile(&rrsig->signer, rrsig->keyid, + rrsig->algorithm, + DST_TYPE_PUBLIC | DST_TYPE_PRIVATE, + NULL, mctx, &privkey); + if (result == ISC_R_SUCCESS) { + dst_key_free(&pubkey); + key = newkeystruct(privkey, ISC_FALSE); + } else + key = newkeystruct(pubkey, ISC_FALSE); + ISC_LIST_APPEND(keylist, key, link); + return (key); +} + +/* + * Check to see if we expect to find a key at this name. If we see a RRSIG + * and can't find the signing key that we expect to find, we drop the rrsig. + * I'm not sure if this is completely correct, but it seems to work. + */ +static isc_boolean_t +expecttofindkey(dns_name_t *name) { + unsigned int options = DNS_DBFIND_NOWILD; + dns_fixedname_t fname; + isc_result_t result; + char namestr[DNS_NAME_FORMATSIZE]; + + dns_fixedname_init(&fname); + result = dns_db_find(gdb, name, gversion, dns_rdatatype_dnskey, options, + 0, NULL, dns_fixedname_name(&fname), NULL, NULL); + switch (result) { + case ISC_R_SUCCESS: + case DNS_R_NXDOMAIN: + case DNS_R_NXRRSET: + return (ISC_TRUE); + case DNS_R_DELEGATION: + case DNS_R_CNAME: + case DNS_R_DNAME: + return (ISC_FALSE); + } + dns_name_format(name, namestr, sizeof(namestr)); + fatal("failure looking for '%s DNSKEY' in database: %s", + namestr, isc_result_totext(result)); + return (ISC_FALSE); /* removes a warning */ +} + +static inline isc_boolean_t +setverifies(dns_name_t *name, dns_rdataset_t *set, signer_key_t *key, + dns_rdata_t *rrsig) +{ + isc_result_t result; + result = dns_dnssec_verify(name, set, key->key, ISC_FALSE, mctx, rrsig); + if (result == ISC_R_SUCCESS) { + INCSTAT(nverified); + return (ISC_TRUE); + } else { + INCSTAT(nverifyfailed); + return (ISC_FALSE); + } +} + +/* + * Signs a set. Goes through contortions to decide if each RRSIG should + * be dropped or retained, and then determines if any new SIGs need to + * be generated. + */ +static void +signset(dns_diff_t *del, dns_diff_t *add, dns_dbnode_t *node, dns_name_t *name, + dns_rdataset_t *set) +{ + dns_rdataset_t sigset; + dns_rdata_t sigrdata = DNS_RDATA_INIT; + dns_rdata_rrsig_t rrsig; + signer_key_t *key; + isc_result_t result; + isc_boolean_t nosigs = ISC_FALSE; + isc_boolean_t *wassignedby, *nowsignedby; + int arraysize; + dns_difftuple_t *tuple; + dns_ttl_t ttl; + int i; + char namestr[DNS_NAME_FORMATSIZE]; + char typestr[TYPE_FORMATSIZE]; + char sigstr[SIG_FORMATSIZE]; + + dns_name_format(name, namestr, sizeof(namestr)); + type_format(set->type, typestr, sizeof(typestr)); + + ttl = ISC_MIN(set->ttl, endtime - starttime); + + dns_rdataset_init(&sigset); + result = dns_db_findrdataset(gdb, node, gversion, dns_rdatatype_rrsig, + set->type, 0, &sigset, NULL); + if (result == ISC_R_NOTFOUND) { + result = ISC_R_SUCCESS; + nosigs = ISC_TRUE; + } + if (result != ISC_R_SUCCESS) + fatal("failed while looking for '%s RRSIG %s': %s", + namestr, typestr, isc_result_totext(result)); + + vbprintf(1, "%s/%s:\n", namestr, typestr); + + arraysize = keycount; + if (!nosigs) + arraysize += dns_rdataset_count(&sigset); + wassignedby = isc_mem_get(mctx, arraysize * sizeof(isc_boolean_t)); + nowsignedby = isc_mem_get(mctx, arraysize * sizeof(isc_boolean_t)); + if (wassignedby == NULL || nowsignedby == NULL) + fatal("out of memory"); + + for (i = 0; i < arraysize; i++) + wassignedby[i] = nowsignedby[i] = ISC_FALSE; + + if (nosigs) + result = ISC_R_NOMORE; + else + result = dns_rdataset_first(&sigset); + + while (result == ISC_R_SUCCESS) { + isc_boolean_t expired, future; + isc_boolean_t keep = ISC_FALSE, resign = ISC_FALSE; + + dns_rdataset_current(&sigset, &sigrdata); + + result = dns_rdata_tostruct(&sigrdata, &rrsig, NULL); + check_result(result, "dns_rdata_tostruct"); + + future = isc_serial_lt(now, rrsig.timesigned); + + key = keythatsigned(&rrsig); + sig_format(&rrsig, sigstr, sizeof(sigstr)); + if (key != NULL && issigningkey(key)) + expired = isc_serial_gt(now + cycle, rrsig.timeexpire); + else + expired = isc_serial_gt(now, rrsig.timeexpire); + + if (isc_serial_gt(rrsig.timesigned, rrsig.timeexpire)) { + /* rrsig is dropped and not replaced */ + vbprintf(2, "\trrsig by %s dropped - " + "invalid validity period\n", + sigstr); + } else if (key == NULL && !future && + expecttofindkey(&rrsig.signer)) + { + /* rrsig is dropped and not replaced */ + vbprintf(2, "\trrsig by %s dropped - " + "private dnskey not found\n", + sigstr); + } else if (key == NULL || future) { + vbprintf(2, "\trrsig by %s %s - dnskey not found\n", + expired ? "retained" : "dropped", sigstr); + if (!expired) + keep = ISC_TRUE; + } else if (issigningkey(key)) { + if (!expired && setverifies(name, set, key, &sigrdata)) + { + vbprintf(2, "\trrsig by %s retained\n", sigstr); + keep = ISC_TRUE; + wassignedby[key->position] = ISC_TRUE; + nowsignedby[key->position] = ISC_TRUE; + } else { + vbprintf(2, "\trrsig by %s dropped - %s\n", + sigstr, + expired ? "expired" : + "failed to verify"); + wassignedby[key->position] = ISC_TRUE; + resign = ISC_TRUE; + } + } else if (iszonekey(key)) { + if (!expired && setverifies(name, set, key, &sigrdata)) + { + vbprintf(2, "\trrsig by %s retained\n", sigstr); + keep = ISC_TRUE; + wassignedby[key->position] = ISC_TRUE; + nowsignedby[key->position] = ISC_TRUE; + } else { + vbprintf(2, "\trrsig by %s dropped - %s\n", + sigstr, + expired ? "expired" : + "failed to verify"); + wassignedby[key->position] = ISC_TRUE; + } + } else if (!expired) { + vbprintf(2, "\trrsig by %s retained\n", sigstr); + keep = ISC_TRUE; + } else { + vbprintf(2, "\trrsig by %s expired\n", sigstr); + } + + if (keep) { + nowsignedby[key->position] = ISC_TRUE; + INCSTAT(nretained); + if (sigset.ttl != ttl) { + vbprintf(2, "\tfixing ttl %s\n", sigstr); + tuple = NULL; + result = dns_difftuple_create(mctx, + DNS_DIFFOP_DEL, + name, sigset.ttl, + &sigrdata, + &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(del, &tuple); + result = dns_difftuple_create(mctx, + DNS_DIFFOP_ADD, + name, ttl, + &sigrdata, + &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(add, &tuple); + } + } else { + tuple = NULL; + result = dns_difftuple_create(mctx, DNS_DIFFOP_DEL, + name, sigset.ttl, + &sigrdata, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(del, &tuple); + INCSTAT(ndropped); + } + + if (resign) { + isc_buffer_t b; + dns_rdata_t trdata = DNS_RDATA_INIT; + unsigned char array[BUFSIZE]; + char keystr[KEY_FORMATSIZE]; + + INSIST(!keep); + + key_format(key->key, keystr, sizeof(keystr)); + vbprintf(1, "\tresigning with dnskey %s\n", keystr); + isc_buffer_init(&b, array, sizeof(array)); + signwithkey(name, set, &trdata, key->key, &b); + nowsignedby[key->position] = ISC_TRUE; + tuple = NULL; + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, + name, ttl, &trdata, + &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(add, &tuple); + } + + dns_rdata_reset(&sigrdata); + dns_rdata_freestruct(&rrsig); + result = dns_rdataset_next(&sigset); + } + if (result == ISC_R_NOMORE) + result = ISC_R_SUCCESS; + + check_result(result, "dns_rdataset_first/next"); + if (dns_rdataset_isassociated(&sigset)) + dns_rdataset_disassociate(&sigset); + + for (key = ISC_LIST_HEAD(keylist); + key != NULL; + key = ISC_LIST_NEXT(key, link)) + { + isc_buffer_t b; + dns_rdata_t trdata; + unsigned char array[BUFSIZE]; + char keystr[KEY_FORMATSIZE]; + + if (nowsignedby[key->position]) + continue; + + if (!key->issigningkey) + continue; + if (!(ignoreksk || key->isdsk || + (key->isksk && + set->type == dns_rdatatype_dnskey && + dns_name_equal(name, gorigin)))) + continue; + + key_format(key->key, keystr, sizeof(keystr)); + vbprintf(1, "\tsigning with dnskey %s\n", keystr); + dns_rdata_init(&trdata); + isc_buffer_init(&b, array, sizeof(array)); + signwithkey(name, set, &trdata, key->key, &b); + tuple = NULL; + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, name, + ttl, &trdata, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(add, &tuple); + } + + isc_mem_put(mctx, wassignedby, arraysize * sizeof(isc_boolean_t)); + isc_mem_put(mctx, nowsignedby, arraysize * sizeof(isc_boolean_t)); +} + +static void +opendb(const char *prefix, dns_name_t *name, dns_rdataclass_t rdclass, + dns_db_t **dbp) +{ + char filename[256]; + isc_buffer_t b; + isc_result_t result; + + isc_buffer_init(&b, filename, sizeof(filename)); + if (directory != NULL) { + isc_buffer_putstr(&b, directory); + if (directory[strlen(directory) - 1] != '/') + isc_buffer_putstr(&b, "/"); + } + isc_buffer_putstr(&b, prefix); + result = dns_name_tofilenametext(name, ISC_FALSE, &b); + check_result(result, "dns_name_tofilenametext()"); + if (isc_buffer_availablelength(&b) == 0) { + char namestr[DNS_NAME_FORMATSIZE]; + dns_name_format(name, namestr, sizeof(namestr)); + fatal("name '%s' is too long", namestr); + } + isc_buffer_putuint8(&b, 0); + + result = dns_db_create(mctx, "rbt", dns_rootname, dns_dbtype_zone, + rdclass, 0, NULL, dbp); + check_result(result, "dns_db_create()"); + + result = dns_db_load(*dbp, filename); + if (result != ISC_R_SUCCESS && result != DNS_R_SEENINCLUDE) + dns_db_detach(dbp); +} + +/* + * Loads the key set for a child zone, if there is one, and builds DS records. + */ +static isc_result_t +loadds(dns_name_t *name, isc_uint32_t ttl, dns_rdataset_t *dsset) { + dns_db_t *db = NULL; + dns_dbversion_t *ver = NULL; + dns_dbnode_t *node = NULL; + isc_result_t result; + dns_rdataset_t keyset; + dns_rdata_t key, ds; + unsigned char dsbuf[DNS_DS_BUFFERSIZE]; + dns_diff_t diff; + dns_difftuple_t *tuple = NULL; + + opendb("keyset-", name, gclass, &db); + if (db == NULL) + return (ISC_R_NOTFOUND); + + result = dns_db_findnode(db, name, ISC_FALSE, &node); + if (result != ISC_R_SUCCESS) { + dns_db_detach(&db); + return (DNS_R_BADDB); + } + dns_rdataset_init(&keyset); + result = dns_db_findrdataset(db, node, NULL, dns_rdatatype_dnskey, 0, 0, + &keyset, NULL); + if (result != ISC_R_SUCCESS) { + dns_db_detachnode(db, &node); + dns_db_detach(&db); + return (result); + } + + vbprintf(2, "found DNSKEY records\n"); + + result = dns_db_newversion(db, &ver); + check_result(result, "dns_db_newversion"); + + dns_diff_init(mctx, &diff); + + for (result = dns_rdataset_first(&keyset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(&keyset)) + { + dns_rdata_init(&key); + dns_rdata_init(&ds); + dns_rdataset_current(&keyset, &key); + result = dns_ds_buildrdata(name, &key, DNS_DSDIGEST_SHA1, + dsbuf, &ds); + check_result(result, "dns_ds_buildrdata"); + + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, name, + ttl, &ds, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(&diff, &tuple); + } + result = dns_diff_apply(&diff, db, ver); + check_result(result, "dns_diff_apply"); + dns_diff_clear(&diff); + + dns_db_closeversion(db, &ver, ISC_TRUE); + + result = dns_db_findrdataset(db, node, NULL, dns_rdatatype_ds, 0, 0, + dsset, NULL); + check_result(result, "dns_db_findrdataset"); + + dns_rdataset_disassociate(&keyset); + dns_db_detachnode(db, &node); + dns_db_detach(&db); + return (result); +} + +static isc_boolean_t +nsec_setbit(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdatatype_t type, + unsigned int val) +{ + isc_result_t result; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdata_nsec_t nsec; + unsigned int newlen; + unsigned char bitmap[8192 + 512]; + unsigned char nsecdata[8192 + 512 + DNS_NAME_MAXWIRE]; + isc_boolean_t answer = ISC_FALSE; + unsigned int i, len, window; + int octet; + + result = dns_rdataset_first(rdataset); + check_result(result, "dns_rdataset_first()"); + dns_rdataset_current(rdataset, &rdata); + result = dns_rdata_tostruct(&rdata, &nsec, NULL); + check_result(result, "dns_rdata_tostruct"); + + INSIST(nsec.len <= sizeof(bitmap)); + + newlen = 0; + + memset(bitmap, 0, sizeof(bitmap)); + for (i = 0; i < nsec.len; i += len) { + INSIST(i + 2 <= nsec.len); + window = nsec.typebits[i]; + len = nsec.typebits[i+1]; + i += 2; + INSIST(len > 0 && len <= 32); + INSIST(i + len <= nsec.len); + memmove(&bitmap[window * 32 + 512], &nsec.typebits[i], len); + } + set_bit(bitmap + 512, type, val); + for (window = 0; window < 256; window++) { + for (octet = 31; octet >= 0; octet--) + if (bitmap[window * 32 + 512 + octet] != 0) + break; + if (octet < 0) + continue; + bitmap[newlen] = window; + bitmap[newlen + 1] = octet + 1; + newlen += 2; + /* + * Overlapping move. + */ + memmove(&bitmap[newlen], &bitmap[window * 32 + 512], octet + 1); + newlen += octet + 1; + } + if (newlen != nsec.len || + memcmp(nsec.typebits, bitmap, newlen) != 0) { + dns_rdata_t newrdata = DNS_RDATA_INIT; + isc_buffer_t b; + dns_diff_t diff; + dns_difftuple_t *tuple = NULL; + + dns_diff_init(mctx, &diff); + result = dns_difftuple_create(mctx, DNS_DIFFOP_DEL, name, + rdataset->ttl, &rdata, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(&diff, &tuple); + + nsec.typebits = bitmap; + nsec.len = newlen; + isc_buffer_init(&b, nsecdata, sizeof(nsecdata)); + result = dns_rdata_fromstruct(&newrdata, rdata.rdclass, + dns_rdatatype_nsec, &nsec, + &b); + check_result(result, "dns_rdata_fromstruct"); + + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, + name, rdataset->ttl, + &newrdata, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(&diff, &tuple); + result = dns_diff_apply(&diff, gdb, gversion); + check_result(result, "dns_difftuple_apply"); + dns_diff_clear(&diff); + answer = ISC_TRUE; + } + dns_rdata_freestruct(&nsec); + return (answer); +} + +static isc_boolean_t +delegation(dns_name_t *name, dns_dbnode_t *node, isc_uint32_t *ttlp) { + dns_rdataset_t nsset; + isc_result_t result; + + if (dns_name_equal(name, gorigin)) + return (ISC_FALSE); + + dns_rdataset_init(&nsset); + result = dns_db_findrdataset(gdb, node, gversion, dns_rdatatype_ns, + 0, 0, &nsset, NULL); + if (dns_rdataset_isassociated(&nsset)) { + if (ttlp != NULL) + *ttlp = nsset.ttl; + dns_rdataset_disassociate(&nsset); + } + + return (ISC_TF(result == ISC_R_SUCCESS)); +} + +/* + * Signs all records at a name. This mostly just signs each set individually, + * but also adds the RRSIG bit to any NSECs generated earlier, deals with + * parent/child KEY signatures, and handles other exceptional cases. + */ +static void +signname(dns_dbnode_t *node, dns_name_t *name) { + isc_result_t result; + dns_rdataset_t rdataset; + dns_rdatasetiter_t *rdsiter; + isc_boolean_t isdelegation = ISC_FALSE; + isc_boolean_t hasds = ISC_FALSE; + isc_boolean_t atorigin; + isc_boolean_t changed = ISC_FALSE; + dns_diff_t del, add; + char namestr[DNS_NAME_FORMATSIZE]; + isc_uint32_t nsttl = 0; + + dns_name_format(name, namestr, sizeof(namestr)); + + atorigin = dns_name_equal(name, gorigin); + + /* + * Determine if this is a delegation point. + */ + if (delegation(name, node, &nsttl)) + isdelegation = ISC_TRUE; + + /* + * If this is a delegation point, look for a DS set. + */ + if (isdelegation) { + dns_rdataset_t dsset; + dns_rdataset_t sigdsset; + + dns_rdataset_init(&dsset); + dns_rdataset_init(&sigdsset); + result = dns_db_findrdataset(gdb, node, gversion, + dns_rdatatype_ds, + 0, 0, &dsset, &sigdsset); + if (result == ISC_R_SUCCESS) { + dns_rdataset_disassociate(&dsset); + if (generateds) { + result = dns_db_deleterdataset(gdb, node, + gversion, + dns_rdatatype_ds, + 0); + check_result(result, "dns_db_deleterdataset"); + } else + hasds = ISC_TRUE; + } + if (generateds) { + result = loadds(name, nsttl, &dsset); + if (result == ISC_R_SUCCESS) { + result = dns_db_addrdataset(gdb, node, + gversion, 0, + &dsset, 0, NULL); + check_result(result, "dns_db_addrdataset"); + hasds = ISC_TRUE; + dns_rdataset_disassociate(&dsset); + if (dns_rdataset_isassociated(&sigdsset)) + dns_rdataset_disassociate(&sigdsset); + } else if (dns_rdataset_isassociated(&sigdsset)) { + result = dns_db_deleterdataset(gdb, node, + gversion, + dns_rdatatype_rrsig, + dns_rdatatype_ds); + check_result(result, "dns_db_deleterdataset"); + dns_rdataset_disassociate(&sigdsset); + } + } else if (dns_rdataset_isassociated(&sigdsset)) + dns_rdataset_disassociate(&sigdsset); + } + + /* + * Make sure that NSEC bits are appropriately set. + */ + dns_rdataset_init(&rdataset); + RUNTIME_CHECK(dns_db_findrdataset(gdb, node, gversion, + dns_rdatatype_nsec, 0, 0, &rdataset, + NULL) == ISC_R_SUCCESS); + if (!nokeys) + changed = nsec_setbit(name, &rdataset, dns_rdatatype_rrsig, 1); + if (changed) { + dns_rdataset_disassociate(&rdataset); + RUNTIME_CHECK(dns_db_findrdataset(gdb, node, gversion, + dns_rdatatype_nsec, 0, 0, + &rdataset, + NULL) == ISC_R_SUCCESS); + } + if (hasds) + (void)nsec_setbit(name, &rdataset, dns_rdatatype_ds, 1); + else + (void)nsec_setbit(name, &rdataset, dns_rdatatype_ds, 0); + dns_rdataset_disassociate(&rdataset); + + /* + * Now iterate through the rdatasets. + */ + dns_diff_init(mctx, &del); + dns_diff_init(mctx, &add); + rdsiter = NULL; + result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter); + check_result(result, "dns_db_allrdatasets()"); + result = dns_rdatasetiter_first(rdsiter); + while (result == ISC_R_SUCCESS) { + dns_rdatasetiter_current(rdsiter, &rdataset); + + /* If this is a RRSIG set, skip it. */ + if (rdataset.type == dns_rdatatype_rrsig) + goto skip; + + /* + * If this name is a delegation point, skip all records + * except NSEC and DS sets. Otherwise check that there + * isn't a DS record. + */ + if (isdelegation) { + if (rdataset.type != dns_rdatatype_nsec && + rdataset.type != dns_rdatatype_ds) + goto skip; + } else if (rdataset.type == dns_rdatatype_ds) { + char namebuf[DNS_NAME_FORMATSIZE]; + dns_name_format(name, namebuf, sizeof(namebuf)); + fatal("'%s': found DS RRset without NS RRset\n", + namebuf); + } + + signset(&del, &add, node, name, &rdataset); + + skip: + dns_rdataset_disassociate(&rdataset); + result = dns_rdatasetiter_next(rdsiter); + } + if (result != ISC_R_NOMORE) + fatal("rdataset iteration for name '%s' failed: %s", + namestr, isc_result_totext(result)); + + dns_rdatasetiter_destroy(&rdsiter); + + result = dns_diff_applysilently(&del, gdb, gversion); + if (result != ISC_R_SUCCESS) + fatal("failed to delete SIGs at node '%s': %s", + namestr, isc_result_totext(result)); + + result = dns_diff_applysilently(&add, gdb, gversion); + if (result != ISC_R_SUCCESS) + fatal("failed to add SIGs at node '%s': %s", + namestr, isc_result_totext(result)); + + dns_diff_clear(&del); + dns_diff_clear(&add); +} + +static inline isc_boolean_t +active_node(dns_dbnode_t *node) { + dns_rdatasetiter_t *rdsiter; + isc_boolean_t active = ISC_FALSE; + isc_result_t result; + dns_rdataset_t rdataset; + + dns_rdataset_init(&rdataset); + rdsiter = NULL; + result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter); + check_result(result, "dns_db_allrdatasets()"); + result = dns_rdatasetiter_first(rdsiter); + while (result == ISC_R_SUCCESS) { + dns_rdatasetiter_current(rdsiter, &rdataset); + if (rdataset.type != dns_rdatatype_nsec && + rdataset.type != dns_rdatatype_rrsig) + active = ISC_TRUE; + dns_rdataset_disassociate(&rdataset); + if (!active) + result = dns_rdatasetiter_next(rdsiter); + else + result = ISC_R_NOMORE; + } + if (result != ISC_R_NOMORE) + fatal("rdataset iteration failed: %s", + isc_result_totext(result)); + + if (!active) { + /* + * Make sure there is no NSEC / RRSIG records for + * this node. + */ + result = dns_db_deleterdataset(gdb, node, gversion, + dns_rdatatype_nsec, 0); + if (result == DNS_R_UNCHANGED) + result = ISC_R_SUCCESS; + check_result(result, "dns_db_deleterdataset(nsec)"); + + result = dns_rdatasetiter_first(rdsiter); + for (result = dns_rdatasetiter_first(rdsiter); + result == ISC_R_SUCCESS; + result = dns_rdatasetiter_next(rdsiter)) { + dns_rdatasetiter_current(rdsiter, &rdataset); + if (rdataset.type == dns_rdatatype_rrsig) { + dns_rdatatype_t type = rdataset.type; + dns_rdatatype_t covers = rdataset.covers; + result = dns_db_deleterdataset(gdb, node, + gversion, type, + covers); + if (result == DNS_R_UNCHANGED) + result = ISC_R_SUCCESS; + check_result(result, + "dns_db_deleterdataset(rrsig)"); + } + dns_rdataset_disassociate(&rdataset); + } + if (result != ISC_R_NOMORE) + fatal("rdataset iteration failed: %s", + isc_result_totext(result)); + } + dns_rdatasetiter_destroy(&rdsiter); + + return (active); +} + +/* + * Extracts the TTL from the SOA. + */ +static dns_ttl_t +soattl(void) { + dns_rdataset_t soaset; + dns_fixedname_t fname; + dns_name_t *name; + isc_result_t result; + dns_ttl_t ttl; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdata_soa_t soa; + + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + dns_rdataset_init(&soaset); + result = dns_db_find(gdb, gorigin, gversion, dns_rdatatype_soa, + 0, 0, NULL, name, &soaset, NULL); + if (result != ISC_R_SUCCESS) + fatal("failed to find an SOA at the zone apex: %s", + isc_result_totext(result)); + + result = dns_rdataset_first(&soaset); + check_result(result, "dns_rdataset_first"); + dns_rdataset_current(&soaset, &rdata); + result = dns_rdata_tostruct(&rdata, &soa, NULL); + check_result(result, "dns_rdata_tostruct"); + ttl = soa.minimum; + dns_rdataset_disassociate(&soaset); + return (ttl); +} + +/* + * Delete any RRSIG records at a node. + */ +static void +cleannode(dns_db_t *db, dns_dbversion_t *version, dns_dbnode_t *node) { + dns_rdatasetiter_t *rdsiter = NULL; + dns_rdataset_t set; + isc_result_t result, dresult; + + dns_rdataset_init(&set); + result = dns_db_allrdatasets(db, node, version, 0, &rdsiter); + check_result(result, "dns_db_allrdatasets"); + result = dns_rdatasetiter_first(rdsiter); + while (result == ISC_R_SUCCESS) { + isc_boolean_t destroy = ISC_FALSE; + dns_rdatatype_t covers = 0; + dns_rdatasetiter_current(rdsiter, &set); + if (set.type == dns_rdatatype_rrsig) { + covers = set.covers; + destroy = ISC_TRUE; + } + dns_rdataset_disassociate(&set); + result = dns_rdatasetiter_next(rdsiter); + if (destroy) { + dresult = dns_db_deleterdataset(db, node, version, + dns_rdatatype_rrsig, + covers); + check_result(dresult, "dns_db_deleterdataset"); + } + } + if (result != ISC_R_NOMORE) + fatal("rdataset iteration failed: %s", + isc_result_totext(result)); + dns_rdatasetiter_destroy(&rdsiter); +} + +/* + * Set up the iterator and global state before starting the tasks. + */ +static void +presign(void) { + isc_result_t result; + + gdbiter = NULL; + result = dns_db_createiterator(gdb, ISC_FALSE, &gdbiter); + check_result(result, "dns_db_createiterator()"); + + result = dns_dbiterator_first(gdbiter); + check_result(result, "dns_dbiterator_first()"); +} + +/* + * Clean up the iterator and global state after the tasks complete. + */ +static void +postsign(void) { + dns_dbiterator_destroy(&gdbiter); +} + +/* + * Assigns a node to a worker thread. This is protected by the master task's + * lock. + */ +static void +assignwork(isc_task_t *task, isc_task_t *worker) { + dns_fixedname_t *fname; + dns_name_t *name; + dns_dbnode_t *node; + sevent_t *sevent; + dns_rdataset_t nsec; + isc_boolean_t found; + isc_result_t result; + + if (shuttingdown) + return; + + if (finished) { + if (assigned == completed) { + isc_task_detach(&task); + isc_app_shutdown(); + } + return; + } + + fname = isc_mem_get(mctx, sizeof(dns_fixedname_t)); + if (fname == NULL) + fatal("out of memory"); + dns_fixedname_init(fname); + name = dns_fixedname_name(fname); + node = NULL; + found = ISC_FALSE; + LOCK(&namelock); + while (!found) { + result = dns_dbiterator_current(gdbiter, &node, name); + if (result != ISC_R_SUCCESS) + fatal("failure iterating database: %s", + isc_result_totext(result)); + dns_rdataset_init(&nsec); + result = dns_db_findrdataset(gdb, node, gversion, + dns_rdatatype_nsec, 0, 0, + &nsec, NULL); + if (result == ISC_R_SUCCESS) + found = ISC_TRUE; + else + dumpnode(name, node); + if (dns_rdataset_isassociated(&nsec)) + dns_rdataset_disassociate(&nsec); + if (!found) + dns_db_detachnode(gdb, &node); + + result = dns_dbiterator_next(gdbiter); + if (result == ISC_R_NOMORE) { + finished = ISC_TRUE; + break; + } else if (result != ISC_R_SUCCESS) + fatal("failure iterating database: %s", + isc_result_totext(result)); + } + UNLOCK(&namelock); + if (!found) { + if (assigned == completed) { + isc_task_detach(&task); + isc_app_shutdown(); + } + isc_mem_put(mctx, fname, sizeof(dns_fixedname_t)); + return; + } + sevent = (sevent_t *) + isc_event_allocate(mctx, task, SIGNER_EVENT_WORK, + sign, NULL, sizeof(sevent_t)); + if (sevent == NULL) + fatal("failed to allocate event\n"); + + sevent->node = node; + sevent->fname = fname; + isc_task_send(worker, ISC_EVENT_PTR(&sevent)); + assigned++; +} + +/* + * Start a worker task + */ +static void +startworker(isc_task_t *task, isc_event_t *event) { + isc_task_t *worker; + + worker = (isc_task_t *)event->ev_arg; + assignwork(task, worker); + isc_event_free(&event); +} + +/* + * Write a node to the output file, and restart the worker task. + */ +static void +writenode(isc_task_t *task, isc_event_t *event) { + isc_task_t *worker; + sevent_t *sevent = (sevent_t *)event; + + completed++; + worker = (isc_task_t *)event->ev_sender; + dumpnode(dns_fixedname_name(sevent->fname), sevent->node); + cleannode(gdb, gversion, sevent->node); + dns_db_detachnode(gdb, &sevent->node); + isc_mem_put(mctx, sevent->fname, sizeof(dns_fixedname_t)); + assignwork(task, worker); + isc_event_free(&event); +} + +/* + * Sign a database node. + */ +static void +sign(isc_task_t *task, isc_event_t *event) { + dns_fixedname_t *fname; + dns_dbnode_t *node; + sevent_t *sevent, *wevent; + + sevent = (sevent_t *)event; + node = sevent->node; + fname = sevent->fname; + isc_event_free(&event); + + signname(node, dns_fixedname_name(fname)); + wevent = (sevent_t *) + isc_event_allocate(mctx, task, SIGNER_EVENT_WRITE, + writenode, NULL, sizeof(sevent_t)); + if (wevent == NULL) + fatal("failed to allocate event\n"); + wevent->node = node; + wevent->fname = fname; + isc_task_send(master, ISC_EVENT_PTR(&wevent)); +} + +/* + * Generate NSEC records for the zone. + */ +static void +nsecify(void) { + dns_dbiterator_t *dbiter = NULL; + dns_dbnode_t *node = NULL, *nextnode = NULL; + dns_fixedname_t fname, fnextname, fzonecut; + dns_name_t *name, *nextname, *zonecut; + isc_boolean_t done = ISC_FALSE; + isc_result_t result; + + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + dns_fixedname_init(&fnextname); + nextname = dns_fixedname_name(&fnextname); + dns_fixedname_init(&fzonecut); + zonecut = NULL; + + result = dns_db_createiterator(gdb, ISC_FALSE, &dbiter); + check_result(result, "dns_db_createiterator()"); + + result = dns_dbiterator_first(dbiter); + check_result(result, "dns_dbiterator_first()"); + + while (!done) { + dns_dbiterator_current(dbiter, &node, name); + if (delegation(name, node, NULL)) { + zonecut = dns_fixedname_name(&fzonecut); + dns_name_copy(name, zonecut, NULL); + } + result = dns_dbiterator_next(dbiter); + nextnode = NULL; + while (result == ISC_R_SUCCESS) { + isc_boolean_t active = ISC_FALSE; + result = dns_dbiterator_current(dbiter, &nextnode, + nextname); + if (result != ISC_R_SUCCESS) + break; + active = active_node(nextnode); + if (!active) { + dns_db_detachnode(gdb, &nextnode); + result = dns_dbiterator_next(dbiter); + continue; + } + if (result != ISC_R_SUCCESS) { + dns_db_detachnode(gdb, &nextnode); + break; + } + if (!dns_name_issubdomain(nextname, gorigin) || + (zonecut != NULL && + dns_name_issubdomain(nextname, zonecut))) + { + dns_db_detachnode(gdb, &nextnode); + result = dns_dbiterator_next(dbiter); + continue; + } + dns_db_detachnode(gdb, &nextnode); + break; + } + if (result == ISC_R_NOMORE) { + dns_name_clone(gorigin, nextname); + done = ISC_TRUE; + } else if (result != ISC_R_SUCCESS) + fatal("iterating through the database failed: %s", + isc_result_totext(result)); + result = dns_nsec_build(gdb, gversion, node, nextname, + zonettl); + check_result(result, "dns_nsec_build()"); + dns_db_detachnode(gdb, &node); + } + + dns_dbiterator_destroy(&dbiter); +} + +/* + * Load the zone file from disk + */ +static void +loadzone(char *file, char *origin, dns_rdataclass_t rdclass, dns_db_t **db) { + isc_buffer_t b; + int len; + dns_fixedname_t fname; + dns_name_t *name; + isc_result_t result; + + len = strlen(origin); + isc_buffer_init(&b, origin, len); + isc_buffer_add(&b, len); + + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + result = dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) + fatal("failed converting name '%s' to dns format: %s", + origin, isc_result_totext(result)); + + result = dns_db_create(mctx, "rbt", name, dns_dbtype_zone, + rdclass, 0, NULL, db); + check_result(result, "dns_db_create()"); + + result = dns_db_load(*db, file); + if (result != ISC_R_SUCCESS && result != DNS_R_SEENINCLUDE) + fatal("failed loading zone from '%s': %s", + file, isc_result_totext(result)); +} + +/* + * Finds all public zone keys in the zone, and attempts to load the + * private keys from disk. + */ +static void +loadzonekeys(dns_db_t *db) { + dns_dbnode_t *node; + dns_dbversion_t *currentversion; + isc_result_t result; + dst_key_t *keys[20]; + unsigned int nkeys, i; + + currentversion = NULL; + dns_db_currentversion(db, ¤tversion); + + node = NULL; + result = dns_db_findnode(db, gorigin, ISC_FALSE, &node); + if (result != ISC_R_SUCCESS) + fatal("failed to find the zone's origin: %s", + isc_result_totext(result)); + + result = dns_dnssec_findzonekeys(db, currentversion, node, gorigin, + mctx, 20, keys, &nkeys); + if (result == ISC_R_NOTFOUND) + result = ISC_R_SUCCESS; + if (result != ISC_R_SUCCESS) + fatal("failed to find the zone keys: %s", + isc_result_totext(result)); + + for (i = 0; i < nkeys; i++) { + signer_key_t *key; + + key = newkeystruct(keys[i], ISC_TRUE); + ISC_LIST_APPEND(keylist, key, link); + } + dns_db_detachnode(db, &node); + dns_db_closeversion(db, ¤tversion, ISC_FALSE); +} + +/* + * Finds all public zone keys in the zone. + */ +static void +loadzonepubkeys(dns_db_t *db) { + dns_dbversion_t *currentversion = NULL; + dns_dbnode_t *node = NULL; + dns_rdataset_t rdataset; + dns_rdata_t rdata = DNS_RDATA_INIT; + dst_key_t *pubkey; + signer_key_t *key; + isc_result_t result; + + dns_db_currentversion(db, ¤tversion); + + result = dns_db_findnode(db, gorigin, ISC_FALSE, &node); + if (result != ISC_R_SUCCESS) + fatal("failed to find the zone's origin: %s", + isc_result_totext(result)); + + dns_rdataset_init(&rdataset); + result = dns_db_findrdataset(db, node, currentversion, + dns_rdatatype_dnskey, 0, 0, &rdataset, NULL); + if (result != ISC_R_SUCCESS) + fatal("failed to find keys at the zone apex: %s", + isc_result_totext(result)); + result = dns_rdataset_first(&rdataset); + check_result(result, "dns_rdataset_first"); + while (result == ISC_R_SUCCESS) { + pubkey = NULL; + dns_rdata_reset(&rdata); + dns_rdataset_current(&rdataset, &rdata); + result = dns_dnssec_keyfromrdata(gorigin, &rdata, mctx, + &pubkey); + if (result != ISC_R_SUCCESS) + goto next; + if (!dst_key_iszonekey(pubkey)) { + dst_key_free(&pubkey); + goto next; + } + + key = newkeystruct(pubkey, ISC_FALSE); + ISC_LIST_APPEND(keylist, key, link); + next: + result = dns_rdataset_next(&rdataset); + } + dns_rdataset_disassociate(&rdataset); + dns_db_detachnode(db, &node); + dns_db_closeversion(db, ¤tversion, ISC_FALSE); +} + +static void +warnifallksk(dns_db_t *db) { + dns_dbversion_t *currentversion = NULL; + dns_dbnode_t *node = NULL; + dns_rdataset_t rdataset; + dns_rdata_t rdata = DNS_RDATA_INIT; + dst_key_t *pubkey; + isc_result_t result; + dns_rdata_key_t key; + isc_boolean_t have_non_ksk = ISC_FALSE; + + dns_db_currentversion(db, ¤tversion); + + result = dns_db_findnode(db, gorigin, ISC_FALSE, &node); + if (result != ISC_R_SUCCESS) + fatal("failed to find the zone's origin: %s", + isc_result_totext(result)); + + dns_rdataset_init(&rdataset); + result = dns_db_findrdataset(db, node, currentversion, + dns_rdatatype_dnskey, 0, 0, &rdataset, NULL); + if (result != ISC_R_SUCCESS) + fatal("failed to find keys at the zone apex: %s", + isc_result_totext(result)); + result = dns_rdataset_first(&rdataset); + check_result(result, "dns_rdataset_first"); + while (result == ISC_R_SUCCESS) { + pubkey = NULL; + dns_rdata_reset(&rdata); + dns_rdataset_current(&rdataset, &rdata); + result = dns_rdata_tostruct(&rdata, &key, NULL); + check_result(result, "dns_rdata_tostruct"); + if ((key.flags & DNS_KEYFLAG_KSK) == 0) { + have_non_ksk = ISC_TRUE; + result = ISC_R_NOMORE; + } else + result = dns_rdataset_next(&rdataset); + } + dns_rdataset_disassociate(&rdataset); + dns_db_detachnode(db, &node); + dns_db_closeversion(db, ¤tversion, ISC_FALSE); + if (!have_non_ksk && !ignoreksk) + fprintf(stderr, "%s: warning: No non-KSK dnskey found. " + "Supply non-KSK dnskey or use '-z'.\n", + program); +} + +static void +writeset(const char *prefix, dns_rdatatype_t type) { + char *filename; + char namestr[DNS_NAME_FORMATSIZE]; + dns_db_t *db = NULL; + dns_dbversion_t *version = NULL; + dns_diff_t diff; + dns_difftuple_t *tuple = NULL; + dns_fixedname_t fixed; + dns_name_t *name; + dns_rdata_t rdata, ds; + isc_boolean_t have_ksk = ISC_FALSE; + isc_boolean_t have_non_ksk = ISC_FALSE; + isc_buffer_t b; + isc_buffer_t namebuf; + isc_region_t r; + isc_result_t result; + signer_key_t *key; + unsigned char dsbuf[DNS_DS_BUFFERSIZE]; + unsigned char keybuf[DST_KEY_MAXSIZE]; + unsigned int filenamelen; + const dns_master_style_t *style = + (type == dns_rdatatype_dnskey) ? masterstyle : dsstyle; + + isc_buffer_init(&namebuf, namestr, sizeof(namestr)); + result = dns_name_tofilenametext(gorigin, ISC_FALSE, &namebuf); + check_result(result, "dns_name_tofilenametext"); + isc_buffer_putuint8(&namebuf, 0); + filenamelen = strlen(prefix) + strlen(namestr); + if (directory != NULL) + filenamelen += strlen(directory) + 1; + filename = isc_mem_get(mctx, filenamelen + 1); + if (filename == NULL) + fatal("out of memory"); + if (directory != NULL) + sprintf(filename, "%s/", directory); + else + filename[0] = 0; + strcat(filename, prefix); + strcat(filename, namestr); + + dns_diff_init(mctx, &diff); + + for (key = ISC_LIST_HEAD(keylist); + key != NULL; + key = ISC_LIST_NEXT(key, link)) + if (!key->isksk) { + have_non_ksk = ISC_TRUE; + break; + } + + for (key = ISC_LIST_HEAD(keylist); + key != NULL; + key = ISC_LIST_NEXT(key, link)) + if (key->isksk) { + have_ksk = ISC_TRUE; + break; + } + + if (type == dns_rdatatype_dlv) { + dns_name_t tname; + unsigned int labels; + + dns_name_init(&tname, NULL); + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + labels = dns_name_countlabels(gorigin); + dns_name_getlabelsequence(gorigin, 0, labels - 1, &tname); + result = dns_name_concatenate(&tname, dlv, name, NULL); + check_result(result, "dns_name_concatenate"); + } else + name = gorigin; + + for (key = ISC_LIST_HEAD(keylist); + key != NULL; + key = ISC_LIST_NEXT(key, link)) + { + if (have_ksk && have_non_ksk && !key->isksk) + continue; + dns_rdata_init(&rdata); + dns_rdata_init(&ds); + isc_buffer_init(&b, keybuf, sizeof(keybuf)); + result = dst_key_todns(key->key, &b); + check_result(result, "dst_key_todns"); + isc_buffer_usedregion(&b, &r); + dns_rdata_fromregion(&rdata, gclass, dns_rdatatype_dnskey, &r); + if (type != dns_rdatatype_dnskey) { + result = dns_ds_buildrdata(gorigin, &rdata, + DNS_DSDIGEST_SHA1, + dsbuf, &ds); + check_result(result, "dns_ds_buildrdata"); + if (type == dns_rdatatype_dlv) + ds.type = dns_rdatatype_dlv; + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, + name, 0, &ds, &tuple); + } else + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, + gorigin, zonettl, + &rdata, &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(&diff, &tuple); + } + + result = dns_db_create(mctx, "rbt", dns_rootname, dns_dbtype_zone, + gclass, 0, NULL, &db); + check_result(result, "dns_db_create"); + + result = dns_db_newversion(db, &version); + check_result(result, "dns_db_newversion"); + + result = dns_diff_apply(&diff, db, version); + check_result(result, "dns_diff_apply"); + dns_diff_clear(&diff); + + result = dns_master_dump(mctx, db, version, style, filename); + check_result(result, "dns_master_dump"); + + isc_mem_put(mctx, filename, filenamelen + 1); + + dns_db_closeversion(db, &version, ISC_FALSE); + dns_db_detach(&db); +} + +static void +print_time(FILE *fp) { + time_t currenttime; + + currenttime = time(NULL); + fprintf(fp, "; File written on %s", ctime(¤ttime)); +} + +static void +print_version(FILE *fp) { + fprintf(fp, "; dnssec_signzone version " VERSION "\n"); +} + +static void +usage(void) { + fprintf(stderr, "Usage:\n"); + fprintf(stderr, "\t%s [options] zonefile [keys]\n", program); + + fprintf(stderr, "\n"); + + fprintf(stderr, "Version: %s\n", VERSION); + + fprintf(stderr, "Options: (default value in parenthesis) \n"); + fprintf(stderr, "\t-c class (IN)\n"); + fprintf(stderr, "\t-d directory\n"); + fprintf(stderr, "\t\tdirectory to find keyset files (.)\n"); + fprintf(stderr, "\t-g:\t"); + fprintf(stderr, "generate DS records from keyset files\n"); + fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n"); + fprintf(stderr, "\t\tRRSIG start time - absolute|offset (now - 1 hour)\n"); + fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n"); + fprintf(stderr, "\t\tRRSIG end time - absolute|from start|from now " + "(now + 30 days)\n"); + fprintf(stderr, "\t-i interval:\n"); + fprintf(stderr, "\t\tcycle interval - resign " + "if < interval from end ( (end-start)/4 )\n"); + fprintf(stderr, "\t-v debuglevel (0)\n"); + fprintf(stderr, "\t-o origin:\n"); + fprintf(stderr, "\t\tzone origin (name of zonefile)\n"); + fprintf(stderr, "\t-f outfile:\n"); + fprintf(stderr, "\t\tfile the signed zone is written in " + "(zonefile + .signed)\n"); + fprintf(stderr, "\t-r randomdev:\n"); + fprintf(stderr, "\t\ta file containing random data\n"); + fprintf(stderr, "\t-a:\t"); + fprintf(stderr, "verify generated signatures\n"); + fprintf(stderr, "\t-p:\t"); + fprintf(stderr, "use pseudorandom data (faster but less secure)\n"); + fprintf(stderr, "\t-t:\t"); + fprintf(stderr, "print statistics\n"); + fprintf(stderr, "\t-n ncpus (number of cpus present)\n"); + fprintf(stderr, "\t-k key_signing_key\n"); + fprintf(stderr, "\t-l lookasidezone\n"); + fprintf(stderr, "\t-z:\t"); + fprintf(stderr, "ignore KSK flag in DNSKEYs"); + + fprintf(stderr, "\n"); + + fprintf(stderr, "Signing Keys: "); + fprintf(stderr, "(default: all zone keys that have private keys)\n"); + fprintf(stderr, "\tkeyfile (Kname+alg+tag)\n"); + exit(0); +} + +static void +removetempfile(void) { + if (removefile) + isc_file_remove(tempfile); +} + +static void +print_stats(isc_time_t *timer_start, isc_time_t *timer_finish) { + isc_uint64_t runtime_us; /* Runtime in microseconds */ + isc_uint64_t runtime_ms; /* Runtime in milliseconds */ + isc_uint64_t sig_ms; /* Signatures per millisecond */ + + runtime_us = isc_time_microdiff(timer_finish, timer_start); + + printf("Signatures generated: %10d\n", nsigned); + printf("Signatures retained: %10d\n", nretained); + printf("Signatures dropped: %10d\n", ndropped); + printf("Signatures successfully verified: %10d\n", nverified); + printf("Signatures unsuccessfully verified: %10d\n", nverifyfailed); + runtime_ms = runtime_us / 1000; + printf("Runtime in seconds: %7u.%03u\n", + (unsigned int) (runtime_ms / 1000), + (unsigned int) (runtime_ms % 1000)); + if (runtime_us > 0) { + sig_ms = ((isc_uint64_t)nsigned * 1000000000) / runtime_us; + printf("Signatures per second: %7u.%03u\n", + (unsigned int) sig_ms / 1000, + (unsigned int) sig_ms % 1000); + } +} + +int +main(int argc, char *argv[]) { + int i, ch; + char *startstr = NULL, *endstr = NULL, *classname = NULL; + char *origin = NULL, *file = NULL, *output = NULL; + char *dskeyfile[MAXDSKEYS]; + int ndskeys = 0; + char *endp; + isc_time_t timer_start, timer_finish; + signer_key_t *key; + isc_result_t result; + isc_log_t *log = NULL; + isc_boolean_t pseudorandom = ISC_FALSE; + unsigned int eflags; + isc_boolean_t free_output = ISC_FALSE; + int tempfilelen; + dns_rdataclass_t rdclass; + dns_db_t *udb = NULL; + isc_task_t **tasks = NULL; + isc_buffer_t b; + int len; + + masterstyle = &dns_master_style_explicitttl; + + check_result(isc_app_start(), "isc_app_start"); + + result = isc_mem_create(0, 0, &mctx); + if (result != ISC_R_SUCCESS) + fatal("out of memory"); + + dns_result_register(); + + while ((ch = isc_commandline_parse(argc, argv, + "ac:d:e:f:ghi:k:l:n:o:pr:s:Stv:z")) + != -1) { + switch (ch) { + case 'a': + tryverify = ISC_TRUE; + break; + + case 'c': + classname = isc_commandline_argument; + break; + + case 'd': + directory = isc_commandline_argument; + break; + + case 'e': + endstr = isc_commandline_argument; + break; + + case 'f': + output = isc_commandline_argument; + break; + + case 'g': + generateds = ISC_TRUE; + break; + + case 'h': + default: + usage(); + break; + + case 'i': + endp = NULL; + cycle = strtol(isc_commandline_argument, &endp, 0); + if (*endp != '\0' || cycle < 0) + fatal("cycle period must be numeric and " + "positive"); + break; + + case 'l': + dns_fixedname_init(&dlv_fixed); + len = strlen(isc_commandline_argument); + isc_buffer_init(&b, isc_commandline_argument, len); + isc_buffer_add(&b, len); + + dns_fixedname_init(&dlv_fixed); + dlv = dns_fixedname_name(&dlv_fixed); + result = dns_name_fromtext(dlv, &b, dns_rootname, + ISC_FALSE, NULL); + check_result(result, "dns_name_fromtext(dlv)"); + break; + + case 'k': + if (ndskeys == MAXDSKEYS) + fatal("too many key-signing keys specified"); + dskeyfile[ndskeys++] = isc_commandline_argument; + break; + + case 'n': + endp = NULL; + ntasks = strtol(isc_commandline_argument, &endp, 0); + if (*endp != '\0' || ntasks > ISC_INT32_MAX) + fatal("number of cpus must be numeric"); + break; + + case 'o': + origin = isc_commandline_argument; + break; + + case 'p': + pseudorandom = ISC_TRUE; + break; + + case 'r': + setup_entropy(mctx, isc_commandline_argument, &ectx); + break; + + case 's': + startstr = isc_commandline_argument; + break; + + case 'S': + /* This is intentionally undocumented */ + /* -S: simple output style */ + masterstyle = &dns_master_style_simple; + break; + + case 't': + printstats = ISC_TRUE; + break; + + case 'v': + endp = NULL; + verbose = strtol(isc_commandline_argument, &endp, 0); + if (*endp != '\0') + fatal("verbose level must be numeric"); + break; + + case 'z': + ignoreksk = ISC_TRUE; + break; + } + } + + if (ectx == NULL) + setup_entropy(mctx, NULL, &ectx); + eflags = ISC_ENTROPY_BLOCKING; + if (!pseudorandom) + eflags |= ISC_ENTROPY_GOODONLY; + result = dst_lib_init(mctx, ectx, eflags); + if (result != ISC_R_SUCCESS) + fatal("could not initialize dst"); + + isc_stdtime_get(&now); + + if (startstr != NULL) + starttime = strtotime(startstr, now, now); + else + starttime = now - 3600; /* Allow for some clock skew. */ + + if (endstr != NULL) + endtime = strtotime(endstr, now, starttime); + else + endtime = starttime + (30 * 24 * 60 * 60); + + if (cycle == -1) + cycle = (endtime - starttime) / 4; + + if (ntasks == 0) + ntasks = isc_os_ncpus(); + vbprintf(4, "using %d cpus\n", ntasks); + + rdclass = strtoclass(classname); + + setup_logging(verbose, mctx, &log); + + argc -= isc_commandline_index; + argv += isc_commandline_index; + + if (argc < 1) + usage(); + + file = argv[0]; + + argc -= 1; + argv += 1; + + if (origin == NULL) + origin = file; + + if (output == NULL) { + free_output = ISC_TRUE; + output = isc_mem_allocate(mctx, + strlen(file) + strlen(".signed") + 1); + if (output == NULL) + fatal("out of memory"); + sprintf(output, "%s.signed", file); + } + + result = dns_master_stylecreate(&dsstyle, DNS_STYLEFLAG_NO_TTL, + 0, 24, 0, 0, 0, 8, mctx); + check_result(result, "dns_master_stylecreate"); + + + gdb = NULL; + TIME_NOW(&timer_start); + loadzone(file, origin, rdclass, &gdb); + gorigin = dns_db_origin(gdb); + gclass = dns_db_class(gdb); + zonettl = soattl(); + + ISC_LIST_INIT(keylist); + + if (argc == 0) { + loadzonekeys(gdb); + } else { + for (i = 0; i < argc; i++) { + dst_key_t *newkey = NULL; + + result = dst_key_fromnamedfile(argv[i], + DST_TYPE_PUBLIC | + DST_TYPE_PRIVATE, + mctx, &newkey); + if (result != ISC_R_SUCCESS) + fatal("cannot load dnskey %s: %s", argv[i], + isc_result_totext(result)); + + key = ISC_LIST_HEAD(keylist); + while (key != NULL) { + dst_key_t *dkey = key->key; + if (dst_key_id(dkey) == dst_key_id(newkey) && + dst_key_alg(dkey) == dst_key_alg(newkey) && + dns_name_equal(dst_key_name(dkey), + dst_key_name(newkey))) + { + if (!dst_key_isprivate(dkey)) + fatal("cannot sign zone with " + "non-private dnskey %s", + argv[i]); + break; + } + key = ISC_LIST_NEXT(key, link); + } + if (key == NULL) { + key = newkeystruct(newkey, ISC_TRUE); + ISC_LIST_APPEND(keylist, key, link); + } else + dst_key_free(&newkey); + } + + loadzonepubkeys(gdb); + } + + for (i = 0; i < ndskeys; i++) { + dst_key_t *newkey = NULL; + + result = dst_key_fromnamedfile(dskeyfile[i], + DST_TYPE_PUBLIC | + DST_TYPE_PRIVATE, + mctx, &newkey); + if (result != ISC_R_SUCCESS) + fatal("cannot load dnskey %s: %s", dskeyfile[i], + isc_result_totext(result)); + + key = ISC_LIST_HEAD(keylist); + while (key != NULL) { + dst_key_t *dkey = key->key; + if (dst_key_id(dkey) == dst_key_id(newkey) && + dst_key_alg(dkey) == dst_key_alg(newkey) && + dns_name_equal(dst_key_name(dkey), + dst_key_name(newkey))) + { + /* Override key flags. */ + key->issigningkey = ISC_TRUE; + key->isksk = ISC_TRUE; + key->isdsk = ISC_FALSE; + dst_key_free(&dkey); + key->key = newkey; + break; + } + key = ISC_LIST_NEXT(key, link); + } + if (key == NULL) { + /* Override dnskey flags. */ + key = newkeystruct(newkey, ISC_TRUE); + key->isksk = ISC_TRUE; + key->isdsk = ISC_FALSE; + ISC_LIST_APPEND(keylist, key, link); + } + } + + if (ISC_LIST_EMPTY(keylist)) { + fprintf(stderr, "%s: warning: No keys specified or found\n", + program); + nokeys = ISC_TRUE; + } + + warnifallksk(gdb); + + gversion = NULL; + result = dns_db_newversion(gdb, &gversion); + check_result(result, "dns_db_newversion()"); + + nsecify(); + + if (!nokeys) { + writeset("keyset-", dns_rdatatype_dnskey); + writeset("dsset-", dns_rdatatype_ds); + if (dlv != NULL) { + writeset("dlvset-", dns_rdatatype_dlv); + } + } + + tempfilelen = strlen(output) + 20; + tempfile = isc_mem_get(mctx, tempfilelen); + if (tempfile == NULL) + fatal("out of memory"); + + result = isc_file_mktemplate(output, tempfile, tempfilelen); + check_result(result, "isc_file_mktemplate"); + + fp = NULL; + result = isc_file_openunique(tempfile, &fp); + if (result != ISC_R_SUCCESS) + fatal("failed to open temporary output file: %s", + isc_result_totext(result)); + removefile = ISC_TRUE; + setfatalcallback(&removetempfile); + + print_time(fp); + print_version(fp); + + result = isc_taskmgr_create(mctx, ntasks, 0, &taskmgr); + if (result != ISC_R_SUCCESS) + fatal("failed to create task manager: %s", + isc_result_totext(result)); + + master = NULL; + result = isc_task_create(taskmgr, 0, &master); + if (result != ISC_R_SUCCESS) + fatal("failed to create task: %s", isc_result_totext(result)); + + tasks = isc_mem_get(mctx, ntasks * sizeof(isc_task_t *)); + if (tasks == NULL) + fatal("out of memory"); + for (i = 0; i < (int)ntasks; i++) { + tasks[i] = NULL; + result = isc_task_create(taskmgr, 0, &tasks[i]); + if (result != ISC_R_SUCCESS) + fatal("failed to create task: %s", + isc_result_totext(result)); + result = isc_app_onrun(mctx, master, startworker, tasks[i]); + if (result != ISC_R_SUCCESS) + fatal("failed to start task: %s", + isc_result_totext(result)); + } + + RUNTIME_CHECK(isc_mutex_init(&namelock) == ISC_R_SUCCESS); + if (printstats) + RUNTIME_CHECK(isc_mutex_init(&statslock) == ISC_R_SUCCESS); + + presign(); + (void)isc_app_run(); + if (!finished) + fatal("process aborted by user"); + shuttingdown = ISC_TRUE; + for (i = 0; i < (int)ntasks; i++) + isc_task_detach(&tasks[i]); + isc_taskmgr_destroy(&taskmgr); + isc_mem_put(mctx, tasks, ntasks * sizeof(isc_task_t *)); + postsign(); + + if (udb != NULL) { + dumpdb(udb); + dns_db_detach(&udb); + } + + result = isc_stdio_close(fp); + check_result(result, "isc_stdio_close"); + removefile = ISC_FALSE; + + result = isc_file_rename(tempfile, output); + if (result != ISC_R_SUCCESS) + fatal("failed to rename temp file to %s: %s\n", + output, isc_result_totext(result)); + + DESTROYLOCK(&namelock); + if (printstats) + DESTROYLOCK(&statslock); + + printf("%s\n", output); + + dns_db_closeversion(gdb, &gversion, ISC_FALSE); + dns_db_detach(&gdb); + + while (!ISC_LIST_EMPTY(keylist)) { + key = ISC_LIST_HEAD(keylist); + ISC_LIST_UNLINK(keylist, key, link); + dst_key_free(&key->key); + isc_mem_put(mctx, key, sizeof(signer_key_t)); + } + + isc_mem_put(mctx, tempfile, tempfilelen); + + if (free_output) + isc_mem_free(mctx, output); + + dns_master_styledestroy(&dsstyle, mctx); + + cleanup_logging(&log); + dst_lib_destroy(); + cleanup_entropy(&ectx); + if (verbose > 10) + isc_mem_stats(mctx, stdout); + isc_mem_destroy(&mctx); + + (void) isc_app_finish(); + + if (printstats) { + TIME_NOW(&timer_finish); + print_stats(&timer_start, &timer_finish); + } + + return (0); +} diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.docbook b/contrib/bind9/bin/dnssec/dnssec-signzone.docbook new file mode 100644 index 000000000000..2b85102a0b54 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-signzone.docbook @@ -0,0 +1,362 @@ + + + + + + + + June 30, 2000 + + + + dnssec-signzone + 8 + BIND9 + + + + dnssec-signzone + DNSSEC zone signing tool + + + + + dnssec-signzone + + + + + + + + + + + + + + + + + + + zonefile + key + + + + + DESCRIPTION + + dnssec-signzone signs a zone. It generates + NSEC and RRSIG records and produces a signed version of the + zone. The security status of delegations from the signed zone + (that is, whether the child zones are secure or not) is + determined by the presence or absence of a + keyset file for each child zone. + + + + + OPTIONS + + + + -a + + + Verify all generated signatures. + + + + + + -c class + + + Specifies the DNS class of the zone. + + + + + + -k key + + + Treat specified key as a key signing key ignoring any + key flags. This option may be specified multiple times. + + + + + + -l domain + + + Generate a DLV set in addition to the key (DNSKEY) and DS sets. + The domain is appended to the name of the records. + + + + + + -d directory + + + Look for keyset files in + as the directory + + + + + + -g + + + Generate DS records for child zones from keyset files. + Existing DS records will be removed. + + + + + + -s start-time + + + Specify the date and time when the generated RRSIG records + become valid. This can be either an absolute or relative + time. An absolute start time is indicated by a number + in YYYYMMDDHHMMSS notation; 20000530144500 denotes + 14:45:00 UTC on May 30th, 2000. A relative start time is + indicated by +N, which is N seconds from the current time. + If no is specified, the current + time minus 1 hour (to allow for clock skew) is used. + + + + + + -e end-time + + + Specify the date and time when the generated RRSIG records + expire. As with , an absolute + time is indicated in YYYYMMDDHHMMSS notation. A time relative + to the start time is indicated with +N, which is N seconds from + the start time. A time relative to the current time is + indicated with now+N. If no is + specified, 30 days from the start time is used as a default. + + + + + + -f output-file + + + The name of the output file containing the signed zone. The + default is to append .signed to the + input file. + + + + + + -h + + + Prints a short summary of the options and arguments to + dnssec-signzone. + + + + + + -i interval + + + When a previously signed zone is passed as input, records + may be resigned. The option + specifies the cycle interval as an offset from the current + time (in seconds). If a RRSIG record expires after the + cycle interval, it is retained. Otherwise, it is considered + to be expiring soon, and it will be replaced. + + + The default cycle interval is one quarter of the difference + between the signature end and start times. So if neither + or + are specified, dnssec-signzone generates + signatures that are valid for 30 days, with a cycle + interval of 7.5 days. Therefore, if any existing RRSIG records + are due to expire in less than 7.5 days, they would be + replaced. + + + + + + -n ncpus + + + Specifies the number of threads to use. By default, one + thread is started for each detected CPU. + + + + + + -o origin + + + The zone origin. If not specified, the name of the zone file + is assumed to be the origin. + + + + + + -p + + + Use pseudo-random data when signing the zone. This is faster, + but less secure, than using real random data. This option + may be useful when signing large zones or when the entropy + source is limited. + + + + + + -r randomdev + + + Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. + + + + + + -t + + + Print statistics at completion. + + + + + + -v level + + + Sets the debugging level. + + + + + + -z + + + Ignore KSK flag on key when determining what to sign. + + + + + + zonefile + + + The file containing the zone to be signed. + Sets the debugging level. + + + + + + key + + + The keys used to sign the zone. If no keys are specified, the + default all zone keys that have private key files in the + current directory. + + + + + + + + + EXAMPLE + + The following command signs the example.com + zone with the DSA key generated in the dnssec-keygen + man page. The zone's keys must be in the zone. If there are + keyset files associated with child zones, + they must be in the current directory. + example.com, the following command would be + issued: + + + dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160 + + + The command would print a string of the form: + + + In this example, dnssec-signzone creates + the file db.example.com.signed. This file + should be referenced in a zone statement in a + named.conf file. + + + + + SEE ALSO + + + dnssec-keygen + 8 + , + BIND 9 Administrator Reference Manual, + RFC 2535. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.html b/contrib/bind9/bin/dnssec/dnssec-signzone.html new file mode 100644 index 000000000000..221099fbdbec --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssec-signzone.html @@ -0,0 +1,553 @@ + + + + + +dnssec-signzone

dnssec-signzone

Name

dnssec-signzone -- DNSSEC zone signing tool

Synopsis

dnssec-signzone [-a] [-c class] [-d directory] [-e end-time] [-f output-file] [-g] [-h] [-k key] [-l domain] [-i interval] [-n nthreads] [-o origin] [-p] [-r randomdev] [-s start-time] [-t] [-v level] [-z] {zonefile} [key...]

DESCRIPTION

dnssec-signzone signs a zone. It generates + NSEC and RRSIG records and produces a signed version of the + zone. The security status of delegations from the signed zone + (that is, whether the child zones are secure or not) is + determined by the presence or absence of a + keyset file for each child zone. +

OPTIONS

-a

Verify all generated signatures. +

-c class

Specifies the DNS class of the zone. +

-k key

Treat specified key as a key signing key ignoring any + key flags. This option may be specified multiple times. +

-l domain

Generate a DLV set in addition to the key (DNSKEY) and DS sets. + The domain is appended to the name of the records. +

-d directory

Look for keyset files in + directory as the directory +

-g

Generate DS records for child zones from keyset files. + Existing DS records will be removed. +

-s start-time

Specify the date and time when the generated RRSIG records + become valid. This can be either an absolute or relative + time. An absolute start time is indicated by a number + in YYYYMMDDHHMMSS notation; 20000530144500 denotes + 14:45:00 UTC on May 30th, 2000. A relative start time is + indicated by +N, which is N seconds from the current time. + If no start-time is specified, the current + time minus 1 hour (to allow for clock skew) is used. +

-e end-time

Specify the date and time when the generated RRSIG records + expire. As with start-time, an absolute + time is indicated in YYYYMMDDHHMMSS notation. A time relative + to the start time is indicated with +N, which is N seconds from + the start time. A time relative to the current time is + indicated with now+N. If no end-time is + specified, 30 days from the start time is used as a default. +

-f output-file

The name of the output file containing the signed zone. The + default is to append .signed to the + input file. +

-h

Prints a short summary of the options and arguments to + dnssec-signzone. +

-i interval

When a previously signed zone is passed as input, records + may be resigned. The interval option + specifies the cycle interval as an offset from the current + time (in seconds). If a RRSIG record expires after the + cycle interval, it is retained. Otherwise, it is considered + to be expiring soon, and it will be replaced. +

The default cycle interval is one quarter of the difference + between the signature end and start times. So if neither + end-time or start-time + are specified, dnssec-signzone generates + signatures that are valid for 30 days, with a cycle + interval of 7.5 days. Therefore, if any existing RRSIG records + are due to expire in less than 7.5 days, they would be + replaced. +

-n ncpus

Specifies the number of threads to use. By default, one + thread is started for each detected CPU. +

-o origin

The zone origin. If not specified, the name of the zone file + is assumed to be the origin. +

-p

Use pseudo-random data when signing the zone. This is faster, + but less secure, than using real random data. This option + may be useful when signing large zones or when the entropy + source is limited. +

-r randomdev

Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. +

-t

Print statistics at completion. +

-v level

Sets the debugging level. +

-z

Ignore KSK flag on key when determining what to sign. +

zonefile

The file containing the zone to be signed. + Sets the debugging level. +

key

The keys used to sign the zone. If no keys are specified, the + default all zone keys that have private key files in the + current directory. +

EXAMPLE

The following command signs the example.com + zone with the DSA key generated in the dnssec-keygen + man page. The zone's keys must be in the zone. If there are + keyset files associated with child zones, + they must be in the current directory. + example.com, the following command would be + issued: +

dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160 +

The command would print a string of the form: +

In this example, dnssec-signzone creates + the file db.example.com.signed. This file + should be referenced in a zone statement in a + named.conf file. +

SEE ALSO

dnssec-keygen(8), + BIND 9 Administrator Reference Manual, + RFC 2535. +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/dnssec/dnssectool.c b/contrib/bind9/bin/dnssec/dnssectool.c new file mode 100644 index 000000000000..1b84de8f48aa --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssectool.c @@ -0,0 +1,305 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001, 2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dnssectool.c,v 1.31.2.3.2.4 2004/03/08 02:07:38 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "dnssectool.h" + +extern int verbose; +extern const char *program; + +typedef struct entropysource entropysource_t; + +struct entropysource { + isc_entropysource_t *source; + isc_mem_t *mctx; + ISC_LINK(entropysource_t) link; +}; + +static ISC_LIST(entropysource_t) sources; +static fatalcallback_t *fatalcallback = NULL; + +void +fatal(const char *format, ...) { + va_list args; + + fprintf(stderr, "%s: ", program); + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + fprintf(stderr, "\n"); + if (fatalcallback != NULL) + (*fatalcallback)(); + exit(1); +} + +void +setfatalcallback(fatalcallback_t *callback) { + fatalcallback = callback; +} + +void +check_result(isc_result_t result, const char *message) { + if (result != ISC_R_SUCCESS) + fatal("%s: %s", message, isc_result_totext(result)); +} + +void +vbprintf(int level, const char *fmt, ...) { + va_list ap; + if (level > verbose) + return; + va_start(ap, fmt); + fprintf(stderr, "%s: ", program); + vfprintf(stderr, fmt, ap); + va_end(ap); +} + +void +type_format(const dns_rdatatype_t type, char *cp, unsigned int size) { + isc_buffer_t b; + isc_region_t r; + isc_result_t result; + + isc_buffer_init(&b, cp, size - 1); + result = dns_rdatatype_totext(type, &b); + check_result(result, "dns_rdatatype_totext()"); + isc_buffer_usedregion(&b, &r); + r.base[r.length] = 0; +} + +void +alg_format(const dns_secalg_t alg, char *cp, unsigned int size) { + isc_buffer_t b; + isc_region_t r; + isc_result_t result; + + isc_buffer_init(&b, cp, size - 1); + result = dns_secalg_totext(alg, &b); + check_result(result, "dns_secalg_totext()"); + isc_buffer_usedregion(&b, &r); + r.base[r.length] = 0; +} + +void +sig_format(dns_rdata_rrsig_t *sig, char *cp, unsigned int size) { + char namestr[DNS_NAME_FORMATSIZE]; + char algstr[DNS_NAME_FORMATSIZE]; + + dns_name_format(&sig->signer, namestr, sizeof(namestr)); + alg_format(sig->algorithm, algstr, sizeof(algstr)); + snprintf(cp, size, "%s/%s/%d", namestr, algstr, sig->keyid); +} + +void +key_format(const dst_key_t *key, char *cp, unsigned int size) { + char namestr[DNS_NAME_FORMATSIZE]; + char algstr[DNS_NAME_FORMATSIZE]; + + dns_name_format(dst_key_name(key), namestr, sizeof(namestr)); + alg_format((dns_secalg_t) dst_key_alg(key), algstr, sizeof(algstr)); + snprintf(cp, size, "%s/%s/%d", namestr, algstr, dst_key_id(key)); +} + +void +setup_logging(int verbose, isc_mem_t *mctx, isc_log_t **logp) { + isc_result_t result; + isc_logdestination_t destination; + isc_logconfig_t *logconfig = NULL; + isc_log_t *log = NULL; + int level; + + switch (verbose) { + case 0: + /* + * We want to see warnings about things like out-of-zone + * data in the master file even when not verbose. + */ + level = ISC_LOG_WARNING; + break; + case 1: + level = ISC_LOG_INFO; + break; + default: + level = ISC_LOG_DEBUG(verbose - 2 + 1); + break; + } + + RUNTIME_CHECK(isc_log_create(mctx, &log, &logconfig) == ISC_R_SUCCESS); + isc_log_setcontext(log); + dns_log_init(log); + dns_log_setcontext(log); + + RUNTIME_CHECK(isc_log_settag(logconfig, program) == ISC_R_SUCCESS); + + /* + * Set up a channel similar to default_stderr except: + * - the logging level is passed in + * - the program name and logging level are printed + * - no time stamp is printed + */ + destination.file.stream = stderr; + destination.file.name = NULL; + destination.file.versions = ISC_LOG_ROLLNEVER; + destination.file.maximum_size = 0; + result = isc_log_createchannel(logconfig, "stderr", + ISC_LOG_TOFILEDESC, + level, + &destination, + ISC_LOG_PRINTTAG|ISC_LOG_PRINTLEVEL); + check_result(result, "isc_log_createchannel()"); + + RUNTIME_CHECK(isc_log_usechannel(logconfig, "stderr", + NULL, NULL) == ISC_R_SUCCESS); + + *logp = log; +} + +void +cleanup_logging(isc_log_t **logp) { + isc_log_t *log; + + REQUIRE(logp != NULL); + + log = *logp; + if (log == NULL) + return; + isc_log_destroy(&log); + isc_log_setcontext(NULL); + dns_log_setcontext(NULL); + logp = NULL; +} + +void +setup_entropy(isc_mem_t *mctx, const char *randomfile, isc_entropy_t **ectx) { + isc_result_t result; + isc_entropysource_t *source = NULL; + entropysource_t *elt; + int usekeyboard = ISC_ENTROPY_KEYBOARDMAYBE; + + REQUIRE(ectx != NULL); + + if (*ectx == NULL) { + result = isc_entropy_create(mctx, ectx); + if (result != ISC_R_SUCCESS) + fatal("could not create entropy object"); + ISC_LIST_INIT(sources); + } + + if (randomfile != NULL && strcmp(randomfile, "keyboard") == 0) { + usekeyboard = ISC_ENTROPY_KEYBOARDYES; + randomfile = NULL; + } + + result = isc_entropy_usebestsource(*ectx, &source, randomfile, + usekeyboard); + + if (result != ISC_R_SUCCESS) + fatal("could not initialize entropy source: %s", + isc_result_totext(result)); + + if (source != NULL) { + elt = isc_mem_get(mctx, sizeof(*elt)); + if (elt == NULL) + fatal("out of memory"); + elt->source = source; + elt->mctx = mctx; + ISC_LINK_INIT(elt, link); + ISC_LIST_APPEND(sources, elt, link); + } +} + +void +cleanup_entropy(isc_entropy_t **ectx) { + entropysource_t *source; + while (!ISC_LIST_EMPTY(sources)) { + source = ISC_LIST_HEAD(sources); + ISC_LIST_UNLINK(sources, source, link); + isc_entropy_destroysource(&source->source); + isc_mem_put(source->mctx, source, sizeof(*source)); + } + isc_entropy_detach(ectx); +} + +isc_stdtime_t +strtotime(const char *str, isc_int64_t now, isc_int64_t base) { + isc_int64_t val, offset; + isc_result_t result; + char *endp; + + if (str[0] == '+') { + offset = strtol(str + 1, &endp, 0); + if (*endp != '\0') + fatal("time value %s is invalid", str); + val = base + offset; + } else if (strncmp(str, "now+", 4) == 0) { + offset = strtol(str + 4, &endp, 0); + if (*endp != '\0') + fatal("time value %s is invalid", str); + val = now + offset; + } else if (strlen(str) == 8U) { + char timestr[15]; + sprintf(timestr, "%s000000", str); + result = dns_time64_fromtext(timestr, &val); + if (result != ISC_R_SUCCESS) + fatal("time value %s is invalid", str); + } else { + result = dns_time64_fromtext(str, &val); + if (result != ISC_R_SUCCESS) + fatal("time value %s is invalid", str); + } + + return ((isc_stdtime_t) val); +} + +dns_rdataclass_t +strtoclass(const char *str) { + isc_textregion_t r; + dns_rdataclass_t rdclass; + isc_result_t ret; + + if (str == NULL) + return dns_rdataclass_in; + DE_CONST(str, r.base); + r.length = strlen(str); + ret = dns_rdataclass_fromtext(&rdclass, &r); + if (ret != ISC_R_SUCCESS) + fatal("unknown class %s", str); + return (rdclass); +} diff --git a/contrib/bind9/bin/dnssec/dnssectool.h b/contrib/bind9/bin/dnssec/dnssectool.h new file mode 100644 index 000000000000..0d179503b766 --- /dev/null +++ b/contrib/bind9/bin/dnssec/dnssectool.h @@ -0,0 +1,76 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001, 2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: dnssectool.h,v 1.15.12.3 2004/03/08 04:04:18 marka Exp $ */ + +#ifndef DNSSECTOOL_H +#define DNSSECTOOL_H 1 + +#include +#include +#include +#include + +typedef void (fatalcallback_t)(void); + +void +fatal(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +void +setfatalcallback(fatalcallback_t *callback); + +void +check_result(isc_result_t result, const char *message); + +void +vbprintf(int level, const char *fmt, ...) ISC_FORMAT_PRINTF(2, 3); + +void +type_format(const dns_rdatatype_t type, char *cp, unsigned int size); +#define TYPE_FORMATSIZE 10 + +void +alg_format(const dns_secalg_t alg, char *cp, unsigned int size); +#define ALG_FORMATSIZE 10 + +void +sig_format(dns_rdata_rrsig_t *sig, char *cp, unsigned int size); +#define SIG_FORMATSIZE (DNS_NAME_FORMATSIZE + ALG_FORMATSIZE + sizeof("65535")) + +void +key_format(const dst_key_t *key, char *cp, unsigned int size); +#define KEY_FORMATSIZE (DNS_NAME_FORMATSIZE + ALG_FORMATSIZE + sizeof("65535")) + +void +setup_logging(int verbose, isc_mem_t *mctx, isc_log_t **logp); + +void +cleanup_logging(isc_log_t **logp); + +void +setup_entropy(isc_mem_t *mctx, const char *randomfile, isc_entropy_t **ectx); + +void +cleanup_entropy(isc_entropy_t **ectx); + +isc_stdtime_t +strtotime(const char *str, isc_int64_t now, isc_int64_t base); + +dns_rdataclass_t +strtoclass(const char *str); + +#endif /* DNSSEC_DNSSECTOOL_H */ diff --git a/contrib/bind9/bin/named/Makefile.in b/contrib/bind9/bin/named/Makefile.in new file mode 100644 index 000000000000..d95351a03a14 --- /dev/null +++ b/contrib/bind9/bin/named/Makefile.in @@ -0,0 +1,131 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 1998-2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.74.12.10 2004/08/21 06:22:40 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_VERSION@ + +@BIND9_MAKE_INCLUDES@ + +# +# Add database drivers here. +# +DBDRIVER_OBJS = +DBDRIVER_SRCS = +DBDRIVER_INCLUDES = +DBDRIVER_LIBS = + +CINCLUDES = -I${srcdir}/include -I${srcdir}/unix/include \ + ${LWRES_INCLUDES} ${DNS_INCLUDES} ${BIND9_INCLUDES} \ + ${ISCCFG_INCLUDES} ${ISCCC_INCLUDES} ${ISC_INCLUDES} \ + ${DBDRIVER_INCLUDES} + +CDEFINES = +CWARNINGS = + +DNSLIBS = ../../lib/dns/libdns.@A@ @DNS_CRYPTO_LIBS@ +ISCCFGLIBS = ../../lib/isccfg/libisccfg.@A@ +ISCCCLIBS = ../../lib/isccc/libisccc.@A@ +ISCLIBS = ../../lib/isc/libisc.@A@ +LWRESLIBS = ../../lib/lwres/liblwres.@A@ +BIND9LIBS = ../../lib/bind9/libbind9.@A@ + +DNSDEPLIBS = ../../lib/dns/libdns.@A@ +ISCCFGDEPLIBS = ../../lib/isccfg/libisccfg.@A@ +ISCCCDEPLIBS = ../../lib/isccc/libisccc.@A@ +ISCDEPLIBS = ../../lib/isc/libisc.@A@ +LWRESDEPLIBS = ../../lib/lwres/liblwres.@A@ +BIND9DEPLIBS = ../../lib/bind9/libbind9.@A@ + +DEPLIBS = ${LWRESDEPLIBS} ${DNSDEPLIBS} ${BIND9DEPLIBS} \ + ${ISCCFGDEPLIBS} ${ISCCCDEPLIBS} ${ISCDEPLIBS} + +LIBS = ${LWRESLIBS} ${DNSLIBS} ${BIND9LIBS} \ + ${ISCCFGLIBS} ${ISCCCLIBS} ${ISCLIBS} ${DBDRIVER_LIBS} @LIBS@ + +SUBDIRS = unix + +TARGETS = named@EXEEXT@ lwresd@EXEEXT@ + +OBJS = aclconf.@O@ builtin.@O@ client.@O@ config.@O@ control.@O@ \ + controlconf.@O@ interfacemgr.@O@ \ + listenlist.@O@ log.@O@ logconf.@O@ main.@O@ notify.@O@ \ + query.@O@ server.@O@ sortlist.@O@ \ + tkeyconf.@O@ tsigconf.@O@ update.@O@ xfrout.@O@ \ + zoneconf.@O@ \ + lwaddr.@O@ lwresd.@O@ lwdclient.@O@ lwderror.@O@ lwdgabn.@O@ \ + lwdgnba.@O@ lwdgrbn.@O@ lwdnoop.@O@ lwsearch.@O@ \ + $(DBDRIVER_OBJS) + +UOBJS = unix/os.@O@ + +SRCS = aclconf.c builtin.c client.c config.c control.c \ + controlconf.c interfacemgr.c \ + listenlist.c log.c logconf.c main.c notify.c \ + query.c server.c sortlist.c \ + tkeyconf.c tsigconf.c update.c xfrout.c \ + zoneconf.c \ + lwaddr.c lwresd.c lwdclient.c lwderror.c lwdgabn.c \ + lwdgnba.c lwdgrbn.c lwdnoop.c lwsearch.c \ + $(DBDRIVER_SRCS) + +MANPAGES = named.8 lwresd.8 named.conf.5 + +HTMLPAGES = named.html lwresd.html named.conf.html + +MANOBJS = ${MANPAGES} ${HTMLPAGES} + +@BIND9_MAKE_RULES@ + +main.@O@: main.c + ${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} \ + -DVERSION=\"${VERSION}\" \ + -DNS_LOCALSTATEDIR=\"${localstatedir}\" \ + -DNS_SYSCONFDIR=\"${sysconfdir}\" -c ${srcdir}/main.c + +config.@O@: config.c + ${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} \ + -DVERSION=\"${VERSION}\" \ + -DNS_LOCALSTATEDIR=\"${localstatedir}\" \ + -c ${srcdir}/config.c + +named@EXEEXT@: ${OBJS} ${UOBJS} ${DEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ + ${OBJS} ${UOBJS} ${LIBS} + +lwresd@EXEEXT@: named@EXEEXT@ + rm -f lwresd@EXEEXT@ + @LN@ named@EXEEXT@ lwresd@EXEEXT@ + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f ${MANOBJS} + +clean distclean maintainer-clean:: + rm -f ${TARGETS} ${OBJS} + +installdirs: + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${sbindir} + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man8 + +install:: named@EXEEXT@ lwresd@EXEEXT@ installdirs + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} named@EXEEXT@ ${DESTDIR}${sbindir} + (cd ${DESTDIR}${sbindir}; rm -f lwresd@EXEEXT@; @LN@ named@EXEEXT@ lwresd@EXEEXT@) + for m in ${MANPAGES}; do ${INSTALL_DATA} ${srcdir}/$$m ${DESTDIR}${mandir}/man8; done diff --git a/contrib/bind9/bin/named/aclconf.c b/contrib/bind9/bin/named/aclconf.c new file mode 100644 index 000000000000..ef36c5681f48 --- /dev/null +++ b/contrib/bind9/bin/named/aclconf.c @@ -0,0 +1,233 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: aclconf.c,v 1.27.12.3 2004/03/08 04:04:18 marka Exp $ */ + +#include + +#include +#include /* Required for HP/UX (and others?) */ +#include + +#include + +#include +#include +#include + +#include + +void +ns_aclconfctx_init(ns_aclconfctx_t *ctx) { + ISC_LIST_INIT(ctx->named_acl_cache); +} + +void +ns_aclconfctx_destroy(ns_aclconfctx_t *ctx) { + dns_acl_t *dacl, *next; + for (dacl = ISC_LIST_HEAD(ctx->named_acl_cache); + dacl != NULL; + dacl = next) + { + next = ISC_LIST_NEXT(dacl, nextincache); + dns_acl_detach(&dacl); + } +} + +/* + * Find the definition of the named acl whose name is "name". + */ +static isc_result_t +get_acl_def(cfg_obj_t *cctx, char *name, cfg_obj_t **ret) { + isc_result_t result; + cfg_obj_t *acls = NULL; + cfg_listelt_t *elt; + + result = cfg_map_get(cctx, "acl", &acls); + if (result != ISC_R_SUCCESS) + return (result); + for (elt = cfg_list_first(acls); + elt != NULL; + elt = cfg_list_next(elt)) { + cfg_obj_t *acl = cfg_listelt_value(elt); + const char *aclname = cfg_obj_asstring(cfg_tuple_get(acl, "name")); + if (strcasecmp(aclname, name) == 0) { + *ret = cfg_tuple_get(acl, "value"); + return (ISC_R_SUCCESS); + } + } + return (ISC_R_NOTFOUND); +} + +static isc_result_t +convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx, + ns_aclconfctx_t *ctx, isc_mem_t *mctx, + dns_acl_t **target) +{ + isc_result_t result; + cfg_obj_t *cacl = NULL; + dns_acl_t *dacl; + char *aclname = cfg_obj_asstring(nameobj); + + /* Look for an already-converted version. */ + for (dacl = ISC_LIST_HEAD(ctx->named_acl_cache); + dacl != NULL; + dacl = ISC_LIST_NEXT(dacl, nextincache)) + { + if (strcasecmp(aclname, dacl->name) == 0) { + dns_acl_attach(dacl, target); + return (ISC_R_SUCCESS); + } + } + /* Not yet converted. Convert now. */ + result = get_acl_def(cctx, aclname, &cacl); + if (result != ISC_R_SUCCESS) { + cfg_obj_log(nameobj, dns_lctx, ISC_LOG_WARNING, + "undefined ACL '%s'", aclname); + return (result); + } + result = ns_acl_fromconfig(cacl, cctx, ctx, mctx, &dacl); + if (result != ISC_R_SUCCESS) + return (result); + dacl->name = isc_mem_strdup(dacl->mctx, aclname); + if (dacl->name == NULL) + return (ISC_R_NOMEMORY); + ISC_LIST_APPEND(ctx->named_acl_cache, dacl, nextincache); + dns_acl_attach(dacl, target); + return (ISC_R_SUCCESS); +} + +static isc_result_t +convert_keyname(cfg_obj_t *keyobj, isc_mem_t *mctx, dns_name_t *dnsname) { + isc_result_t result; + isc_buffer_t buf; + dns_fixedname_t fixname; + unsigned int keylen; + const char *txtname = cfg_obj_asstring(keyobj); + + keylen = strlen(txtname); + isc_buffer_init(&buf, txtname, keylen); + isc_buffer_add(&buf, keylen); + dns_fixedname_init(&fixname); + result = dns_name_fromtext(dns_fixedname_name(&fixname), &buf, + dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) { + cfg_obj_log(keyobj, dns_lctx, ISC_LOG_WARNING, + "key name '%s' is not a valid domain name", + txtname); + return (result); + } + return (dns_name_dup(dns_fixedname_name(&fixname), mctx, dnsname)); +} + +isc_result_t +ns_acl_fromconfig(cfg_obj_t *caml, + cfg_obj_t *cctx, + ns_aclconfctx_t *ctx, + isc_mem_t *mctx, + dns_acl_t **target) +{ + isc_result_t result; + unsigned int count; + dns_acl_t *dacl = NULL; + dns_aclelement_t *de; + cfg_listelt_t *elt; + + REQUIRE(target != NULL && *target == NULL); + + count = 0; + for (elt = cfg_list_first(caml); + elt != NULL; + elt = cfg_list_next(elt)) + count++; + + result = dns_acl_create(mctx, count, &dacl); + if (result != ISC_R_SUCCESS) + return (result); + + de = dacl->elements; + for (elt = cfg_list_first(caml); + elt != NULL; + elt = cfg_list_next(elt)) + { + cfg_obj_t *ce = cfg_listelt_value(elt); + if (cfg_obj_istuple(ce)) { + /* This must be a negated element. */ + ce = cfg_tuple_get(ce, "value"); + de->negative = ISC_TRUE; + } else { + de->negative = ISC_FALSE; + } + + if (cfg_obj_isnetprefix(ce)) { + /* Network prefix */ + de->type = dns_aclelementtype_ipprefix; + + cfg_obj_asnetprefix(ce, + &de->u.ip_prefix.address, + &de->u.ip_prefix.prefixlen); + } else if (cfg_obj_istype(ce, &cfg_type_keyref)) { + /* Key name */ + de->type = dns_aclelementtype_keyname; + dns_name_init(&de->u.keyname, NULL); + result = convert_keyname(ce, mctx, &de->u.keyname); + if (result != ISC_R_SUCCESS) + goto cleanup; + } else if (cfg_obj_islist(ce)) { + /* Nested ACL */ + de->type = dns_aclelementtype_nestedacl; + result = ns_acl_fromconfig(ce, cctx, ctx, mctx, + &de->u.nestedacl); + if (result != ISC_R_SUCCESS) + goto cleanup; + } else if (cfg_obj_isstring(ce)) { + /* ACL name */ + char *name = cfg_obj_asstring(ce); + if (strcasecmp(name, "localhost") == 0) { + de->type = dns_aclelementtype_localhost; + } else if (strcasecmp(name, "localnets") == 0) { + de->type = dns_aclelementtype_localnets; + } else if (strcasecmp(name, "any") == 0) { + de->type = dns_aclelementtype_any; + } else if (strcasecmp(name, "none") == 0) { + de->type = dns_aclelementtype_any; + de->negative = ISC_TF(! de->negative); + } else { + de->type = dns_aclelementtype_nestedacl; + result = convert_named_acl(ce, cctx, ctx, mctx, + &de->u.nestedacl); + if (result != ISC_R_SUCCESS) + goto cleanup; + } + } else { + cfg_obj_log(ce, dns_lctx, ISC_LOG_WARNING, + "address match list contains " + "unsupported element type"); + result = ISC_R_FAILURE; + goto cleanup; + } + de++; + dacl->length++; + } + + *target = dacl; + return (ISC_R_SUCCESS); + + cleanup: + dns_acl_detach(&dacl); + return (result); +} diff --git a/contrib/bind9/bin/named/builtin.c b/contrib/bind9/bin/named/builtin.c new file mode 100644 index 000000000000..af4d7a3f0d43 --- /dev/null +++ b/contrib/bind9/bin/named/builtin.c @@ -0,0 +1,228 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: builtin.c,v 1.4.106.4 2004/03/08 04:04:18 marka Exp $ */ + +/* + * The built-in "version", "hostname", "id" and "authors" databases. + */ + +#include + +#include +#include + +#include +#include +#include + +#include +#include + +#include +#include +#include +#include + +typedef struct builtin builtin_t; + +static isc_result_t do_version_lookup(dns_sdblookup_t *lookup); +static isc_result_t do_hostname_lookup(dns_sdblookup_t *lookup); +static isc_result_t do_authors_lookup(dns_sdblookup_t *lookup); +static isc_result_t do_id_lookup(dns_sdblookup_t *lookup); + +/* + * We can't use function pointers as the db_data directly + * because ANSI C does not guarantee that function pointers + * can safely be cast to void pointers and back. + */ + +struct builtin { + isc_result_t (*do_lookup)(dns_sdblookup_t *lookup); +}; + +static builtin_t version_builtin = { do_version_lookup }; +static builtin_t hostname_builtin = { do_hostname_lookup }; +static builtin_t authors_builtin = { do_authors_lookup }; +static builtin_t id_builtin = { do_id_lookup }; + +static dns_sdbimplementation_t *builtin_impl; + +static isc_result_t +builtin_lookup(const char *zone, const char *name, void *dbdata, + dns_sdblookup_t *lookup) +{ + builtin_t *b = (builtin_t *) dbdata; + + UNUSED(zone); + + if (strcmp(name, "@") == 0) + return (b->do_lookup(lookup)); + else + return (ISC_R_NOTFOUND); +} + +static isc_result_t +put_txt(dns_sdblookup_t *lookup, const char *text) { + unsigned char buf[256]; + unsigned int len = strlen(text); + if (len > 255) + len = 255; /* Silently truncate */ + buf[0] = len; + memcpy(&buf[1], text, len); + return (dns_sdb_putrdata(lookup, dns_rdatatype_txt, 0, buf, len + 1)); +} + +static isc_result_t +do_version_lookup(dns_sdblookup_t *lookup) { + if (ns_g_server->version_set) { + if (ns_g_server->version == NULL) + return (ISC_R_SUCCESS); + else + return (put_txt(lookup, ns_g_server->version)); + } else { + return (put_txt(lookup, ns_g_version)); + } +} + +static isc_result_t +do_hostname_lookup(dns_sdblookup_t *lookup) { + if (ns_g_server->hostname_set) { + if (ns_g_server->hostname == NULL) + return (ISC_R_SUCCESS); + else + return (put_txt(lookup, ns_g_server->hostname)); + } else { + char buf[256]; + isc_result_t result = ns_os_gethostname(buf, sizeof(buf)); + if (result != ISC_R_SUCCESS) + return (result); + return (put_txt(lookup, buf)); + } +} + +static isc_result_t +do_authors_lookup(dns_sdblookup_t *lookup) { + isc_result_t result; + const char **p; + static const char *authors[] = { + "Mark Andrews", + "James Brister", + "Ben Cottrell", + "Michael Graff", + "Andreas Gustafsson", + "Bob Halley", + "David Lawrence", + "Danny Mayer", + "Damien Neil", + "Matt Nelson", + "Michael Sawyer", + "Brian Wellington", + NULL + }; + + /* + * If a version string is specified, disable the authors.bind zone. + */ + if (ns_g_server->version_set) + return (ISC_R_SUCCESS); + + for (p = authors; *p != NULL; p++) { + result = put_txt(lookup, *p); + if (result != ISC_R_SUCCESS) + return (result); + } + return (ISC_R_SUCCESS); +} + +static isc_result_t +do_id_lookup(dns_sdblookup_t *lookup) { + + if (ns_g_server->server_usehostname) { + char buf[256]; + isc_result_t result = ns_os_gethostname(buf, sizeof(buf)); + if (result != ISC_R_SUCCESS) + return (result); + return (put_txt(lookup, buf)); + } + + if (ns_g_server->server_id == NULL) + return (ISC_R_SUCCESS); + else + return (put_txt(lookup, ns_g_server->server_id)); +} + +static isc_result_t +builtin_authority(const char *zone, void *dbdata, dns_sdblookup_t *lookup) { + isc_result_t result; + + UNUSED(zone); + UNUSED(dbdata); + + result = dns_sdb_putsoa(lookup, "@", "hostmaster", 0); + if (result != ISC_R_SUCCESS) + return (ISC_R_FAILURE); + result = dns_sdb_putrr(lookup, "ns", 0, "@"); + if (result != ISC_R_SUCCESS) + return (ISC_R_FAILURE); + + return (ISC_R_SUCCESS); +} + +static isc_result_t +builtin_create(const char *zone, int argc, char **argv, + void *driverdata, void **dbdata) +{ + UNUSED(zone); + UNUSED(driverdata); + if (argc != 1) + return (DNS_R_SYNTAX); + if (strcmp(argv[0], "version") == 0) + *dbdata = &version_builtin; + else if (strcmp(argv[0], "hostname") == 0) + *dbdata = &hostname_builtin; + else if (strcmp(argv[0], "authors") == 0) + *dbdata = &authors_builtin; + else if (strcmp(argv[0], "id") == 0) + *dbdata = &id_builtin; + else + return (ISC_R_NOTIMPLEMENTED); + return (ISC_R_SUCCESS); +} + +static dns_sdbmethods_t builtin_methods = { + builtin_lookup, + builtin_authority, + NULL, /* allnodes */ + builtin_create, + NULL /* destroy */ +}; + +isc_result_t +ns_builtin_init(void) { + RUNTIME_CHECK(dns_sdb_register("_builtin", &builtin_methods, NULL, + DNS_SDBFLAG_RELATIVEOWNER | + DNS_SDBFLAG_RELATIVERDATA, + ns_g_mctx, &builtin_impl) + == ISC_R_SUCCESS); + return (ISC_R_SUCCESS); +} + +void +ns_builtin_deinit(void) { + dns_sdb_unregister(&builtin_impl); +} diff --git a/contrib/bind9/bin/named/client.c b/contrib/bind9/bin/named/client.c new file mode 100644 index 000000000000..acb9b21de546 --- /dev/null +++ b/contrib/bind9/bin/named/client.c @@ -0,0 +1,2361 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: client.c,v 1.176.2.13.4.22 2004/07/23 02:56:51 marka Exp $ */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/*** + *** Client + ***/ + +/* + * Important note! + * + * All client state changes, other than that from idle to listening, occur + * as a result of events. This guarantees serialization and avoids the + * need for locking. + * + * If a routine is ever created that allows someone other than the client's + * task to change the client, then the client will have to be locked. + */ + +#define NS_CLIENT_TRACE +#ifdef NS_CLIENT_TRACE +#define CTRACE(m) ns_client_log(client, \ + NS_LOGCATEGORY_CLIENT, \ + NS_LOGMODULE_CLIENT, \ + ISC_LOG_DEBUG(3), \ + "%s", (m)) +#define MTRACE(m) isc_log_write(ns_g_lctx, \ + NS_LOGCATEGORY_GENERAL, \ + NS_LOGMODULE_CLIENT, \ + ISC_LOG_DEBUG(3), \ + "clientmgr @%p: %s", manager, (m)) +#else +#define CTRACE(m) ((void)(m)) +#define MTRACE(m) ((void)(m)) +#endif + +#define TCP_CLIENT(c) (((c)->attributes & NS_CLIENTATTR_TCP) != 0) + +#define TCP_BUFFER_SIZE (65535 + 2) +#define SEND_BUFFER_SIZE 4096 +#define RECV_BUFFER_SIZE 4096 + +struct ns_clientmgr { + /* Unlocked. */ + unsigned int magic; + isc_mem_t * mctx; + isc_taskmgr_t * taskmgr; + isc_timermgr_t * timermgr; + isc_mutex_t lock; + /* Locked by lock. */ + isc_boolean_t exiting; + client_list_t active; /* Active clients */ + client_list_t recursing; /* Recursing clients */ + client_list_t inactive; /* To be recycled */ +}; + +#define MANAGER_MAGIC ISC_MAGIC('N', 'S', 'C', 'm') +#define VALID_MANAGER(m) ISC_MAGIC_VALID(m, MANAGER_MAGIC) + +/* + * Client object states. Ordering is significant: higher-numbered + * states are generally "more active", meaning that the client can + * have more dynamically allocated data, outstanding events, etc. + * In the list below, any such properties listed for state N + * also apply to any state > N. + * + * To force the client into a less active state, set client->newstate + * to that state and call exit_check(). This will cause any + * activities defined for higher-numbered states to be aborted. + */ + +#define NS_CLIENTSTATE_FREED 0 +/* + * The client object no longer exists. + */ + +#define NS_CLIENTSTATE_INACTIVE 1 +/* + * The client object exists and has a task and timer. + * Its "query" struct and sendbuf are initialized. + * It is on the client manager's list of inactive clients. + * It has a message and OPT, both in the reset state. + */ + +#define NS_CLIENTSTATE_READY 2 +/* + * The client object is either a TCP or a UDP one, and + * it is associated with a network interface. It is on the + * client manager's list of active clients. + * + * If it is a TCP client object, it has a TCP listener socket + * and an outstanding TCP listen request. + * + * If it is a UDP client object, it has a UDP listener socket + * and an outstanding UDP receive request. + */ + +#define NS_CLIENTSTATE_READING 3 +/* + * The client object is a TCP client object that has received + * a connection. It has a tcpsocket, tcpmsg, TCP quota, and an + * outstanding TCP read request. This state is not used for + * UDP client objects. + */ + +#define NS_CLIENTSTATE_WORKING 4 +/* + * The client object has received a request and is working + * on it. It has a view, and it may have any of a non-reset OPT, + * recursion quota, and an outstanding write request. + */ + +#define NS_CLIENTSTATE_MAX 9 +/* + * Sentinel value used to indicate "no state". When client->newstate + * has this value, we are not attempting to exit the current state. + * Must be greater than any valid state. + */ + + +static void client_read(ns_client_t *client); +static void client_accept(ns_client_t *client); +static void client_udprecv(ns_client_t *client); +static void clientmgr_destroy(ns_clientmgr_t *manager); +static isc_boolean_t exit_check(ns_client_t *client); +static void ns_client_endrequest(ns_client_t *client); +static void ns_client_checkactive(ns_client_t *client); +static void client_start(isc_task_t *task, isc_event_t *event); +static void client_request(isc_task_t *task, isc_event_t *event); +static void ns_client_dumpmessage(ns_client_t *client, const char *reason); + +void +ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest) { + ns_client_t *oldest; + REQUIRE(NS_CLIENT_VALID(client)); + + LOCK(&client->manager->lock); + if (killoldest) { + oldest = ISC_LIST_HEAD(client->manager->recursing); + if (oldest != NULL) { + ns_query_cancel(oldest); + ISC_LIST_UNLINK(*oldest->list, oldest, link); + ISC_LIST_APPEND(client->manager->active, oldest, link); + oldest->list = &client->manager->active; + } + } + ISC_LIST_UNLINK(*client->list, client, link); + ISC_LIST_APPEND(client->manager->recursing, client, link); + client->list = &client->manager->recursing; + UNLOCK(&client->manager->lock); +} + +void +ns_client_settimeout(ns_client_t *client, unsigned int seconds) { + isc_result_t result; + isc_interval_t interval; + + isc_interval_set(&interval, seconds, 0); + result = isc_timer_reset(client->timer, isc_timertype_once, NULL, + &interval, ISC_FALSE); + client->timerset = ISC_TRUE; + if (result != ISC_R_SUCCESS) { + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_ERROR, + "setting timeout: %s", + isc_result_totext(result)); + /* Continue anyway. */ + } +} + +/* + * Check for a deactivation or shutdown request and take appropriate + * action. Returns ISC_TRUE if either is in progress; in this case + * the caller must no longer use the client object as it may have been + * freed. + */ +static isc_boolean_t +exit_check(ns_client_t *client) { + ns_clientmgr_t *locked_manager = NULL; + ns_clientmgr_t *destroy_manager = NULL; + + REQUIRE(NS_CLIENT_VALID(client)); + + if (client->state <= client->newstate) + return (ISC_FALSE); /* Business as usual. */ + + INSIST(client->newstate < NS_CLIENTSTATE_WORKING); + + /* + * We need to detach from the view early when shutting down + * the server to break the following vicious circle: + * + * - The resolver will not shut down until the view refcount is zero + * - The view refcount does not go to zero until all clients detach + * - The client does not detach from the view until references is zero + * - references does not go to zero until the resolver has shut down + * + * Keep the view attached until any outstanding updates complete. + */ + if (client->nupdates == 0 && + client->newstate == NS_CLIENTSTATE_FREED && client->view != NULL) + dns_view_detach(&client->view); + + if (client->state == NS_CLIENTSTATE_WORKING) { + INSIST(client->newstate <= NS_CLIENTSTATE_READING); + /* + * Let the update processing complete. + */ + if (client->nupdates > 0) + return (ISC_TRUE); + /* + * We are trying to abort request processing. + */ + if (client->nsends > 0) { + isc_socket_t *socket; + if (TCP_CLIENT(client)) + socket = client->tcpsocket; + else + socket = client->udpsocket; + isc_socket_cancel(socket, client->task, + ISC_SOCKCANCEL_SEND); + } + + if (! (client->nsends == 0 && client->nrecvs == 0 && + client->references == 0)) + { + /* + * Still waiting for I/O cancel completion. + * or lingering references. + */ + return (ISC_TRUE); + } + /* + * I/O cancel is complete. Burn down all state + * related to the current request. + */ + ns_client_endrequest(client); + + client->state = NS_CLIENTSTATE_READING; + INSIST(client->recursionquota == NULL); + if (NS_CLIENTSTATE_READING == client->newstate) { + client_read(client); + client->newstate = NS_CLIENTSTATE_MAX; + return (ISC_TRUE); /* We're done. */ + } + } + + if (client->state == NS_CLIENTSTATE_READING) { + /* + * We are trying to abort the current TCP connection, + * if any. + */ + INSIST(client->recursionquota == NULL); + INSIST(client->newstate <= NS_CLIENTSTATE_READY); + if (client->nreads > 0) + dns_tcpmsg_cancelread(&client->tcpmsg); + if (! client->nreads == 0) { + /* Still waiting for read cancel completion. */ + return (ISC_TRUE); + } + + if (client->tcpmsg_valid) { + dns_tcpmsg_invalidate(&client->tcpmsg); + client->tcpmsg_valid = ISC_FALSE; + } + if (client->tcpsocket != NULL) { + CTRACE("closetcp"); + isc_socket_detach(&client->tcpsocket); + } + + if (client->tcpquota != NULL) + isc_quota_detach(&client->tcpquota); + + if (client->timerset) { + (void)isc_timer_reset(client->timer, + isc_timertype_inactive, + NULL, NULL, ISC_TRUE); + client->timerset = ISC_FALSE; + } + + client->peeraddr_valid = ISC_FALSE; + + client->state = NS_CLIENTSTATE_READY; + INSIST(client->recursionquota == NULL); + + /* + * Now the client is ready to accept a new TCP connection + * or UDP request, but we may have enough clients doing + * that already. Check whether this client needs to remain + * active and force it to go inactive if not. + */ + ns_client_checkactive(client); + + if (NS_CLIENTSTATE_READY == client->newstate) { + if (TCP_CLIENT(client)) { + client_accept(client); + } else + client_udprecv(client); + client->newstate = NS_CLIENTSTATE_MAX; + return (ISC_TRUE); + } + } + + if (client->state == NS_CLIENTSTATE_READY) { + INSIST(client->newstate <= NS_CLIENTSTATE_INACTIVE); + /* + * We are trying to enter the inactive state. + */ + if (client->naccepts > 0) + isc_socket_cancel(client->tcplistener, client->task, + ISC_SOCKCANCEL_ACCEPT); + + if (! (client->naccepts == 0)) { + /* Still waiting for accept cancel completion. */ + return (ISC_TRUE); + } + /* Accept cancel is complete. */ + + if (client->nrecvs > 0) + isc_socket_cancel(client->udpsocket, client->task, + ISC_SOCKCANCEL_RECV); + if (! (client->nrecvs == 0)) { + /* Still waiting for recv cancel completion. */ + return (ISC_TRUE); + } + /* Recv cancel is complete. */ + + if (client->nctls > 0) { + /* Still waiting for control event to be delivered */ + return (ISC_TRUE); + } + + /* Deactivate the client. */ + if (client->interface) + ns_interface_detach(&client->interface); + + INSIST(client->naccepts == 0); + INSIST(client->recursionquota == NULL); + if (client->tcplistener != NULL) + isc_socket_detach(&client->tcplistener); + + if (client->udpsocket != NULL) + isc_socket_detach(&client->udpsocket); + + if (client->dispatch != NULL) + dns_dispatch_detach(&client->dispatch); + + client->attributes = 0; + client->mortal = ISC_FALSE; + + LOCK(&client->manager->lock); + /* + * Put the client on the inactive list. If we are aiming for + * the "freed" state, it will be removed from the inactive + * list shortly, and we need to keep the manager locked until + * that has been done, lest the manager decide to reactivate + * the dying client inbetween. + */ + locked_manager = client->manager; + ISC_LIST_UNLINK(*client->list, client, link); + ISC_LIST_APPEND(client->manager->inactive, client, link); + client->list = &client->manager->inactive; + client->state = NS_CLIENTSTATE_INACTIVE; + INSIST(client->recursionquota == NULL); + + if (client->state == client->newstate) { + client->newstate = NS_CLIENTSTATE_MAX; + goto unlock; + } + } + + if (client->state == NS_CLIENTSTATE_INACTIVE) { + INSIST(client->newstate == NS_CLIENTSTATE_FREED); + /* + * We are trying to free the client. + * + * When "shuttingdown" is true, either the task has received + * its shutdown event or no shutdown event has ever been + * set up. Thus, we have no outstanding shutdown + * event at this point. + */ + REQUIRE(client->state == NS_CLIENTSTATE_INACTIVE); + + INSIST(client->recursionquota == NULL); + + ns_query_free(client); + isc_mem_put(client->mctx, client->recvbuf, RECV_BUFFER_SIZE); + isc_event_free((isc_event_t **)&client->sendevent); + isc_event_free((isc_event_t **)&client->recvevent); + isc_timer_detach(&client->timer); + + if (client->tcpbuf != NULL) + isc_mem_put(client->mctx, client->tcpbuf, TCP_BUFFER_SIZE); + if (client->opt != NULL) { + INSIST(dns_rdataset_isassociated(client->opt)); + dns_rdataset_disassociate(client->opt); + dns_message_puttemprdataset(client->message, &client->opt); + } + dns_message_destroy(&client->message); + if (client->manager != NULL) { + ns_clientmgr_t *manager = client->manager; + if (locked_manager == NULL) { + LOCK(&manager->lock); + locked_manager = manager; + } + ISC_LIST_UNLINK(*client->list, client, link); + client->list = NULL; + if (manager->exiting && + ISC_LIST_EMPTY(manager->active) && + ISC_LIST_EMPTY(manager->inactive) && + ISC_LIST_EMPTY(manager->recursing)) + destroy_manager = manager; + } + /* + * Detaching the task must be done after unlinking from + * the manager's lists because the manager accesses + * client->task. + */ + if (client->task != NULL) + isc_task_detach(&client->task); + + CTRACE("free"); + client->magic = 0; + isc_mem_put(client->mctx, client, sizeof(*client)); + + goto unlock; + } + + unlock: + if (locked_manager != NULL) { + UNLOCK(&locked_manager->lock); + locked_manager = NULL; + } + + /* + * Only now is it safe to destroy the client manager (if needed), + * because we have accessed its lock for the last time. + */ + if (destroy_manager != NULL) + clientmgr_destroy(destroy_manager); + + return (ISC_TRUE); +} + +/* + * The client's task has received the client's control event + * as part of the startup process. + */ +static void +client_start(isc_task_t *task, isc_event_t *event) { + ns_client_t *client = (ns_client_t *) event->ev_arg; + + INSIST(task == client->task); + + UNUSED(task); + + INSIST(client->nctls == 1); + client->nctls--; + + if (exit_check(client)) + return; + + if (TCP_CLIENT(client)) { + client_accept(client); + } else { + client_udprecv(client); + } +} + + +/* + * The client's task has received a shutdown event. + */ +static void +client_shutdown(isc_task_t *task, isc_event_t *event) { + ns_client_t *client; + + REQUIRE(event != NULL); + REQUIRE(event->ev_type == ISC_TASKEVENT_SHUTDOWN); + client = event->ev_arg; + REQUIRE(NS_CLIENT_VALID(client)); + REQUIRE(task == client->task); + + UNUSED(task); + + CTRACE("shutdown"); + + isc_event_free(&event); + + if (client->shutdown != NULL) { + (client->shutdown)(client->shutdown_arg, ISC_R_SHUTTINGDOWN); + client->shutdown = NULL; + client->shutdown_arg = NULL; + } + + client->newstate = NS_CLIENTSTATE_FREED; + (void)exit_check(client); +} + +static void +ns_client_endrequest(ns_client_t *client) { + INSIST(client->naccepts == 0); + INSIST(client->nreads == 0); + INSIST(client->nsends == 0); + INSIST(client->nrecvs == 0); + INSIST(client->nupdates == 0); + INSIST(client->state == NS_CLIENTSTATE_WORKING); + + CTRACE("endrequest"); + + if (client->next != NULL) { + (client->next)(client); + client->next = NULL; + } + + if (client->view != NULL) + dns_view_detach(&client->view); + if (client->opt != NULL) { + INSIST(dns_rdataset_isassociated(client->opt)); + dns_rdataset_disassociate(client->opt); + dns_message_puttemprdataset(client->message, &client->opt); + } + + client->udpsize = 512; + client->extflags = 0; + dns_message_reset(client->message, DNS_MESSAGE_INTENTPARSE); + + if (client->recursionquota != NULL) + isc_quota_detach(&client->recursionquota); + + /* + * Clear all client attributes that are specific to + * the request; that's all except the TCP flag. + */ + client->attributes &= NS_CLIENTATTR_TCP; +} + +static void +ns_client_checkactive(ns_client_t *client) { + if (client->mortal) { + /* + * This client object should normally go inactive + * at this point, but if we have fewer active client + * objects than desired due to earlier quota exhaustion, + * keep it active to make up for the shortage. + */ + isc_boolean_t need_another_client = ISC_FALSE; + if (TCP_CLIENT(client)) { + LOCK(&client->interface->lock); + if (client->interface->ntcpcurrent < + client->interface->ntcptarget) + need_another_client = ISC_TRUE; + UNLOCK(&client->interface->lock); + } else { + /* + * The UDP client quota is enforced by making + * requests fail rather than by not listening + * for new ones. Therefore, there is always a + * full set of UDP clients listening. + */ + } + if (! need_another_client) { + /* + * We don't need this client object. Recycle it. + */ + if (client->newstate >= NS_CLIENTSTATE_INACTIVE) + client->newstate = NS_CLIENTSTATE_INACTIVE; + } + } +} + +void +ns_client_next(ns_client_t *client, isc_result_t result) { + int newstate; + + REQUIRE(NS_CLIENT_VALID(client)); + REQUIRE(client->state == NS_CLIENTSTATE_WORKING || + client->state == NS_CLIENTSTATE_READING); + + CTRACE("next"); + + if (result != ISC_R_SUCCESS) + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3), + "request failed: %s", isc_result_totext(result)); + + /* + * An error processing a TCP request may have left + * the connection out of sync. To be safe, we always + * sever the connection when result != ISC_R_SUCCESS. + */ + if (result == ISC_R_SUCCESS && TCP_CLIENT(client)) + newstate = NS_CLIENTSTATE_READING; + else + newstate = NS_CLIENTSTATE_READY; + + if (client->newstate > newstate) + client->newstate = newstate; + (void)exit_check(client); +} + + +static void +client_senddone(isc_task_t *task, isc_event_t *event) { + ns_client_t *client; + isc_socketevent_t *sevent = (isc_socketevent_t *) event; + + REQUIRE(sevent != NULL); + REQUIRE(sevent->ev_type == ISC_SOCKEVENT_SENDDONE); + client = sevent->ev_arg; + REQUIRE(NS_CLIENT_VALID(client)); + REQUIRE(task == client->task); + REQUIRE(sevent == client->sendevent); + + UNUSED(task); + + CTRACE("senddone"); + + if (sevent->result != ISC_R_SUCCESS) + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_WARNING, + "error sending response: %s", + isc_result_totext(sevent->result)); + + INSIST(client->nsends > 0); + client->nsends--; + + if (client->tcpbuf != NULL) { + INSIST(TCP_CLIENT(client)); + isc_mem_put(client->mctx, client->tcpbuf, TCP_BUFFER_SIZE); + client->tcpbuf = NULL; + } + + if (exit_check(client)) + return; + + ns_client_next(client, ISC_R_SUCCESS); +} + +/* + * We only want to fail with ISC_R_NOSPACE when called from + * ns_client_sendraw() and not when called from ns_client_send(), + * tcpbuffer is NULL when called from ns_client_sendraw() and + * length != 0. tcpbuffer != NULL when called from ns_client_send() + * and length == 0. + */ + +static isc_result_t +client_allocsendbuf(ns_client_t *client, isc_buffer_t *buffer, + isc_buffer_t *tcpbuffer, isc_uint32_t length, + unsigned char *sendbuf, unsigned char **datap) +{ + unsigned char *data; + isc_uint32_t bufsize; + isc_result_t result; + + INSIST(datap != NULL); + INSIST((tcpbuffer == NULL && length != 0) || + (tcpbuffer != NULL && length == 0)); + + if (TCP_CLIENT(client)) { + INSIST(client->tcpbuf == NULL); + if (length + 2 > TCP_BUFFER_SIZE) { + result = ISC_R_NOSPACE; + goto done; + } + client->tcpbuf = isc_mem_get(client->mctx, TCP_BUFFER_SIZE); + if (client->tcpbuf == NULL) { + result = ISC_R_NOMEMORY; + goto done; + } + data = client->tcpbuf; + if (tcpbuffer != NULL) { + isc_buffer_init(tcpbuffer, data, TCP_BUFFER_SIZE); + isc_buffer_init(buffer, data + 2, TCP_BUFFER_SIZE - 2); + } else { + isc_buffer_init(buffer, data, TCP_BUFFER_SIZE); + INSIST(length <= 0xffff); + isc_buffer_putuint16(buffer, (isc_uint16_t)length); + } + } else { + data = sendbuf; + if (client->udpsize < SEND_BUFFER_SIZE) + bufsize = client->udpsize; + else + bufsize = SEND_BUFFER_SIZE; + if (length > bufsize) { + result = ISC_R_NOSPACE; + goto done; + } + isc_buffer_init(buffer, data, bufsize); + } + *datap = data; + result = ISC_R_SUCCESS; + + done: + return (result); +} + +static isc_result_t +client_sendpkg(ns_client_t *client, isc_buffer_t *buffer) { + struct in6_pktinfo *pktinfo; + isc_result_t result; + isc_region_t r; + isc_sockaddr_t *address; + isc_socket_t *socket; + isc_netaddr_t netaddr; + int match; + unsigned int sockflags = ISC_SOCKFLAG_IMMEDIATE; + + if (TCP_CLIENT(client)) { + socket = client->tcpsocket; + address = NULL; + } else { + socket = client->udpsocket; + address = &client->peeraddr; + + isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr); + if (ns_g_server->blackholeacl != NULL && + dns_acl_match(&netaddr, NULL, + ns_g_server->blackholeacl, + &ns_g_server->aclenv, + &match, NULL) == ISC_R_SUCCESS && + match > 0) + return (DNS_R_BLACKHOLED); + sockflags |= ISC_SOCKFLAG_NORETRY; + } + + if ((client->attributes & NS_CLIENTATTR_PKTINFO) != 0 && + (client->attributes & NS_CLIENTATTR_MULTICAST) == 0) + pktinfo = &client->pktinfo; + else + pktinfo = NULL; + + isc_buffer_usedregion(buffer, &r); + + CTRACE("sendto"); + + result = isc_socket_sendto2(socket, &r, client->task, + address, pktinfo, + client->sendevent, sockflags); + if (result == ISC_R_SUCCESS || result == ISC_R_INPROGRESS) { + client->nsends++; + if (result == ISC_R_SUCCESS) + client_senddone(client->task, + (isc_event_t *)client->sendevent); + result = ISC_R_SUCCESS; + } + return (result); +} + +void +ns_client_sendraw(ns_client_t *client, dns_message_t *message) { + isc_result_t result; + unsigned char *data; + isc_buffer_t buffer; + isc_region_t r; + isc_region_t *mr; + unsigned char sendbuf[SEND_BUFFER_SIZE]; + + REQUIRE(NS_CLIENT_VALID(client)); + + CTRACE("sendraw"); + + mr = dns_message_getrawmessage(message); + if (mr == NULL) { + result = ISC_R_UNEXPECTEDEND; + goto done; + } + + result = client_allocsendbuf(client, &buffer, NULL, mr->length, + sendbuf, &data); + if (result != ISC_R_SUCCESS) + goto done; + + /* + * Copy message to buffer and fixup id. + */ + isc_buffer_availableregion(&buffer, &r); + result = isc_buffer_copyregion(&buffer, mr); + if (result != ISC_R_SUCCESS) + goto done; + r.base[0] = (client->message->id >> 8) & 0xff; + r.base[1] = client->message->id & 0xff; + + result = client_sendpkg(client, &buffer); + if (result == ISC_R_SUCCESS) + return; + + done: + if (client->tcpbuf != NULL) { + isc_mem_put(client->mctx, client->tcpbuf, TCP_BUFFER_SIZE); + client->tcpbuf = NULL; + } + ns_client_next(client, result); +} + +void +ns_client_send(ns_client_t *client) { + isc_result_t result; + unsigned char *data; + isc_buffer_t buffer; + isc_buffer_t tcpbuffer; + isc_region_t r; + dns_compress_t cctx; + isc_boolean_t cleanup_cctx = ISC_FALSE; + unsigned char sendbuf[SEND_BUFFER_SIZE]; + unsigned int dnssec_opts; + unsigned int preferred_glue; + + REQUIRE(NS_CLIENT_VALID(client)); + + CTRACE("send"); + + if ((client->attributes & NS_CLIENTATTR_RA) != 0) + client->message->flags |= DNS_MESSAGEFLAG_RA; + + if ((client->attributes & NS_CLIENTATTR_WANTDNSSEC) != 0) + dnssec_opts = 0; + else + dnssec_opts = DNS_MESSAGERENDER_OMITDNSSEC; + + preferred_glue = 0; + if (client->view != NULL) { + if (client->view->preferred_glue == dns_rdatatype_a) + preferred_glue = DNS_MESSAGERENDER_PREFER_A; + else if (client->view->preferred_glue == dns_rdatatype_aaaa) + preferred_glue = DNS_MESSAGERENDER_PREFER_AAAA; + } + + /* + * XXXRTH The following doesn't deal with TCP buffer resizing. + */ + result = client_allocsendbuf(client, &buffer, &tcpbuffer, 0, + sendbuf, &data); + if (result != ISC_R_SUCCESS) + goto done; + + result = dns_compress_init(&cctx, -1, client->mctx); + if (result != ISC_R_SUCCESS) + goto done; + cleanup_cctx = ISC_TRUE; + + result = dns_message_renderbegin(client->message, &cctx, &buffer); + if (result != ISC_R_SUCCESS) + goto done; + if (client->opt != NULL) { + result = dns_message_setopt(client->message, client->opt); + /* + * XXXRTH dns_message_setopt() should probably do this... + */ + client->opt = NULL; + if (result != ISC_R_SUCCESS) + goto done; + } + result = dns_message_rendersection(client->message, + DNS_SECTION_QUESTION, 0); + if (result == ISC_R_NOSPACE) { + client->message->flags |= DNS_MESSAGEFLAG_TC; + goto renderend; + } + if (result != ISC_R_SUCCESS) + goto done; + result = dns_message_rendersection(client->message, + DNS_SECTION_ANSWER, + DNS_MESSAGERENDER_PARTIAL | + dnssec_opts); + if (result == ISC_R_NOSPACE) { + client->message->flags |= DNS_MESSAGEFLAG_TC; + goto renderend; + } + if (result != ISC_R_SUCCESS) + goto done; + result = dns_message_rendersection(client->message, + DNS_SECTION_AUTHORITY, + DNS_MESSAGERENDER_PARTIAL | + dnssec_opts); + if (result == ISC_R_NOSPACE) { + client->message->flags |= DNS_MESSAGEFLAG_TC; + goto renderend; + } + if (result != ISC_R_SUCCESS) + goto done; + result = dns_message_rendersection(client->message, + DNS_SECTION_ADDITIONAL, + preferred_glue | dnssec_opts); + if (result != ISC_R_SUCCESS && result != ISC_R_NOSPACE) + goto done; + renderend: + result = dns_message_renderend(client->message); + + if (result != ISC_R_SUCCESS) + goto done; + + if (cleanup_cctx) { + dns_compress_invalidate(&cctx); + cleanup_cctx = ISC_FALSE; + } + + if (TCP_CLIENT(client)) { + isc_buffer_usedregion(&buffer, &r); + isc_buffer_putuint16(&tcpbuffer, (isc_uint16_t) r.length); + isc_buffer_add(&tcpbuffer, r.length); + result = client_sendpkg(client, &tcpbuffer); + } else + result = client_sendpkg(client, &buffer); + if (result == ISC_R_SUCCESS) + return; + + done: + if (client->tcpbuf != NULL) { + isc_mem_put(client->mctx, client->tcpbuf, TCP_BUFFER_SIZE); + client->tcpbuf = NULL; + } + + if (cleanup_cctx) + dns_compress_invalidate(&cctx); + + ns_client_next(client, result); +} + +void +ns_client_error(ns_client_t *client, isc_result_t result) { + dns_rcode_t rcode; + dns_message_t *message; + + REQUIRE(NS_CLIENT_VALID(client)); + + CTRACE("error"); + + message = client->message; + rcode = dns_result_torcode(result); + + /* + * Message may be an in-progress reply that we had trouble + * with, in which case QR will be set. We need to clear QR before + * calling dns_message_reply() to avoid triggering an assertion. + */ + message->flags &= ~DNS_MESSAGEFLAG_QR; + /* + * AA and AD shouldn't be set. + */ + message->flags &= ~(DNS_MESSAGEFLAG_AA | DNS_MESSAGEFLAG_AD); + result = dns_message_reply(message, ISC_TRUE); + if (result != ISC_R_SUCCESS) { + /* + * It could be that we've got a query with a good header, + * but a bad question section, so we try again with + * want_question_section set to ISC_FALSE. + */ + result = dns_message_reply(message, ISC_FALSE); + if (result != ISC_R_SUCCESS) { + ns_client_next(client, result); + return; + } + } + message->rcode = rcode; + + /* + * FORMERR loop avoidance: If we sent a FORMERR message + * with the same ID to the same client less than two + * seconds ago, assume that we are in an infinite error + * packet dialog with a server for some protocol whose + * error responses look enough like DNS queries to + * elicit a FORMERR response. Drop a packet to break + * the loop. + */ + if (rcode == dns_rcode_formerr) { + if (isc_sockaddr_equal(&client->peeraddr, + &client->formerrcache.addr) && + message->id == client->formerrcache.id && + client->requesttime - client->formerrcache.time < 2) { + /* Drop packet. */ + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(1), + "possible error packet loop, " + "FORMERR dropped"); + ns_client_next(client, result); + return; + } + client->formerrcache.addr = client->peeraddr; + client->formerrcache.time = client->requesttime; + client->formerrcache.id = message->id; + } + ns_client_send(client); +} + +static inline isc_result_t +client_addopt(ns_client_t *client) { + dns_rdataset_t *rdataset; + dns_rdatalist_t *rdatalist; + dns_rdata_t *rdata; + isc_result_t result; + dns_view_t *view; + dns_resolver_t *resolver; + isc_uint16_t udpsize; + + REQUIRE(client->opt == NULL); /* XXXRTH free old. */ + + rdatalist = NULL; + result = dns_message_gettemprdatalist(client->message, &rdatalist); + if (result != ISC_R_SUCCESS) + return (result); + rdata = NULL; + result = dns_message_gettemprdata(client->message, &rdata); + if (result != ISC_R_SUCCESS) + return (result); + rdataset = NULL; + result = dns_message_gettemprdataset(client->message, &rdataset); + if (result != ISC_R_SUCCESS) + return (result); + dns_rdataset_init(rdataset); + + rdatalist->type = dns_rdatatype_opt; + rdatalist->covers = 0; + + /* + * Set the maximum UDP buffer size. + */ + view = client->view; + resolver = (view != NULL) ? view->resolver : NULL; + if (resolver != NULL) + udpsize = dns_resolver_getudpsize(resolver); + else + udpsize = ns_g_udpsize; + rdatalist->rdclass = udpsize; + + /* + * Set EXTENDED-RCODE, VERSION and Z to 0. + */ + rdatalist->ttl = (client->extflags & DNS_MESSAGEEXTFLAG_REPLYPRESERVE); + + /* + * No ENDS options in the default case. + */ + rdata->data = NULL; + rdata->length = 0; + rdata->rdclass = rdatalist->rdclass; + rdata->type = rdatalist->type; + rdata->flags = 0; + + ISC_LIST_INIT(rdatalist->rdata); + ISC_LIST_APPEND(rdatalist->rdata, rdata, link); + RUNTIME_CHECK(dns_rdatalist_tordataset(rdatalist, rdataset) + == ISC_R_SUCCESS); + + client->opt = rdataset; + + return (ISC_R_SUCCESS); +} + +static inline isc_boolean_t +allowed(isc_netaddr_t *addr, dns_name_t *signer, dns_acl_t *acl) { + int match; + isc_result_t result; + + if (acl == NULL) + return (ISC_TRUE); + result = dns_acl_match(addr, signer, acl, &ns_g_server->aclenv, + &match, NULL); + if (result == ISC_R_SUCCESS && match > 0) + return (ISC_TRUE); + return (ISC_FALSE); +} + +/* + * Handle an incoming request event from the socket (UDP case) + * or tcpmsg (TCP case). + */ +static void +client_request(isc_task_t *task, isc_event_t *event) { + ns_client_t *client; + isc_socketevent_t *sevent; + isc_result_t result; + isc_result_t sigresult = ISC_R_SUCCESS; + isc_buffer_t *buffer; + isc_buffer_t tbuffer; + dns_view_t *view; + dns_rdataset_t *opt; + isc_boolean_t ra; /* Recursion available. */ + isc_netaddr_t netaddr; + isc_netaddr_t destaddr; + int match; + dns_messageid_t id; + unsigned int flags; + isc_boolean_t notimp; + + REQUIRE(event != NULL); + client = event->ev_arg; + REQUIRE(NS_CLIENT_VALID(client)); + REQUIRE(task == client->task); + + INSIST(client->recursionquota == NULL); + + INSIST(client->state == + TCP_CLIENT(client) ? + NS_CLIENTSTATE_READING : + NS_CLIENTSTATE_READY); + + if (event->ev_type == ISC_SOCKEVENT_RECVDONE) { + INSIST(!TCP_CLIENT(client)); + sevent = (isc_socketevent_t *)event; + REQUIRE(sevent == client->recvevent); + isc_buffer_init(&tbuffer, sevent->region.base, sevent->n); + isc_buffer_add(&tbuffer, sevent->n); + buffer = &tbuffer; + result = sevent->result; + if (result == ISC_R_SUCCESS) { + client->peeraddr = sevent->address; + client->peeraddr_valid = ISC_TRUE; + } + if ((sevent->attributes & ISC_SOCKEVENTATTR_PKTINFO) != 0) { + client->attributes |= NS_CLIENTATTR_PKTINFO; + client->pktinfo = sevent->pktinfo; + } + if ((sevent->attributes & ISC_SOCKEVENTATTR_MULTICAST) != 0) + client->attributes |= NS_CLIENTATTR_MULTICAST; + client->nrecvs--; + } else { + INSIST(TCP_CLIENT(client)); + REQUIRE(event->ev_type == DNS_EVENT_TCPMSG); + REQUIRE(event->ev_sender == &client->tcpmsg); + buffer = &client->tcpmsg.buffer; + result = client->tcpmsg.result; + INSIST(client->nreads == 1); + /* + * client->peeraddr was set when the connection was accepted. + */ + client->nreads--; + } + + if (exit_check(client)) + goto cleanup; + client->state = client->newstate = NS_CLIENTSTATE_WORKING; + + isc_task_getcurrenttime(task, &client->requesttime); + client->now = client->requesttime; + + if (result != ISC_R_SUCCESS) { + if (TCP_CLIENT(client)) { + ns_client_next(client, result); + } else { + if (result != ISC_R_CANCELED) + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, + ISC_LOG_ERROR, + "UDP client handler shutting " + "down due to fatal receive " + "error: %s", + isc_result_totext(result)); + isc_task_shutdown(client->task); + } + goto cleanup; + } + + isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr); + + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3), + "%s request", + TCP_CLIENT(client) ? "TCP" : "UDP"); + + /* + * Check the blackhole ACL for UDP only, since TCP is done in + * client_newconn. + */ + if (!TCP_CLIENT(client)) { + + if (ns_g_server->blackholeacl != NULL && + dns_acl_match(&netaddr, NULL, ns_g_server->blackholeacl, + &ns_g_server->aclenv, + &match, NULL) == ISC_R_SUCCESS && + match > 0) + { + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(10), + "blackholed UDP datagram"); + ns_client_next(client, ISC_R_SUCCESS); + goto cleanup; + } + } + + /* + * Silently drop multicast requests for the present. + * XXXMPA look at when/if mDNS spec stabilizes. + */ + if ((client->attributes & NS_CLIENTATTR_MULTICAST) != 0) { + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(2), + "dropping multicast request"); + ns_client_next(client, DNS_R_REFUSED); + } + + result = dns_message_peekheader(buffer, &id, &flags); + if (result != ISC_R_SUCCESS) { + /* + * There isn't enough header to determine whether + * this was a request or a response. Drop it. + */ + ns_client_next(client, result); + goto cleanup; + } + + /* + * The client object handles requests, not responses. + * If this is a UDP response, forward it to the dispatcher. + * If it's a TCP response, discard it here. + */ + if ((flags & DNS_MESSAGEFLAG_QR) != 0) { + if (TCP_CLIENT(client)) { + CTRACE("unexpected response"); + ns_client_next(client, DNS_R_FORMERR); + goto cleanup; + } else { + dns_dispatch_importrecv(client->dispatch, event); + ns_client_next(client, ISC_R_SUCCESS); + goto cleanup; + } + } + + /* + * It's a request. Parse it. + */ + result = dns_message_parse(client->message, buffer, 0); + if (result != ISC_R_SUCCESS) { + /* + * Parsing the request failed. Send a response + * (typically FORMERR or SERVFAIL). + */ + ns_client_error(client, result); + goto cleanup; + } + + switch (client->message->opcode) { + case dns_opcode_query: + case dns_opcode_update: + case dns_opcode_notify: + notimp = ISC_FALSE; + break; + case dns_opcode_iquery: + default: + notimp = ISC_TRUE; + break; + } + + client->message->rcode = dns_rcode_noerror; + + /* RFC1123 section 6.1.3.2 */ + if ((client->attributes & NS_CLIENTATTR_MULTICAST) != 0) + client->message->flags &= ~DNS_MESSAGEFLAG_RD; + + /* + * Deal with EDNS. + */ + opt = dns_message_getopt(client->message); + if (opt != NULL) { + unsigned int version; + + /* + * Set the client's UDP buffer size. + */ + client->udpsize = opt->rdclass; + + /* + * If the requested UDP buffer size is less than 512, + * ignore it and use 512. + */ + if (client->udpsize < 512) + client->udpsize = 512; + + /* + * Get the flags out of the OPT record. + */ + client->extflags = (isc_uint16_t)(opt->ttl & 0xFFFF); + + /* + * Create an OPT for our reply. + */ + result = client_addopt(client); + if (result != ISC_R_SUCCESS) { + ns_client_error(client, result); + goto cleanup; + } + + /* + * Do we understand this version of ENDS? + * + * XXXRTH need library support for this! + */ + version = (opt->ttl & 0x00FF0000) >> 16; + if (version != 0) { + ns_client_error(client, DNS_R_BADVERS); + goto cleanup; + } + } + + if (client->message->rdclass == 0) { + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(1), + "message class could not be determined"); + ns_client_dumpmessage(client, + "message class could not be determined"); + ns_client_error(client, notimp ? DNS_R_NOTIMP : DNS_R_FORMERR); + goto cleanup; + } + + /* + * Determine the destination address. If the receiving interface is + * bound to a specific address, we simply use it regardless of the + * address family. All IPv4 queries should fall into this case. + * Otherwise, if this is a TCP query, get the address from the + * receiving socket (this needs a system call and can be heavy). + * For IPv6 UDP queries, we get this from the pktinfo structure (if + * supported). + * If all the attempts fail (this can happen due to memory shortage, + * etc), we regard this as an error for safety. + */ + if ((client->interface->flags & NS_INTERFACEFLAG_ANYADDR) == 0) + isc_netaddr_fromsockaddr(&destaddr, &client->interface->addr); + else { + result = ISC_R_FAILURE; + + if (TCP_CLIENT(client)) { + isc_sockaddr_t destsockaddr; + + result = isc_socket_getsockname(client->tcpsocket, + &destsockaddr); + if (result == ISC_R_SUCCESS) + isc_netaddr_fromsockaddr(&destaddr, + &destsockaddr); + } + if (result != ISC_R_SUCCESS && + client->interface->addr.type.sa.sa_family == AF_INET6 && + (client->attributes & NS_CLIENTATTR_PKTINFO) != 0) { + isc_uint32_t zone = 0; + + /* + * XXXJT technically, we should convert the receiving + * interface ID to a proper scope zone ID. However, + * due to the fact there is no standard API for this, + * we only handle link-local addresses and use the + * interface index as link ID. Despite the assumption, + * it should cover most typical cases. + */ + if (IN6_IS_ADDR_LINKLOCAL(&client->pktinfo.ipi6_addr)) + zone = (isc_uint32_t)client->pktinfo.ipi6_ifindex; + + isc_netaddr_fromin6(&destaddr, + &client->pktinfo.ipi6_addr); + isc_netaddr_setzone(&destaddr, zone); + result = ISC_R_SUCCESS; + } + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "failed to get request's " + "destination: %s", + isc_result_totext(result)); + goto cleanup; + } + } + + /* + * Find a view that matches the client's source address. + */ + for (view = ISC_LIST_HEAD(ns_g_server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) { + if (client->message->rdclass == view->rdclass || + client->message->rdclass == dns_rdataclass_any) + { + dns_name_t *tsig = NULL; + sigresult = dns_message_rechecksig(client->message, + view); + if (sigresult == ISC_R_SUCCESS) + tsig = client->message->tsigname; + + if (allowed(&netaddr, tsig, view->matchclients) && + allowed(&destaddr, tsig, view->matchdestinations) && + !((client->message->flags & DNS_MESSAGEFLAG_RD) + == 0 && view->matchrecursiveonly)) + { + dns_view_attach(view, &client->view); + break; + } + } + } + + if (view == NULL) { + char classname[DNS_RDATACLASS_FORMATSIZE]; + + /* + * Do a dummy TSIG verification attempt so that the + * response will have a TSIG if the query did, as + * required by RFC2845. + */ + isc_buffer_t b; + isc_region_t *r; + + dns_message_resetsig(client->message); + + r = dns_message_getrawmessage(client->message); + isc_buffer_init(&b, r->base, r->length); + isc_buffer_add(&b, r->length); + (void)dns_tsig_verify(&b, client->message, NULL, NULL); + + dns_rdataclass_format(client->message->rdclass, classname, + sizeof(classname)); + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(1), + "no matching view in class '%s'", classname); + ns_client_dumpmessage(client, "no matching view in class"); + ns_client_error(client, notimp ? DNS_R_NOTIMP : DNS_R_REFUSED); + goto cleanup; + } + + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(5), + "using view '%s'", view->name); + + /* + * Check for a signature. We log bad signatures regardless of + * whether they ultimately cause the request to be rejected or + * not. We do not log the lack of a signature unless we are + * debugging. + */ + client->signer = NULL; + dns_name_init(&client->signername, NULL); + result = dns_message_signer(client->message, &client->signername); + if (result == ISC_R_SUCCESS) { + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3), + "request has valid signature"); + client->signer = &client->signername; + } else if (result == ISC_R_NOTFOUND) { + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3), + "request is not signed"); + } else if (result == DNS_R_NOIDENTITY) { + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3), + "request is signed by a nonauthoritative key"); + } else { + char tsigrcode[64]; + isc_buffer_t b; + dns_name_t *name = NULL; + + isc_buffer_init(&b, tsigrcode, sizeof(tsigrcode) - 1); + RUNTIME_CHECK(dns_tsigrcode_totext(client->message->tsigstatus, + &b) == ISC_R_SUCCESS); + tsigrcode[isc_buffer_usedlength(&b)] = '\0'; + /* There is a signature, but it is bad. */ + if (dns_message_gettsig(client->message, &name) != NULL) { + char namebuf[DNS_NAME_FORMATSIZE]; + dns_name_format(name, namebuf, sizeof(namebuf)); + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_ERROR, + "request has invalid signature: " + "TSIG %s: %s (%s)", namebuf, + isc_result_totext(result), tsigrcode); + } else { + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_ERROR, + "request has invalid signature: %s (%s)", + isc_result_totext(result), tsigrcode); + } + /* + * Accept update messages signed by unknown keys so that + * update forwarding works transparently through slaves + * that don't have all the same keys as the master. + */ + if (!(client->message->tsigstatus == dns_tsigerror_badkey && + client->message->opcode == dns_opcode_update)) { + ns_client_error(client, sigresult); + goto cleanup; + } + } + + /* + * Decide whether recursive service is available to this client. + * We do this here rather than in the query code so that we can + * set the RA bit correctly on all kinds of responses, not just + * responses to ordinary queries. + */ + ra = ISC_FALSE; + if (client->view->resolver != NULL && + client->view->recursion == ISC_TRUE && + ns_client_checkaclsilent(client, client->view->recursionacl, + ISC_TRUE) == ISC_R_SUCCESS) + ra = ISC_TRUE; + + if (ra == ISC_TRUE) + client->attributes |= NS_CLIENTATTR_RA; + + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, NS_LOGMODULE_CLIENT, + ISC_LOG_DEBUG(3), ra ? "recursion available" : + "recursion not available"); + + /* + * Dispatch the request. + */ + switch (client->message->opcode) { + case dns_opcode_query: + CTRACE("query"); + ns_query_start(client); + break; + case dns_opcode_update: + CTRACE("update"); + ns_client_settimeout(client, 60); + ns_update_start(client, sigresult); + break; + case dns_opcode_notify: + CTRACE("notify"); + ns_client_settimeout(client, 60); + ns_notify_start(client); + break; + case dns_opcode_iquery: + CTRACE("iquery"); + ns_client_error(client, DNS_R_NOTIMP); + break; + default: + CTRACE("unknown opcode"); + ns_client_error(client, DNS_R_NOTIMP); + } + + cleanup: + return; +} + +static void +client_timeout(isc_task_t *task, isc_event_t *event) { + ns_client_t *client; + + REQUIRE(event != NULL); + REQUIRE(event->ev_type == ISC_TIMEREVENT_LIFE || + event->ev_type == ISC_TIMEREVENT_IDLE); + client = event->ev_arg; + REQUIRE(NS_CLIENT_VALID(client)); + REQUIRE(task == client->task); + REQUIRE(client->timer != NULL); + + UNUSED(task); + + CTRACE("timeout"); + + isc_event_free(&event); + + if (client->shutdown != NULL) { + (client->shutdown)(client->shutdown_arg, ISC_R_TIMEDOUT); + client->shutdown = NULL; + client->shutdown_arg = NULL; + } + + if (client->newstate > NS_CLIENTSTATE_READY) + client->newstate = NS_CLIENTSTATE_READY; + (void)exit_check(client); +} + +static isc_result_t +client_create(ns_clientmgr_t *manager, ns_client_t **clientp) +{ + ns_client_t *client; + isc_result_t result; + + /* + * Caller must be holding the manager lock. + * + * Note: creating a client does not add the client to the + * manager's client list or set the client's manager pointer. + * The caller is responsible for that. + */ + + REQUIRE(clientp != NULL && *clientp == NULL); + + client = isc_mem_get(manager->mctx, sizeof(*client)); + if (client == NULL) + return (ISC_R_NOMEMORY); + + client->task = NULL; + result = isc_task_create(manager->taskmgr, 0, &client->task); + if (result != ISC_R_SUCCESS) + goto cleanup_client; + isc_task_setname(client->task, "client", client); + + client->timer = NULL; + result = isc_timer_create(manager->timermgr, isc_timertype_inactive, + NULL, NULL, client->task, client_timeout, + client, &client->timer); + if (result != ISC_R_SUCCESS) + goto cleanup_task; + client->timerset = ISC_FALSE; + + client->message = NULL; + result = dns_message_create(manager->mctx, DNS_MESSAGE_INTENTPARSE, + &client->message); + if (result != ISC_R_SUCCESS) + goto cleanup_timer; + + /* XXXRTH Hardwired constants */ + + client->sendevent = (isc_socketevent_t *) + isc_event_allocate(manager->mctx, client, + ISC_SOCKEVENT_SENDDONE, + client_senddone, client, + sizeof(isc_socketevent_t)); + if (client->sendevent == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup_message; + } + + client->recvbuf = isc_mem_get(manager->mctx, RECV_BUFFER_SIZE); + if (client->recvbuf == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup_sendevent; + } + + client->recvevent = (isc_socketevent_t *) + isc_event_allocate(manager->mctx, client, + ISC_SOCKEVENT_RECVDONE, + client_request, client, + sizeof(isc_socketevent_t)); + if (client->recvevent == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup_recvbuf; + } + + client->magic = NS_CLIENT_MAGIC; + client->mctx = manager->mctx; + client->manager = NULL; + client->state = NS_CLIENTSTATE_INACTIVE; + client->newstate = NS_CLIENTSTATE_MAX; + client->naccepts = 0; + client->nreads = 0; + client->nsends = 0; + client->nrecvs = 0; + client->nupdates = 0; + client->nctls = 0; + client->references = 0; + client->attributes = 0; + client->view = NULL; + client->dispatch = NULL; + client->udpsocket = NULL; + client->tcplistener = NULL; + client->tcpsocket = NULL; + client->tcpmsg_valid = ISC_FALSE; + client->tcpbuf = NULL; + client->opt = NULL; + client->udpsize = 512; + client->extflags = 0; + client->next = NULL; + client->shutdown = NULL; + client->shutdown_arg = NULL; + dns_name_init(&client->signername, NULL); + client->mortal = ISC_FALSE; + client->tcpquota = NULL; + client->recursionquota = NULL; + client->interface = NULL; + client->peeraddr_valid = ISC_FALSE; + ISC_EVENT_INIT(&client->ctlevent, sizeof(client->ctlevent), 0, NULL, + NS_EVENT_CLIENTCONTROL, client_start, client, client, + NULL, NULL); + /* + * Initialize FORMERR cache to sentinel value that will not match + * any actual FORMERR response. + */ + isc_sockaddr_any(&client->formerrcache.addr); + client->formerrcache.time = 0; + client->formerrcache.id = 0; + ISC_LINK_INIT(client, link); + client->list = NULL; + + /* + * We call the init routines for the various kinds of client here, + * after we have created an otherwise valid client, because some + * of them call routines that REQUIRE(NS_CLIENT_VALID(client)). + */ + result = ns_query_init(client); + if (result != ISC_R_SUCCESS) + goto cleanup_recvevent; + + result = isc_task_onshutdown(client->task, client_shutdown, client); + if (result != ISC_R_SUCCESS) + goto cleanup_query; + + CTRACE("create"); + + *clientp = client; + + return (ISC_R_SUCCESS); + + cleanup_query: + ns_query_free(client); + + cleanup_recvevent: + isc_event_free((isc_event_t **)&client->recvevent); + + cleanup_recvbuf: + isc_mem_put(manager->mctx, client->recvbuf, RECV_BUFFER_SIZE); + + cleanup_sendevent: + isc_event_free((isc_event_t **)&client->sendevent); + + client->magic = 0; + + cleanup_message: + dns_message_destroy(&client->message); + + cleanup_timer: + isc_timer_detach(&client->timer); + + cleanup_task: + isc_task_detach(&client->task); + + cleanup_client: + isc_mem_put(manager->mctx, client, sizeof(*client)); + + return (result); +} + +static void +client_read(ns_client_t *client) { + isc_result_t result; + + CTRACE("read"); + + result = dns_tcpmsg_readmessage(&client->tcpmsg, client->task, + client_request, client); + if (result != ISC_R_SUCCESS) + goto fail; + + /* + * Set a timeout to limit the amount of time we will wait + * for a request on this TCP connection. + */ + ns_client_settimeout(client, 30); + + client->state = client->newstate = NS_CLIENTSTATE_READING; + INSIST(client->nreads == 0); + INSIST(client->recursionquota == NULL); + client->nreads++; + + return; + fail: + ns_client_next(client, result); +} + +static void +client_newconn(isc_task_t *task, isc_event_t *event) { + ns_client_t *client = event->ev_arg; + isc_socket_newconnev_t *nevent = (isc_socket_newconnev_t *)event; + isc_result_t result; + + REQUIRE(event->ev_type == ISC_SOCKEVENT_NEWCONN); + REQUIRE(NS_CLIENT_VALID(client)); + REQUIRE(client->task == task); + + UNUSED(task); + + INSIST(client->state == NS_CLIENTSTATE_READY); + + INSIST(client->naccepts == 1); + client->naccepts--; + + LOCK(&client->interface->lock); + INSIST(client->interface->ntcpcurrent > 0); + client->interface->ntcpcurrent--; + UNLOCK(&client->interface->lock); + + /* + * We must take ownership of the new socket before the exit + * check to make sure it gets destroyed if we decide to exit. + */ + if (nevent->result == ISC_R_SUCCESS) { + client->tcpsocket = nevent->newsocket; + client->state = NS_CLIENTSTATE_READING; + INSIST(client->recursionquota == NULL); + + (void)isc_socket_getpeername(client->tcpsocket, + &client->peeraddr); + client->peeraddr_valid = ISC_TRUE; + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3), + "new TCP connection"); + } else { + /* + * XXXRTH What should we do? We're trying to accept but + * it didn't work. If we just give up, then TCP + * service may eventually stop. + * + * For now, we just go idle. + * + * Going idle is probably the right thing if the + * I/O was canceled. + */ + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3), + "accept failed: %s", + isc_result_totext(nevent->result)); + } + + if (exit_check(client)) + goto freeevent; + + if (nevent->result == ISC_R_SUCCESS) { + int match; + isc_netaddr_t netaddr; + + isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr); + + if (ns_g_server->blackholeacl != NULL && + dns_acl_match(&netaddr, NULL, + ns_g_server->blackholeacl, + &ns_g_server->aclenv, + &match, NULL) == ISC_R_SUCCESS && + match > 0) + { + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(10), + "blackholed connection attempt"); + client->newstate = NS_CLIENTSTATE_READY; + (void)exit_check(client); + goto freeevent; + } + + INSIST(client->tcpmsg_valid == ISC_FALSE); + dns_tcpmsg_init(client->mctx, client->tcpsocket, + &client->tcpmsg); + client->tcpmsg_valid = ISC_TRUE; + + /* + * Let a new client take our place immediately, before + * we wait for a request packet. If we don't, + * telnetting to port 53 (once per CPU) will + * deny service to legititmate TCP clients. + */ + result = isc_quota_attach(&ns_g_server->tcpquota, + &client->tcpquota); + if (result == ISC_R_SUCCESS) + result = ns_client_replace(client); + if (result != ISC_R_SUCCESS) { + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_WARNING, + "no more TCP clients: %s", + isc_result_totext(result)); + } + + client_read(client); + } + + freeevent: + isc_event_free(&event); +} + +static void +client_accept(ns_client_t *client) { + isc_result_t result; + + CTRACE("accept"); + + result = isc_socket_accept(client->tcplistener, client->task, + client_newconn, client); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_socket_accept() failed: %s", + isc_result_totext(result)); + /* + * XXXRTH What should we do? We're trying to accept but + * it didn't work. If we just give up, then TCP + * service may eventually stop. + * + * For now, we just go idle. + */ + return; + } + INSIST(client->naccepts == 0); + client->naccepts++; + LOCK(&client->interface->lock); + client->interface->ntcpcurrent++; + UNLOCK(&client->interface->lock); +} + +static void +client_udprecv(ns_client_t *client) { + isc_result_t result; + isc_region_t r; + + CTRACE("udprecv"); + + r.base = client->recvbuf; + r.length = RECV_BUFFER_SIZE; + result = isc_socket_recv2(client->udpsocket, &r, 1, + client->task, client->recvevent, 0); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_socket_recv() failed: %s", + isc_result_totext(result)); + /* + * This cannot happen in the current implementation, since + * isc_socket_recv2() cannot fail if flags == 0. + * + * If this does fail, we just go idle. + */ + return; + } + INSIST(client->nrecvs == 0); + client->nrecvs++; +} + +void +ns_client_attach(ns_client_t *source, ns_client_t **targetp) { + REQUIRE(NS_CLIENT_VALID(source)); + REQUIRE(targetp != NULL && *targetp == NULL); + + source->references++; + ns_client_log(source, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(10), + "ns_client_attach: ref = %d", source->references); + *targetp = source; +} + +void +ns_client_detach(ns_client_t **clientp) { + ns_client_t *client = *clientp; + + client->references--; + INSIST(client->references >= 0); + *clientp = NULL; + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(10), + "ns_client_detach: ref = %d", client->references); + (void)exit_check(client); +} + +isc_boolean_t +ns_client_shuttingdown(ns_client_t *client) { + return (ISC_TF(client->newstate == NS_CLIENTSTATE_FREED)); +} + +isc_result_t +ns_client_replace(ns_client_t *client) { + isc_result_t result; + + CTRACE("replace"); + + result = ns_clientmgr_createclients(client->manager, + 1, client->interface, + (TCP_CLIENT(client) ? + ISC_TRUE : ISC_FALSE)); + if (result != ISC_R_SUCCESS) + return (result); + + /* + * The responsibility for listening for new requests is hereby + * transferred to the new client. Therefore, the old client + * should refrain from listening for any more requests. + */ + client->mortal = ISC_TRUE; + + return (ISC_R_SUCCESS); +} + +/*** + *** Client Manager + ***/ + +static void +clientmgr_destroy(ns_clientmgr_t *manager) { + REQUIRE(ISC_LIST_EMPTY(manager->active)); + REQUIRE(ISC_LIST_EMPTY(manager->inactive)); + REQUIRE(ISC_LIST_EMPTY(manager->recursing)); + + MTRACE("clientmgr_destroy"); + + DESTROYLOCK(&manager->lock); + manager->magic = 0; + isc_mem_put(manager->mctx, manager, sizeof(*manager)); +} + +isc_result_t +ns_clientmgr_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr, + isc_timermgr_t *timermgr, ns_clientmgr_t **managerp) +{ + ns_clientmgr_t *manager; + isc_result_t result; + + manager = isc_mem_get(mctx, sizeof(*manager)); + if (manager == NULL) + return (ISC_R_NOMEMORY); + + result = isc_mutex_init(&manager->lock); + if (result != ISC_R_SUCCESS) + goto cleanup_manager; + + manager->mctx = mctx; + manager->taskmgr = taskmgr; + manager->timermgr = timermgr; + manager->exiting = ISC_FALSE; + ISC_LIST_INIT(manager->active); + ISC_LIST_INIT(manager->inactive); + ISC_LIST_INIT(manager->recursing); + manager->magic = MANAGER_MAGIC; + + MTRACE("create"); + + *managerp = manager; + + return (ISC_R_SUCCESS); + + cleanup_manager: + isc_mem_put(manager->mctx, manager, sizeof(*manager)); + + return (result); +} + +void +ns_clientmgr_destroy(ns_clientmgr_t **managerp) { + ns_clientmgr_t *manager; + ns_client_t *client; + isc_boolean_t need_destroy = ISC_FALSE; + + REQUIRE(managerp != NULL); + manager = *managerp; + REQUIRE(VALID_MANAGER(manager)); + + MTRACE("destroy"); + + LOCK(&manager->lock); + + manager->exiting = ISC_TRUE; + + for (client = ISC_LIST_HEAD(manager->recursing); + client != NULL; + client = ISC_LIST_NEXT(client, link)) + isc_task_shutdown(client->task); + + for (client = ISC_LIST_HEAD(manager->active); + client != NULL; + client = ISC_LIST_NEXT(client, link)) + isc_task_shutdown(client->task); + + for (client = ISC_LIST_HEAD(manager->inactive); + client != NULL; + client = ISC_LIST_NEXT(client, link)) + isc_task_shutdown(client->task); + + if (ISC_LIST_EMPTY(manager->active) && + ISC_LIST_EMPTY(manager->inactive) && + ISC_LIST_EMPTY(manager->recursing)) + need_destroy = ISC_TRUE; + + UNLOCK(&manager->lock); + + if (need_destroy) + clientmgr_destroy(manager); + + *managerp = NULL; +} + +isc_result_t +ns_clientmgr_createclients(ns_clientmgr_t *manager, unsigned int n, + ns_interface_t *ifp, isc_boolean_t tcp) +{ + isc_result_t result = ISC_R_SUCCESS; + unsigned int i; + ns_client_t *client; + + REQUIRE(VALID_MANAGER(manager)); + REQUIRE(n > 0); + + MTRACE("createclients"); + + /* + * We MUST lock the manager lock for the entire client creation + * process. If we didn't do this, then a client could get a + * shutdown event and disappear out from under us. + */ + + LOCK(&manager->lock); + + for (i = 0; i < n; i++) { + isc_event_t *ev; + /* + * Allocate a client. First try to get a recycled one; + * if that fails, make a new one. + */ + client = ISC_LIST_HEAD(manager->inactive); + if (client != NULL) { + MTRACE("recycle"); + ISC_LIST_UNLINK(manager->inactive, client, link); + client->list = NULL; + } else { + MTRACE("create new"); + result = client_create(manager, &client); + if (result != ISC_R_SUCCESS) + break; + } + + ns_interface_attach(ifp, &client->interface); + client->state = NS_CLIENTSTATE_READY; + INSIST(client->recursionquota == NULL); + + if (tcp) { + client->attributes |= NS_CLIENTATTR_TCP; + isc_socket_attach(ifp->tcpsocket, + &client->tcplistener); + } else { + isc_socket_t *sock; + + dns_dispatch_attach(ifp->udpdispatch, + &client->dispatch); + sock = dns_dispatch_getsocket(client->dispatch); + isc_socket_attach(sock, &client->udpsocket); + } + client->manager = manager; + ISC_LIST_APPEND(manager->active, client, link); + client->list = &manager->active; + + INSIST(client->nctls == 0); + client->nctls++; + ev = &client->ctlevent; + isc_task_send(client->task, &ev); + } + if (i != 0) { + /* + * We managed to create at least one client, so we + * declare victory. + */ + result = ISC_R_SUCCESS; + } + + UNLOCK(&manager->lock); + + return (result); +} + +isc_sockaddr_t * +ns_client_getsockaddr(ns_client_t *client) { + return (&client->peeraddr); +} + +isc_result_t +ns_client_checkaclsilent(ns_client_t *client, dns_acl_t *acl, + isc_boolean_t default_allow) +{ + isc_result_t result; + int match; + isc_netaddr_t netaddr; + + if (acl == NULL) { + if (default_allow) + goto allow; + else + goto deny; + } + + isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr); + + result = dns_acl_match(&netaddr, client->signer, acl, + &ns_g_server->aclenv, + &match, NULL); + if (result != ISC_R_SUCCESS) + goto deny; /* Internal error, already logged. */ + if (match > 0) + goto allow; + goto deny; /* Negative match or no match. */ + + allow: + return (ISC_R_SUCCESS); + + deny: + return (DNS_R_REFUSED); +} + +isc_result_t +ns_client_checkacl(ns_client_t *client, + const char *opname, dns_acl_t *acl, + isc_boolean_t default_allow, int log_level) +{ + isc_result_t result = + ns_client_checkaclsilent(client, acl, default_allow); + + if (result == ISC_R_SUCCESS) + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3), + "%s approved", opname); + else + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_CLIENT, + log_level, "%s denied", opname); + return (result); +} + +static void +ns_client_name(ns_client_t *client, char *peerbuf, size_t len) { + if (client->peeraddr_valid) + isc_sockaddr_format(&client->peeraddr, peerbuf, len); + else + snprintf(peerbuf, len, "@%p", client); +} + +void +ns_client_logv(ns_client_t *client, isc_logcategory_t *category, + isc_logmodule_t *module, int level, const char *fmt, va_list ap) +{ + char msgbuf[2048]; + char peerbuf[ISC_SOCKADDR_FORMATSIZE]; + const char *name = ""; + const char *sep = ""; + + vsnprintf(msgbuf, sizeof(msgbuf), fmt, ap); + ns_client_name(client, peerbuf, sizeof(peerbuf)); + if (client->view != NULL && strcmp(client->view->name, "_bind") != 0 && + strcmp(client->view->name, "_default") != 0) { + name = client->view->name; + sep = ": view "; + } + + isc_log_write(ns_g_lctx, category, module, level, + "client %s%s%s: %s", peerbuf, sep, name, msgbuf); +} + +void +ns_client_log(ns_client_t *client, isc_logcategory_t *category, + isc_logmodule_t *module, int level, const char *fmt, ...) +{ + va_list ap; + + if (! isc_log_wouldlog(ns_g_lctx, level)) + return; + + va_start(ap, fmt); + ns_client_logv(client, category, module, level, fmt, ap); + va_end(ap); +} + +void +ns_client_aclmsg(const char *msg, dns_name_t *name, dns_rdatatype_t type, + dns_rdataclass_t rdclass, char *buf, size_t len) +{ + char namebuf[DNS_NAME_FORMATSIZE]; + char typebuf[DNS_RDATATYPE_FORMATSIZE]; + char classbuf[DNS_RDATACLASS_FORMATSIZE]; + + dns_name_format(name, namebuf, sizeof(namebuf)); + dns_rdatatype_format(type, typebuf, sizeof(typebuf)); + dns_rdataclass_format(rdclass, classbuf, sizeof(classbuf)); + (void)snprintf(buf, len, "%s '%s/%s/%s'", msg, namebuf, typebuf, + classbuf); +} + +static void +ns_client_dumpmessage(ns_client_t *client, const char *reason) { + isc_buffer_t buffer; + char *buf = NULL; + int len = 1024; + isc_result_t result; + + /* + * Note that these are multiline debug messages. We want a newline + * to appear in the log after each message. + */ + + do { + buf = isc_mem_get(client->mctx, len); + if (buf == NULL) + break; + isc_buffer_init(&buffer, buf, len); + result = dns_message_totext(client->message, + &dns_master_style_debug, + 0, &buffer); + if (result == ISC_R_NOSPACE) { + isc_mem_put(client->mctx, buf, len); + len += 1024; + } else if (result == ISC_R_SUCCESS) + ns_client_log(client, NS_LOGCATEGORY_UNMATCHED, + NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(1), + "%s\n%.*s", reason, + (int)isc_buffer_usedlength(&buffer), + buf); + } while (result == ISC_R_NOSPACE); + + if (buf != NULL) + isc_mem_put(client->mctx, buf, len); +} + +void +ns_client_dumprecursing(FILE *f, ns_clientmgr_t *manager) { + ns_client_t *client; + char namebuf[DNS_NAME_FORMATSIZE]; + char peerbuf[ISC_SOCKADDR_FORMATSIZE]; + const char *name; + const char *sep; + + REQUIRE(VALID_MANAGER(manager)); + + LOCK(&manager->lock); + client = ISC_LIST_HEAD(manager->recursing); + while (client != NULL) { + ns_client_name(client, peerbuf, sizeof(peerbuf)); + if (client->view != NULL && + strcmp(client->view->name, "_bind") != 0 && + strcmp(client->view->name, "_default") != 0) { + name = client->view->name; + sep = ": view "; + } else { + name = ""; + sep = ""; + } + dns_name_format(client->query.qname, namebuf, sizeof(namebuf)); + fprintf(f, "; client %s%s%s: '%s' requesttime %d\n", + peerbuf, sep, name, namebuf, client->requesttime); + client = ISC_LIST_NEXT(client, link); + } + UNLOCK(&manager->lock); +} diff --git a/contrib/bind9/bin/named/config.c b/contrib/bind9/bin/named/config.c new file mode 100644 index 000000000000..75158c05eca3 --- /dev/null +++ b/contrib/bind9/bin/named/config.c @@ -0,0 +1,723 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: config.c,v 1.11.2.4.8.28 2004/08/28 05:41:42 marka Exp $ */ + +#include + +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include + +#include +#include + +static char defaultconf[] = "\ +options {\n\ +# blackhole {none;};\n" +#ifndef WIN32 +" coresize default;\n\ + datasize default;\n\ + files default;\n\ + stacksize default;\n" +#endif +" deallocate-on-exit true;\n\ +# directory \n\ + dump-file \"named_dump.db\";\n\ + fake-iquery no;\n\ + has-old-clients false;\n\ + heartbeat-interval 60;\n\ + host-statistics no;\n\ + interface-interval 60;\n\ + listen-on {any;};\n\ + listen-on-v6 {none;};\n\ + match-mapped-addresses no;\n\ + memstatistics-file \"named.memstats\";\n\ + multiple-cnames no;\n\ +# named-xfer ;\n\ +# pid-file \"" NS_LOCALSTATEDIR "/named.pid\"; /* or /lwresd.pid */\n\ + port 53;\n\ + recursing-file \"named.recursing\";\n\ +" +#ifdef PATH_RANDOMDEV +"\ + random-device \"" PATH_RANDOMDEV "\";\n\ +" +#endif +"\ + recursive-clients 1000;\n\ + rrset-order {order cyclic;};\n\ + serial-queries 20;\n\ + serial-query-rate 20;\n\ + server-id none;\n\ + statistics-file \"named.stats\";\n\ + statistics-interval 60;\n\ + tcp-clients 100;\n\ + tcp-listen-queue 3;\n\ +# tkey-dhkey \n\ +# tkey-gssapi-credential \n\ +# tkey-domain \n\ + transfers-per-ns 2;\n\ + transfers-in 10;\n\ + transfers-out 10;\n\ + treat-cr-as-space true;\n\ + use-id-pool true;\n\ + use-ixfr true;\n\ + edns-udp-size 4096;\n\ +\n\ + /* view */\n\ + allow-notify {none;};\n\ + allow-update-forwarding {none;};\n\ + allow-recursion {any;};\n\ +# allow-v6-synthesis ;\n\ +# sortlist \n\ +# topology \n\ + auth-nxdomain false;\n\ + minimal-responses false;\n\ + recursion true;\n\ + provide-ixfr true;\n\ + request-ixfr true;\n\ + fetch-glue no;\n\ + rfc2308-type1 no;\n\ + additional-from-auth true;\n\ + additional-from-cache true;\n\ + query-source address *;\n\ + query-source-v6 address *;\n\ + notify-source *;\n\ + notify-source-v6 *;\n\ + cleaning-interval 60;\n\ + min-roots 2;\n\ + lame-ttl 600;\n\ + max-ncache-ttl 10800; /* 3 hours */\n\ + max-cache-ttl 604800; /* 1 week */\n\ + transfer-format many-answers;\n\ + max-cache-size 0;\n\ + check-names master fail;\n\ + check-names slave warn;\n\ + check-names response ignore;\n\ + dnssec-enable no; /* Make yes for 9.4. */ \n\ +" + +" /* zone */\n\ + allow-query {any;};\n\ + allow-transfer {any;};\n\ + notify yes;\n\ +# also-notify \n\ + dialup no;\n\ +# forward \n\ +# forwarders \n\ + maintain-ixfr-base no;\n\ +# max-ixfr-log-size \n\ + transfer-source *;\n\ + transfer-source-v6 *;\n\ + alt-transfer-source *;\n\ + alt-transfer-source-v6 *;\n\ + max-transfer-time-in 120;\n\ + max-transfer-time-out 120;\n\ + max-transfer-idle-in 60;\n\ + max-transfer-idle-out 60;\n\ + max-retry-time 1209600; /* 2 weeks */\n\ + min-retry-time 500;\n\ + max-refresh-time 2419200; /* 4 weeks */\n\ + min-refresh-time 300;\n\ + multi-master no;\n\ + sig-validity-interval 30; /* days */\n\ + zone-statistics false;\n\ + max-journal-size unlimited;\n\ + ixfr-from-differences false;\n\ +};\n\ +" + +"#\n\ +# Zones in the \"_bind\" view are NOT counted is the count of zones.\n\ +#\n\ +view \"_bind\" chaos {\n\ + recursion no;\n\ + notify no;\n\ +\n\ + zone \"version.bind\" chaos {\n\ + type master;\n\ + database \"_builtin version\";\n\ + };\n\ +\n\ + zone \"hostname.bind\" chaos {\n\ + type master;\n\ + database \"_builtin hostname\";\n\ + };\n\ +\n\ + zone \"authors.bind\" chaos {\n\ + type master;\n\ + database \"_builtin authors\";\n\ + };\n\ + zone \"id.server\" chaos {\n\ + type master;\n\ + database \"_builtin id\";\n\ + };\n\ +};\n\ +"; + +isc_result_t +ns_config_parsedefaults(cfg_parser_t *parser, cfg_obj_t **conf) { + isc_buffer_t b; + + isc_buffer_init(&b, defaultconf, sizeof(defaultconf) - 1); + isc_buffer_add(&b, sizeof(defaultconf) - 1); + return (cfg_parse_buffer(parser, &b, &cfg_type_namedconf, conf)); +} + +isc_result_t +ns_config_get(cfg_obj_t **maps, const char *name, cfg_obj_t **obj) { + int i; + + for (i = 0;; i++) { + if (maps[i] == NULL) + return (ISC_R_NOTFOUND); + if (cfg_map_get(maps[i], name, obj) == ISC_R_SUCCESS) + return (ISC_R_SUCCESS); + } +} + +isc_result_t +ns_checknames_get(cfg_obj_t **maps, const char *which, cfg_obj_t **obj) { + cfg_listelt_t *element; + cfg_obj_t *checknames; + cfg_obj_t *type; + cfg_obj_t *value; + int i; + + for (i = 0;; i++) { + if (maps[i] == NULL) + return (ISC_R_NOTFOUND); + checknames = NULL; + if (cfg_map_get(maps[i], "check-names", &checknames) == ISC_R_SUCCESS) { + /* + * Zone map entry is not a list. + */ + if (checknames != NULL && !cfg_obj_islist(checknames)) { + *obj = checknames; + return (ISC_R_SUCCESS); + } + for (element = cfg_list_first(checknames); + element != NULL; + element = cfg_list_next(element)) { + value = cfg_listelt_value(element); + type = cfg_tuple_get(value, "type"); + if (strcasecmp(cfg_obj_asstring(type), which) == 0) { + *obj = cfg_tuple_get(value, "mode"); + return (ISC_R_SUCCESS); + } + } + + } + } +} + +int +ns_config_listcount(cfg_obj_t *list) { + cfg_listelt_t *e; + int i = 0; + + for (e = cfg_list_first(list); e != NULL; e = cfg_list_next(e)) + i++; + + return (i); +} + +isc_result_t +ns_config_getclass(cfg_obj_t *classobj, dns_rdataclass_t defclass, + dns_rdataclass_t *classp) { + char *str; + isc_textregion_t r; + isc_result_t result; + + if (!cfg_obj_isstring(classobj)) { + *classp = defclass; + return (ISC_R_SUCCESS); + } + str = cfg_obj_asstring(classobj); + r.base = str; + r.length = strlen(str); + result = dns_rdataclass_fromtext(classp, &r); + if (result != ISC_R_SUCCESS) + cfg_obj_log(classobj, ns_g_lctx, ISC_LOG_ERROR, + "unknown class '%s'", str); + return (result); +} + +isc_result_t +ns_config_gettype(cfg_obj_t *typeobj, dns_rdatatype_t deftype, + dns_rdatatype_t *typep) { + char *str; + isc_textregion_t r; + isc_result_t result; + + if (!cfg_obj_isstring(typeobj)) { + *typep = deftype; + return (ISC_R_SUCCESS); + } + str = cfg_obj_asstring(typeobj); + r.base = str; + r.length = strlen(str); + result = dns_rdatatype_fromtext(typep, &r); + if (result != ISC_R_SUCCESS) + cfg_obj_log(typeobj, ns_g_lctx, ISC_LOG_ERROR, + "unknown type '%s'", str); + return (result); +} + +dns_zonetype_t +ns_config_getzonetype(cfg_obj_t *zonetypeobj) { + dns_zonetype_t ztype = dns_zone_none; + char *str; + + str = cfg_obj_asstring(zonetypeobj); + if (strcasecmp(str, "master") == 0) + ztype = dns_zone_master; + else if (strcasecmp(str, "slave") == 0) + ztype = dns_zone_slave; + else if (strcasecmp(str, "stub") == 0) + ztype = dns_zone_stub; + else + INSIST(0); + return (ztype); +} + +isc_result_t +ns_config_getiplist(cfg_obj_t *config, cfg_obj_t *list, + in_port_t defport, isc_mem_t *mctx, + isc_sockaddr_t **addrsp, isc_uint32_t *countp) +{ + int count, i = 0; + cfg_obj_t *addrlist; + cfg_obj_t *portobj; + cfg_listelt_t *element; + isc_sockaddr_t *addrs; + in_port_t port; + isc_result_t result; + + INSIST(addrsp != NULL && *addrsp == NULL); + INSIST(countp != NULL); + + addrlist = cfg_tuple_get(list, "addresses"); + count = ns_config_listcount(addrlist); + + portobj = cfg_tuple_get(list, "port"); + if (cfg_obj_isuint32(portobj)) { + isc_uint32_t val = cfg_obj_asuint32(portobj); + if (val > ISC_UINT16_MAX) { + cfg_obj_log(portobj, ns_g_lctx, ISC_LOG_ERROR, + "port '%u' out of range", val); + return (ISC_R_RANGE); + } + port = (in_port_t) val; + } else if (defport != 0) + port = defport; + else { + result = ns_config_getport(config, &port); + if (result != ISC_R_SUCCESS) + return (result); + } + + addrs = isc_mem_get(mctx, count * sizeof(isc_sockaddr_t)); + if (addrs == NULL) + return (ISC_R_NOMEMORY); + + for (element = cfg_list_first(addrlist); + element != NULL; + element = cfg_list_next(element), i++) + { + INSIST(i < count); + addrs[i] = *cfg_obj_assockaddr(cfg_listelt_value(element)); + if (isc_sockaddr_getport(&addrs[i]) == 0) + isc_sockaddr_setport(&addrs[i], port); + } + INSIST(i == count); + + *addrsp = addrs; + *countp = count; + + return (ISC_R_SUCCESS); +} + +void +ns_config_putiplist(isc_mem_t *mctx, isc_sockaddr_t **addrsp, + isc_uint32_t count) +{ + INSIST(addrsp != NULL && *addrsp != NULL); + + isc_mem_put(mctx, *addrsp, count * sizeof(isc_sockaddr_t)); + *addrsp = NULL; +} + +static isc_result_t +get_masters_def(cfg_obj_t *cctx, char *name, cfg_obj_t **ret) { + isc_result_t result; + cfg_obj_t *masters = NULL; + cfg_listelt_t *elt; + + result = cfg_map_get(cctx, "masters", &masters); + if (result != ISC_R_SUCCESS) + return (result); + for (elt = cfg_list_first(masters); + elt != NULL; + elt = cfg_list_next(elt)) { + cfg_obj_t *list; + const char *listname; + + list = cfg_listelt_value(elt); + listname = cfg_obj_asstring(cfg_tuple_get(list, "name")); + + if (strcasecmp(listname, name) == 0) { + *ret = list; + return (ISC_R_SUCCESS); + } + } + return (ISC_R_NOTFOUND); +} + +isc_result_t +ns_config_getipandkeylist(cfg_obj_t *config, cfg_obj_t *list, isc_mem_t *mctx, + isc_sockaddr_t **addrsp, dns_name_t ***keysp, + isc_uint32_t *countp) +{ + isc_uint32_t addrcount = 0, keycount = 0, i = 0; + isc_uint32_t listcount = 0, l = 0, j; + isc_uint32_t stackcount = 0, pushed = 0; + isc_result_t result; + cfg_listelt_t *element; + cfg_obj_t *addrlist; + cfg_obj_t *portobj; + in_port_t port; + dns_fixedname_t fname; + isc_sockaddr_t *addrs = NULL; + dns_name_t **keys = NULL; + char **lists = NULL; + struct { + cfg_listelt_t *element; + in_port_t port; + } *stack = NULL; + + REQUIRE(addrsp != NULL && *addrsp == NULL); + REQUIRE(keysp != NULL && *keysp == NULL); + REQUIRE(countp != NULL); + + newlist: + addrlist = cfg_tuple_get(list, "addresses"); + portobj = cfg_tuple_get(list, "port"); + if (cfg_obj_isuint32(portobj)) { + isc_uint32_t val = cfg_obj_asuint32(portobj); + if (val > ISC_UINT16_MAX) { + cfg_obj_log(portobj, ns_g_lctx, ISC_LOG_ERROR, + "port '%u' out of range", val); + return (ISC_R_RANGE); + } + port = (in_port_t) val; + } else { + result = ns_config_getport(config, &port); + if (result != ISC_R_SUCCESS) + return (result); + } + + result = ISC_R_NOMEMORY; + + element = cfg_list_first(addrlist); + resume: + for ( ; + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *addr; + cfg_obj_t *key; + char *keystr; + isc_buffer_t b; + + addr = cfg_tuple_get(cfg_listelt_value(element), + "masterselement"); + key = cfg_tuple_get(cfg_listelt_value(element), "key"); + + if (!cfg_obj_issockaddr(addr)) { + char *listname = cfg_obj_asstring(addr); + isc_result_t tresult; + + /* Grow lists? */ + if (listcount == l) { + void * new; + isc_uint32_t newlen = listcount + 16; + size_t newsize, oldsize; + + newsize = newlen * sizeof(*lists); + oldsize = listcount * sizeof(*lists); + new = isc_mem_get(mctx, newsize); + if (new == NULL) + goto cleanup; + if (listcount != 0) { + memcpy(new, lists, oldsize); + isc_mem_put(mctx, lists, oldsize); + } + lists = new; + listcount = newlen; + } + /* Seen? */ + for (j = 0; j < l; j++) + if (strcasecmp(lists[j], listname) == 0) + break; + if (j < l) + continue; + tresult = get_masters_def(config, listname, &list); + if (tresult == ISC_R_NOTFOUND) { + cfg_obj_log(addr, ns_g_lctx, ISC_LOG_ERROR, + "masters \"%s\" not found", listname); + + result = tresult; + goto cleanup; + } + if (tresult != ISC_R_SUCCESS) + goto cleanup; + lists[l++] = listname; + /* Grow stack? */ + if (stackcount == pushed) { + void * new; + isc_uint32_t newlen = stackcount + 16; + size_t newsize, oldsize; + + newsize = newlen * sizeof(*stack); + oldsize = stackcount * sizeof(*stack); + new = isc_mem_get(mctx, newsize); + if (new == NULL) + goto cleanup; + if (stackcount != 0) { + memcpy(new, stack, oldsize); + isc_mem_put(mctx, stack, oldsize); + } + stack = new; + stackcount = newlen; + } + /* + * We want to resume processing this list on the + * next element. + */ + stack[pushed].element = cfg_list_next(element); + stack[pushed].port = port; + pushed++; + goto newlist; + } + + if (i == addrcount) { + void * new; + isc_uint32_t newlen = addrcount + 16; + size_t newsize, oldsize; + + newsize = newlen * sizeof(isc_sockaddr_t); + oldsize = addrcount * sizeof(isc_sockaddr_t); + new = isc_mem_get(mctx, newsize); + if (new == NULL) + goto cleanup; + if (addrcount != 0) { + memcpy(new, addrs, oldsize); + isc_mem_put(mctx, addrs, oldsize); + } + addrs = new; + addrcount = newlen; + + newsize = newlen * sizeof(dns_name_t *); + oldsize = keycount * sizeof(dns_name_t *); + new = isc_mem_get(mctx, newsize); + if (new == NULL) + goto cleanup; + if (keycount != 0) { + memcpy(new, keys, newsize); + isc_mem_put(mctx, keys, newsize); + } + keys = new; + keycount = newlen; + } + + addrs[i] = *cfg_obj_assockaddr(addr); + if (isc_sockaddr_getport(&addrs[i]) == 0) + isc_sockaddr_setport(&addrs[i], port); + keys[i] = NULL; + if (!cfg_obj_isstring(key)) { + i++; + continue; + } + keys[i] = isc_mem_get(mctx, sizeof(dns_name_t)); + if (keys[i] == NULL) + goto cleanup; + dns_name_init(keys[i], NULL); + + keystr = cfg_obj_asstring(key); + isc_buffer_init(&b, keystr, strlen(keystr)); + isc_buffer_add(&b, strlen(keystr)); + dns_fixedname_init(&fname); + result = dns_name_fromtext(dns_fixedname_name(&fname), &b, + dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) + goto cleanup; + result = dns_name_dup(dns_fixedname_name(&fname), mctx, + keys[i]); + if (result != ISC_R_SUCCESS) + goto cleanup; + i++; + } + if (pushed != 0) { + pushed--; + element = stack[pushed].element; + port = stack[pushed].port; + goto resume; + } + if (i < addrcount) { + void * new; + size_t newsize, oldsize; + + newsize = i * sizeof(isc_sockaddr_t); + oldsize = addrcount * sizeof(isc_sockaddr_t); + if (i != 0) { + new = isc_mem_get(mctx, newsize); + if (new == NULL) + goto cleanup; + memcpy(new, addrs, newsize); + isc_mem_put(mctx, addrs, oldsize); + } else + new = NULL; + addrs = new; + addrcount = i; + + newsize = i * sizeof(dns_name_t *); + oldsize = keycount * sizeof(dns_name_t *); + if (i != 0) { + new = isc_mem_get(mctx, newsize); + if (new == NULL) + goto cleanup; + memcpy(new, keys, newsize); + isc_mem_put(mctx, keys, oldsize); + } else + new = NULL; + keys = new; + keycount = i; + } + + if (lists != NULL) + isc_mem_put(mctx, lists, listcount * sizeof(*lists)); + if (stack != NULL) + isc_mem_put(mctx, stack, stackcount * sizeof(*stack)); + + INSIST(keycount == addrcount); + + *addrsp = addrs; + *keysp = keys; + *countp = addrcount; + + return (ISC_R_SUCCESS); + + cleanup: + if (addrs != NULL) + isc_mem_put(mctx, addrs, addrcount * sizeof(isc_sockaddr_t)); + if (keys != NULL) { + for (j = 0; j <= i; j++) { + if (keys[j] == NULL) + continue; + if (dns_name_dynamic(keys[j])) + dns_name_free(keys[j], mctx); + isc_mem_put(mctx, keys[j], sizeof(dns_name_t)); + } + isc_mem_put(mctx, keys, keycount * sizeof(dns_name_t *)); + } + if (lists != NULL) + isc_mem_put(mctx, lists, listcount * sizeof(*lists)); + if (stack != NULL) + isc_mem_put(mctx, stack, stackcount * sizeof(*stack)); + return (result); +} + +void +ns_config_putipandkeylist(isc_mem_t *mctx, isc_sockaddr_t **addrsp, + dns_name_t ***keysp, isc_uint32_t count) +{ + unsigned int i; + dns_name_t **keys = *keysp; + + INSIST(addrsp != NULL && *addrsp != NULL); + + isc_mem_put(mctx, *addrsp, count * sizeof(isc_sockaddr_t)); + for (i = 0; i < count; i++) { + if (keys[i] == NULL) + continue; + if (dns_name_dynamic(keys[i])) + dns_name_free(keys[i], mctx); + isc_mem_put(mctx, keys[i], sizeof(dns_name_t)); + } + isc_mem_put(mctx, *keysp, count * sizeof(dns_name_t *)); + *addrsp = NULL; + *keysp = NULL; +} + +isc_result_t +ns_config_getport(cfg_obj_t *config, in_port_t *portp) { + cfg_obj_t *maps[3]; + cfg_obj_t *options = NULL; + cfg_obj_t *portobj = NULL; + isc_result_t result; + int i; + + (void)cfg_map_get(config, "options", &options); + i = 0; + if (options != NULL) + maps[i++] = options; + maps[i++] = ns_g_defaults; + maps[i] = NULL; + + result = ns_config_get(maps, "port", &portobj); + INSIST(result == ISC_R_SUCCESS); + if (cfg_obj_asuint32(portobj) >= ISC_UINT16_MAX) { + cfg_obj_log(portobj, ns_g_lctx, ISC_LOG_ERROR, + "port '%u' out of range", + cfg_obj_asuint32(portobj)); + return (ISC_R_RANGE); + } + *portp = (in_port_t)cfg_obj_asuint32(portobj); + return (ISC_R_SUCCESS); +} + +isc_result_t +ns_config_getkeyalgorithm(const char *str, dns_name_t **name) +{ + if (strcasecmp(str, "hmac-md5") == 0 || + strcasecmp(str, "hmac-md5.sig-alg.reg.int") == 0 || + strcasecmp(str, "hmac-md5.sig-alg.reg.int.") == 0) + { + if (name != NULL) + *name = dns_tsig_hmacmd5_name; + return (ISC_R_SUCCESS); + } + return (ISC_R_NOTFOUND); +} diff --git a/contrib/bind9/bin/named/control.c b/contrib/bind9/bin/named/control.c new file mode 100644 index 000000000000..89e36bd458c5 --- /dev/null +++ b/contrib/bind9/bin/named/control.c @@ -0,0 +1,140 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: control.c,v 1.7.2.2.2.10 2004/03/22 01:52:22 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include + +#include + +#include +#include +#include + +#include +#include +#include +#include + +static isc_boolean_t +command_compare(const char *text, const char *command) { + unsigned int commandlen = strlen(command); + if (strncasecmp(text, command, commandlen) == 0 && + (text[commandlen] == '\0' || + text[commandlen] == ' ' || + text[commandlen] == '\t')) + return (ISC_TRUE); + return (ISC_FALSE); +} + +/* + * This function is called to process the incoming command + * when a control channel message is received. + */ +isc_result_t +ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) { + isccc_sexpr_t *data; + char *command; + isc_result_t result; + + data = isccc_alist_lookup(message, "_data"); + if (data == NULL) { + /* + * No data section. + */ + return (ISC_R_FAILURE); + } + + result = isccc_cc_lookupstring(data, "type", &command); + if (result != ISC_R_SUCCESS) { + /* + * We have no idea what this is. + */ + return (result); + } + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_DEBUG(1), + "received control channel command '%s'", + command); + + /* + * Compare the 'command' parameter against all known control commands. + */ + if (command_compare(command, NS_COMMAND_RELOAD)) { + result = ns_server_reloadcommand(ns_g_server, command, text); + } else if (command_compare(command, NS_COMMAND_RECONFIG)) { + result = ns_server_reconfigcommand(ns_g_server, command); + } else if (command_compare(command, NS_COMMAND_REFRESH)) { + result = ns_server_refreshcommand(ns_g_server, command, text); + } else if (command_compare(command, NS_COMMAND_RETRANSFER)) { + result = ns_server_retransfercommand(ns_g_server, command); + } else if (command_compare(command, NS_COMMAND_HALT)) { + ns_server_flushonshutdown(ns_g_server, ISC_FALSE); + ns_os_shutdownmsg(command, text); + isc_app_shutdown(); + result = ISC_R_SUCCESS; + } else if (command_compare(command, NS_COMMAND_STOP)) { + ns_server_flushonshutdown(ns_g_server, ISC_TRUE); + ns_os_shutdownmsg(command, text); + isc_app_shutdown(); + result = ISC_R_SUCCESS; + } else if (command_compare(command, NS_COMMAND_DUMPSTATS)) { + result = ns_server_dumpstats(ns_g_server); + } else if (command_compare(command, NS_COMMAND_QUERYLOG)) { + result = ns_server_togglequerylog(ns_g_server); + } else if (command_compare(command, NS_COMMAND_DUMPDB)) { + ns_server_dumpdb(ns_g_server, command); + result = ISC_R_SUCCESS; + } else if (command_compare(command, NS_COMMAND_TRACE)) { + result = ns_server_setdebuglevel(ns_g_server, command); + } else if (command_compare(command, NS_COMMAND_NOTRACE)) { + ns_g_debuglevel = 0; + isc_log_setdebuglevel(ns_g_lctx, ns_g_debuglevel); + result = ISC_R_SUCCESS; + } else if (command_compare(command, NS_COMMAND_FLUSH)) { + result = ns_server_flushcache(ns_g_server, command); + } else if (command_compare(command, NS_COMMAND_FLUSHNAME)) { + result = ns_server_flushname(ns_g_server, command); + } else if (command_compare(command, NS_COMMAND_STATUS)) { + result = ns_server_status(ns_g_server, text); + } else if (command_compare(command, NS_COMMAND_FREEZE)) { + result = ns_server_freeze(ns_g_server, ISC_TRUE, command); + } else if (command_compare(command, NS_COMMAND_UNFREEZE)) { + result = ns_server_freeze(ns_g_server, ISC_FALSE, command); + } else if (command_compare(command, NS_COMMAND_RECURSING)) { + result = ns_server_dumprecursing(ns_g_server); + } else if (command_compare(command, NS_COMMAND_NULL)) { + result = ISC_R_SUCCESS; + } else { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_WARNING, + "unknown control channel command '%s'", + command); + result = DNS_R_UNKNOWNCOMMAND; + } + + return (result); +} diff --git a/contrib/bind9/bin/named/controlconf.c b/contrib/bind9/bin/named/controlconf.c new file mode 100644 index 000000000000..5b87fb9c0a1f --- /dev/null +++ b/contrib/bind9/bin/named/controlconf.c @@ -0,0 +1,1323 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: controlconf.c,v 1.28.2.9.2.6 2004/03/08 09:04:14 marka Exp $ */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include + +/* + * Note: Listeners and connections are not locked. All event handlers are + * executed by the server task, and all callers of exported routines must + * be running under the server task. + */ + +typedef struct controlkey controlkey_t; +typedef ISC_LIST(controlkey_t) controlkeylist_t; + +typedef struct controlconnection controlconnection_t; +typedef ISC_LIST(controlconnection_t) controlconnectionlist_t; + +typedef struct controllistener controllistener_t; +typedef ISC_LIST(controllistener_t) controllistenerlist_t; + +struct controlkey { + char * keyname; + isc_region_t secret; + ISC_LINK(controlkey_t) link; +}; + +struct controlconnection { + isc_socket_t * sock; + isccc_ccmsg_t ccmsg; + isc_boolean_t ccmsg_valid; + isc_boolean_t sending; + isc_timer_t * timer; + unsigned char buffer[2048]; + controllistener_t * listener; + isc_uint32_t nonce; + ISC_LINK(controlconnection_t) link; +}; + +struct controllistener { + ns_controls_t * controls; + isc_mem_t * mctx; + isc_task_t * task; + isc_sockaddr_t address; + isc_socket_t * sock; + dns_acl_t * acl; + isc_boolean_t listening; + isc_boolean_t exiting; + controlkeylist_t keys; + controlconnectionlist_t connections; + ISC_LINK(controllistener_t) link; +}; + +struct ns_controls { + ns_server_t *server; + controllistenerlist_t listeners; + isc_boolean_t shuttingdown; + isccc_symtab_t *symtab; +}; + +static void control_newconn(isc_task_t *task, isc_event_t *event); +static void control_recvmessage(isc_task_t *task, isc_event_t *event); + +#define CLOCKSKEW 300 + +static void +free_controlkey(controlkey_t *key, isc_mem_t *mctx) { + if (key->keyname != NULL) + isc_mem_free(mctx, key->keyname); + if (key->secret.base != NULL) + isc_mem_put(mctx, key->secret.base, key->secret.length); + isc_mem_put(mctx, key, sizeof(*key)); +} + +static void +free_controlkeylist(controlkeylist_t *keylist, isc_mem_t *mctx) { + while (!ISC_LIST_EMPTY(*keylist)) { + controlkey_t *key = ISC_LIST_HEAD(*keylist); + ISC_LIST_UNLINK(*keylist, key, link); + free_controlkey(key, mctx); + } +} + +static void +free_listener(controllistener_t *listener) { + INSIST(listener->exiting); + INSIST(!listener->listening); + INSIST(ISC_LIST_EMPTY(listener->connections)); + + if (listener->sock != NULL) + isc_socket_detach(&listener->sock); + + free_controlkeylist(&listener->keys, listener->mctx); + + if (listener->acl != NULL) + dns_acl_detach(&listener->acl); + + isc_mem_put(listener->mctx, listener, sizeof(*listener)); +} + +static void +maybe_free_listener(controllistener_t *listener) { + if (listener->exiting && + !listener->listening && + ISC_LIST_EMPTY(listener->connections)) + free_listener(listener); +} + +static void +maybe_free_connection(controlconnection_t *conn) { + controllistener_t *listener = conn->listener; + + if (conn->timer != NULL) + isc_timer_detach(&conn->timer); + + if (conn->ccmsg_valid) { + isccc_ccmsg_cancelread(&conn->ccmsg); + return; + } + + if (conn->sending) { + isc_socket_cancel(conn->sock, listener->task, + ISC_SOCKCANCEL_SEND); + return; + } + + ISC_LIST_UNLINK(listener->connections, conn, link); + isc_mem_put(listener->mctx, conn, sizeof(*conn)); +} + +static void +shutdown_listener(controllistener_t *listener) { + controlconnection_t *conn; + controlconnection_t *next; + + if (!listener->exiting) { + char socktext[ISC_SOCKADDR_FORMATSIZE]; + + ISC_LIST_UNLINK(listener->controls->listeners, listener, link); + + isc_sockaddr_format(&listener->address, socktext, + sizeof(socktext)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_NOTICE, + "stopping command channel on %s", socktext); + listener->exiting = ISC_TRUE; + } + + for (conn = ISC_LIST_HEAD(listener->connections); + conn != NULL; + conn = next) + { + next = ISC_LIST_NEXT(conn, link); + maybe_free_connection(conn); + } + + if (listener->listening) + isc_socket_cancel(listener->sock, listener->task, + ISC_SOCKCANCEL_ACCEPT); + + maybe_free_listener(listener); +} + +static isc_boolean_t +address_ok(isc_sockaddr_t *sockaddr, dns_acl_t *acl) { + isc_netaddr_t netaddr; + isc_result_t result; + int match; + + isc_netaddr_fromsockaddr(&netaddr, sockaddr); + + result = dns_acl_match(&netaddr, NULL, acl, + &ns_g_server->aclenv, &match, NULL); + + if (result != ISC_R_SUCCESS || match <= 0) + return (ISC_FALSE); + else + return (ISC_TRUE); +} + +static isc_result_t +control_accept(controllistener_t *listener) { + isc_result_t result; + result = isc_socket_accept(listener->sock, + listener->task, + control_newconn, listener); + if (result != ISC_R_SUCCESS) + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_socket_accept() failed: %s", + isc_result_totext(result)); + else + listener->listening = ISC_TRUE; + return (result); +} + +static isc_result_t +control_listen(controllistener_t *listener) { + isc_result_t result; + + result = isc_socket_listen(listener->sock, 0); + if (result != ISC_R_SUCCESS) + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_socket_listen() failed: %s", + isc_result_totext(result)); + return (result); +} + +static void +control_next(controllistener_t *listener) { + (void)control_accept(listener); +} + +static void +control_senddone(isc_task_t *task, isc_event_t *event) { + isc_socketevent_t *sevent = (isc_socketevent_t *) event; + controlconnection_t *conn = event->ev_arg; + controllistener_t *listener = conn->listener; + isc_socket_t *sock = (isc_socket_t *)sevent->ev_sender; + isc_result_t result; + + REQUIRE(conn->sending); + + UNUSED(task); + + conn->sending = ISC_FALSE; + + if (sevent->result != ISC_R_SUCCESS && + sevent->result != ISC_R_CANCELED) + { + char socktext[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_t peeraddr; + + (void)isc_socket_getpeername(sock, &peeraddr); + isc_sockaddr_format(&peeraddr, socktext, sizeof(socktext)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_WARNING, + "error sending command response to %s: %s", + socktext, isc_result_totext(sevent->result)); + } + isc_event_free(&event); + + result = isccc_ccmsg_readmessage(&conn->ccmsg, listener->task, + control_recvmessage, conn); + if (result != ISC_R_SUCCESS) { + isc_socket_detach(&conn->sock); + maybe_free_connection(conn); + maybe_free_listener(listener); + } +} + +static inline void +log_invalid(isccc_ccmsg_t *ccmsg, isc_result_t result) { + char socktext[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_t peeraddr; + + (void)isc_socket_getpeername(ccmsg->sock, &peeraddr); + isc_sockaddr_format(&peeraddr, socktext, sizeof(socktext)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_ERROR, + "invalid command from %s: %s", + socktext, isc_result_totext(result)); +} + +static void +control_recvmessage(isc_task_t *task, isc_event_t *event) { + controlconnection_t *conn; + controllistener_t *listener; + controlkey_t *key; + isccc_sexpr_t *request = NULL; + isccc_sexpr_t *response = NULL; + isccc_region_t ccregion; + isccc_region_t secret; + isc_stdtime_t now; + isc_buffer_t b; + isc_region_t r; + isc_uint32_t len; + isc_buffer_t text; + char textarray[1024]; + isc_result_t result; + isc_result_t eresult; + isccc_sexpr_t *_ctrl; + isccc_time_t sent; + isccc_time_t exp; + isc_uint32_t nonce; + + REQUIRE(event->ev_type == ISCCC_EVENT_CCMSG); + + conn = event->ev_arg; + listener = conn->listener; + secret.rstart = NULL; + + /* Is the server shutting down? */ + if (listener->controls->shuttingdown) + goto cleanup; + + if (conn->ccmsg.result != ISC_R_SUCCESS) { + if (conn->ccmsg.result != ISC_R_CANCELED && + conn->ccmsg.result != ISC_R_EOF) + log_invalid(&conn->ccmsg, conn->ccmsg.result); + goto cleanup; + } + + request = NULL; + + for (key = ISC_LIST_HEAD(listener->keys); + key != NULL; + key = ISC_LIST_NEXT(key, link)) + { + ccregion.rstart = isc_buffer_base(&conn->ccmsg.buffer); + ccregion.rend = isc_buffer_used(&conn->ccmsg.buffer); + secret.rstart = isc_mem_get(listener->mctx, key->secret.length); + if (secret.rstart == NULL) + goto cleanup; + memcpy(secret.rstart, key->secret.base, key->secret.length); + secret.rend = secret.rstart + key->secret.length; + result = isccc_cc_fromwire(&ccregion, &request, &secret); + if (result == ISC_R_SUCCESS) + break; + else if (result == ISCCC_R_BADAUTH) { + /* + * For some reason, request is non-NULL when + * isccc_cc_fromwire returns ISCCC_R_BADAUTH. + */ + if (request != NULL) + isccc_sexpr_free(&request); + isc_mem_put(listener->mctx, secret.rstart, + REGION_SIZE(secret)); + } else { + log_invalid(&conn->ccmsg, result); + goto cleanup; + } + } + + if (key == NULL) { + log_invalid(&conn->ccmsg, ISCCC_R_BADAUTH); + goto cleanup; + } + + /* We shouldn't be getting a reply. */ + if (isccc_cc_isreply(request)) { + log_invalid(&conn->ccmsg, ISC_R_FAILURE); + goto cleanup; + } + + isc_stdtime_get(&now); + + /* + * Limit exposure to replay attacks. + */ + _ctrl = isccc_alist_lookup(request, "_ctrl"); + if (_ctrl == NULL) { + log_invalid(&conn->ccmsg, ISC_R_FAILURE); + goto cleanup; + } + + if (isccc_cc_lookupuint32(_ctrl, "_tim", &sent) == ISC_R_SUCCESS) { + if ((sent + CLOCKSKEW) < now || (sent - CLOCKSKEW) > now) { + log_invalid(&conn->ccmsg, ISCCC_R_CLOCKSKEW); + goto cleanup; + } + } else { + log_invalid(&conn->ccmsg, ISC_R_FAILURE); + goto cleanup; + } + + /* + * Expire messages that are too old. + */ + if (isccc_cc_lookupuint32(_ctrl, "_exp", &exp) == ISC_R_SUCCESS && + now > exp) { + log_invalid(&conn->ccmsg, ISCCC_R_EXPIRED); + goto cleanup; + } + + /* + * Duplicate suppression (required for UDP). + */ + isccc_cc_cleansymtab(listener->controls->symtab, now); + result = isccc_cc_checkdup(listener->controls->symtab, request, now); + if (result != ISC_R_SUCCESS) { + if (result == ISC_R_EXISTS) + result = ISCCC_R_DUPLICATE; + log_invalid(&conn->ccmsg, result); + goto cleanup; + } + + if (conn->nonce != 0 && + (isccc_cc_lookupuint32(_ctrl, "_nonce", &nonce) != ISC_R_SUCCESS || + conn->nonce != nonce)) { + log_invalid(&conn->ccmsg, ISCCC_R_BADAUTH); + goto cleanup; + } + + /* + * Establish nonce. + */ + while (conn->nonce == 0) + isc_random_get(&conn->nonce); + + isc_buffer_init(&text, textarray, sizeof(textarray)); + eresult = ns_control_docommand(request, &text); + + result = isccc_cc_createresponse(request, now, now + 60, &response); + if (result != ISC_R_SUCCESS) + goto cleanup; + if (eresult != ISC_R_SUCCESS) { + isccc_sexpr_t *data; + + data = isccc_alist_lookup(response, "_data"); + if (data != NULL) { + const char *estr = isc_result_totext(eresult); + if (isccc_cc_definestring(data, "err", estr) == NULL) + goto cleanup; + } + } + + if (isc_buffer_usedlength(&text) > 0) { + isccc_sexpr_t *data; + + data = isccc_alist_lookup(response, "_data"); + if (data != NULL) { + char *str = (char *)isc_buffer_base(&text); + if (isccc_cc_definestring(data, "text", str) == NULL) + goto cleanup; + } + } + + _ctrl = isccc_alist_lookup(response, "_ctrl"); + if (_ctrl == NULL || + isccc_cc_defineuint32(_ctrl, "_nonce", conn->nonce) == NULL) + goto cleanup; + + ccregion.rstart = conn->buffer + 4; + ccregion.rend = conn->buffer + sizeof(conn->buffer); + result = isccc_cc_towire(response, &ccregion, &secret); + if (result != ISC_R_SUCCESS) + goto cleanup; + isc_buffer_init(&b, conn->buffer, 4); + len = sizeof(conn->buffer) - REGION_SIZE(ccregion); + isc_buffer_putuint32(&b, len - 4); + r.base = conn->buffer; + r.length = len; + + result = isc_socket_send(conn->sock, &r, task, control_senddone, conn); + if (result != ISC_R_SUCCESS) + goto cleanup; + conn->sending = ISC_TRUE; + + if (secret.rstart != NULL) + isc_mem_put(listener->mctx, secret.rstart, + REGION_SIZE(secret)); + if (request != NULL) + isccc_sexpr_free(&request); + if (response != NULL) + isccc_sexpr_free(&response); + return; + + cleanup: + if (secret.rstart != NULL) + isc_mem_put(listener->mctx, secret.rstart, + REGION_SIZE(secret)); + isc_socket_detach(&conn->sock); + isccc_ccmsg_invalidate(&conn->ccmsg); + conn->ccmsg_valid = ISC_FALSE; + maybe_free_connection(conn); + maybe_free_listener(listener); + if (request != NULL) + isccc_sexpr_free(&request); + if (response != NULL) + isccc_sexpr_free(&response); +} + +static void +control_timeout(isc_task_t *task, isc_event_t *event) { + controlconnection_t *conn = event->ev_arg; + + UNUSED(task); + + isc_timer_detach(&conn->timer); + maybe_free_connection(conn); + + isc_event_free(&event); +} + +static isc_result_t +newconnection(controllistener_t *listener, isc_socket_t *sock) { + controlconnection_t *conn; + isc_interval_t interval; + isc_result_t result; + + conn = isc_mem_get(listener->mctx, sizeof(*conn)); + if (conn == NULL) + return (ISC_R_NOMEMORY); + + conn->sock = sock; + isccc_ccmsg_init(listener->mctx, sock, &conn->ccmsg); + conn->ccmsg_valid = ISC_TRUE; + conn->sending = ISC_FALSE; + conn->timer = NULL; + isc_interval_set(&interval, 60, 0); + result = isc_timer_create(ns_g_timermgr, isc_timertype_once, + NULL, &interval, listener->task, + control_timeout, conn, &conn->timer); + if (result != ISC_R_SUCCESS) + goto cleanup; + + conn->listener = listener; + conn->nonce = 0; + ISC_LINK_INIT(conn, link); + + result = isccc_ccmsg_readmessage(&conn->ccmsg, listener->task, + control_recvmessage, conn); + if (result != ISC_R_SUCCESS) + goto cleanup; + isccc_ccmsg_setmaxsize(&conn->ccmsg, 2048); + + ISC_LIST_APPEND(listener->connections, conn, link); + return (ISC_R_SUCCESS); + + cleanup: + isccc_ccmsg_invalidate(&conn->ccmsg); + if (conn->timer != NULL) + isc_timer_detach(&conn->timer); + isc_mem_put(listener->mctx, conn, sizeof(*conn)); + return (result); +} + +static void +control_newconn(isc_task_t *task, isc_event_t *event) { + isc_socket_newconnev_t *nevent = (isc_socket_newconnev_t *)event; + controllistener_t *listener = event->ev_arg; + isc_socket_t *sock; + isc_sockaddr_t peeraddr; + isc_result_t result; + + UNUSED(task); + + listener->listening = ISC_FALSE; + + if (nevent->result != ISC_R_SUCCESS) { + if (nevent->result == ISC_R_CANCELED) { + shutdown_listener(listener); + goto cleanup; + } + goto restart; + } + + sock = nevent->newsocket; + (void)isc_socket_getpeername(sock, &peeraddr); + if (!address_ok(&peeraddr, listener->acl)) { + char socktext[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_format(&peeraddr, socktext, sizeof(socktext)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_WARNING, + "rejected command channel message from %s", + socktext); + isc_socket_detach(&sock); + goto restart; + } + + result = newconnection(listener, sock); + if (result != ISC_R_SUCCESS) { + char socktext[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_format(&peeraddr, socktext, sizeof(socktext)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_WARNING, + "dropped command channel from %s: %s", + socktext, isc_result_totext(result)); + isc_socket_detach(&sock); + goto restart; + } + + restart: + control_next(listener); + cleanup: + isc_event_free(&event); +} + +static void +controls_shutdown(ns_controls_t *controls) { + controllistener_t *listener; + controllistener_t *next; + + for (listener = ISC_LIST_HEAD(controls->listeners); + listener != NULL; + listener = next) + { + /* + * This is asynchronous. As listeners shut down, they will + * call their callbacks. + */ + next = ISC_LIST_NEXT(listener, link); + shutdown_listener(listener); + } +} + +void +ns_controls_shutdown(ns_controls_t *controls) { + controls_shutdown(controls); + controls->shuttingdown = ISC_TRUE; +} + +static isc_result_t +cfgkeylist_find(cfg_obj_t *keylist, const char *keyname, cfg_obj_t **objp) { + cfg_listelt_t *element; + const char *str; + cfg_obj_t *obj; + + for (element = cfg_list_first(keylist); + element != NULL; + element = cfg_list_next(element)) + { + obj = cfg_listelt_value(element); + str = cfg_obj_asstring(cfg_map_getname(obj)); + if (strcasecmp(str, keyname) == 0) + break; + } + if (element == NULL) + return (ISC_R_NOTFOUND); + obj = cfg_listelt_value(element); + *objp = obj; + return (ISC_R_SUCCESS); +} + +static isc_result_t +controlkeylist_fromcfg(cfg_obj_t *keylist, isc_mem_t *mctx, + controlkeylist_t *keyids) +{ + cfg_listelt_t *element; + char *newstr = NULL; + const char *str; + cfg_obj_t *obj; + controlkey_t *key = NULL; + + for (element = cfg_list_first(keylist); + element != NULL; + element = cfg_list_next(element)) + { + obj = cfg_listelt_value(element); + str = cfg_obj_asstring(obj); + newstr = isc_mem_strdup(mctx, str); + if (newstr == NULL) + goto cleanup; + key = isc_mem_get(mctx, sizeof(*key)); + if (key == NULL) + goto cleanup; + key->keyname = newstr; + key->secret.base = NULL; + key->secret.length = 0; + ISC_LINK_INIT(key, link); + ISC_LIST_APPEND(*keyids, key, link); + key = NULL; + newstr = NULL; + } + return (ISC_R_SUCCESS); + + cleanup: + if (newstr != NULL) + isc_mem_free(mctx, newstr); + if (key != NULL) + isc_mem_put(mctx, key, sizeof(*key)); + free_controlkeylist(keyids, mctx); + return (ISC_R_NOMEMORY); +} + +static void +register_keys(cfg_obj_t *control, cfg_obj_t *keylist, + controlkeylist_t *keyids, isc_mem_t *mctx, const char *socktext) +{ + controlkey_t *keyid, *next; + cfg_obj_t *keydef; + char secret[1024]; + isc_buffer_t b; + isc_result_t result; + + /* + * Find the keys corresponding to the keyids used by this listener. + */ + for (keyid = ISC_LIST_HEAD(*keyids); keyid != NULL; keyid = next) { + next = ISC_LIST_NEXT(keyid, link); + + result = cfgkeylist_find(keylist, keyid->keyname, &keydef); + if (result != ISC_R_SUCCESS) { + cfg_obj_log(control, ns_g_lctx, ISC_LOG_WARNING, + "couldn't find key '%s' for use with " + "command channel %s", + keyid->keyname, socktext); + ISC_LIST_UNLINK(*keyids, keyid, link); + free_controlkey(keyid, mctx); + } else { + cfg_obj_t *algobj = NULL; + cfg_obj_t *secretobj = NULL; + char *algstr = NULL; + char *secretstr = NULL; + + (void)cfg_map_get(keydef, "algorithm", &algobj); + (void)cfg_map_get(keydef, "secret", &secretobj); + INSIST(algobj != NULL && secretobj != NULL); + + algstr = cfg_obj_asstring(algobj); + secretstr = cfg_obj_asstring(secretobj); + + if (ns_config_getkeyalgorithm(algstr, NULL) != + ISC_R_SUCCESS) + { + cfg_obj_log(control, ns_g_lctx, + ISC_LOG_WARNING, + "unsupported algorithm '%s' in " + "key '%s' for use with command " + "channel %s", + algstr, keyid->keyname, socktext); + ISC_LIST_UNLINK(*keyids, keyid, link); + free_controlkey(keyid, mctx); + continue; + } + + isc_buffer_init(&b, secret, sizeof(secret)); + result = isc_base64_decodestring(secretstr, &b); + + if (result != ISC_R_SUCCESS) { + cfg_obj_log(keydef, ns_g_lctx, ISC_LOG_WARNING, + "secret for key '%s' on " + "command channel %s: %s", + keyid->keyname, socktext, + isc_result_totext(result)); + ISC_LIST_UNLINK(*keyids, keyid, link); + free_controlkey(keyid, mctx); + continue; + } + + keyid->secret.length = isc_buffer_usedlength(&b); + keyid->secret.base = isc_mem_get(mctx, + keyid->secret.length); + if (keyid->secret.base == NULL) { + cfg_obj_log(keydef, ns_g_lctx, ISC_LOG_WARNING, + "couldn't register key '%s': " + "out of memory", keyid->keyname); + ISC_LIST_UNLINK(*keyids, keyid, link); + free_controlkey(keyid, mctx); + break; + } + memcpy(keyid->secret.base, isc_buffer_base(&b), + keyid->secret.length); + } + } +} + +#define CHECK(x) \ + do { \ + result = (x); \ + if (result != ISC_R_SUCCESS) \ + goto cleanup; \ + } while (0) + +static isc_result_t +get_rndckey(isc_mem_t *mctx, controlkeylist_t *keyids) { + isc_result_t result; + cfg_parser_t *pctx = NULL; + cfg_obj_t *config = NULL; + cfg_obj_t *key = NULL; + cfg_obj_t *algobj = NULL; + cfg_obj_t *secretobj = NULL; + char *algstr = NULL; + char *secretstr = NULL; + controlkey_t *keyid = NULL; + char secret[1024]; + isc_buffer_t b; + + CHECK(cfg_parser_create(mctx, ns_g_lctx, &pctx)); + CHECK(cfg_parse_file(pctx, ns_g_keyfile, &cfg_type_rndckey, &config)); + CHECK(cfg_map_get(config, "key", &key)); + + keyid = isc_mem_get(mctx, sizeof(*keyid)); + if (keyid == NULL) + CHECK(ISC_R_NOMEMORY); + keyid->keyname = isc_mem_strdup(mctx, + cfg_obj_asstring(cfg_map_getname(key))); + keyid->secret.base = NULL; + keyid->secret.length = 0; + ISC_LINK_INIT(keyid, link); + if (keyid->keyname == NULL) + CHECK(ISC_R_NOMEMORY); + + CHECK(bind9_check_key(key, ns_g_lctx)); + + (void)cfg_map_get(key, "algorithm", &algobj); + (void)cfg_map_get(key, "secret", &secretobj); + INSIST(algobj != NULL && secretobj != NULL); + + algstr = cfg_obj_asstring(algobj); + secretstr = cfg_obj_asstring(secretobj); + + if (ns_config_getkeyalgorithm(algstr, NULL) != ISC_R_SUCCESS) { + cfg_obj_log(key, ns_g_lctx, + ISC_LOG_WARNING, + "unsupported algorithm '%s' in " + "key '%s' for use with command " + "channel", + algstr, keyid->keyname); + goto cleanup; + } + + isc_buffer_init(&b, secret, sizeof(secret)); + result = isc_base64_decodestring(secretstr, &b); + + if (result != ISC_R_SUCCESS) { + cfg_obj_log(key, ns_g_lctx, ISC_LOG_WARNING, + "secret for key '%s' on command channel: %s", + keyid->keyname, isc_result_totext(result)); + CHECK(result); + } + + keyid->secret.length = isc_buffer_usedlength(&b); + keyid->secret.base = isc_mem_get(mctx, + keyid->secret.length); + if (keyid->secret.base == NULL) { + cfg_obj_log(key, ns_g_lctx, ISC_LOG_WARNING, + "couldn't register key '%s': " + "out of memory", keyid->keyname); + CHECK(ISC_R_NOMEMORY); + } + memcpy(keyid->secret.base, isc_buffer_base(&b), + keyid->secret.length); + ISC_LIST_APPEND(*keyids, keyid, link); + keyid = NULL; + result = ISC_R_SUCCESS; + + cleanup: + if (keyid != NULL) + free_controlkey(keyid, mctx); + if (config != NULL) + cfg_obj_destroy(pctx, &config); + if (pctx != NULL) + cfg_parser_destroy(&pctx); + return (result); +} + +/* + * Ensures that both '*global_keylistp' and '*control_keylistp' are + * valid or both are NULL. + */ +static void +get_key_info(cfg_obj_t *config, cfg_obj_t *control, + cfg_obj_t **global_keylistp, cfg_obj_t **control_keylistp) +{ + isc_result_t result; + cfg_obj_t *control_keylist = NULL; + cfg_obj_t *global_keylist = NULL; + + REQUIRE(global_keylistp != NULL && *global_keylistp == NULL); + REQUIRE(control_keylistp != NULL && *control_keylistp == NULL); + + control_keylist = cfg_tuple_get(control, "keys"); + + if (!cfg_obj_isvoid(control_keylist) && + cfg_list_first(control_keylist) != NULL) { + result = cfg_map_get(config, "key", &global_keylist); + + if (result == ISC_R_SUCCESS) { + *global_keylistp = global_keylist; + *control_keylistp = control_keylist; + } + } +} + +static void +update_listener(ns_controls_t *cp, + controllistener_t **listenerp, cfg_obj_t *control, + cfg_obj_t *config, isc_sockaddr_t *addr, + ns_aclconfctx_t *aclconfctx, const char *socktext) +{ + controllistener_t *listener; + cfg_obj_t *allow; + cfg_obj_t *global_keylist = NULL; + cfg_obj_t *control_keylist = NULL; + dns_acl_t *new_acl = NULL; + controlkeylist_t keys; + isc_result_t result = ISC_R_SUCCESS; + + for (listener = ISC_LIST_HEAD(cp->listeners); + listener != NULL; + listener = ISC_LIST_NEXT(listener, link)) + if (isc_sockaddr_equal(addr, &listener->address)) + break; + + if (listener == NULL) { + *listenerp = NULL; + return; + } + + /* + * There is already a listener for this sockaddr. + * Update the access list and key information. + * + * First try to deal with the key situation. There are a few + * possibilities: + * (a) It had an explicit keylist and still has an explicit keylist. + * (b) It had an automagic key and now has an explicit keylist. + * (c) It had an explicit keylist and now needs an automagic key. + * (d) It has an automagic key and still needs the automagic key. + * + * (c) and (d) are the annoying ones. The caller needs to know + * that it should use the automagic configuration for key information + * in place of the named.conf configuration. + * + * XXXDCL There is one other hazard that has not been dealt with, + * the problem that if a key change is being caused by a control + * channel reload, then the response will be with the new key + * and not able to be decrypted by the client. + */ + if (control != NULL) + get_key_info(config, control, &global_keylist, + &control_keylist); + + if (control_keylist != NULL) { + INSIST(global_keylist != NULL); + + ISC_LIST_INIT(keys); + result = controlkeylist_fromcfg(control_keylist, + listener->mctx, &keys); + if (result == ISC_R_SUCCESS) { + free_controlkeylist(&listener->keys, listener->mctx); + listener->keys = keys; + register_keys(control, global_keylist, &listener->keys, + listener->mctx, socktext); + } + } else { + free_controlkeylist(&listener->keys, listener->mctx); + result = get_rndckey(listener->mctx, &listener->keys); + } + + if (result != ISC_R_SUCCESS && global_keylist != NULL) + /* + * This message might be a little misleading since the + * "new keys" might in fact be identical to the old ones, + * but tracking whether they are identical just for the + * sake of avoiding this message would be too much trouble. + */ + cfg_obj_log(control, ns_g_lctx, ISC_LOG_WARNING, + "couldn't install new keys for " + "command channel %s: %s", + socktext, isc_result_totext(result)); + + + /* + * Now, keep the old access list unless a new one can be made. + */ + if (control != NULL) { + allow = cfg_tuple_get(control, "allow"); + result = ns_acl_fromconfig(allow, config, aclconfctx, + listener->mctx, &new_acl); + } else { + result = dns_acl_any(listener->mctx, &new_acl); + } + + if (result == ISC_R_SUCCESS) { + dns_acl_detach(&listener->acl); + dns_acl_attach(new_acl, &listener->acl); + dns_acl_detach(&new_acl); + } else + /* XXXDCL say the old acl is still used? */ + cfg_obj_log(control, ns_g_lctx, ISC_LOG_WARNING, + "couldn't install new acl for " + "command channel %s: %s", + socktext, isc_result_totext(result)); + + *listenerp = listener; +} + +static void +add_listener(ns_controls_t *cp, controllistener_t **listenerp, + cfg_obj_t *control, cfg_obj_t *config, isc_sockaddr_t *addr, + ns_aclconfctx_t *aclconfctx, const char *socktext) +{ + isc_mem_t *mctx = cp->server->mctx; + controllistener_t *listener; + cfg_obj_t *allow; + cfg_obj_t *global_keylist = NULL; + cfg_obj_t *control_keylist = NULL; + dns_acl_t *new_acl = NULL; + isc_result_t result = ISC_R_SUCCESS; + + listener = isc_mem_get(mctx, sizeof(*listener)); + if (listener == NULL) + result = ISC_R_NOMEMORY; + + if (result == ISC_R_SUCCESS) { + listener->controls = cp; + listener->mctx = mctx; + listener->task = cp->server->task; + listener->address = *addr; + listener->sock = NULL; + listener->listening = ISC_FALSE; + listener->exiting = ISC_FALSE; + listener->acl = NULL; + ISC_LINK_INIT(listener, link); + ISC_LIST_INIT(listener->keys); + ISC_LIST_INIT(listener->connections); + + /* + * Make the acl. + */ + if (control != NULL) { + allow = cfg_tuple_get(control, "allow"); + result = ns_acl_fromconfig(allow, config, aclconfctx, + mctx, &new_acl); + } else { + result = dns_acl_any(mctx, &new_acl); + } + } + + if (result == ISC_R_SUCCESS) { + dns_acl_attach(new_acl, &listener->acl); + dns_acl_detach(&new_acl); + + if (config != NULL) + get_key_info(config, control, &global_keylist, + &control_keylist); + + if (control_keylist != NULL) { + result = controlkeylist_fromcfg(control_keylist, + listener->mctx, + &listener->keys); + if (result == ISC_R_SUCCESS) + register_keys(control, global_keylist, + &listener->keys, + listener->mctx, socktext); + } else + result = get_rndckey(mctx, &listener->keys); + + if (result != ISC_R_SUCCESS && control != NULL) + cfg_obj_log(control, ns_g_lctx, ISC_LOG_WARNING, + "couldn't install keys for " + "command channel %s: %s", + socktext, isc_result_totext(result)); + } + + if (result == ISC_R_SUCCESS) { + int pf = isc_sockaddr_pf(&listener->address); + if ((pf == AF_INET && isc_net_probeipv4() != ISC_R_SUCCESS) || + (pf == AF_INET6 && isc_net_probeipv6() != ISC_R_SUCCESS)) + result = ISC_R_FAMILYNOSUPPORT; + } + + if (result == ISC_R_SUCCESS) + result = isc_socket_create(ns_g_socketmgr, + isc_sockaddr_pf(&listener->address), + isc_sockettype_tcp, + &listener->sock); + + if (result == ISC_R_SUCCESS) + result = isc_socket_bind(listener->sock, + &listener->address); + + if (result == ISC_R_SUCCESS) + result = control_listen(listener); + + if (result == ISC_R_SUCCESS) + result = control_accept(listener); + + if (result == ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_NOTICE, + "command channel listening on %s", socktext); + *listenerp = listener; + + } else { + if (listener != NULL) { + listener->exiting = ISC_TRUE; + free_listener(listener); + } + + if (control != NULL) + cfg_obj_log(control, ns_g_lctx, ISC_LOG_WARNING, + "couldn't add command channel %s: %s", + socktext, isc_result_totext(result)); + else + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, ISC_LOG_NOTICE, + "couldn't add command channel %s: %s", + socktext, isc_result_totext(result)); + + *listenerp = NULL; + } + + /* XXXDCL return error results? fail hard? */ +} + +isc_result_t +ns_controls_configure(ns_controls_t *cp, cfg_obj_t *config, + ns_aclconfctx_t *aclconfctx) +{ + controllistener_t *listener; + controllistenerlist_t new_listeners; + cfg_obj_t *controlslist = NULL; + cfg_listelt_t *element, *element2; + char socktext[ISC_SOCKADDR_FORMATSIZE]; + + ISC_LIST_INIT(new_listeners); + + /* + * Get the list of named.conf 'controls' statements. + */ + (void)cfg_map_get(config, "controls", &controlslist); + + /* + * Run through the new control channel list, noting sockets that + * are already being listened on and moving them to the new list. + * + * Identifying duplicate addr/port combinations is left to either + * the underlying config code, or to the bind attempt getting an + * address-in-use error. + */ + if (controlslist != NULL) { + for (element = cfg_list_first(controlslist); + element != NULL; + element = cfg_list_next(element)) { + cfg_obj_t *controls; + cfg_obj_t *inetcontrols = NULL; + + controls = cfg_listelt_value(element); + (void)cfg_map_get(controls, "inet", &inetcontrols); + if (inetcontrols == NULL) + continue; + + for (element2 = cfg_list_first(inetcontrols); + element2 != NULL; + element2 = cfg_list_next(element2)) { + cfg_obj_t *control; + cfg_obj_t *obj; + isc_sockaddr_t *addr; + + /* + * The parser handles BIND 8 configuration file + * syntax, so it allows unix phrases as well + * inet phrases with no keys{} clause. + * + * "unix" phrases have been reported as + * unsupported by the parser. + */ + control = cfg_listelt_value(element2); + + obj = cfg_tuple_get(control, "address"); + addr = cfg_obj_assockaddr(obj); + if (isc_sockaddr_getport(addr) == 0) + isc_sockaddr_setport(addr, + NS_CONTROL_PORT); + + isc_sockaddr_format(addr, socktext, + sizeof(socktext)); + + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, + ISC_LOG_DEBUG(9), + "processing control channel %s", + socktext); + + update_listener(cp, &listener, control, config, + addr, aclconfctx, socktext); + + if (listener != NULL) + /* + * Remove the listener from the old + * list, so it won't be shut down. + */ + ISC_LIST_UNLINK(cp->listeners, + listener, link); + else + /* + * This is a new listener. + */ + add_listener(cp, &listener, control, + config, addr, aclconfctx, + socktext); + + if (listener != NULL) + ISC_LIST_APPEND(new_listeners, + listener, link); + } + } + } else { + int i; + + for (i = 0; i < 2; i++) { + isc_sockaddr_t addr; + + if (i == 0) { + struct in_addr localhost; + + if (isc_net_probeipv4() != ISC_R_SUCCESS) + continue; + localhost.s_addr = htonl(INADDR_LOOPBACK); + isc_sockaddr_fromin(&addr, &localhost, 0); + } else { + if (isc_net_probeipv6() != ISC_R_SUCCESS) + continue; + isc_sockaddr_fromin6(&addr, + &in6addr_loopback, 0); + } + isc_sockaddr_setport(&addr, NS_CONTROL_PORT); + + isc_sockaddr_format(&addr, socktext, sizeof(socktext)); + + update_listener(cp, &listener, NULL, NULL, + &addr, NULL, socktext); + + if (listener != NULL) + /* + * Remove the listener from the old + * list, so it won't be shut down. + */ + ISC_LIST_UNLINK(cp->listeners, + listener, link); + else + /* + * This is a new listener. + */ + add_listener(cp, &listener, NULL, NULL, + &addr, NULL, socktext); + + if (listener != NULL) + ISC_LIST_APPEND(new_listeners, + listener, link); + } + } + + /* + * ns_control_shutdown() will stop whatever is on the global + * listeners list, which currently only has whatever sockaddrs + * were in the previous configuration (if any) that do not + * remain in the current configuration. + */ + controls_shutdown(cp); + + /* + * Put all of the valid listeners on the listeners list. + * Anything already on listeners in the process of shutting + * down will be taken care of by listen_done(). + */ + ISC_LIST_APPENDLIST(cp->listeners, new_listeners, link); + return (ISC_R_SUCCESS); +} + +isc_result_t +ns_controls_create(ns_server_t *server, ns_controls_t **ctrlsp) { + isc_mem_t *mctx = server->mctx; + isc_result_t result; + ns_controls_t *controls = isc_mem_get(mctx, sizeof(*controls)); + + if (controls == NULL) + return (ISC_R_NOMEMORY); + controls->server = server; + ISC_LIST_INIT(controls->listeners); + controls->shuttingdown = ISC_FALSE; + controls->symtab = NULL; + result = isccc_cc_createsymtab(&controls->symtab); + if (result != ISC_R_SUCCESS) { + isc_mem_put(server->mctx, controls, sizeof(*controls)); + return (result); + } + *ctrlsp = controls; + return (ISC_R_SUCCESS); +} + +void +ns_controls_destroy(ns_controls_t **ctrlsp) { + ns_controls_t *controls = *ctrlsp; + + REQUIRE(ISC_LIST_EMPTY(controls->listeners)); + + isccc_symtab_destroy(&controls->symtab); + isc_mem_put(controls->server->mctx, controls, sizeof(*controls)); + *ctrlsp = NULL; +} diff --git a/contrib/bind9/bin/named/include/named/aclconf.h b/contrib/bind9/bin/named/include/named/aclconf.h new file mode 100644 index 000000000000..812657278485 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/aclconf.h @@ -0,0 +1,72 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: aclconf.h,v 1.12.208.1 2004/03/06 10:21:23 marka Exp $ */ + +#ifndef NS_ACLCONF_H +#define NS_ACLCONF_H 1 + +#include + +#include + +#include + +typedef struct ns_aclconfctx { + ISC_LIST(dns_acl_t) named_acl_cache; +} ns_aclconfctx_t; + +/*** + *** Functions + ***/ + +ISC_LANG_BEGINDECLS + +void +ns_aclconfctx_init(ns_aclconfctx_t *ctx); +/* + * Initialize an ACL configuration context. + */ + +void +ns_aclconfctx_destroy(ns_aclconfctx_t *ctx); +/* + * Destroy an ACL configuration context. + */ + +isc_result_t +ns_acl_fromconfig(cfg_obj_t *caml, + cfg_obj_t *cctx, + ns_aclconfctx_t *ctx, + isc_mem_t *mctx, + dns_acl_t **target); +/* + * Construct a new dns_acl_t from configuration data in 'caml' and + * 'cctx'. Memory is allocated through 'mctx'. + * + * Any named ACLs referred to within 'caml' will be be converted + * inte nested dns_acl_t objects. Multiple references to the same + * named ACLs will be converted into shared references to a single + * nested dns_acl_t object when the referring objects were created + * passing the same ACL configuration context 'ctx'. + * + * On success, attach '*target' to the new dns_acl_t object. + */ + +ISC_LANG_ENDDECLS + +#endif /* NS_ACLCONF_H */ diff --git a/contrib/bind9/bin/named/include/named/builtin.h b/contrib/bind9/bin/named/include/named/builtin.h new file mode 100644 index 000000000000..15564bf3fb0d --- /dev/null +++ b/contrib/bind9/bin/named/include/named/builtin.h @@ -0,0 +1,29 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: builtin.h,v 1.1.204.3 2004/03/08 04:04:20 marka Exp $ */ + +#ifndef NAMED_BUILTIN_H +#define NAMED_BUILTIN_H 1 + +#include + +isc_result_t ns_builtin_init(void); + +void ns_builtin_deinit(void); + +#endif /* NAMED_BUILTIN_H */ diff --git a/contrib/bind9/bin/named/include/named/client.h b/contrib/bind9/bin/named/include/named/client.h new file mode 100644 index 000000000000..97951a41683c --- /dev/null +++ b/contrib/bind9/bin/named/include/named/client.h @@ -0,0 +1,337 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: client.h,v 1.60.2.2.10.8 2004/07/23 02:56:52 marka Exp $ */ + +#ifndef NAMED_CLIENT_H +#define NAMED_CLIENT_H 1 + +/***** + ***** Module Info + *****/ + +/* + * Client + * + * This module defines two objects, ns_client_t and ns_clientmgr_t. + * + * An ns_client_t object handles incoming DNS requests from clients + * on a given network interface. + * + * Each ns_client_t object can handle only one TCP connection or UDP + * request at a time. Therefore, several ns_client_t objects are + * typically created to serve each network interface, e.g., one + * for handling TCP requests and a few (one per CPU) for handling + * UDP requests. + * + * Incoming requests are classified as queries, zone transfer + * requests, update requests, notify requests, etc, and handed off + * to the appropriate request handler. When the request has been + * fully handled (which can be much later), the ns_client_t must be + * notified of this by calling one of the following functions + * exactly once in the context of its task: + * + * ns_client_send() (sending a non-error response) + * ns_client_sendraw() (sending a raw response) + * ns_client_error() (sending an error response) + * ns_client_next() (sending no response) + * + * This will release any resources used by the request and + * and allow the ns_client_t to listen for the next request. + * + * A ns_clientmgr_t manages a number of ns_client_t objects. + * New ns_client_t objects are created by calling + * ns_clientmgr_createclients(). They are destroyed by + * destroying their manager. + */ + +/*** + *** Imports + ***/ + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include +#include + +/*** + *** Types + ***/ + +typedef ISC_LIST(ns_client_t) client_list_t; + +struct ns_client { + unsigned int magic; + isc_mem_t * mctx; + ns_clientmgr_t * manager; + int state; + int newstate; + int naccepts; + int nreads; + int nsends; + int nrecvs; + int nupdates; + int nctls; + int references; + unsigned int attributes; + isc_task_t * task; + dns_view_t * view; + dns_dispatch_t * dispatch; + isc_socket_t * udpsocket; + isc_socket_t * tcplistener; + isc_socket_t * tcpsocket; + unsigned char * tcpbuf; + dns_tcpmsg_t tcpmsg; + isc_boolean_t tcpmsg_valid; + isc_timer_t * timer; + isc_boolean_t timerset; + dns_message_t * message; + isc_socketevent_t * sendevent; + isc_socketevent_t * recvevent; + unsigned char * recvbuf; + dns_rdataset_t * opt; + isc_uint16_t udpsize; + isc_uint16_t extflags; + void (*next)(ns_client_t *); + void (*shutdown)(void *arg, isc_result_t result); + void *shutdown_arg; + ns_query_t query; + isc_stdtime_t requesttime; + isc_stdtime_t now; + dns_name_t signername; /* [T]SIG key name */ + dns_name_t * signer; /* NULL if not valid sig */ + isc_boolean_t mortal; /* Die after handling request */ + isc_quota_t *tcpquota; + isc_quota_t *recursionquota; + ns_interface_t *interface; + isc_sockaddr_t peeraddr; + isc_boolean_t peeraddr_valid; + struct in6_pktinfo pktinfo; + isc_event_t ctlevent; + /* + * Information about recent FORMERR response(s), for + * FORMERR loop avoidance. This is separate for each + * client object rather than global only to avoid + * the need for locking. + */ + struct { + isc_sockaddr_t addr; + isc_stdtime_t time; + dns_messageid_t id; + } formerrcache; + ISC_LINK(ns_client_t) link; + /* + * The list 'link' is part of, or NULL if not on any list. + */ + client_list_t *list; +}; + +#define NS_CLIENT_MAGIC ISC_MAGIC('N','S','C','c') +#define NS_CLIENT_VALID(c) ISC_MAGIC_VALID(c, NS_CLIENT_MAGIC) + +#define NS_CLIENTATTR_TCP 0x01 +#define NS_CLIENTATTR_RA 0x02 /* Client gets recusive service */ +#define NS_CLIENTATTR_PKTINFO 0x04 /* pktinfo is valid */ +#define NS_CLIENTATTR_MULTICAST 0x08 /* recv'd from multicast */ +#define NS_CLIENTATTR_WANTDNSSEC 0x10 /* include dnssec records */ + + +/*** + *** Functions + ***/ + +/* + * Note! These ns_client_ routines MUST be called ONLY from the client's + * task in order to ensure synchronization. + */ + +void +ns_client_send(ns_client_t *client); +/* + * Finish processing the current client request and + * send client->message as a response. + */ + +void +ns_client_sendraw(ns_client_t *client, dns_message_t *msg); +/* + * Finish processing the current client request and + * send msg as a response using client->message->id for the id. + */ + +void +ns_client_error(ns_client_t *client, isc_result_t result); +/* + * Finish processing the current client request and return + * an error response to the client. The error response + * will have an RCODE determined by 'result'. + */ + +void +ns_client_next(ns_client_t *client, isc_result_t result); +/* + * Finish processing the current client request, + * return no response to the client. + */ + +isc_boolean_t +ns_client_shuttingdown(ns_client_t *client); +/* + * Return ISC_TRUE iff the client is currently shutting down. + */ + +void +ns_client_attach(ns_client_t *source, ns_client_t **target); +/* + * Attach '*targetp' to 'source'. + */ + +void +ns_client_detach(ns_client_t **clientp); +/* + * Detach '*clientp' from its client. + */ + +isc_result_t +ns_client_replace(ns_client_t *client); +/* + * Try to replace the current client with a new one, so that the + * current one can go off and do some lengthy work without + * leaving the dispatch/socket without service. + */ + +void +ns_client_settimeout(ns_client_t *client, unsigned int seconds); +/* + * Set a timer in the client to go off in the specified amount of time. + */ + +isc_result_t +ns_clientmgr_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr, + isc_timermgr_t *timermgr, ns_clientmgr_t **managerp); +/* + * Create a client manager. + */ + +void +ns_clientmgr_destroy(ns_clientmgr_t **managerp); +/* + * Destroy a client manager and all ns_client_t objects + * managed by it. + */ + +isc_result_t +ns_clientmgr_createclients(ns_clientmgr_t *manager, unsigned int n, + ns_interface_t *ifp, isc_boolean_t tcp); +/* + * Create up to 'n' clients listening on interface 'ifp'. + * If 'tcp' is ISC_TRUE, the clients will listen for TCP connections, + * otherwise for UDP requests. + */ + +isc_sockaddr_t * +ns_client_getsockaddr(ns_client_t *client); +/* + * Get the socket address of the client whose request is + * currently being processed. + */ + +isc_result_t +ns_client_checkaclsilent(ns_client_t *client,dns_acl_t *acl, + isc_boolean_t default_allow); + +/* + * Convenience function for client request ACL checking. + * + * Check the current client request against 'acl'. If 'acl' + * is NULL, allow the request iff 'default_allow' is ISC_TRUE. + * + * Notes: + * This is appropriate for checking allow-update, + * allow-query, allow-transfer, etc. It is not appropriate + * for checking the blackhole list because we treat positive + * matches as "allow" and negative matches as "deny"; in + * the case of the blackhole list this would be backwards. + * + * Requires: + * 'client' points to a valid client. + * 'acl' points to a valid ACL, or is NULL. + * + * Returns: + * ISC_R_SUCCESS if the request should be allowed + * ISC_R_REFUSED if the request should be denied + * No other return values are possible. + */ + +isc_result_t +ns_client_checkacl(ns_client_t *client, + const char *opname, dns_acl_t *acl, + isc_boolean_t default_allow, + int log_level); +/* + * Like ns_client_checkacl, but also logs the outcome of the + * check at log level 'log_level' if denied, and at debug 3 + * if approved. Log messages will refer to the request as + * an 'opname' request. + * + * Requires: + * Those of ns_client_checkaclsilent(), and: + * + * 'opname' points to a null-terminated string. + */ + +void +ns_client_log(ns_client_t *client, isc_logcategory_t *category, + isc_logmodule_t *module, int level, + const char *fmt, ...) ISC_FORMAT_PRINTF(5, 6); + +void +ns_client_logv(ns_client_t *client, isc_logcategory_t *category, + isc_logmodule_t *module, int level, const char *fmt, va_list ap) ISC_FORMAT_PRINTF(5, 0); + +void +ns_client_aclmsg(const char *msg, dns_name_t *name, dns_rdatatype_t type, + dns_rdataclass_t rdclass, char *buf, size_t len); + +#define NS_CLIENT_ACLMSGSIZE(x) \ + (DNS_NAME_FORMATSIZE + DNS_RDATATYPE_FORMATSIZE + \ + DNS_RDATACLASS_FORMATSIZE + sizeof(x) + sizeof("'/'")) + +void +ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest); +/* + * Add client to end of recursing list. If 'killoldest' is true + * kill the oldest recursive client (list head). + */ + +void +ns_client_dumprecursing(FILE *f, ns_clientmgr_t *manager); +/* + * Dump the outstanding recursive queries to 'f'. + */ + +#endif /* NAMED_CLIENT_H */ diff --git a/contrib/bind9/bin/named/include/named/config.h b/contrib/bind9/bin/named/include/named/config.h new file mode 100644 index 000000000000..b3b4f121606b --- /dev/null +++ b/contrib/bind9/bin/named/include/named/config.h @@ -0,0 +1,75 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001, 2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: config.h,v 1.4.12.4 2004/04/20 14:12:10 marka Exp $ */ + +#ifndef NAMED_CONFIG_H +#define NAMED_CONFIG_H 1 + +#include + +#include +#include + +isc_result_t +ns_config_parsedefaults(cfg_parser_t *parser, cfg_obj_t **conf); + +isc_result_t +ns_config_get(cfg_obj_t **maps, const char* name, cfg_obj_t **obj); + +isc_result_t +ns_checknames_get(cfg_obj_t **maps, const char* name, cfg_obj_t **obj); + +int +ns_config_listcount(cfg_obj_t *list); + +isc_result_t +ns_config_getclass(cfg_obj_t *classobj, dns_rdataclass_t defclass, + dns_rdataclass_t *classp); + +isc_result_t +ns_config_gettype(cfg_obj_t *typeobj, dns_rdatatype_t deftype, + dns_rdatatype_t *typep); + +dns_zonetype_t +ns_config_getzonetype(cfg_obj_t *zonetypeobj); + +isc_result_t +ns_config_getiplist(cfg_obj_t *config, cfg_obj_t *list, + in_port_t defport, isc_mem_t *mctx, + isc_sockaddr_t **addrsp, isc_uint32_t *countp); + +void +ns_config_putiplist(isc_mem_t *mctx, isc_sockaddr_t **addrsp, + isc_uint32_t count); + +isc_result_t +ns_config_getipandkeylist(cfg_obj_t *config, cfg_obj_t *list, isc_mem_t *mctx, + isc_sockaddr_t **addrsp, dns_name_t ***keys, + isc_uint32_t *countp); + +void +ns_config_putipandkeylist(isc_mem_t *mctx, isc_sockaddr_t **addrsp, + dns_name_t ***keys, isc_uint32_t count); + +isc_result_t +ns_config_getport(cfg_obj_t *config, in_port_t *portp); + +isc_result_t +ns_config_getkeyalgorithm(const char *str, dns_name_t **name); + +#endif /* NAMED_CONFIG_H */ diff --git a/contrib/bind9/bin/named/include/named/control.h b/contrib/bind9/bin/named/include/named/control.h new file mode 100644 index 000000000000..b8d95d8bd2b0 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/control.h @@ -0,0 +1,87 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: control.h,v 1.6.2.2.2.6 2004/03/08 04:04:20 marka Exp $ */ + +#ifndef NAMED_CONTROL_H +#define NAMED_CONTROL_H 1 + +/* + * The name server command channel. + */ + +#include + +#include +#include + +#define NS_CONTROL_PORT 953 + +#define NS_COMMAND_STOP "stop" +#define NS_COMMAND_HALT "halt" +#define NS_COMMAND_RELOAD "reload" +#define NS_COMMAND_RECONFIG "reconfig" +#define NS_COMMAND_REFRESH "refresh" +#define NS_COMMAND_RETRANSFER "retransfer" +#define NS_COMMAND_DUMPSTATS "stats" +#define NS_COMMAND_QUERYLOG "querylog" +#define NS_COMMAND_DUMPDB "dumpdb" +#define NS_COMMAND_TRACE "trace" +#define NS_COMMAND_NOTRACE "notrace" +#define NS_COMMAND_FLUSH "flush" +#define NS_COMMAND_FLUSHNAME "flushname" +#define NS_COMMAND_STATUS "status" +#define NS_COMMAND_FREEZE "freeze" +#define NS_COMMAND_UNFREEZE "unfreeze" +#define NS_COMMAND_RECURSING "recursing" +#define NS_COMMAND_NULL "null" + +isc_result_t +ns_controls_create(ns_server_t *server, ns_controls_t **ctrlsp); +/* + * Create an initial, empty set of command channels for 'server'. + */ + +void +ns_controls_destroy(ns_controls_t **ctrlsp); +/* + * Destroy a set of command channels. + * + * Requires: + * Shutdown of the channels has completed. + */ + +isc_result_t +ns_controls_configure(ns_controls_t *controls, cfg_obj_t *config, + ns_aclconfctx_t *aclconfctx); +/* + * Configure zero or more command channels into 'controls' + * as defined in the configuration parse tree 'config'. + * The channels will evaluate ACLs in the context of + * 'aclconfctx'. + */ + +void +ns_controls_shutdown(ns_controls_t *controls); +/* + * Initiate shutdown of all the command channels in 'controls'. + */ + +isc_result_t +ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text); + +#endif /* NAMED_CONTROL_H */ diff --git a/contrib/bind9/bin/named/include/named/globals.h b/contrib/bind9/bin/named/include/named/globals.h new file mode 100644 index 000000000000..2cc854839562 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/globals.h @@ -0,0 +1,118 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: globals.h,v 1.59.68.5 2004/03/08 04:04:20 marka Exp $ */ + +#ifndef NAMED_GLOBALS_H +#define NAMED_GLOBALS_H 1 + +#include +#include +#include + +#include + +#include + +#include + +#undef EXTERN +#undef INIT +#ifdef NS_MAIN +#define EXTERN +#define INIT(v) = (v) +#else +#define EXTERN extern +#define INIT(v) +#endif + +EXTERN isc_mem_t * ns_g_mctx INIT(NULL); +EXTERN unsigned int ns_g_cpus INIT(0); +EXTERN isc_taskmgr_t * ns_g_taskmgr INIT(NULL); +EXTERN dns_dispatchmgr_t * ns_g_dispatchmgr INIT(NULL); +EXTERN isc_entropy_t * ns_g_entropy INIT(NULL); +EXTERN isc_entropy_t * ns_g_fallbackentropy INIT(NULL); + +/* + * XXXRTH We're going to want multiple timer managers eventually. One + * for really short timers, another for client timers, and one + * for zone timers. + */ +EXTERN isc_timermgr_t * ns_g_timermgr INIT(NULL); +EXTERN isc_socketmgr_t * ns_g_socketmgr INIT(NULL); +EXTERN cfg_parser_t * ns_g_parser INIT(NULL); +EXTERN const char * ns_g_version INIT(VERSION); +EXTERN in_port_t ns_g_port INIT(0); +EXTERN in_port_t lwresd_g_listenport INIT(0); + +EXTERN ns_server_t * ns_g_server INIT(NULL); + +EXTERN isc_boolean_t ns_g_lwresdonly INIT(ISC_FALSE); + +/* + * Logging. + */ +EXTERN isc_log_t * ns_g_lctx INIT(NULL); +EXTERN isc_logcategory_t * ns_g_categories INIT(NULL); +EXTERN isc_logmodule_t * ns_g_modules INIT(NULL); +EXTERN unsigned int ns_g_debuglevel INIT(0); + +/* + * Current configuration information. + */ +EXTERN cfg_obj_t * ns_g_config INIT(NULL); +EXTERN cfg_obj_t * ns_g_defaults INIT(NULL); +EXTERN const char * ns_g_conffile INIT(NS_SYSCONFDIR + "/named.conf"); +EXTERN const char * ns_g_keyfile INIT(NS_SYSCONFDIR + "/rndc.key"); +EXTERN const char * lwresd_g_conffile INIT(NS_SYSCONFDIR + "/lwresd.conf"); +EXTERN const char * lwresd_g_resolvconffile INIT("/etc" + "/resolv.conf"); +EXTERN isc_boolean_t ns_g_conffileset INIT(ISC_FALSE); +EXTERN isc_boolean_t lwresd_g_useresolvconf INIT(ISC_FALSE); +EXTERN isc_uint16_t ns_g_udpsize INIT(4096); + +/* + * Initial resource limits. + */ +EXTERN isc_resourcevalue_t ns_g_initstacksize INIT(0); +EXTERN isc_resourcevalue_t ns_g_initdatasize INIT(0); +EXTERN isc_resourcevalue_t ns_g_initcoresize INIT(0); +EXTERN isc_resourcevalue_t ns_g_initopenfiles INIT(0); + +/* + * Misc. + */ +EXTERN isc_boolean_t ns_g_coreok INIT(ISC_TRUE); +EXTERN const char * ns_g_chrootdir INIT(NULL); +EXTERN isc_boolean_t ns_g_foreground INIT(ISC_FALSE); +EXTERN isc_boolean_t ns_g_logstderr INIT(ISC_FALSE); + +EXTERN const char * ns_g_defaultpidfile INIT(NS_LOCALSTATEDIR + "/run/named.pid"); +EXTERN const char * lwresd_g_defaultpidfile INIT(NS_LOCALSTATEDIR + "/run/lwresd.pid"); +EXTERN const char * ns_g_username INIT(NULL); + +EXTERN int ns_g_listen INIT(3); + +#undef EXTERN +#undef INIT + +#endif /* NAMED_GLOBALS_H */ diff --git a/contrib/bind9/bin/named/include/named/interfacemgr.h b/contrib/bind9/bin/named/include/named/interfacemgr.h new file mode 100644 index 000000000000..54bd91cbd4c5 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/interfacemgr.h @@ -0,0 +1,173 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: interfacemgr.h,v 1.23.24.7 2004/04/29 01:31:22 marka Exp $ */ + +#ifndef NAMED_INTERFACEMGR_H +#define NAMED_INTERFACEMGR_H 1 + +/***** + ***** Module Info + *****/ + +/* + * Interface manager + * + * The interface manager monitors the operating system's list + * of network interfaces, creating and destroying listeners + * as needed. + * + * Reliability: + * No impact expected. + * + * Resources: + * + * Security: + * The server will only be able to bind to the DNS port on + * newly discovered interfaces if it is running as root. + * + * Standards: + * The API for scanning varies greatly among operating systems. + * This module attempts to hide the differences. + */ + +/*** + *** Imports + ***/ + +#include +#include +#include + +#include + +#include +#include + +/*** + *** Types + ***/ + +#define IFACE_MAGIC ISC_MAGIC('I',':','-',')') +#define NS_INTERFACE_VALID(t) ISC_MAGIC_VALID(t, IFACE_MAGIC) + +#define NS_INTERFACEFLAG_ANYADDR 0x01U /* bound to "any" address */ + +struct ns_interface { + unsigned int magic; /* Magic number. */ + ns_interfacemgr_t * mgr; /* Interface manager. */ + isc_mutex_t lock; + int references; /* Locked */ + unsigned int generation; /* Generation number. */ + isc_sockaddr_t addr; /* Address and port. */ + unsigned int flags; /* Interface characteristics */ + char name[32]; /* Null terminated. */ + dns_dispatch_t * udpdispatch; /* UDP dispatcher. */ + isc_socket_t * tcpsocket; /* TCP socket. */ + int ntcptarget; /* Desired number of concurrent + TCP accepts */ + int ntcpcurrent; /* Current ditto, locked */ + ns_clientmgr_t * clientmgr; /* Client manager. */ + ISC_LINK(ns_interface_t) link; +}; + +/*** + *** Functions + ***/ + +isc_result_t +ns_interfacemgr_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr, + isc_socketmgr_t *socketmgr, + dns_dispatchmgr_t *dispatchmgr, + ns_interfacemgr_t **mgrp); +/* + * Create a new interface manager. + * + * Initially, the new manager will not listen on any interfaces. + * Call ns_interfacemgr_setlistenon() and/or ns_interfacemgr_setlistenon6() + * to set nonempty listen-on lists. + */ + +void +ns_interfacemgr_attach(ns_interfacemgr_t *source, ns_interfacemgr_t **target); + +void +ns_interfacemgr_detach(ns_interfacemgr_t **targetp); + +void +ns_interfacemgr_shutdown(ns_interfacemgr_t *mgr); + +void +ns_interfacemgr_scan(ns_interfacemgr_t *mgr, isc_boolean_t verbose); +/* + * Scan the operatings system's list of network interfaces + * and create listeners when new interfaces are discovered. + * Shut down the sockets for interfaces that go away. + * + * This should be called once on server startup and then + * periodically according to the 'interface-interval' option + * in named.conf. + */ + +void +ns_interfacemgr_adjust(ns_interfacemgr_t *mgr, ns_listenlist_t *list, + isc_boolean_t verbose); +/* + * Similar to ns_interfacemgr_scan(), but this function also tries to see the + * need for an explicit listen-on when a list element in 'list' is going to + * override an already-listening a wildcard interface. + * + * This function does not update localhost and localnets ACLs. + * + * This should be called once on server startup, after configuring views and + * zones. + */ + +void +ns_interfacemgr_setlistenon4(ns_interfacemgr_t *mgr, ns_listenlist_t *value); +/* + * Set the IPv4 "listen-on" list of 'mgr' to 'value'. + * The previous IPv4 listen-on list is freed. + */ + +void +ns_interfacemgr_setlistenon6(ns_interfacemgr_t *mgr, ns_listenlist_t *value); +/* + * Set the IPv6 "listen-on" list of 'mgr' to 'value'. + * The previous IPv6 listen-on list is freed. + */ + +dns_aclenv_t * +ns_interfacemgr_getaclenv(ns_interfacemgr_t *mgr); + +void +ns_interface_attach(ns_interface_t *source, ns_interface_t **target); + +void +ns_interface_detach(ns_interface_t **targetp); + +void +ns_interface_shutdown(ns_interface_t *ifp); +/* + * Stop listening for queries on interface 'ifp'. + * May safely be called multiple times. + */ + +void +ns_interfacemgr_dumprecursing(FILE *f, ns_interfacemgr_t *mgr); + +#endif /* NAMED_INTERFACEMGR_H */ diff --git a/contrib/bind9/bin/named/include/named/listenlist.h b/contrib/bind9/bin/named/include/named/listenlist.h new file mode 100644 index 000000000000..31e889393895 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/listenlist.h @@ -0,0 +1,104 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: listenlist.h,v 1.10.208.1 2004/03/06 10:21:24 marka Exp $ */ + +#ifndef NAMED_LISTENLIST_H +#define NAMED_LISTENLIST_H 1 + +/***** + ***** Module Info + *****/ + +/* + * "Listen lists", as in the "listen-on" configuration statement. + */ + +/*** + *** Imports + ***/ +#include + +#include + +/*** + *** Types + ***/ + +typedef struct ns_listenelt ns_listenelt_t; +typedef struct ns_listenlist ns_listenlist_t; + +struct ns_listenelt { + isc_mem_t * mctx; + in_port_t port; + dns_acl_t * acl; + ISC_LINK(ns_listenelt_t) link; +}; + +struct ns_listenlist { + isc_mem_t * mctx; + int refcount; + ISC_LIST(ns_listenelt_t) elts; +}; + +/*** + *** Functions + ***/ + +isc_result_t +ns_listenelt_create(isc_mem_t *mctx, in_port_t port, + dns_acl_t *acl, ns_listenelt_t **target); +/* + * Create a listen-on list element. + */ + +void +ns_listenelt_destroy(ns_listenelt_t *elt); +/* + * Destroy a listen-on list element. + */ + +isc_result_t +ns_listenlist_create(isc_mem_t *mctx, ns_listenlist_t **target); +/* + * Create a new, empty listen-on list. + */ + +void +ns_listenlist_attach(ns_listenlist_t *source, ns_listenlist_t **target); +/* + * Attach '*target' to '*source'. + */ + +void +ns_listenlist_detach(ns_listenlist_t **listp); +/* + * Detach 'listp'. + */ + +isc_result_t +ns_listenlist_default(isc_mem_t *mctx, in_port_t port, + isc_boolean_t enabled, ns_listenlist_t **target); +/* + * Create a listen-on list with default contents, matching + * all addresses with port 'port' (if 'enabled' is ISC_TRUE), + * or no addresses (if 'enabled' is ISC_FALSE). + */ + +#endif /* NAMED_LISTENLIST_H */ + + diff --git a/contrib/bind9/bin/named/include/named/log.h b/contrib/bind9/bin/named/include/named/log.h new file mode 100644 index 000000000000..e8ad1ca15ff1 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/log.h @@ -0,0 +1,96 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: log.h,v 1.19.12.3 2004/03/08 04:04:21 marka Exp $ */ + +#ifndef NAMED_LOG_H +#define NAMED_LOG_H 1 + +#include +#include + +#include + +#include /* Required for ns_g_(categories|modules). */ + +/* Unused slot 0. */ +#define NS_LOGCATEGORY_CLIENT (&ns_g_categories[1]) +#define NS_LOGCATEGORY_NETWORK (&ns_g_categories[2]) +#define NS_LOGCATEGORY_UPDATE (&ns_g_categories[3]) +#define NS_LOGCATEGORY_QUERIES (&ns_g_categories[4]) +#define NS_LOGCATEGORY_UNMATCHED (&ns_g_categories[5]) +#define NS_LOGCATEGORY_UPDATE_SECURITY (&ns_g_categories[6]) + +/* + * Backwards compatibility. + */ +#define NS_LOGCATEGORY_GENERAL ISC_LOGCATEGORY_GENERAL + +#define NS_LOGMODULE_MAIN (&ns_g_modules[0]) +#define NS_LOGMODULE_CLIENT (&ns_g_modules[1]) +#define NS_LOGMODULE_SERVER (&ns_g_modules[2]) +#define NS_LOGMODULE_QUERY (&ns_g_modules[3]) +#define NS_LOGMODULE_INTERFACEMGR (&ns_g_modules[4]) +#define NS_LOGMODULE_UPDATE (&ns_g_modules[5]) +#define NS_LOGMODULE_XFER_IN (&ns_g_modules[6]) +#define NS_LOGMODULE_XFER_OUT (&ns_g_modules[7]) +#define NS_LOGMODULE_NOTIFY (&ns_g_modules[8]) +#define NS_LOGMODULE_CONTROL (&ns_g_modules[9]) +#define NS_LOGMODULE_LWRESD (&ns_g_modules[10]) + +isc_result_t +ns_log_init(isc_boolean_t safe); +/* + * Initialize the logging system and set up an initial default + * logging default configuration that will be used until the + * config file has been read. + * + * If 'safe' is true, use a default configuration that refrains + * from opening files. This is to avoid creating log files + * as root. + */ + +isc_result_t +ns_log_setdefaultchannels(isc_logconfig_t *lcfg); +/* + * Set up logging channels according to the named defaults, which + * may differ from the logging library defaults. Currently, + * this just means setting up default_debug. + */ + +isc_result_t +ns_log_setsafechannels(isc_logconfig_t *lcfg); +/* + * Like ns_log_setdefaultchannels(), but omits any logging to files. + */ + +isc_result_t +ns_log_setdefaultcategory(isc_logconfig_t *lcfg); +/* + * Set up "category default" to go to the right places. + */ + +isc_result_t +ns_log_setunmatchedcategory(isc_logconfig_t *lcfg); +/* + * Set up "category unmatched" to go to the right places. + */ + +void +ns_log_shutdown(void); + +#endif /* NAMED_LOG_H */ diff --git a/contrib/bind9/bin/named/include/named/logconf.h b/contrib/bind9/bin/named/include/named/logconf.h new file mode 100644 index 000000000000..a6f7450c9386 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/logconf.h @@ -0,0 +1,32 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: logconf.h,v 1.10.208.1 2004/03/06 10:21:24 marka Exp $ */ + +#ifndef NAMED_LOGCONF_H +#define NAMED_LOGCONF_H 1 + +#include + +isc_result_t +ns_log_configure(isc_logconfig_t *logconf, cfg_obj_t *logstmt); +/* + * Set up the logging configuration in '*logconf' according to + * the named.conf data in 'logstmt'. + */ + +#endif /* NAMED_LOGCONF_H */ diff --git a/contrib/bind9/bin/named/include/named/lwaddr.h b/contrib/bind9/bin/named/include/named/lwaddr.h new file mode 100644 index 000000000000..0aa66b78019f --- /dev/null +++ b/contrib/bind9/bin/named/include/named/lwaddr.h @@ -0,0 +1,34 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwaddr.h,v 1.3.208.1 2004/03/06 10:21:24 marka Exp $ */ + +#include +#include + +isc_result_t +lwaddr_netaddr_fromlwresaddr(isc_netaddr_t *na, lwres_addr_t *la); + +isc_result_t +lwaddr_sockaddr_fromlwresaddr(isc_sockaddr_t *sa, lwres_addr_t *la, + in_port_t port); + +isc_result_t +lwaddr_lwresaddr_fromnetaddr(lwres_addr_t *la, isc_netaddr_t *na); + +isc_result_t +lwaddr_lwresaddr_fromsockaddr(lwres_addr_t *la, isc_sockaddr_t *sa); diff --git a/contrib/bind9/bin/named/include/named/lwdclient.h b/contrib/bind9/bin/named/include/named/lwdclient.h new file mode 100644 index 000000000000..09d68ff086e3 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/lwdclient.h @@ -0,0 +1,230 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwdclient.h,v 1.13.208.1 2004/03/06 10:21:24 marka Exp $ */ + +#ifndef NAMED_LWDCLIENT_H +#define NAMED_LWDCLIENT_H 1 + +#include +#include +#include +#include +#include + +#include +#include + +#include + +#include + +#define LWRD_EVENTCLASS ISC_EVENTCLASS(4242) + +#define LWRD_SHUTDOWN (LWRD_EVENTCLASS + 0x0001) + +struct ns_lwdclient { + isc_sockaddr_t address; /* where to reply */ + struct in6_pktinfo pktinfo; + isc_boolean_t pktinfo_valid; + ns_lwdclientmgr_t *clientmgr; /* our parent */ + ISC_LINK(ns_lwdclient_t) link; + unsigned int state; + void *arg; /* packet processing state */ + + /* + * Received data info. + */ + unsigned char buffer[LWRES_RECVLENGTH]; /* receive buffer */ + isc_uint32_t recvlength; /* length recv'd */ + lwres_lwpacket_t pkt; + + /* + * Send data state. If sendbuf != buffer (that is, the send buffer + * isn't our receive buffer) it will be freed to the lwres_context_t. + */ + unsigned char *sendbuf; + isc_uint32_t sendlength; + isc_buffer_t recv_buffer; + + /* + * gabn (get address by name) state info. + */ + dns_adbfind_t *find; + dns_adbfind_t *v4find; + dns_adbfind_t *v6find; + unsigned int find_wanted; /* Addresses we want */ + dns_fixedname_t query_name; + dns_fixedname_t target_name; + ns_lwsearchctx_t searchctx; + lwres_gabnresponse_t gabn; + + /* + * gnba (get name by address) state info. + */ + lwres_gnbaresponse_t gnba; + dns_byaddr_t *byaddr; + unsigned int options; + isc_netaddr_t na; + + /* + * grbn (get rrset by name) state info. + * + * Note: this also uses target_name and searchctx. + */ + lwres_grbnresponse_t grbn; + dns_lookup_t *lookup; + dns_rdatatype_t rdtype; + + /* + * Alias and address info. This is copied up to the gabn/gnba + * structures eventually. + * + * XXXMLG We can keep all of this in a client since we only service + * three packet types right now. If we started handling more, + * we'd need to use "arg" above and allocate/destroy things. + */ + char *aliases[LWRES_MAX_ALIASES]; + isc_uint16_t aliaslen[LWRES_MAX_ALIASES]; + lwres_addr_t addrs[LWRES_MAX_ADDRS]; +}; + +/* + * Client states. + * + * _IDLE The client is not doing anything at all. + * + * _RECV The client is waiting for data after issuing a socket recv(). + * + * _RECVDONE Data has been received, and is being processed. + * + * _FINDWAIT An adb (or other) request was made that cannot be satisfied + * immediately. An event will wake the client up. + * + * _SEND All data for a response has completed, and a reply was + * sent via a socket send() call. + * + * Badly formatted state table: + * + * IDLE -> RECV when client has a recv() queued. + * + * RECV -> RECVDONE when recvdone event received. + * + * RECVDONE -> SEND if the data for a reply is at hand. + * RECVDONE -> FINDWAIT if more searching is needed, and events will + * eventually wake us up again. + * + * FINDWAIT -> SEND when enough data was received to reply. + * + * SEND -> IDLE when a senddone event was received. + * + * At any time -> IDLE on error. Sometimes this will be -> SEND + * instead, if enough data is on hand to reply with a meaningful + * error. + * + * Packets which are badly formatted may or may not get error returns. + */ +#define NS_LWDCLIENT_STATEIDLE 1 +#define NS_LWDCLIENT_STATERECV 2 +#define NS_LWDCLIENT_STATERECVDONE 3 +#define NS_LWDCLIENT_STATEFINDWAIT 4 +#define NS_LWDCLIENT_STATESEND 5 +#define NS_LWDCLIENT_STATESENDDONE 6 + +#define NS_LWDCLIENT_ISIDLE(c) \ + ((c)->state == NS_LWDCLIENT_STATEIDLE) +#define NS_LWDCLIENT_ISRECV(c) \ + ((c)->state == NS_LWDCLIENT_STATERECV) +#define NS_LWDCLIENT_ISRECVDONE(c) \ + ((c)->state == NS_LWDCLIENT_STATERECVDONE) +#define NS_LWDCLIENT_ISFINDWAIT(c) \ + ((c)->state == NS_LWDCLIENT_STATEFINDWAIT) +#define NS_LWDCLIENT_ISSEND(c) \ + ((c)->state == NS_LWDCLIENT_STATESEND) + +/* + * Overall magic test that means we're not idle. + */ +#define NS_LWDCLIENT_ISRUNNING(c) (!NS_LWDCLIENT_ISIDLE(c)) + +#define NS_LWDCLIENT_SETIDLE(c) \ + ((c)->state = NS_LWDCLIENT_STATEIDLE) +#define NS_LWDCLIENT_SETRECV(c) \ + ((c)->state = NS_LWDCLIENT_STATERECV) +#define NS_LWDCLIENT_SETRECVDONE(c) \ + ((c)->state = NS_LWDCLIENT_STATERECVDONE) +#define NS_LWDCLIENT_SETFINDWAIT(c) \ + ((c)->state = NS_LWDCLIENT_STATEFINDWAIT) +#define NS_LWDCLIENT_SETSEND(c) \ + ((c)->state = NS_LWDCLIENT_STATESEND) +#define NS_LWDCLIENT_SETSENDDONE(c) \ + ((c)->state = NS_LWDCLIENT_STATESENDDONE) + +struct ns_lwdclientmgr { + ns_lwreslistener_t *listener; + isc_mem_t *mctx; + isc_socket_t *sock; /* socket to use */ + dns_view_t *view; + lwres_context_t *lwctx; /* lightweight proto context */ + isc_task_t *task; /* owning task */ + unsigned int flags; + ISC_LINK(ns_lwdclientmgr_t) link; + ISC_LIST(ns_lwdclient_t) idle; /* idle client slots */ + ISC_LIST(ns_lwdclient_t) running; /* running clients */ +}; + +#define NS_LWDCLIENTMGR_FLAGRECVPENDING 0x00000001 +#define NS_LWDCLIENTMGR_FLAGSHUTTINGDOWN 0x00000002 + +isc_result_t +ns_lwdclientmgr_create(ns_lwreslistener_t *, unsigned int, isc_taskmgr_t *); + +void +ns_lwdclient_initialize(ns_lwdclient_t *, ns_lwdclientmgr_t *); + +isc_result_t +ns_lwdclient_startrecv(ns_lwdclientmgr_t *); + +void +ns_lwdclient_stateidle(ns_lwdclient_t *); + +void +ns_lwdclient_recv(isc_task_t *, isc_event_t *); + +void +ns_lwdclient_shutdown(isc_task_t *, isc_event_t *); + +void +ns_lwdclient_send(isc_task_t *, isc_event_t *); + +isc_result_t +ns_lwdclient_sendreply(ns_lwdclient_t *client, isc_region_t *r); + +/* + * Processing functions of various types. + */ +void ns_lwdclient_processgabn(ns_lwdclient_t *, lwres_buffer_t *); +void ns_lwdclient_processgnba(ns_lwdclient_t *, lwres_buffer_t *); +void ns_lwdclient_processgrbn(ns_lwdclient_t *, lwres_buffer_t *); +void ns_lwdclient_processnoop(ns_lwdclient_t *, lwres_buffer_t *); + +void ns_lwdclient_errorpktsend(ns_lwdclient_t *, isc_uint32_t); + +void ns_lwdclient_log(int level, const char *format, ...) + ISC_FORMAT_PRINTF(2, 3); + +#endif /* NAMED_LWDCLIENT_H */ diff --git a/contrib/bind9/bin/named/include/named/lwresd.h b/contrib/bind9/bin/named/include/named/lwresd.h new file mode 100644 index 000000000000..7ba857c04ed1 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/lwresd.h @@ -0,0 +1,111 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwresd.h,v 1.12.208.1 2004/03/06 10:21:25 marka Exp $ */ + +#ifndef NAMED_LWRESD_H +#define NAMED_LWRESD_H 1 + +#include +#include + +#include + +#include + +struct ns_lwresd { + unsigned int magic; + + isc_mutex_t lock; + dns_view_t *view; + ns_lwsearchlist_t *search; + unsigned int ndots; + isc_mem_t *mctx; + isc_boolean_t shutting_down; + unsigned int refs; +}; + +struct ns_lwreslistener { + unsigned int magic; + + isc_mutex_t lock; + isc_mem_t *mctx; + isc_sockaddr_t address; + ns_lwresd_t *manager; + isc_socket_t *sock; + unsigned int refs; + ISC_LIST(ns_lwdclientmgr_t) cmgrs; + ISC_LINK(ns_lwreslistener_t) link; +}; + +/* + * Configure lwresd. + */ +isc_result_t +ns_lwresd_configure(isc_mem_t *mctx, cfg_obj_t *config); + +isc_result_t +ns_lwresd_parseeresolvconf(isc_mem_t *mctx, cfg_parser_t *pctx, + cfg_obj_t **configp); + +/* + * Trigger shutdown. + */ +void +ns_lwresd_shutdown(void); + +/* + * Manager functions + */ +isc_result_t +ns_lwdmanager_create(isc_mem_t *mctx, cfg_obj_t *lwres, ns_lwresd_t **lwresdp); + +void +ns_lwdmanager_attach(ns_lwresd_t *source, ns_lwresd_t **targetp); + +void +ns_lwdmanager_detach(ns_lwresd_t **lwresdp); + +/* + * Listener functions + */ +void +ns_lwreslistener_attach(ns_lwreslistener_t *source, + ns_lwreslistener_t **targetp); + +void +ns_lwreslistener_detach(ns_lwreslistener_t **listenerp); + +void +ns_lwreslistener_unlinkcm(ns_lwreslistener_t *listener, ns_lwdclientmgr_t *cm); + +void +ns_lwreslistener_linkcm(ns_lwreslistener_t *listener, ns_lwdclientmgr_t *cm); + + + + +/* + * INTERNAL FUNCTIONS. + */ +void * +ns__lwresd_memalloc(void *arg, size_t size); + +void +ns__lwresd_memfree(void *arg, void *mem, size_t size); + +#endif /* NAMED_LWRESD_H */ diff --git a/contrib/bind9/bin/named/include/named/lwsearch.h b/contrib/bind9/bin/named/include/named/lwsearch.h new file mode 100644 index 000000000000..a864a89d8292 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/lwsearch.h @@ -0,0 +1,110 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwsearch.h,v 1.4.208.1 2004/03/06 10:21:25 marka Exp $ */ + +#ifndef NAMED_LWSEARCH_H +#define NAMED_LWSEARCH_H 1 + +#include +#include +#include + +#include + +#include + +/* + * Lightweight resolver search list types and routines. + * + * An ns_lwsearchlist_t holds a list of search path elements. + * + * An ns_lwsearchctx stores the state of search list during a lookup + * operation. + */ + +struct ns_lwsearchlist { + unsigned int magic; + + isc_mutex_t lock; + isc_mem_t *mctx; + unsigned int refs; + dns_namelist_t names; +}; + +struct ns_lwsearchctx { + dns_name_t *relname; + dns_name_t *searchname; + unsigned int ndots; + ns_lwsearchlist_t *list; + isc_boolean_t doneexact; + isc_boolean_t exactfirst; +}; + +isc_result_t +ns_lwsearchlist_create(isc_mem_t *mctx, ns_lwsearchlist_t **listp); +/* + * Create an empty search list object. + */ + +void +ns_lwsearchlist_attach(ns_lwsearchlist_t *source, ns_lwsearchlist_t **target); +/* + * Attach to a search list object. + */ + +void +ns_lwsearchlist_detach(ns_lwsearchlist_t **listp); +/* + * Detach from a search list object. + */ + +isc_result_t +ns_lwsearchlist_append(ns_lwsearchlist_t *list, dns_name_t *name); +/* + * Append an element to a search list. This creates a copy of the name. + */ + +void +ns_lwsearchctx_init(ns_lwsearchctx_t *sctx, ns_lwsearchlist_t *list, + dns_name_t *name, unsigned int ndots); +/* + * Creates a search list context structure. + */ + +void +ns_lwsearchctx_first(ns_lwsearchctx_t *sctx); +/* + * Moves the search list context iterator to the first element, which + * is usually the exact name. + */ + +isc_result_t +ns_lwsearchctx_next(ns_lwsearchctx_t *sctx); +/* + * Moves the search list context iterator to the next element. + */ + +isc_result_t +ns_lwsearchctx_current(ns_lwsearchctx_t *sctx, dns_name_t *absname); +/* + * Obtains the current name to be looked up. This involves either + * concatenating the name with a search path element, making an + * exact name absolute, or doing nothing. + */ + +#endif /* NAMED_LWSEARCH_H */ diff --git a/contrib/bind9/bin/named/include/named/main.h b/contrib/bind9/bin/named/include/named/main.h new file mode 100644 index 000000000000..e37b5198fd03 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/main.h @@ -0,0 +1,32 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: main.h,v 1.8.2.2.8.4 2004/03/08 04:04:21 marka Exp $ */ + +#ifndef NAMED_MAIN_H +#define NAMED_MAIN_H 1 + +void +ns_main_earlyfatal(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +void +ns_main_earlywarning(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +void +ns_main_setmemstats(const char *); + +#endif /* NAMED_MAIN_H */ diff --git a/contrib/bind9/bin/named/include/named/notify.h b/contrib/bind9/bin/named/include/named/notify.h new file mode 100644 index 000000000000..3cb1d854e932 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/notify.h @@ -0,0 +1,54 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: notify.h,v 1.9.208.1 2004/03/06 10:21:25 marka Exp $ */ + +#ifndef NAMED_NOTIFY_H +#define NAMED_NOTIFY_H 1 + +#include +#include + +/*** + *** Module Info + ***/ + +/* + * RFC 1996 + * A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) + */ + +/*** + *** Functions. + ***/ + +void +ns_notify_start(ns_client_t *client); + +/* + * Examines the incoming message to determine apporiate zone. + * Returns FORMERR if there is not exactly one question. + * Returns REFUSED if we do not serve the listed zone. + * Pass the message to the zone module for processing + * and returns the return status. + * + * Requires + * client to be valid. + */ + +#endif /* NAMED_NOTIFY_H */ + diff --git a/contrib/bind9/bin/named/include/named/query.h b/contrib/bind9/bin/named/include/named/query.h new file mode 100644 index 000000000000..6f348d530e7c --- /dev/null +++ b/contrib/bind9/bin/named/include/named/query.h @@ -0,0 +1,83 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: query.h,v 1.28.2.3.8.6 2004/03/08 04:04:21 marka Exp $ */ + +#ifndef NAMED_QUERY_H +#define NAMED_QUERY_H 1 + +#include +#include +#include + +#include + +#include + +typedef struct ns_dbversion { + dns_db_t *db; + dns_dbversion_t *version; + isc_boolean_t queryok; + ISC_LINK(struct ns_dbversion) link; +} ns_dbversion_t; + +struct ns_query { + unsigned int attributes; + unsigned int restarts; + isc_boolean_t timerset; + dns_name_t * qname; + dns_name_t * origqname; + unsigned int dboptions; + unsigned int fetchoptions; + dns_db_t * gluedb; + dns_db_t * authdb; + dns_zone_t * authzone; + isc_boolean_t authdbset; + isc_boolean_t isreferral; + isc_mutex_t fetchlock; + dns_fetch_t * fetch; + isc_bufferlist_t namebufs; + ISC_LIST(ns_dbversion_t) activeversions; + ISC_LIST(ns_dbversion_t) freeversions; +}; + +#define NS_QUERYATTR_RECURSIONOK 0x0001 +#define NS_QUERYATTR_CACHEOK 0x0002 +#define NS_QUERYATTR_PARTIALANSWER 0x0004 +#define NS_QUERYATTR_NAMEBUFUSED 0x0008 +#define NS_QUERYATTR_RECURSING 0x0010 +#define NS_QUERYATTR_CACHEGLUEOK 0x0020 +#define NS_QUERYATTR_QUERYOKVALID 0x0040 +#define NS_QUERYATTR_QUERYOK 0x0080 +#define NS_QUERYATTR_WANTRECURSION 0x0100 +#define NS_QUERYATTR_SECURE 0x0200 +#define NS_QUERYATTR_NOAUTHORITY 0x0400 +#define NS_QUERYATTR_NOADDITIONAL 0x0800 + +isc_result_t +ns_query_init(ns_client_t *client); + +void +ns_query_free(ns_client_t *client); + +void +ns_query_start(ns_client_t *client); + +void +ns_query_cancel(ns_client_t *client); + +#endif /* NAMED_QUERY_H */ diff --git a/contrib/bind9/bin/named/include/named/server.h b/contrib/bind9/bin/named/include/named/server.h new file mode 100644 index 000000000000..97eb2efce341 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/server.h @@ -0,0 +1,213 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: server.h,v 1.58.2.1.10.11 2004/03/08 04:04:21 marka Exp $ */ + +#ifndef NAMED_SERVER_H +#define NAMED_SERVER_H 1 + +#include +#include +#include +#include +#include + +#include +#include + +#include + +#define NS_EVENTCLASS ISC_EVENTCLASS(0x4E43) +#define NS_EVENT_RELOAD (NS_EVENTCLASS + 0) +#define NS_EVENT_CLIENTCONTROL (NS_EVENTCLASS + 1) + +/* + * Name server state. Better here than in lots of separate global variables. + */ +struct ns_server { + unsigned int magic; + isc_mem_t * mctx; + + isc_task_t * task; + + /* Configurable data. */ + isc_quota_t xfroutquota; + isc_quota_t tcpquota; + isc_quota_t recursionquota; + dns_acl_t *blackholeacl; + char * statsfile; /* Statistics file name */ + char * dumpfile; /* Dump file name */ + char * recfile; /* Recursive file name */ + isc_boolean_t version_set; /* User has set version */ + char * version; /* User-specified version */ + isc_boolean_t hostname_set; /* User has set hostname */ + char * hostname; /* User-specified hostname */ + /* Use hostname for server id */ + isc_boolean_t server_usehostname; + char * server_id; /* User-specified server id */ + + /* + * Current ACL environment. This defines the + * current values of the localhost and localnets + * ACLs. + */ + dns_aclenv_t aclenv; + + /* Server data structures. */ + dns_loadmgr_t * loadmgr; + dns_zonemgr_t * zonemgr; + dns_viewlist_t viewlist; + ns_interfacemgr_t * interfacemgr; + dns_db_t * in_roothints; + dns_tkeyctx_t * tkeyctx; + + isc_timer_t * interface_timer; + isc_timer_t * heartbeat_timer; + isc_uint32_t interface_interval; + isc_uint32_t heartbeat_interval; + + isc_mutex_t reload_event_lock; + isc_event_t * reload_event; + + isc_boolean_t flushonshutdown; + isc_boolean_t log_queries; /* For BIND 8 compatibility */ + + isc_uint64_t * querystats; /* Query statistics counters */ + + ns_controls_t * controls; /* Control channels */ + unsigned int dispatchgen; + ns_dispatchlist_t dispatches; + +}; + +#define NS_SERVER_MAGIC ISC_MAGIC('S','V','E','R') +#define NS_SERVER_VALID(s) ISC_MAGIC_VALID(s, NS_SERVER_MAGIC) + +void +ns_server_create(isc_mem_t *mctx, ns_server_t **serverp); +/* + * Create a server object with default settings. + * This function either succeeds or causes the program to exit + * with a fatal error. + */ + +void +ns_server_destroy(ns_server_t **serverp); +/* + * Destroy a server object, freeing its memory. + */ + +void +ns_server_reloadwanted(ns_server_t *server); +/* + * Inform a server that a reload is wanted. This function + * may be called asynchronously, from outside the server's task. + * If a reload is already scheduled or in progress, the call + * is ignored. + */ + +void +ns_server_flushonshutdown(ns_server_t *server, isc_boolean_t flush); +/* + * Inform the server that the zones should be flushed to disk on shutdown. + */ + +isc_result_t +ns_server_reloadcommand(ns_server_t *server, char *args, isc_buffer_t *text); +/* + * Act on a "reload" command from the command channel. + */ + +isc_result_t +ns_server_reconfigcommand(ns_server_t *server, char *args); +/* + * Act on a "reconfig" command from the command channel. + */ + +isc_result_t +ns_server_refreshcommand(ns_server_t *server, char *args, isc_buffer_t *text); +/* + * Act on a "refresh" command from the command channel. + */ + +isc_result_t +ns_server_retransfercommand(ns_server_t *server, char *args); +/* + * Act on a "retransfer" command from the command channel. + */ + +isc_result_t +ns_server_togglequerylog(ns_server_t *server); +/* + * Toggle logging of queries, as in BIND 8. + */ + +/* + * Dump the current statistics to the statistics file. + */ +isc_result_t +ns_server_dumpstats(ns_server_t *server); + +/* + * Dump the current cache to the dump file. + */ +isc_result_t +ns_server_dumpdb(ns_server_t *server, char *args); + +/* + * Change or increment the server debug level. + */ +isc_result_t +ns_server_setdebuglevel(ns_server_t *server, char *args); + +/* + * Flush the server's cache(s) + */ +isc_result_t +ns_server_flushcache(ns_server_t *server, char *args); + +/* + * Flush a particular name from the server's cache(s) + */ +isc_result_t +ns_server_flushname(ns_server_t *server, char *args); + +/* + * Report the server's status. + */ +isc_result_t +ns_server_status(ns_server_t *server, isc_buffer_t *text); + +/* + * Enable or disable updates for a zone. + */ +isc_result_t +ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args); + +/* + * Dump the current recursive queries. + */ +isc_result_t +ns_server_dumprecursing(ns_server_t *server); + +/* + * Maintain a list of dispatches that require reserved ports. + */ +void +ns_add_reserved_dispatch(ns_server_t *server, isc_sockaddr_t *addr); + +#endif /* NAMED_SERVER_H */ diff --git a/contrib/bind9/bin/named/include/named/sortlist.h b/contrib/bind9/bin/named/include/named/sortlist.h new file mode 100644 index 000000000000..88a149387795 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/sortlist.h @@ -0,0 +1,84 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: sortlist.h,v 1.4.208.1 2004/03/06 10:21:26 marka Exp $ */ + +#ifndef NAMED_SORTLIST_H +#define NAMED_SORTLIST_H 1 + +#include + +#include + +/* + * Type for callback functions that rank addresses. + */ +typedef int +(*dns_addressorderfunc_t)(isc_netaddr_t *address, void *arg); + +/* + * Return value type for setup_sortlist. + */ +typedef enum { + NS_SORTLISTTYPE_NONE, + NS_SORTLISTTYPE_1ELEMENT, + NS_SORTLISTTYPE_2ELEMENT +} ns_sortlisttype_t; + +ns_sortlisttype_t +ns_sortlist_setup(dns_acl_t *acl, isc_netaddr_t *clientaddr, void **argp); +/* + * Find the sortlist statement in 'acl' that applies to 'clientaddr', if any. + * + * If a 1-element sortlist item applies, return NS_SORTLISTTYPE_1ELEMENT and + * make '*argp' point to the matching subelement. + * + * If a 2-element sortlist item applies, return NS_SORTLISTTYPE_2ELEMENT and + * make '*argp' point to ACL that forms the second element. + * + * If no sortlist item applies, return NS_SORTLISTTYPE_NONE and set '*argp' + * to NULL. + */ + +int +ns_sortlist_addrorder1(isc_netaddr_t *addr, void *arg); +/* + * Find the sort order of 'addr' in 'arg', the matching element + * of a 1-element top-level sortlist statement. + */ + +int +ns_sortlist_addrorder2(isc_netaddr_t *addr, void *arg); +/* + * Find the sort order of 'addr' in 'arg', a topology-like + * ACL forming the second element in a 2-element top-level + * sortlist statement. + */ + +void +ns_sortlist_byaddrsetup(dns_acl_t *sortlist_acl, isc_netaddr_t *client_addr, + dns_addressorderfunc_t *orderp, + void **argp); +/* + * Find the sortlist statement in 'acl' that applies to 'clientaddr', if any. + * If a sortlist statement applies, return in '*orderp' a pointer to a function + * for ranking network addresses based on that sortlist statement, and in + * '*argp' an argument to pass to said function. If no sortlist statement + * applies, set '*orderp' and '*argp' to NULL. + */ + +#endif /* NAMED_SORTLIST_H */ diff --git a/contrib/bind9/bin/named/include/named/tkeyconf.h b/contrib/bind9/bin/named/include/named/tkeyconf.h new file mode 100644 index 000000000000..e3710eae3e00 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/tkeyconf.h @@ -0,0 +1,51 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: tkeyconf.h,v 1.9.208.1 2004/03/06 10:21:26 marka Exp $ */ + +#ifndef NS_TKEYCONF_H +#define NS_TKEYCONF_H 1 + +#include +#include + +#include + +ISC_LANG_BEGINDECLS + +isc_result_t +ns_tkeyctx_fromconfig(cfg_obj_t *options, isc_mem_t *mctx, isc_entropy_t *ectx, + dns_tkeyctx_t **tctxp); +/* + * Create a TKEY context and configure it, including the default DH key + * and default domain, according to 'options'. + * + * Requires: + * 'cfg' is a valid configuration options object. + * 'mctx' is not NULL + * 'ectx' is not NULL + * 'tctx' is not NULL + * '*tctx' is NULL + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOMEMORY + */ + +ISC_LANG_ENDDECLS + +#endif /* NS_TKEYCONF_H */ diff --git a/contrib/bind9/bin/named/include/named/tsigconf.h b/contrib/bind9/bin/named/include/named/tsigconf.h new file mode 100644 index 000000000000..ef4161ded8a1 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/tsigconf.h @@ -0,0 +1,47 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: tsigconf.h,v 1.9.208.1 2004/03/06 10:21:26 marka Exp $ */ + +#ifndef NS_TSIGCONF_H +#define NS_TSIGCONF_H 1 + +#include +#include + +ISC_LANG_BEGINDECLS + +isc_result_t +ns_tsigkeyring_fromconfig(cfg_obj_t *config, cfg_obj_t *vconfig, + isc_mem_t *mctx, dns_tsig_keyring_t **ringp); +/* + * Create a TSIG key ring and configure it according to the 'key' + * statements in the global and view configuration objects. + * + * Requires: + * 'config' is not NULL. + * 'mctx' is not NULL + * 'ring' is not NULL, and '*ring' is NULL + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOMEMORY + */ + +ISC_LANG_ENDDECLS + +#endif /* NS_TSIGCONF_H */ diff --git a/contrib/bind9/bin/named/include/named/types.h b/contrib/bind9/bin/named/include/named/types.h new file mode 100644 index 000000000000..eb44c53b66f3 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/types.h @@ -0,0 +1,41 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: types.h,v 1.19.208.2 2004/03/06 10:21:26 marka Exp $ */ + +#ifndef NAMED_TYPES_H +#define NAMED_TYPES_H 1 + +#include + +typedef struct ns_client ns_client_t; +typedef struct ns_clientmgr ns_clientmgr_t; +typedef struct ns_query ns_query_t; +typedef struct ns_server ns_server_t; +typedef struct ns_interface ns_interface_t; +typedef struct ns_interfacemgr ns_interfacemgr_t; +typedef struct ns_lwresd ns_lwresd_t; +typedef struct ns_lwreslistener ns_lwreslistener_t; +typedef struct ns_lwdclient ns_lwdclient_t; +typedef struct ns_lwdclientmgr ns_lwdclientmgr_t; +typedef struct ns_lwsearchlist ns_lwsearchlist_t; +typedef struct ns_lwsearchctx ns_lwsearchctx_t; +typedef struct ns_controls ns_controls_t; +typedef struct ns_dispatch ns_dispatch_t; +typedef ISC_LIST(ns_dispatch_t) ns_dispatchlist_t; + +#endif /* NAMED_TYPES_H */ diff --git a/contrib/bind9/bin/named/include/named/update.h b/contrib/bind9/bin/named/include/named/update.h new file mode 100644 index 000000000000..4c97235cc93c --- /dev/null +++ b/contrib/bind9/bin/named/include/named/update.h @@ -0,0 +1,49 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: update.h,v 1.8.208.1 2004/03/06 10:21:26 marka Exp $ */ + +#ifndef NAMED_UPDATE_H +#define NAMED_UPDATE_H 1 + +/***** + ***** Module Info + *****/ + +/* + * RFC2136 Dynamic Update + */ + +/*** + *** Imports + ***/ + +#include +#include + +/*** + *** Types. + ***/ + +/*** + *** Functions + ***/ + +void +ns_update_start(ns_client_t *client, isc_result_t sigresult); + +#endif /* NAMED_UPDATE_H */ diff --git a/contrib/bind9/bin/named/include/named/xfrout.h b/contrib/bind9/bin/named/include/named/xfrout.h new file mode 100644 index 000000000000..e96ff31dd2de --- /dev/null +++ b/contrib/bind9/bin/named/include/named/xfrout.h @@ -0,0 +1,38 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: xfrout.h,v 1.7.208.1 2004/03/06 10:21:27 marka Exp $ */ + +#ifndef NAMED_XFROUT_H +#define NAMED_XFROUT_H 1 + +/***** + ***** Module Info + *****/ + +/* + * Outgoing zone transfers (AXFR + IXFR). + */ + +/*** + *** Functions + ***/ + +void +ns_xfr_start(ns_client_t *client, dns_rdatatype_t xfrtype); + +#endif /* NAMED_XFROUT_H */ diff --git a/contrib/bind9/bin/named/include/named/zoneconf.h b/contrib/bind9/bin/named/include/named/zoneconf.h new file mode 100644 index 000000000000..3b8f200dc79f --- /dev/null +++ b/contrib/bind9/bin/named/include/named/zoneconf.h @@ -0,0 +1,61 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: zoneconf.h,v 1.16.2.2.8.1 2004/03/06 10:21:27 marka Exp $ */ + +#ifndef NS_ZONECONF_H +#define NS_ZONECONF_H 1 + +#include +#include + +#include + +#include + +ISC_LANG_BEGINDECLS + +isc_result_t +ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig, + ns_aclconfctx_t *ac, dns_zone_t *zone); +/* + * Configure or reconfigure a zone according to the named.conf + * data in 'cctx' and 'czone'. + * + * The zone origin is not configured, it is assumed to have been set + * at zone creation time. + * + * Require: + * 'lctx' to be initialized or NULL. + * 'cctx' to be initialized or NULL. + * 'ac' to point to an initialized ns_aclconfctx_t. + * 'czone' to be initialized. + * 'zone' to be initialized. + */ + +isc_boolean_t +ns_zone_reusable(dns_zone_t *zone, cfg_obj_t *zconfig); +/* + * If 'zone' can be safely reconfigured according to the configuration + * data in 'zconfig', return ISC_TRUE. If the configuration data is so + * different from the current zone state that the zone needs to be destroyed + * and recreated, return ISC_FALSE. + */ + +ISC_LANG_ENDDECLS + +#endif /* NS_ZONECONF_H */ diff --git a/contrib/bind9/bin/named/interfacemgr.c b/contrib/bind9/bin/named/interfacemgr.c new file mode 100644 index 000000000000..b212892c8e1a --- /dev/null +++ b/contrib/bind9/bin/named/interfacemgr.c @@ -0,0 +1,911 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: interfacemgr.c,v 1.59.2.5.8.15 2004/08/10 04:56:23 jinmei Exp $ */ + +#include + +#include +#include +#include +#include + +#include +#include + +#include +#include +#include + +#define IFMGR_MAGIC ISC_MAGIC('I', 'F', 'M', 'G') +#define NS_INTERFACEMGR_VALID(t) ISC_MAGIC_VALID(t, IFMGR_MAGIC) + +#define IFMGR_COMMON_LOGARGS \ + ns_g_lctx, NS_LOGCATEGORY_NETWORK, NS_LOGMODULE_INTERFACEMGR + +struct ns_interfacemgr { + unsigned int magic; /* Magic number. */ + int references; + isc_mutex_t lock; + isc_mem_t * mctx; /* Memory context. */ + isc_taskmgr_t * taskmgr; /* Task manager. */ + isc_socketmgr_t * socketmgr; /* Socket manager. */ + dns_dispatchmgr_t * dispatchmgr; + unsigned int generation; /* Current generation no. */ + ns_listenlist_t * listenon4; + ns_listenlist_t * listenon6; + dns_aclenv_t aclenv; /* Localhost/localnets ACLs */ + ISC_LIST(ns_interface_t) interfaces; /* List of interfaces. */ +}; + +static void +purge_old_interfaces(ns_interfacemgr_t *mgr); + +isc_result_t +ns_interfacemgr_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr, + isc_socketmgr_t *socketmgr, + dns_dispatchmgr_t *dispatchmgr, + ns_interfacemgr_t **mgrp) +{ + isc_result_t result; + ns_interfacemgr_t *mgr; + + REQUIRE(mctx != NULL); + REQUIRE(mgrp != NULL); + REQUIRE(*mgrp == NULL); + + mgr = isc_mem_get(mctx, sizeof(*mgr)); + if (mgr == NULL) + return (ISC_R_NOMEMORY); + + result = isc_mutex_init(&mgr->lock); + if (result != ISC_R_SUCCESS) + goto cleanup_mem; + + mgr->mctx = mctx; + mgr->taskmgr = taskmgr; + mgr->socketmgr = socketmgr; + mgr->dispatchmgr = dispatchmgr; + mgr->generation = 1; + mgr->listenon4 = NULL; + mgr->listenon6 = NULL; + + ISC_LIST_INIT(mgr->interfaces); + + /* + * The listen-on lists are initially empty. + */ + result = ns_listenlist_create(mctx, &mgr->listenon4); + if (result != ISC_R_SUCCESS) + goto cleanup_mem; + ns_listenlist_attach(mgr->listenon4, &mgr->listenon6); + + result = dns_aclenv_init(mctx, &mgr->aclenv); + if (result != ISC_R_SUCCESS) + goto cleanup_listenon; + + mgr->references = 1; + mgr->magic = IFMGR_MAGIC; + *mgrp = mgr; + return (ISC_R_SUCCESS); + + cleanup_listenon: + ns_listenlist_detach(&mgr->listenon4); + ns_listenlist_detach(&mgr->listenon6); + cleanup_mem: + isc_mem_put(mctx, mgr, sizeof(*mgr)); + return (result); +} + +static void +ns_interfacemgr_destroy(ns_interfacemgr_t *mgr) { + REQUIRE(NS_INTERFACEMGR_VALID(mgr)); + dns_aclenv_destroy(&mgr->aclenv); + ns_listenlist_detach(&mgr->listenon4); + ns_listenlist_detach(&mgr->listenon6); + DESTROYLOCK(&mgr->lock); + mgr->magic = 0; + isc_mem_put(mgr->mctx, mgr, sizeof(*mgr)); +} + +dns_aclenv_t * +ns_interfacemgr_getaclenv(ns_interfacemgr_t *mgr) { + return (&mgr->aclenv); +} + +void +ns_interfacemgr_attach(ns_interfacemgr_t *source, ns_interfacemgr_t **target) { + REQUIRE(NS_INTERFACEMGR_VALID(source)); + LOCK(&source->lock); + INSIST(source->references > 0); + source->references++; + UNLOCK(&source->lock); + *target = source; +} + +void +ns_interfacemgr_detach(ns_interfacemgr_t **targetp) { + isc_result_t need_destroy = ISC_FALSE; + ns_interfacemgr_t *target = *targetp; + REQUIRE(target != NULL); + REQUIRE(NS_INTERFACEMGR_VALID(target)); + LOCK(&target->lock); + REQUIRE(target->references > 0); + target->references--; + if (target->references == 0) + need_destroy = ISC_TRUE; + UNLOCK(&target->lock); + if (need_destroy) + ns_interfacemgr_destroy(target); + *targetp = NULL; +} + +void +ns_interfacemgr_shutdown(ns_interfacemgr_t *mgr) { + REQUIRE(NS_INTERFACEMGR_VALID(mgr)); + + /* + * Shut down and detach all interfaces. + * By incrementing the generation count, we make purge_old_interfaces() + * consider all interfaces "old". + */ + mgr->generation++; + purge_old_interfaces(mgr); +} + + +static isc_result_t +ns_interface_create(ns_interfacemgr_t *mgr, isc_sockaddr_t *addr, + const char *name, ns_interface_t **ifpret) +{ + ns_interface_t *ifp; + isc_result_t result; + + REQUIRE(NS_INTERFACEMGR_VALID(mgr)); + ifp = isc_mem_get(mgr->mctx, sizeof(*ifp)); + if (ifp == NULL) + return (ISC_R_NOMEMORY); + ifp->mgr = NULL; + ifp->generation = mgr->generation; + ifp->addr = *addr; + strncpy(ifp->name, name, sizeof(ifp->name)); + ifp->name[sizeof(ifp->name)-1] = '\0'; + ifp->clientmgr = NULL; + + result = isc_mutex_init(&ifp->lock); + if (result != ISC_R_SUCCESS) + goto lock_create_failure; + + result = ns_clientmgr_create(mgr->mctx, mgr->taskmgr, + ns_g_timermgr, + &ifp->clientmgr); + if (result != ISC_R_SUCCESS) { + isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR, + "ns_clientmgr_create() failed: %s", + isc_result_totext(result)); + goto clientmgr_create_failure; + } + + ifp->udpdispatch = NULL; + + ifp->tcpsocket = NULL; + /* + * Create a single TCP client object. It will replace itself + * with a new one as soon as it gets a connection, so the actual + * connections will be handled in parallel even though there is + * only one client initially. + */ + ifp->ntcptarget = 1; + ifp->ntcpcurrent = 0; + + ISC_LINK_INIT(ifp, link); + + ns_interfacemgr_attach(mgr, &ifp->mgr); + ISC_LIST_APPEND(mgr->interfaces, ifp, link); + + ifp->references = 1; + ifp->magic = IFACE_MAGIC; + *ifpret = ifp; + + return (ISC_R_SUCCESS); + + clientmgr_create_failure: + DESTROYLOCK(&ifp->lock); + lock_create_failure: + ifp->magic = 0; + isc_mem_put(mgr->mctx, ifp, sizeof(*ifp)); + + return (ISC_R_UNEXPECTED); +} + +static isc_result_t +ns_interface_listenudp(ns_interface_t *ifp) { + isc_result_t result; + unsigned int attrs; + unsigned int attrmask; + + attrs = 0; + attrs |= DNS_DISPATCHATTR_UDP; + if (isc_sockaddr_pf(&ifp->addr) == AF_INET) + attrs |= DNS_DISPATCHATTR_IPV4; + else + attrs |= DNS_DISPATCHATTR_IPV6; + attrs |= DNS_DISPATCHATTR_NOLISTEN; + attrmask = 0; + attrmask |= DNS_DISPATCHATTR_UDP | DNS_DISPATCHATTR_TCP; + attrmask |= DNS_DISPATCHATTR_IPV4 | DNS_DISPATCHATTR_IPV6; + result = dns_dispatch_getudp(ifp->mgr->dispatchmgr, ns_g_socketmgr, + ns_g_taskmgr, &ifp->addr, + 4096, 1000, 32768, 8219, 8237, + attrs, attrmask, &ifp->udpdispatch); + if (result != ISC_R_SUCCESS) { + isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR, + "could not listen on UDP socket: %s", + isc_result_totext(result)); + goto udp_dispatch_failure; + } + + result = ns_clientmgr_createclients(ifp->clientmgr, ns_g_cpus, + ifp, ISC_FALSE); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "UDP ns_clientmgr_createclients(): %s", + isc_result_totext(result)); + goto addtodispatch_failure; + } + return (ISC_R_SUCCESS); + + addtodispatch_failure: + dns_dispatch_changeattributes(ifp->udpdispatch, 0, + DNS_DISPATCHATTR_NOLISTEN); + dns_dispatch_detach(&ifp->udpdispatch); + udp_dispatch_failure: + return (result); +} + +static isc_result_t +ns_interface_accepttcp(ns_interface_t *ifp) { + isc_result_t result; + + /* + * Open a TCP socket. + */ + result = isc_socket_create(ifp->mgr->socketmgr, + isc_sockaddr_pf(&ifp->addr), + isc_sockettype_tcp, + &ifp->tcpsocket); + if (result != ISC_R_SUCCESS) { + isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR, + "creating TCP socket: %s", + isc_result_totext(result)); + goto tcp_socket_failure; + } +#ifndef ISC_ALLOW_MAPPED + isc_socket_ipv6only(ifp->tcpsocket, ISC_TRUE); +#endif + result = isc_socket_bind(ifp->tcpsocket, &ifp->addr); + if (result != ISC_R_SUCCESS) { + isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR, + "binding TCP socket: %s", + isc_result_totext(result)); + goto tcp_bind_failure; + } + result = isc_socket_listen(ifp->tcpsocket, ns_g_listen); + if (result != ISC_R_SUCCESS) { + isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR, + "listening on TCP socket: %s", + isc_result_totext(result)); + goto tcp_listen_failure; + } + + /* + * If/when there a multiple filters listen to the + * result. + */ + (void)isc_socket_filter(ifp->tcpsocket, "dataready"); + + result = ns_clientmgr_createclients(ifp->clientmgr, + ifp->ntcptarget, ifp, + ISC_TRUE); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "TCP ns_clientmgr_createclients(): %s", + isc_result_totext(result)); + goto accepttcp_failure; + } + return (ISC_R_SUCCESS); + + accepttcp_failure: + tcp_listen_failure: + tcp_bind_failure: + isc_socket_detach(&ifp->tcpsocket); + tcp_socket_failure: + return (ISC_R_SUCCESS); +} + +static isc_result_t +ns_interface_setup(ns_interfacemgr_t *mgr, isc_sockaddr_t *addr, + const char *name, ns_interface_t **ifpret, + isc_boolean_t accept_tcp) +{ + isc_result_t result; + ns_interface_t *ifp = NULL; + REQUIRE(ifpret != NULL && *ifpret == NULL); + + result = ns_interface_create(mgr, addr, name, &ifp); + if (result != ISC_R_SUCCESS) + return (result); + + result = ns_interface_listenudp(ifp); + if (result != ISC_R_SUCCESS) + goto cleanup_interface; + + if (accept_tcp == ISC_TRUE) { + result = ns_interface_accepttcp(ifp); + if (result != ISC_R_SUCCESS) { + /* + * XXXRTH We don't currently have a way to easily stop + * dispatch service, so we currently return + * ISC_R_SUCCESS (the UDP stuff will work even if TCP + * creation failed). This will be fixed later. + */ + result = ISC_R_SUCCESS; + } + } + *ifpret = ifp; + return (ISC_R_SUCCESS); + + cleanup_interface: + ISC_LIST_UNLINK(ifp->mgr->interfaces, ifp, link); + ns_interface_detach(&ifp); + return (result); +} + +void +ns_interface_shutdown(ns_interface_t *ifp) { + if (ifp->clientmgr != NULL) + ns_clientmgr_destroy(&ifp->clientmgr); +} + +static void +ns_interface_destroy(ns_interface_t *ifp) { + isc_mem_t *mctx = ifp->mgr->mctx; + REQUIRE(NS_INTERFACE_VALID(ifp)); + + ns_interface_shutdown(ifp); + + if (ifp->udpdispatch != NULL) { + dns_dispatch_changeattributes(ifp->udpdispatch, 0, + DNS_DISPATCHATTR_NOLISTEN); + dns_dispatch_detach(&ifp->udpdispatch); + } + if (ifp->tcpsocket != NULL) + isc_socket_detach(&ifp->tcpsocket); + + DESTROYLOCK(&ifp->lock); + + ns_interfacemgr_detach(&ifp->mgr); + + ifp->magic = 0; + isc_mem_put(mctx, ifp, sizeof(*ifp)); +} + +void +ns_interface_attach(ns_interface_t *source, ns_interface_t **target) { + REQUIRE(NS_INTERFACE_VALID(source)); + LOCK(&source->lock); + INSIST(source->references > 0); + source->references++; + UNLOCK(&source->lock); + *target = source; +} + +void +ns_interface_detach(ns_interface_t **targetp) { + isc_result_t need_destroy = ISC_FALSE; + ns_interface_t *target = *targetp; + REQUIRE(target != NULL); + REQUIRE(NS_INTERFACE_VALID(target)); + LOCK(&target->lock); + REQUIRE(target->references > 0); + target->references--; + if (target->references == 0) + need_destroy = ISC_TRUE; + UNLOCK(&target->lock); + if (need_destroy) + ns_interface_destroy(target); + *targetp = NULL; +} + +/* + * Search the interface list for an interface whose address and port + * both match those of 'addr'. Return a pointer to it, or NULL if not found. + */ +static ns_interface_t * +find_matching_interface(ns_interfacemgr_t *mgr, isc_sockaddr_t *addr) { + ns_interface_t *ifp; + for (ifp = ISC_LIST_HEAD(mgr->interfaces); ifp != NULL; + ifp = ISC_LIST_NEXT(ifp, link)) { + if (isc_sockaddr_equal(&ifp->addr, addr)) + break; + } + return (ifp); +} + +/* + * Remove any interfaces whose generation number is not the current one. + */ +static void +purge_old_interfaces(ns_interfacemgr_t *mgr) { + ns_interface_t *ifp, *next; + for (ifp = ISC_LIST_HEAD(mgr->interfaces); ifp != NULL; ifp = next) { + INSIST(NS_INTERFACE_VALID(ifp)); + next = ISC_LIST_NEXT(ifp, link); + if (ifp->generation != mgr->generation) { + char sabuf[256]; + ISC_LIST_UNLINK(ifp->mgr->interfaces, ifp, link); + isc_sockaddr_format(&ifp->addr, sabuf, sizeof(sabuf)); + isc_log_write(IFMGR_COMMON_LOGARGS, + ISC_LOG_INFO, + "no longer listening on %s", sabuf); + ns_interface_shutdown(ifp); + ns_interface_detach(&ifp); + } + } +} + +static isc_result_t +clearacl(isc_mem_t *mctx, dns_acl_t **aclp) { + dns_acl_t *newacl = NULL; + isc_result_t result; + result = dns_acl_create(mctx, 10, &newacl); + if (result != ISC_R_SUCCESS) + return (result); + dns_acl_detach(aclp); + dns_acl_attach(newacl, aclp); + dns_acl_detach(&newacl); + return (ISC_R_SUCCESS); +} + +static isc_boolean_t +listenon_is_ip6_any(ns_listenelt_t *elt) { + if (elt->acl->length != 1) + return (ISC_FALSE); + if (elt->acl->elements[0].negative == ISC_FALSE && + elt->acl->elements[0].type == dns_aclelementtype_any) + return (ISC_TRUE); /* listen-on-v6 { any; } */ + return (ISC_FALSE); /* All others */ +} + +static isc_result_t +setup_locals(ns_interfacemgr_t *mgr, isc_interface_t *interface) { + isc_result_t result; + dns_aclelement_t elt; + unsigned int family; + unsigned int prefixlen; + + family = interface->address.family; + + elt.type = dns_aclelementtype_ipprefix; + elt.negative = ISC_FALSE; + elt.u.ip_prefix.address = interface->address; + elt.u.ip_prefix.prefixlen = (family == AF_INET) ? 32 : 128; + result = dns_acl_appendelement(mgr->aclenv.localhost, &elt); + if (result != ISC_R_SUCCESS) + return (result); + + result = isc_netaddr_masktoprefixlen(&interface->netmask, + &prefixlen); + + /* Non contigious netmasks not allowed by IPv6 arch. */ + if (result != ISC_R_SUCCESS && family == AF_INET6) + return (result); + + if (result != ISC_R_SUCCESS) { + isc_log_write(IFMGR_COMMON_LOGARGS, + ISC_LOG_WARNING, + "omitting IPv4 interface %s from " + "localnets ACL: %s", + interface->name, + isc_result_totext(result)); + } else { + elt.u.ip_prefix.prefixlen = prefixlen; + if (dns_acl_elementmatch(mgr->aclenv.localnets, &elt, + NULL) == ISC_R_NOTFOUND) { + result = dns_acl_appendelement(mgr->aclenv.localnets, + &elt); + if (result != ISC_R_SUCCESS) + return (result); + } + } + + return (ISC_R_SUCCESS); +} + +static isc_result_t +do_scan(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen, + isc_boolean_t verbose) +{ + isc_interfaceiter_t *iter = NULL; + isc_boolean_t scan_ipv4 = ISC_FALSE; + isc_boolean_t scan_ipv6 = ISC_FALSE; + isc_boolean_t adjusting = ISC_FALSE; + isc_boolean_t ipv6only = ISC_TRUE; + isc_boolean_t ipv6pktinfo = ISC_TRUE; + isc_result_t result; + isc_netaddr_t zero_address, zero_address6; + ns_listenelt_t *le; + isc_sockaddr_t listen_addr; + ns_interface_t *ifp; + isc_boolean_t log_explicit = ISC_FALSE; + + if (ext_listen != NULL) + adjusting = ISC_TRUE; + + if (isc_net_probeipv6() == ISC_R_SUCCESS) + scan_ipv6 = ISC_TRUE; +#ifdef WANT_IPV6 + else + isc_log_write(IFMGR_COMMON_LOGARGS, + verbose ? ISC_LOG_INFO : ISC_LOG_DEBUG(1), + "no IPv6 interfaces found"); +#endif + + if (isc_net_probeipv4() == ISC_R_SUCCESS) + scan_ipv4 = ISC_TRUE; + else + isc_log_write(IFMGR_COMMON_LOGARGS, + verbose ? ISC_LOG_INFO : ISC_LOG_DEBUG(1), + "no IPv4 interfaces found"); + + /* + * A special, but typical case; listen-on-v6 { any; }. + * When we can make the socket IPv6-only, open a single wildcard + * socket for IPv6 communication. Otherwise, make separate socket + * for each IPv6 address in order to avoid accepting IPv4 packets + * as the form of mapped addresses unintentionally unless explicitly + * allowed. + */ +#ifndef ISC_ALLOW_MAPPED + if (scan_ipv6 == ISC_TRUE && + isc_net_probe_ipv6only() != ISC_R_SUCCESS) { + ipv6only = ISC_FALSE; + log_explicit = ISC_TRUE; + } +#endif + if (scan_ipv6 == ISC_TRUE && + isc_net_probe_ipv6pktinfo() != ISC_R_SUCCESS) { + ipv6pktinfo = ISC_FALSE; + log_explicit = ISC_TRUE; + } + if (scan_ipv6 == ISC_TRUE && ipv6only && ipv6pktinfo) { + for (le = ISC_LIST_HEAD(mgr->listenon6->elts); + le != NULL; + le = ISC_LIST_NEXT(le, link)) { + struct in6_addr in6a; + + if (!listenon_is_ip6_any(le)) + continue; + + in6a = in6addr_any; + isc_sockaddr_fromin6(&listen_addr, &in6a, le->port); + + ifp = find_matching_interface(mgr, &listen_addr); + if (ifp != NULL) { + ifp->generation = mgr->generation; + } else { + isc_log_write(IFMGR_COMMON_LOGARGS, + ISC_LOG_INFO, + "listening on IPv6 " + "interfaces, port %u", + le->port); + result = ns_interface_setup(mgr, &listen_addr, + "", &ifp, + ISC_TRUE); + if (result == ISC_R_SUCCESS) + ifp->flags |= NS_INTERFACEFLAG_ANYADDR; + else + isc_log_write(IFMGR_COMMON_LOGARGS, + ISC_LOG_ERROR, + "listening on all IPv6 " + "interfaces failed"); + /* Continue. */ + } + } + } + + isc_netaddr_any(&zero_address); + isc_netaddr_any6(&zero_address6); + + result = isc_interfaceiter_create(mgr->mctx, &iter); + if (result != ISC_R_SUCCESS) + return (result); + + if (adjusting == ISC_FALSE) { + result = clearacl(mgr->mctx, &mgr->aclenv.localhost); + if (result != ISC_R_SUCCESS) + goto cleanup_iter; + result = clearacl(mgr->mctx, &mgr->aclenv.localnets); + if (result != ISC_R_SUCCESS) + goto cleanup_iter; + } + + for (result = isc_interfaceiter_first(iter); + result == ISC_R_SUCCESS; + result = isc_interfaceiter_next(iter)) + { + isc_interface_t interface; + ns_listenlist_t *ll; + unsigned int family; + + result = isc_interfaceiter_current(iter, &interface); + if (result != ISC_R_SUCCESS) + break; + + family = interface.address.family; + if (family != AF_INET && family != AF_INET6) + continue; + if (scan_ipv4 == ISC_FALSE && family == AF_INET) + continue; + if (scan_ipv6 == ISC_FALSE && family == AF_INET6) + continue; + + /* + * Test for the address being nonzero rather than testing + * INTERFACE_F_UP, because on some systems the latter + * follows the media state and we could end up ignoring + * the interface for an entire rescan interval due to + * a temporary media glitch at rescan time. + */ + if (family == AF_INET && + isc_netaddr_equal(&interface.address, &zero_address)) { + continue; + } + if (family == AF_INET6 && + isc_netaddr_equal(&interface.address, &zero_address6)) { + continue; + } + + if (adjusting == ISC_FALSE) { + result = setup_locals(mgr, &interface); + if (result != ISC_R_SUCCESS) + goto ignore_interface; + } + + ll = (family == AF_INET) ? mgr->listenon4 : mgr->listenon6; + for (le = ISC_LIST_HEAD(ll->elts); + le != NULL; + le = ISC_LIST_NEXT(le, link)) + { + int match; + isc_boolean_t ipv6_wildcard = ISC_FALSE; + isc_netaddr_t listen_netaddr; + isc_sockaddr_t listen_sockaddr; + + /* + * Construct a socket address for this IP/port + * combination. + */ + if (family == AF_INET) { + isc_netaddr_fromin(&listen_netaddr, + &interface.address.type.in); + } else { + isc_netaddr_fromin6(&listen_netaddr, + &interface.address.type.in6); + isc_netaddr_setzone(&listen_netaddr, + interface.address.zone); + } + isc_sockaddr_fromnetaddr(&listen_sockaddr, + &listen_netaddr, + le->port); + + /* + * See if the address matches the listen-on statement; + * if not, ignore the interface. + */ + result = dns_acl_match(&listen_netaddr, NULL, + le->acl, &mgr->aclenv, + &match, NULL); + if (match <= 0) + continue; + + /* + * The case of "any" IPv6 address will require + * special considerations later, so remember it. + */ + if (family == AF_INET6 && ipv6only && ipv6pktinfo && + listenon_is_ip6_any(le)) + ipv6_wildcard = ISC_TRUE; + + /* + * When adjusting interfaces with extra a listening + * list, see if the address matches the extra list. + * If it does, and is also covered by a wildcard + * interface, we need to listen on the address + * explicitly. + */ + if (adjusting == ISC_TRUE) { + ns_listenelt_t *ele; + + match = 0; + for (ele = ISC_LIST_HEAD(ext_listen->elts); + ele != NULL; + ele = ISC_LIST_NEXT(ele, link)) { + dns_acl_match(&listen_netaddr, NULL, + ele->acl, NULL, + &match, NULL); + if (match > 0 && ele->port == le->port) + break; + else + match = 0; + } + if (ipv6_wildcard == ISC_TRUE && match == 0) + continue; + } + + ifp = find_matching_interface(mgr, &listen_sockaddr); + if (ifp != NULL) { + ifp->generation = mgr->generation; + } else { + char sabuf[ISC_SOCKADDR_FORMATSIZE]; + + if (adjusting == ISC_FALSE && + ipv6_wildcard == ISC_TRUE) + continue; + + if (log_explicit && family == AF_INET6 && + !adjusting && listenon_is_ip6_any(le)) { + isc_log_write(IFMGR_COMMON_LOGARGS, + verbose ? ISC_LOG_INFO : + ISC_LOG_DEBUG(1), + "IPv6 socket API is " + "incomplete; explicitly " + "binding to each IPv6 " + "address separately"); + log_explicit = ISC_FALSE; + } + isc_sockaddr_format(&listen_sockaddr, + sabuf, sizeof(sabuf)); + isc_log_write(IFMGR_COMMON_LOGARGS, + ISC_LOG_INFO, + "%s" + "listening on %s interface " + "%s, %s", + (adjusting == ISC_TRUE) ? + "additionally " : "", + (family == AF_INET) ? + "IPv4" : "IPv6", + interface.name, sabuf); + + result = ns_interface_setup(mgr, + &listen_sockaddr, + interface.name, + &ifp, + (adjusting == ISC_TRUE) ? + ISC_FALSE : + ISC_TRUE); + + if (result != ISC_R_SUCCESS) { + isc_log_write(IFMGR_COMMON_LOGARGS, + ISC_LOG_ERROR, + "creating %s interface " + "%s failed; interface " + "ignored", + (family == AF_INET) ? + "IPv4" : "IPv6", + interface.name); + } + /* Continue. */ + } + + } + continue; + + ignore_interface: + isc_log_write(IFMGR_COMMON_LOGARGS, + ISC_LOG_ERROR, + "ignoring %s interface %s: %s", + (family == AF_INET) ? "IPv4" : "IPv6", + interface.name, isc_result_totext(result)); + continue; + } + if (result != ISC_R_NOMORE) + UNEXPECTED_ERROR(__FILE__, __LINE__, + "interface iteration failed: %s", + isc_result_totext(result)); + else + result = ISC_R_SUCCESS; + cleanup_iter: + isc_interfaceiter_destroy(&iter); + return (result); +} + +static void +ns_interfacemgr_scan0(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen, + isc_boolean_t verbose) +{ + isc_boolean_t purge = ISC_TRUE; + + REQUIRE(NS_INTERFACEMGR_VALID(mgr)); + + mgr->generation++; /* Increment the generation count. */ + + if (do_scan(mgr, ext_listen, verbose) != ISC_R_SUCCESS) + purge = ISC_FALSE; + + /* + * Now go through the interface list and delete anything that + * does not have the current generation number. This is + * how we catch interfaces that go away or change their + * addresses. + */ + if (purge) + purge_old_interfaces(mgr); + + /* + * Warn if we are not listening on any interface, unless + * we're in lwresd-only mode, in which case that is to + * be expected. + */ + if (ext_listen == NULL && + ISC_LIST_EMPTY(mgr->interfaces) && ! ns_g_lwresdonly) { + isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_WARNING, + "not listening on any interfaces"); + } +} + +void +ns_interfacemgr_scan(ns_interfacemgr_t *mgr, isc_boolean_t verbose) { + ns_interfacemgr_scan0(mgr, NULL, verbose); +} + +void +ns_interfacemgr_adjust(ns_interfacemgr_t *mgr, ns_listenlist_t *list, + isc_boolean_t verbose) +{ + ns_interfacemgr_scan0(mgr, list, verbose); +} + +void +ns_interfacemgr_setlistenon4(ns_interfacemgr_t *mgr, ns_listenlist_t *value) { + LOCK(&mgr->lock); + ns_listenlist_detach(&mgr->listenon4); + ns_listenlist_attach(value, &mgr->listenon4); + UNLOCK(&mgr->lock); +} + +void +ns_interfacemgr_setlistenon6(ns_interfacemgr_t *mgr, ns_listenlist_t *value) { + LOCK(&mgr->lock); + ns_listenlist_detach(&mgr->listenon6); + ns_listenlist_attach(value, &mgr->listenon6); + UNLOCK(&mgr->lock); +} + +void +ns_interfacemgr_dumprecursing(FILE *f, ns_interfacemgr_t *mgr) { + ns_interface_t *interface; + + LOCK(&mgr->lock); + interface = ISC_LIST_HEAD(mgr->interfaces); + while (interface != NULL) { + if (interface->clientmgr != NULL) + ns_client_dumprecursing(f, interface->clientmgr); + interface = ISC_LIST_NEXT(interface, link); + } + UNLOCK(&mgr->lock); +} diff --git a/contrib/bind9/bin/named/listenlist.c b/contrib/bind9/bin/named/listenlist.c new file mode 100644 index 000000000000..bba164f08126 --- /dev/null +++ b/contrib/bind9/bin/named/listenlist.c @@ -0,0 +1,136 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: listenlist.c,v 1.9.208.1 2004/03/06 10:21:18 marka Exp $ */ + +#include + +#include +#include + +#include + +#include + +static void +destroy(ns_listenlist_t *list); + +isc_result_t +ns_listenelt_create(isc_mem_t *mctx, in_port_t port, + dns_acl_t *acl, ns_listenelt_t **target) +{ + ns_listenelt_t *elt = NULL; + REQUIRE(target != NULL && *target == NULL); + elt = isc_mem_get(mctx, sizeof(*elt)); + if (elt == NULL) + return (ISC_R_NOMEMORY); + elt->mctx = mctx; + ISC_LINK_INIT(elt, link); + elt->port = port; + elt->acl = acl; + *target = elt; + return (ISC_R_SUCCESS); +} + +void +ns_listenelt_destroy(ns_listenelt_t *elt) { + if (elt->acl != NULL) + dns_acl_detach(&elt->acl); + isc_mem_put(elt->mctx, elt, sizeof(*elt)); +} + +isc_result_t +ns_listenlist_create(isc_mem_t *mctx, ns_listenlist_t **target) { + ns_listenlist_t *list = NULL; + REQUIRE(target != NULL && *target == NULL); + list = isc_mem_get(mctx, sizeof(*list)); + if (list == NULL) + return (ISC_R_NOMEMORY); + list->mctx = mctx; + list->refcount = 1; + ISC_LIST_INIT(list->elts); + *target = list; + return (ISC_R_SUCCESS); +} + +static void +destroy(ns_listenlist_t *list) { + ns_listenelt_t *elt, *next; + for (elt = ISC_LIST_HEAD(list->elts); + elt != NULL; + elt = next) + { + next = ISC_LIST_NEXT(elt, link); + ns_listenelt_destroy(elt); + } + isc_mem_put(list->mctx, list, sizeof(*list)); +} + +void +ns_listenlist_attach(ns_listenlist_t *source, ns_listenlist_t **target) { + INSIST(source->refcount > 0); + source->refcount++; + *target = source; +} + +void +ns_listenlist_detach(ns_listenlist_t **listp) { + ns_listenlist_t *list = *listp; + INSIST(list->refcount > 0); + list->refcount--; + if (list->refcount == 0) + destroy(list); + *listp = NULL; +} + +isc_result_t +ns_listenlist_default(isc_mem_t *mctx, in_port_t port, + isc_boolean_t enabled, ns_listenlist_t **target) +{ + isc_result_t result; + dns_acl_t *acl = NULL; + ns_listenelt_t *elt = NULL; + ns_listenlist_t *list = NULL; + + REQUIRE(target != NULL && *target == NULL); + if (enabled) + result = dns_acl_any(mctx, &acl); + else + result = dns_acl_none(mctx, &acl); + if (result != ISC_R_SUCCESS) + goto cleanup; + + result = ns_listenelt_create(mctx, port, acl, &elt); + if (result != ISC_R_SUCCESS) + goto cleanup_acl; + + result = ns_listenlist_create(mctx, &list); + if (result != ISC_R_SUCCESS) + goto cleanup_listenelt; + + ISC_LIST_APPEND(list->elts, elt, link); + + *target = list; + return (ISC_R_SUCCESS); + + cleanup_listenelt: + ns_listenelt_destroy(elt); + cleanup_acl: + dns_acl_detach(&acl); + cleanup: + return (result); +} diff --git a/contrib/bind9/bin/named/log.c b/contrib/bind9/bin/named/log.c new file mode 100644 index 000000000000..31af4bdd13c7 --- /dev/null +++ b/contrib/bind9/bin/named/log.c @@ -0,0 +1,217 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: log.c,v 1.33.2.1.10.4 2004/03/08 09:04:14 marka Exp $ */ + +#include + +#include + +#include + +#include + +#ifndef ISC_FACILITY +#define ISC_FACILITY LOG_DAEMON +#endif + +/* + * When adding a new category, be sure to add the appropriate + * #define to . + */ +static isc_logcategory_t categories[] = { + { "", 0 }, + { "client", 0 }, + { "network", 0 }, + { "update", 0 }, + { "queries", 0 }, + { "unmatched", 0 }, + { "update-security", 0 }, + { NULL, 0 } +}; + +/* + * When adding a new module, be sure to add the appropriate + * #define to . + */ +static isc_logmodule_t modules[] = { + { "main", 0 }, + { "client", 0 }, + { "server", 0 }, + { "query", 0 }, + { "interfacemgr", 0 }, + { "update", 0 }, + { "xfer-in", 0 }, + { "xfer-out", 0 }, + { "notify", 0 }, + { "control", 0 }, + { "lwresd", 0 }, + { NULL, 0 } +}; + +isc_result_t +ns_log_init(isc_boolean_t safe) { + isc_result_t result; + isc_logconfig_t *lcfg = NULL; + + ns_g_categories = categories; + ns_g_modules = modules; + + /* + * Setup a logging context. + */ + result = isc_log_create(ns_g_mctx, &ns_g_lctx, &lcfg); + if (result != ISC_R_SUCCESS) + return (result); + + isc_log_registercategories(ns_g_lctx, ns_g_categories); + isc_log_registermodules(ns_g_lctx, ns_g_modules); + isc_log_setcontext(ns_g_lctx); + dns_log_init(ns_g_lctx); + dns_log_setcontext(ns_g_lctx); + cfg_log_init(ns_g_lctx); + + if (safe) + result = ns_log_setsafechannels(lcfg); + else + result = ns_log_setdefaultchannels(lcfg); + if (result != ISC_R_SUCCESS) + goto cleanup; + + result = ns_log_setdefaultcategory(lcfg); + if (result != ISC_R_SUCCESS) + goto cleanup; + + return (ISC_R_SUCCESS); + + cleanup: + isc_log_destroy(&ns_g_lctx); + isc_log_setcontext(NULL); + dns_log_setcontext(NULL); + + return (result); +} + +isc_result_t +ns_log_setdefaultchannels(isc_logconfig_t *lcfg) { + isc_result_t result; + isc_logdestination_t destination; + + /* + * By default, the logging library makes "default_debug" log to + * stderr. In BIND, we want to override this and log to named.run + * instead, unless the the -g option was given. + */ + if (! ns_g_logstderr) { + destination.file.stream = NULL; + destination.file.name = "named.run"; + destination.file.versions = ISC_LOG_ROLLNEVER; + destination.file.maximum_size = 0; + result = isc_log_createchannel(lcfg, "default_debug", + ISC_LOG_TOFILE, + ISC_LOG_DYNAMIC, + &destination, + ISC_LOG_PRINTTIME| + ISC_LOG_DEBUGONLY); + if (result != ISC_R_SUCCESS) + goto cleanup; + } + +#if ISC_FACILITY != LOG_DAEMON + destination.facility = ISC_FACILITY; + result = isc_log_createchannel(lcfg, "default_syslog", + ISC_LOG_TOSYSLOG, ISC_LOG_INFO, + &destination, 0); + if (result != ISC_R_SUCCESS) + goto cleanup; +#endif + + /* + * Set the initial debug level. + */ + isc_log_setdebuglevel(ns_g_lctx, ns_g_debuglevel); + + result = ISC_R_SUCCESS; + + cleanup: + return (result); +} + +isc_result_t +ns_log_setsafechannels(isc_logconfig_t *lcfg) { + isc_result_t result; + + if (! ns_g_logstderr) { + result = isc_log_createchannel(lcfg, "default_debug", + ISC_LOG_TONULL, + ISC_LOG_DYNAMIC, + NULL, 0); + if (result != ISC_R_SUCCESS) + goto cleanup; + + /* + * Setting the debug level to zero should get the output + * discarded a bit faster. + */ + isc_log_setdebuglevel(ns_g_lctx, 0); + } else { + isc_log_setdebuglevel(ns_g_lctx, ns_g_debuglevel); + } + + result = ISC_R_SUCCESS; + + cleanup: + return (result); +} + +isc_result_t +ns_log_setdefaultcategory(isc_logconfig_t *lcfg) { + isc_result_t result; + + if (! ns_g_logstderr) { + result = isc_log_usechannel(lcfg, "default_syslog", + ISC_LOGCATEGORY_DEFAULT, NULL); + if (result != ISC_R_SUCCESS) + goto cleanup; + } + + result = isc_log_usechannel(lcfg, "default_debug", + ISC_LOGCATEGORY_DEFAULT, NULL); + if (result != ISC_R_SUCCESS) + goto cleanup; + + result = ISC_R_SUCCESS; + + cleanup: + return (result); +} + +isc_result_t +ns_log_setunmatchedcategory(isc_logconfig_t *lcfg) { + isc_result_t result; + + result = isc_log_usechannel(lcfg, "null", + NS_LOGCATEGORY_UNMATCHED, NULL); + return (result); +} + +void +ns_log_shutdown(void) { + isc_log_destroy(&ns_g_lctx); + isc_log_setcontext(NULL); + dns_log_setcontext(NULL); +} diff --git a/contrib/bind9/bin/named/logconf.c b/contrib/bind9/bin/named/logconf.c new file mode 100644 index 000000000000..596d40166bb3 --- /dev/null +++ b/contrib/bind9/bin/named/logconf.c @@ -0,0 +1,295 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: logconf.c,v 1.30.2.3.10.2 2004/03/06 10:21:18 marka Exp $ */ + +#include + +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + +#define CHECK(op) \ + do { result = (op); \ + if (result != ISC_R_SUCCESS) goto cleanup; \ + } while (0) + +/* + * Set up a logging category according to the named.conf data + * in 'ccat' and add it to 'lctx'. + */ +static isc_result_t +category_fromconf(cfg_obj_t *ccat, isc_logconfig_t *lctx) { + isc_result_t result; + const char *catname; + isc_logcategory_t *category; + isc_logmodule_t *module; + cfg_obj_t *destinations = NULL; + cfg_listelt_t *element = NULL; + + catname = cfg_obj_asstring(cfg_tuple_get(ccat, "name")); + category = isc_log_categorybyname(ns_g_lctx, catname); + if (category == NULL) { + cfg_obj_log(ccat, ns_g_lctx, ISC_LOG_ERROR, + "unknown logging category '%s' ignored", + catname); + /* + * Allow further processing by returning success. + */ + return (ISC_R_SUCCESS); + } + + module = NULL; + + destinations = cfg_tuple_get(ccat, "destinations"); + for (element = cfg_list_first(destinations); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *channel = cfg_listelt_value(element); + char *channelname = cfg_obj_asstring(channel); + + result = isc_log_usechannel(lctx, channelname, category, + module); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, CFG_LOGCATEGORY_CONFIG, + NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "logging channel '%s': %s", channelname, + isc_result_totext(result)); + return (result); + } + } + return (ISC_R_SUCCESS); +} + +/* + * Set up a logging channel according to the named.conf data + * in 'cchan' and add it to 'lctx'. + */ +static isc_result_t +channel_fromconf(cfg_obj_t *channel, isc_logconfig_t *lctx) { + isc_result_t result; + isc_logdestination_t dest; + unsigned int type; + unsigned int flags = 0; + int level; + const char *channelname; + cfg_obj_t *fileobj = NULL; + cfg_obj_t *syslogobj = NULL; + cfg_obj_t *nullobj = NULL; + cfg_obj_t *stderrobj = NULL; + cfg_obj_t *severity = NULL; + int i; + + channelname = cfg_obj_asstring(cfg_map_getname(channel)); + + (void)cfg_map_get(channel, "file", &fileobj); + (void)cfg_map_get(channel, "syslog", &syslogobj); + (void)cfg_map_get(channel, "null", &nullobj); + (void)cfg_map_get(channel, "stderr", &stderrobj); + + i = 0; + if (fileobj != NULL) + i++; + if (syslogobj != NULL) + i++; + if (nullobj != NULL) + i++; + if (stderrobj != NULL) + i++; + + if (i != 1) { + cfg_obj_log(channel, ns_g_lctx, ISC_LOG_ERROR, + "channel '%s': exactly one of file, syslog, " + "null, and stderr must be present", channelname); + return (ISC_R_FAILURE); + } + + type = ISC_LOG_TONULL; + + if (fileobj != NULL) { + cfg_obj_t *pathobj = cfg_tuple_get(fileobj, "file"); + cfg_obj_t *sizeobj = cfg_tuple_get(fileobj, "size"); + cfg_obj_t *versionsobj = cfg_tuple_get(fileobj, "versions"); + isc_int32_t versions = ISC_LOG_ROLLNEVER; + isc_offset_t size = 0; + + type = ISC_LOG_TOFILE; + + if (versionsobj != NULL && cfg_obj_isuint32(versionsobj)) + versions = cfg_obj_asuint32(versionsobj); + if (versionsobj != NULL && cfg_obj_isstring(versionsobj) && + strcasecmp(cfg_obj_asstring(versionsobj), "unlimited") == 0) + versions = ISC_LOG_ROLLINFINITE; + if (sizeobj != NULL && + cfg_obj_isuint64(sizeobj) && + cfg_obj_asuint64(sizeobj) < ISC_OFFSET_MAXIMUM) + size = (isc_offset_t)cfg_obj_asuint64(sizeobj); + dest.file.stream = NULL; + dest.file.name = cfg_obj_asstring(pathobj); + dest.file.versions = versions; + dest.file.maximum_size = size; + } else if (syslogobj != NULL) { + int facility = LOG_DAEMON; + + type = ISC_LOG_TOSYSLOG; + + if (cfg_obj_isstring(syslogobj)) { + char *facilitystr = cfg_obj_asstring(syslogobj); + (void)isc_syslog_facilityfromstring(facilitystr, + &facility); + } + dest.facility = facility; + } else if (stderrobj != NULL) { + type = ISC_LOG_TOFILEDESC; + dest.file.stream = stderr; + dest.file.name = NULL; + dest.file.versions = ISC_LOG_ROLLNEVER; + dest.file.maximum_size = 0; + } + + /* + * Munge flags. + */ + { + cfg_obj_t *printcat = NULL; + cfg_obj_t *printsev = NULL; + cfg_obj_t *printtime = NULL; + + (void)cfg_map_get(channel, "print-category", &printcat); + (void)cfg_map_get(channel, "print-severity", &printsev); + (void)cfg_map_get(channel, "print-time", &printtime); + + if (printcat != NULL && cfg_obj_asboolean(printcat)) + flags |= ISC_LOG_PRINTCATEGORY; + if (printtime != NULL && cfg_obj_asboolean(printtime)) + flags |= ISC_LOG_PRINTTIME; + if (printsev != NULL && cfg_obj_asboolean(printsev)) + flags |= ISC_LOG_PRINTLEVEL; + } + + level = ISC_LOG_INFO; + if (cfg_map_get(channel, "severity", &severity) == ISC_R_SUCCESS) { + if (cfg_obj_isstring(severity)) { + char *str = cfg_obj_asstring(severity); + if (strcasecmp(str, "critical") == 0) + level = ISC_LOG_CRITICAL; + else if (strcasecmp(str, "error") == 0) + level = ISC_LOG_ERROR; + else if (strcasecmp(str, "warning") == 0) + level = ISC_LOG_WARNING; + else if (strcasecmp(str, "notice") == 0) + level = ISC_LOG_NOTICE; + else if (strcasecmp(str, "info") == 0) + level = ISC_LOG_INFO; + else if (strcasecmp(str, "dynamic") == 0) + level = ISC_LOG_DYNAMIC; + } else + /* debug */ + level = cfg_obj_asuint32(severity); + } + + result = isc_log_createchannel(lctx, channelname, + type, level, &dest, flags); + + if (result == ISC_R_SUCCESS && type == ISC_LOG_TOFILE) { + FILE *fp; + + /* + * Test that the file can be opened, since isc_log_open() + * can't effectively report failures when called in + * isc_log_doit(). + */ + result = isc_stdio_open(dest.file.name, "a", &fp); + if (result != ISC_R_SUCCESS) + isc_log_write(ns_g_lctx, CFG_LOGCATEGORY_CONFIG, + NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "logging channel '%s' file '%s': %s", + channelname, dest.file.name, + isc_result_totext(result)); + else + (void)isc_stdio_close(fp); + + /* + * Allow named to continue by returning success. + */ + result = ISC_R_SUCCESS; + } + + return (result); +} + +isc_result_t +ns_log_configure(isc_logconfig_t *logconf, cfg_obj_t *logstmt) { + isc_result_t result; + cfg_obj_t *channels = NULL; + cfg_obj_t *categories = NULL; + cfg_listelt_t *element; + isc_boolean_t default_set = ISC_FALSE; + isc_boolean_t unmatched_set = ISC_FALSE; + + CHECK(ns_log_setdefaultchannels(logconf)); + + (void)cfg_map_get(logstmt, "channel", &channels); + for (element = cfg_list_first(channels); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *channel = cfg_listelt_value(element); + CHECK(channel_fromconf(channel, logconf)); + } + + (void)cfg_map_get(logstmt, "category", &categories); + for (element = cfg_list_first(categories); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *category = cfg_listelt_value(element); + CHECK(category_fromconf(category, logconf)); + if (!default_set) { + cfg_obj_t *catname = cfg_tuple_get(category, "name"); + if (strcmp(cfg_obj_asstring(catname), "default") == 0) + default_set = ISC_TRUE; + } + if (!unmatched_set) { + cfg_obj_t *catname = cfg_tuple_get(category, "name"); + if (strcmp(cfg_obj_asstring(catname), "unmatched") == 0) + unmatched_set = ISC_TRUE; + } + } + + if (!default_set) + CHECK(ns_log_setdefaultcategory(logconf)); + + if (!unmatched_set) + CHECK(ns_log_setunmatchedcategory(logconf)); + + return (ISC_R_SUCCESS); + + cleanup: + if (logconf != NULL) + isc_logconfig_destroy(&logconf); + return (result); +} diff --git a/contrib/bind9/bin/named/lwaddr.c b/contrib/bind9/bin/named/lwaddr.c new file mode 100644 index 000000000000..1bd8d82875e7 --- /dev/null +++ b/contrib/bind9/bin/named/lwaddr.c @@ -0,0 +1,92 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwaddr.c,v 1.3.208.1 2004/03/06 10:21:18 marka Exp $ */ + +#include + +#include + +#include +#include +#include + +#include + +#include + +/* + * Convert addresses from lwres to isc format. + */ +isc_result_t +lwaddr_netaddr_fromlwresaddr(isc_netaddr_t *na, lwres_addr_t *la) { + if (la->family != LWRES_ADDRTYPE_V4 && la->family != LWRES_ADDRTYPE_V6) + return (ISC_R_FAMILYNOSUPPORT); + + if (la->family == LWRES_ADDRTYPE_V4) { + struct in_addr ina; + memcpy(&ina.s_addr, la->address, 4); + isc_netaddr_fromin(na, &ina); + } else { + struct in6_addr ina6; + memcpy(&ina6.s6_addr, la->address, 16); + isc_netaddr_fromin6(na, &ina6); + } + return (ISC_R_SUCCESS); +} + +isc_result_t +lwaddr_sockaddr_fromlwresaddr(isc_sockaddr_t *sa, lwres_addr_t *la, + in_port_t port) +{ + isc_netaddr_t na; + isc_result_t result; + + result = lwaddr_netaddr_fromlwresaddr(&na, la); + if (result != ISC_R_SUCCESS) + return (result); + isc_sockaddr_fromnetaddr(sa, &na, port); + return (ISC_R_SUCCESS); +} + +/* + * Convert addresses from isc to lwres format. + */ + +isc_result_t +lwaddr_lwresaddr_fromnetaddr(lwres_addr_t *la, isc_netaddr_t *na) { + if (na->family != AF_INET && na->family != AF_INET6) + return (ISC_R_FAMILYNOSUPPORT); + + if (na->family == AF_INET) { + la->family = LWRES_ADDRTYPE_V4; + la->length = 4; + memcpy(la->address, &na->type.in, 4); + } else { + la->family = LWRES_ADDRTYPE_V6; + la->length = 16; + memcpy(la->address, &na->type.in, 16); + } + return (ISC_R_SUCCESS); +} + +isc_result_t +lwaddr_lwresaddr_fromsockaddr(lwres_addr_t *la, isc_sockaddr_t *sa) { + isc_netaddr_t na; + isc_netaddr_fromsockaddr(&na, sa); + return (lwaddr_lwresaddr_fromnetaddr(la, &na)); +} diff --git a/contrib/bind9/bin/named/lwdclient.c b/contrib/bind9/bin/named/lwdclient.c new file mode 100644 index 000000000000..7975a4991e13 --- /dev/null +++ b/contrib/bind9/bin/named/lwdclient.c @@ -0,0 +1,465 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwdclient.c,v 1.13.12.5 2004/03/08 09:04:15 marka Exp $ */ + +#include + +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include +#include + +#define SHUTTINGDOWN(cm) ((cm->flags & NS_LWDCLIENTMGR_FLAGSHUTTINGDOWN) != 0) + +static void +lwdclientmgr_shutdown_callback(isc_task_t *task, isc_event_t *ev); + +void +ns_lwdclient_log(int level, const char *format, ...) { + va_list args; + + va_start(args, format); + isc_log_vwrite(dns_lctx, + DNS_LOGCATEGORY_DATABASE, DNS_LOGMODULE_ADB, + ISC_LOG_DEBUG(level), format, args); + va_end(args); +} + +isc_result_t +ns_lwdclientmgr_create(ns_lwreslistener_t *listener, unsigned int nclients, + isc_taskmgr_t *taskmgr) +{ + ns_lwresd_t *lwresd = listener->manager; + ns_lwdclientmgr_t *cm; + ns_lwdclient_t *client; + unsigned int i; + isc_result_t result = ISC_R_FAILURE; + + cm = isc_mem_get(lwresd->mctx, sizeof(ns_lwdclientmgr_t)); + if (cm == NULL) + return (ISC_R_NOMEMORY); + + cm->listener = NULL; + ns_lwreslistener_attach(listener, &cm->listener); + cm->mctx = lwresd->mctx; + cm->sock = NULL; + isc_socket_attach(listener->sock, &cm->sock); + cm->view = lwresd->view; + cm->lwctx = NULL; + cm->task = NULL; + cm->flags = 0; + ISC_LINK_INIT(cm, link); + ISC_LIST_INIT(cm->idle); + ISC_LIST_INIT(cm->running); + + if (lwres_context_create(&cm->lwctx, cm->mctx, + ns__lwresd_memalloc, ns__lwresd_memfree, + LWRES_CONTEXT_SERVERMODE) + != ISC_R_SUCCESS) + goto errout; + + for (i = 0; i < nclients; i++) { + client = isc_mem_get(lwresd->mctx, sizeof(ns_lwdclient_t)); + if (client != NULL) { + ns_lwdclient_log(50, "created client %p, manager %p", + client, cm); + ns_lwdclient_initialize(client, cm); + } + } + + /* + * If we could create no clients, clean up and return. + */ + if (ISC_LIST_EMPTY(cm->idle)) + goto errout; + + result = isc_task_create(taskmgr, 0, &cm->task); + if (result != ISC_R_SUCCESS) + goto errout; + + /* + * This MUST be last, since there is no way to cancel an onshutdown... + */ + result = isc_task_onshutdown(cm->task, lwdclientmgr_shutdown_callback, + cm); + if (result != ISC_R_SUCCESS) + goto errout; + + ns_lwreslistener_linkcm(listener, cm); + + return (ISC_R_SUCCESS); + + errout: + client = ISC_LIST_HEAD(cm->idle); + while (client != NULL) { + ISC_LIST_UNLINK(cm->idle, client, link); + isc_mem_put(lwresd->mctx, client, sizeof(*client)); + client = ISC_LIST_HEAD(cm->idle); + } + + if (cm->task != NULL) + isc_task_detach(&cm->task); + + if (cm->lwctx != NULL) + lwres_context_destroy(&cm->lwctx); + + isc_mem_put(lwresd->mctx, cm, sizeof(*cm)); + return (result); +} + +static void +lwdclientmgr_destroy(ns_lwdclientmgr_t *cm) { + ns_lwdclient_t *client; + ns_lwreslistener_t *listener; + + if (!SHUTTINGDOWN(cm)) + return; + + /* + * run through the idle list and free the clients there. Idle + * clients do not have a recv running nor do they have any finds + * or similar running. + */ + client = ISC_LIST_HEAD(cm->idle); + while (client != NULL) { + ns_lwdclient_log(50, "destroying client %p, manager %p", + client, cm); + ISC_LIST_UNLINK(cm->idle, client, link); + isc_mem_put(cm->mctx, client, sizeof(*client)); + client = ISC_LIST_HEAD(cm->idle); + } + + if (!ISC_LIST_EMPTY(cm->running)) + return; + + lwres_context_destroy(&cm->lwctx); + cm->view = NULL; + isc_socket_detach(&cm->sock); + isc_task_detach(&cm->task); + + listener = cm->listener; + ns_lwreslistener_unlinkcm(listener, cm); + ns_lwdclient_log(50, "destroying manager %p", cm); + isc_mem_put(cm->mctx, cm, sizeof(*cm)); + ns_lwreslistener_detach(&listener); +} + +static void +process_request(ns_lwdclient_t *client) { + lwres_buffer_t b; + isc_result_t result; + + lwres_buffer_init(&b, client->buffer, client->recvlength); + lwres_buffer_add(&b, client->recvlength); + + result = lwres_lwpacket_parseheader(&b, &client->pkt); + if (result != ISC_R_SUCCESS) { + ns_lwdclient_log(50, "invalid packet header received"); + goto restart; + } + + ns_lwdclient_log(50, "opcode %08x", client->pkt.opcode); + + switch (client->pkt.opcode) { + case LWRES_OPCODE_GETADDRSBYNAME: + ns_lwdclient_processgabn(client, &b); + return; + case LWRES_OPCODE_GETNAMEBYADDR: + ns_lwdclient_processgnba(client, &b); + return; + case LWRES_OPCODE_GETRDATABYNAME: + ns_lwdclient_processgrbn(client, &b); + return; + case LWRES_OPCODE_NOOP: + ns_lwdclient_processnoop(client, &b); + return; + default: + ns_lwdclient_log(50, "unknown opcode %08x", client->pkt.opcode); + goto restart; + } + + /* + * Drop the packet. + */ + restart: + ns_lwdclient_log(50, "restarting client %p...", client); + ns_lwdclient_stateidle(client); +} + +void +ns_lwdclient_recv(isc_task_t *task, isc_event_t *ev) { + isc_result_t result; + ns_lwdclient_t *client = ev->ev_arg; + ns_lwdclientmgr_t *cm = client->clientmgr; + isc_socketevent_t *dev = (isc_socketevent_t *)ev; + + INSIST(dev->region.base == client->buffer); + INSIST(NS_LWDCLIENT_ISRECV(client)); + + NS_LWDCLIENT_SETRECVDONE(client); + + INSIST((cm->flags & NS_LWDCLIENTMGR_FLAGRECVPENDING) != 0); + cm->flags &= ~NS_LWDCLIENTMGR_FLAGRECVPENDING; + + ns_lwdclient_log(50, + "event received: task %p, length %u, result %u (%s)", + task, dev->n, dev->result, + isc_result_totext(dev->result)); + + if (dev->result != ISC_R_SUCCESS) { + isc_event_free(&ev); + dev = NULL; + + /* + * Go idle. + */ + ns_lwdclient_stateidle(client); + + return; + } + + client->recvlength = dev->n; + client->address = dev->address; + if ((dev->attributes & ISC_SOCKEVENTATTR_PKTINFO) != 0) { + client->pktinfo = dev->pktinfo; + client->pktinfo_valid = ISC_TRUE; + } else + client->pktinfo_valid = ISC_FALSE; + isc_event_free(&ev); + dev = NULL; + + result = ns_lwdclient_startrecv(cm); + if (result != ISC_R_SUCCESS) + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_ERROR, + "could not start lwres " + "client handler: %s", + isc_result_totext(result)); + + process_request(client); +} + +/* + * This function will start a new recv() on a socket for this client manager. + */ +isc_result_t +ns_lwdclient_startrecv(ns_lwdclientmgr_t *cm) { + ns_lwdclient_t *client; + isc_result_t result; + isc_region_t r; + + if (SHUTTINGDOWN(cm)) { + lwdclientmgr_destroy(cm); + return (ISC_R_SUCCESS); + } + + /* + * If a recv is already running, don't bother. + */ + if ((cm->flags & NS_LWDCLIENTMGR_FLAGRECVPENDING) != 0) + return (ISC_R_SUCCESS); + + /* + * If we have no idle slots, just return success. + */ + client = ISC_LIST_HEAD(cm->idle); + if (client == NULL) + return (ISC_R_SUCCESS); + INSIST(NS_LWDCLIENT_ISIDLE(client)); + + /* + * Issue the recv. If it fails, return that it did. + */ + r.base = client->buffer; + r.length = LWRES_RECVLENGTH; + result = isc_socket_recv(cm->sock, &r, 0, cm->task, ns_lwdclient_recv, + client); + if (result != ISC_R_SUCCESS) + return (result); + + /* + * Set the flag to say we've issued a recv() call. + */ + cm->flags |= NS_LWDCLIENTMGR_FLAGRECVPENDING; + + /* + * Remove the client from the idle list, and put it on the running + * list. + */ + NS_LWDCLIENT_SETRECV(client); + ISC_LIST_UNLINK(cm->idle, client, link); + ISC_LIST_APPEND(cm->running, client, link); + + return (ISC_R_SUCCESS); +} + +static void +lwdclientmgr_shutdown_callback(isc_task_t *task, isc_event_t *ev) { + ns_lwdclientmgr_t *cm = ev->ev_arg; + ns_lwdclient_t *client; + + REQUIRE(!SHUTTINGDOWN(cm)); + + ns_lwdclient_log(50, "got shutdown event, task %p, lwdclientmgr %p", + task, cm); + + /* + * run through the idle list and free the clients there. Idle + * clients do not have a recv running nor do they have any finds + * or similar running. + */ + client = ISC_LIST_HEAD(cm->idle); + while (client != NULL) { + ns_lwdclient_log(50, "destroying client %p, manager %p", + client, cm); + ISC_LIST_UNLINK(cm->idle, client, link); + isc_mem_put(cm->mctx, client, sizeof(*client)); + client = ISC_LIST_HEAD(cm->idle); + } + + /* + * Cancel any pending I/O. + */ + isc_socket_cancel(cm->sock, task, ISC_SOCKCANCEL_ALL); + + /* + * Run through the running client list and kill off any finds + * in progress. + */ + client = ISC_LIST_HEAD(cm->running); + while (client != NULL) { + if (client->find != client->v4find + && client->find != client->v6find) + dns_adb_cancelfind(client->find); + if (client->v4find != NULL) + dns_adb_cancelfind(client->v4find); + if (client->v6find != NULL) + dns_adb_cancelfind(client->v6find); + client = ISC_LIST_NEXT(client, link); + } + + cm->flags |= NS_LWDCLIENTMGR_FLAGSHUTTINGDOWN; + + isc_event_free(&ev); +} + +/* + * Do all the crap needed to move a client from the run queue to the idle + * queue. + */ +void +ns_lwdclient_stateidle(ns_lwdclient_t *client) { + ns_lwdclientmgr_t *cm; + isc_result_t result; + + cm = client->clientmgr; + + INSIST(client->sendbuf == NULL); + INSIST(client->sendlength == 0); + INSIST(client->arg == NULL); + INSIST(client->v4find == NULL); + INSIST(client->v6find == NULL); + + ISC_LIST_UNLINK(cm->running, client, link); + ISC_LIST_PREPEND(cm->idle, client, link); + + NS_LWDCLIENT_SETIDLE(client); + + result = ns_lwdclient_startrecv(cm); + if (result != ISC_R_SUCCESS) + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_ERROR, + "could not start lwres " + "client handler: %s", + isc_result_totext(result)); +} + +void +ns_lwdclient_send(isc_task_t *task, isc_event_t *ev) { + ns_lwdclient_t *client = ev->ev_arg; + ns_lwdclientmgr_t *cm = client->clientmgr; + isc_socketevent_t *dev = (isc_socketevent_t *)ev; + + UNUSED(task); + UNUSED(dev); + + INSIST(NS_LWDCLIENT_ISSEND(client)); + INSIST(client->sendbuf == dev->region.base); + + ns_lwdclient_log(50, "task %p for client %p got send-done event", + task, client); + + if (client->sendbuf != client->buffer) + lwres_context_freemem(cm->lwctx, client->sendbuf, + client->sendlength); + client->sendbuf = NULL; + client->sendlength = 0; + + ns_lwdclient_stateidle(client); + + isc_event_free(&ev); +} + +isc_result_t +ns_lwdclient_sendreply(ns_lwdclient_t *client, isc_region_t *r) { + struct in6_pktinfo *pktinfo; + ns_lwdclientmgr_t *cm = client->clientmgr; + + if (client->pktinfo_valid) + pktinfo = &client->pktinfo; + else + pktinfo = NULL; + return (isc_socket_sendto(cm->sock, r, cm->task, ns_lwdclient_send, + client, &client->address, pktinfo)); +} + +void +ns_lwdclient_initialize(ns_lwdclient_t *client, ns_lwdclientmgr_t *cmgr) { + client->clientmgr = cmgr; + ISC_LINK_INIT(client, link); + NS_LWDCLIENT_SETIDLE(client); + client->arg = NULL; + + client->recvlength = 0; + + client->sendbuf = NULL; + client->sendlength = 0; + + client->find = NULL; + client->v4find = NULL; + client->v6find = NULL; + client->find_wanted = 0; + + client->options = 0; + client->byaddr = NULL; + + client->lookup = NULL; + + client->pktinfo_valid = ISC_FALSE; + + ISC_LIST_APPEND(cmgr->idle, client, link); +} diff --git a/contrib/bind9/bin/named/lwderror.c b/contrib/bind9/bin/named/lwderror.c new file mode 100644 index 000000000000..51cecf0abd57 --- /dev/null +++ b/contrib/bind9/bin/named/lwderror.c @@ -0,0 +1,78 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwderror.c,v 1.7.208.1 2004/03/06 10:21:18 marka Exp $ */ + +#include + +#include +#include + +#include +#include + +/* + * Generate an error packet for the client, schedule a send, and put us in + * the SEND state. + * + * The client->pkt structure will be modified to form an error return. + * The receiver needs to verify that it is in fact an error, and do the + * right thing with it. The opcode will be unchanged. The result needs + * to be set before calling this function. + * + * The only change this code makes is to set the receive buffer size to the + * size we use, set the reply bit, and recompute any security information. + */ +void +ns_lwdclient_errorpktsend(ns_lwdclient_t *client, isc_uint32_t _result) { + isc_result_t result; + int lwres; + isc_region_t r; + lwres_buffer_t b; + + REQUIRE(NS_LWDCLIENT_ISRUNNING(client)); + + /* + * Since we are only sending the packet header, we can safely toss + * the receive buffer. This means we won't need to allocate space + * for sending an error reply. This is a Good Thing. + */ + client->pkt.length = LWRES_LWPACKET_LENGTH; + client->pkt.pktflags |= LWRES_LWPACKETFLAG_RESPONSE; + client->pkt.recvlength = LWRES_RECVLENGTH; + client->pkt.authtype = 0; /* XXXMLG */ + client->pkt.authlength = 0; + client->pkt.result = _result; + + lwres_buffer_init(&b, client->buffer, LWRES_RECVLENGTH); + lwres = lwres_lwpacket_renderheader(&b, &client->pkt); + if (lwres != LWRES_R_SUCCESS) { + ns_lwdclient_stateidle(client); + return; + } + + r.base = client->buffer; + r.length = b.used; + client->sendbuf = client->buffer; + result = ns_lwdclient_sendreply(client, &r); + if (result != ISC_R_SUCCESS) { + ns_lwdclient_stateidle(client); + return; + } + + NS_LWDCLIENT_SETSEND(client); +} diff --git a/contrib/bind9/bin/named/lwdgabn.c b/contrib/bind9/bin/named/lwdgabn.c new file mode 100644 index 000000000000..030a77ae7864 --- /dev/null +++ b/contrib/bind9/bin/named/lwdgabn.c @@ -0,0 +1,655 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwdgabn.c,v 1.13.12.3 2004/03/08 04:04:19 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include /* Required for HP/UX (and others?) */ +#include + +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#define NEED_V4(c) ((((c)->find_wanted & LWRES_ADDRTYPE_V4) != 0) \ + && ((c)->v4find == NULL)) +#define NEED_V6(c) ((((c)->find_wanted & LWRES_ADDRTYPE_V6) != 0) \ + && ((c)->v6find == NULL)) + +static isc_result_t start_find(ns_lwdclient_t *); +static void restart_find(ns_lwdclient_t *); +static void init_gabn(ns_lwdclient_t *); + +/* + * Destroy any finds. This can be used to "start over from scratch" and + * should only be called when events are _not_ being generated by the finds. + */ +static void +cleanup_gabn(ns_lwdclient_t *client) { + ns_lwdclient_log(50, "cleaning up client %p", client); + + if (client->v6find != NULL) { + if (client->v6find == client->v4find) + client->v6find = NULL; + else + dns_adb_destroyfind(&client->v6find); + } + if (client->v4find != NULL) + dns_adb_destroyfind(&client->v4find); +} + +static void +setup_addresses(ns_lwdclient_t *client, dns_adbfind_t *find, unsigned int at) { + dns_adbaddrinfo_t *ai; + lwres_addr_t *addr; + int af; + const struct sockaddr *sa; + isc_result_t result; + + if (at == DNS_ADBFIND_INET) + af = AF_INET; + else + af = AF_INET6; + + ai = ISC_LIST_HEAD(find->list); + while (ai != NULL && client->gabn.naddrs < LWRES_MAX_ADDRS) { + sa = &ai->sockaddr.type.sa; + if (sa->sa_family != af) + goto next; + + addr = &client->addrs[client->gabn.naddrs]; + + result = lwaddr_lwresaddr_fromsockaddr(addr, &ai->sockaddr); + if (result != ISC_R_SUCCESS) + goto next; + + ns_lwdclient_log(50, "adding address %p, family %d, length %d", + addr->address, addr->family, addr->length); + + client->gabn.naddrs++; + REQUIRE(!LWRES_LINK_LINKED(addr, link)); + LWRES_LIST_APPEND(client->gabn.addrs, addr, link); + + next: + ai = ISC_LIST_NEXT(ai, publink); + } +} + +typedef struct { + isc_netaddr_t address; + int rank; +} rankedaddress; + +static int +addr_compare(const void *av, const void *bv) { + const rankedaddress *a = (const rankedaddress *) av; + const rankedaddress *b = (const rankedaddress *) bv; + return (a->rank - b->rank); +} + +static void +sort_addresses(ns_lwdclient_t *client) { + unsigned int naddrs; + rankedaddress *addrs; + isc_netaddr_t remote; + dns_addressorderfunc_t order; + void *arg; + ns_lwresd_t *lwresd = client->clientmgr->listener->manager; + unsigned int i; + isc_result_t result; + + naddrs = client->gabn.naddrs; + + if (naddrs <= 1 || lwresd->view->sortlist == NULL) + return; + + addrs = isc_mem_get(lwresd->mctx, sizeof(rankedaddress) * naddrs); + if (addrs == NULL) + return; + + isc_netaddr_fromsockaddr(&remote, &client->address); + ns_sortlist_byaddrsetup(lwresd->view->sortlist, + &remote, &order, &arg); + if (order == NULL) { + isc_mem_put(lwresd->mctx, addrs, + sizeof(rankedaddress) * naddrs); + return; + } + for (i = 0; i < naddrs; i++) { + result = lwaddr_netaddr_fromlwresaddr(&addrs[i].address, + &client->addrs[i]); + INSIST(result == ISC_R_SUCCESS); + addrs[i].rank = (*order)(&addrs[i].address, arg); + } + qsort(addrs, naddrs, sizeof(rankedaddress), addr_compare); + for (i = 0; i < naddrs; i++) { + result = lwaddr_lwresaddr_fromnetaddr(&client->addrs[i], + &addrs[i].address); + INSIST(result == ISC_R_SUCCESS); + } + + isc_mem_put(lwresd->mctx, addrs, sizeof(rankedaddress) * naddrs); +} + +static void +generate_reply(ns_lwdclient_t *client) { + isc_result_t result; + int lwres; + isc_region_t r; + lwres_buffer_t lwb; + ns_lwdclientmgr_t *cm; + + cm = client->clientmgr; + lwb.base = NULL; + + ns_lwdclient_log(50, "generating gabn reply for client %p", client); + + /* + * We must make certain the client->find is not still active. + * If it is either the v4 or v6 answer, just set it to NULL and + * let the cleanup code destroy it. Otherwise, destroy it now. + */ + if (client->find == client->v4find || client->find == client->v6find) + client->find = NULL; + else + if (client->find != NULL) + dns_adb_destroyfind(&client->find); + + /* + * perhaps there are some here? + */ + if (NEED_V6(client) && client->v4find != NULL) + client->v6find = client->v4find; + + /* + * Run through the finds we have and wire them up to the gabn + * structure. + */ + LWRES_LIST_INIT(client->gabn.addrs); + if (client->v4find != NULL) + setup_addresses(client, client->v4find, DNS_ADBFIND_INET); + if (client->v6find != NULL) + setup_addresses(client, client->v6find, DNS_ADBFIND_INET6); + + /* + * If there are no addresses, try the next element in the search + * path, if there are any more. Otherwise, fall through into + * the error handling code below. + */ + if (client->gabn.naddrs == 0) { + do { + result = ns_lwsearchctx_next(&client->searchctx); + if (result == ISC_R_SUCCESS) { + cleanup_gabn(client); + result = start_find(client); + if (result == ISC_R_SUCCESS) + return; + } + } while (result == ISC_R_SUCCESS); + } + + /* + * Render the packet. + */ + client->pkt.recvlength = LWRES_RECVLENGTH; + client->pkt.authtype = 0; /* XXXMLG */ + client->pkt.authlength = 0; + + /* + * If there are no addresses, return failure. + */ + if (client->gabn.naddrs != 0) + client->pkt.result = LWRES_R_SUCCESS; + else + client->pkt.result = LWRES_R_NOTFOUND; + + sort_addresses(client); + + lwres = lwres_gabnresponse_render(cm->lwctx, &client->gabn, + &client->pkt, &lwb); + if (lwres != LWRES_R_SUCCESS) + goto out; + + r.base = lwb.base; + r.length = lwb.used; + client->sendbuf = r.base; + client->sendlength = r.length; + result = ns_lwdclient_sendreply(client, &r); + if (result != ISC_R_SUCCESS) + goto out; + + NS_LWDCLIENT_SETSEND(client); + + /* + * All done! + */ + cleanup_gabn(client); + + return; + + out: + cleanup_gabn(client); + + if (lwb.base != NULL) + lwres_context_freemem(client->clientmgr->lwctx, + lwb.base, lwb.length); + + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); +} + +/* + * Take the current real name, move it to an alias slot (if any are + * open) then put this new name in as the real name for the target. + * + * Return success if it can be rendered, otherwise failure. Note that + * not having enough alias slots open is NOT a failure. + */ +static isc_result_t +add_alias(ns_lwdclient_t *client) { + isc_buffer_t b; + isc_result_t result; + isc_uint16_t naliases; + + b = client->recv_buffer; + + /* + * Render the new name to the buffer. + */ + result = dns_name_totext(dns_fixedname_name(&client->target_name), + ISC_TRUE, &client->recv_buffer); + if (result != ISC_R_SUCCESS) + return (result); + + /* + * Are there any open slots? + */ + naliases = client->gabn.naliases; + if (naliases < LWRES_MAX_ALIASES) { + client->gabn.aliases[naliases] = client->gabn.realname; + client->gabn.aliaslen[naliases] = client->gabn.realnamelen; + client->gabn.naliases++; + } + + /* + * Save this name away as the current real name. + */ + client->gabn.realname = (char *)(b.base) + b.used; + client->gabn.realnamelen = client->recv_buffer.used - b.used; + + return (ISC_R_SUCCESS); +} + +static isc_result_t +store_realname(ns_lwdclient_t *client) { + isc_buffer_t b; + isc_result_t result; + dns_name_t *tname; + + b = client->recv_buffer; + + tname = dns_fixedname_name(&client->target_name); + result = ns_lwsearchctx_current(&client->searchctx, tname); + if (result != ISC_R_SUCCESS) + return (result); + + /* + * Render the new name to the buffer. + */ + result = dns_name_totext(tname, ISC_TRUE, &client->recv_buffer); + if (result != ISC_R_SUCCESS) + return (result); + + /* + * Save this name away as the current real name. + */ + client->gabn.realname = (char *) b.base + b.used; + client->gabn.realnamelen = client->recv_buffer.used - b.used; + + return (ISC_R_SUCCESS); +} + +static void +process_gabn_finddone(isc_task_t *task, isc_event_t *ev) { + ns_lwdclient_t *client = ev->ev_arg; + isc_eventtype_t evtype; + isc_boolean_t claimed; + + ns_lwdclient_log(50, "find done for task %p, client %p", task, client); + + evtype = ev->ev_type; + isc_event_free(&ev); + + /* + * No more info to be had? If so, we have all the good stuff + * right now, so we can render things. + */ + claimed = ISC_FALSE; + if (evtype == DNS_EVENT_ADBNOMOREADDRESSES) { + if (NEED_V4(client)) { + client->v4find = client->find; + claimed = ISC_TRUE; + } + if (NEED_V6(client)) { + client->v6find = client->find; + claimed = ISC_TRUE; + } + if (client->find != NULL) { + if (claimed) + client->find = NULL; + else + dns_adb_destroyfind(&client->find); + + } + generate_reply(client); + return; + } + + /* + * We probably don't need this find anymore. We're either going to + * reissue it, or an error occurred. Either way, we're done with + * it. + */ + if ((client->find != client->v4find) + && (client->find != client->v6find)) { + dns_adb_destroyfind(&client->find); + } else { + client->find = NULL; + } + + /* + * We have some new information we can gather. Run off and fetch + * it. + */ + if (evtype == DNS_EVENT_ADBMOREADDRESSES) { + restart_find(client); + return; + } + + /* + * An error or other strangeness happened. Drop this query. + */ + cleanup_gabn(client); + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); +} + +static void +restart_find(ns_lwdclient_t *client) { + unsigned int options; + isc_result_t result; + isc_boolean_t claimed; + + ns_lwdclient_log(50, "starting find for client %p", client); + + /* + * Issue a find for the name contained in the request. We won't + * set the bit that says "anything is good enough" -- we want it + * all. + */ + options = 0; + options |= DNS_ADBFIND_WANTEVENT; + options |= DNS_ADBFIND_RETURNLAME; + + /* + * Set the bits up here to mark that we want this address family + * and that we do not currently have a find pending. We will + * set that bit again below if it turns out we will get an event. + */ + if (NEED_V4(client)) + options |= DNS_ADBFIND_INET; + if (NEED_V6(client)) + options |= DNS_ADBFIND_INET6; + + find_again: + INSIST(client->find == NULL); + result = dns_adb_createfind(client->clientmgr->view->adb, + client->clientmgr->task, + process_gabn_finddone, client, + dns_fixedname_name(&client->target_name), + dns_rootname, options, 0, + dns_fixedname_name(&client->target_name), + client->clientmgr->view->dstport, + &client->find); + + /* + * Did we get an alias? If so, save it and re-issue the query. + */ + if (result == DNS_R_ALIAS) { + ns_lwdclient_log(50, "found alias, restarting query"); + dns_adb_destroyfind(&client->find); + cleanup_gabn(client); + result = add_alias(client); + if (result != ISC_R_SUCCESS) { + ns_lwdclient_log(50, + "out of buffer space adding alias"); + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); + return; + } + goto find_again; + } + + ns_lwdclient_log(50, "find returned %d (%s)", result, + isc_result_totext(result)); + + /* + * Did we get an error? + */ + if (result != ISC_R_SUCCESS) { + if (client->find != NULL) + dns_adb_destroyfind(&client->find); + cleanup_gabn(client); + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); + return; + } + + claimed = ISC_FALSE; + + /* + * Did we get our answer to V4 addresses? + */ + if (NEED_V4(client) + && ((client->find->query_pending & DNS_ADBFIND_INET) == 0)) { + ns_lwdclient_log(50, "client %p ipv4 satisfied by find %p", + client, client->find); + claimed = ISC_TRUE; + client->v4find = client->find; + } + + /* + * Did we get our answer to V6 addresses? + */ + if (NEED_V6(client) + && ((client->find->query_pending & DNS_ADBFIND_INET6) == 0)) { + ns_lwdclient_log(50, "client %p ipv6 satisfied by find %p", + client, client->find); + claimed = ISC_TRUE; + client->v6find = client->find; + } + + /* + * If we're going to get an event, set our internal pending flag + * and return. When we get an event back we'll do the right + * thing, basically by calling this function again, perhaps with a + * new target name. + * + * If we have both v4 and v6, and we are still getting an event, + * we have a programming error, so die hard. + */ + if ((client->find->options & DNS_ADBFIND_WANTEVENT) != 0) { + ns_lwdclient_log(50, "event will be sent"); + INSIST(client->v4find == NULL || client->v6find == NULL); + return; + } + ns_lwdclient_log(50, "no event will be sent"); + if (claimed) + client->find = NULL; + else + dns_adb_destroyfind(&client->find); + + /* + * We seem to have everything we asked for, or at least we are + * able to respond with things we've learned. + */ + + generate_reply(client); +} + +static isc_result_t +start_find(ns_lwdclient_t *client) { + isc_result_t result; + + /* + * Initialize the real name and alias arrays in the reply we're + * going to build up. + */ + init_gabn(client); + + result = store_realname(client); + if (result != ISC_R_SUCCESS) + return (result); + restart_find(client); + return (ISC_R_SUCCESS); + +} + +static void +init_gabn(ns_lwdclient_t *client) { + int i; + + /* + * Initialize the real name and alias arrays in the reply we're + * going to build up. + */ + for (i = 0; i < LWRES_MAX_ALIASES; i++) { + client->aliases[i] = NULL; + client->aliaslen[i] = 0; + } + for (i = 0; i < LWRES_MAX_ADDRS; i++) { + client->addrs[i].family = 0; + client->addrs[i].length = 0; + memset(client->addrs[i].address, 0, LWRES_ADDR_MAXLEN); + LWRES_LINK_INIT(&client->addrs[i], link); + } + + client->gabn.naliases = 0; + client->gabn.naddrs = 0; + client->gabn.realname = NULL; + client->gabn.aliases = client->aliases; + client->gabn.realnamelen = 0; + client->gabn.aliaslen = client->aliaslen; + LWRES_LIST_INIT(client->gabn.addrs); + client->gabn.base = NULL; + client->gabn.baselen = 0; + + /* + * Set up the internal buffer to point to the receive region. + */ + isc_buffer_init(&client->recv_buffer, client->buffer, LWRES_RECVLENGTH); +} + +/* + * When we are called, we can be assured that: + * + * client->sockaddr contains the address we need to reply to, + * + * client->pkt contains the packet header data, + * + * the packet "checks out" overall -- any MD5 hashes or crypto + * bits have been verified, + * + * "b" points to the remaining data after the packet header + * was parsed off. + * + * We are in a the RECVDONE state. + * + * From this state we will enter the SEND state if we happen to have + * everything we need or we need to return an error packet, or to the + * FINDWAIT state if we need to look things up. + */ +void +ns_lwdclient_processgabn(ns_lwdclient_t *client, lwres_buffer_t *b) { + isc_result_t result; + lwres_gabnrequest_t *req; + ns_lwdclientmgr_t *cm; + isc_buffer_t namebuf; + + REQUIRE(NS_LWDCLIENT_ISRECVDONE(client)); + + cm = client->clientmgr; + req = NULL; + + result = lwres_gabnrequest_parse(client->clientmgr->lwctx, + b, &client->pkt, &req); + if (result != LWRES_R_SUCCESS) + goto out; + if (req->name == NULL) + goto out; + + isc_buffer_init(&namebuf, req->name, req->namelen); + isc_buffer_add(&namebuf, req->namelen); + + dns_fixedname_init(&client->target_name); + dns_fixedname_init(&client->query_name); + result = dns_name_fromtext(dns_fixedname_name(&client->query_name), + &namebuf, NULL, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) + goto out; + ns_lwsearchctx_init(&client->searchctx, + cm->listener->manager->search, + dns_fixedname_name(&client->query_name), + cm->listener->manager->ndots); + ns_lwsearchctx_first(&client->searchctx); + + client->find_wanted = req->addrtypes; + ns_lwdclient_log(50, "client %p looking for addrtypes %08x", + client, client->find_wanted); + + /* + * We no longer need to keep this around. + */ + lwres_gabnrequest_free(client->clientmgr->lwctx, &req); + + /* + * Start the find. + */ + result = start_find(client); + if (result != ISC_R_SUCCESS) + goto out; + + return; + + /* + * We're screwed. Return an error packet to our caller. + */ + out: + if (req != NULL) + lwres_gabnrequest_free(client->clientmgr->lwctx, &req); + + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); +} diff --git a/contrib/bind9/bin/named/lwdgnba.c b/contrib/bind9/bin/named/lwdgnba.c new file mode 100644 index 000000000000..21ef804ac933 --- /dev/null +++ b/contrib/bind9/bin/named/lwdgnba.c @@ -0,0 +1,270 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwdgnba.c,v 1.13.2.1.2.5 2004/03/08 04:04:19 marka Exp $ */ + +#include + +#include +#include /* Required for HP/UX (and others?) */ +#include + +#include +#include +#include + +#include +#include + +static void start_byaddr(ns_lwdclient_t *); + +static void +byaddr_done(isc_task_t *task, isc_event_t *event) { + ns_lwdclient_t *client; + ns_lwdclientmgr_t *cm; + dns_byaddrevent_t *bevent; + int lwres; + lwres_buffer_t lwb; + dns_name_t *name; + isc_result_t result; + lwres_result_t lwresult; + isc_region_t r; + isc_buffer_t b; + lwres_gnbaresponse_t *gnba; + isc_uint16_t naliases; + + UNUSED(task); + + lwb.base = NULL; + client = event->ev_arg; + cm = client->clientmgr; + INSIST(client->byaddr == (dns_byaddr_t *)event->ev_sender); + + bevent = (dns_byaddrevent_t *)event; + gnba = &client->gnba; + + ns_lwdclient_log(50, "byaddr event result = %s", + isc_result_totext(bevent->result)); + + result = bevent->result; + if (result != ISC_R_SUCCESS) { + dns_byaddr_destroy(&client->byaddr); + isc_event_free(&event); + bevent = NULL; + + if (client->na.family != AF_INET6 || + (client->options & DNS_BYADDROPT_IPV6INT) != 0) { + if (result == DNS_R_NCACHENXDOMAIN || + result == DNS_R_NCACHENXRRSET || + result == DNS_R_NXDOMAIN || + result == DNS_R_NXRRSET) + lwresult = LWRES_R_NOTFOUND; + else + lwresult = LWRES_R_FAILURE; + ns_lwdclient_errorpktsend(client, lwresult); + return; + } + + /* + * Fall back to ip6.int reverse if the default ip6.arpa + * fails. + */ + client->options |= DNS_BYADDROPT_IPV6INT; + + start_byaddr(client); + return; + } + + for (name = ISC_LIST_HEAD(bevent->names); + name != NULL; + name = ISC_LIST_NEXT(name, link)) + { + b = client->recv_buffer; + + result = dns_name_totext(name, ISC_TRUE, &client->recv_buffer); + if (result != ISC_R_SUCCESS) + goto out; + ns_lwdclient_log(50, "found name '%.*s'", + (int)(client->recv_buffer.used - b.used), + (char *)(b.base) + b.used); + if (gnba->realname == NULL) { + gnba->realname = (char *)(b.base) + b.used; + gnba->realnamelen = client->recv_buffer.used - b.used; + } else { + naliases = gnba->naliases; + if (naliases >= LWRES_MAX_ALIASES) + break; + gnba->aliases[naliases] = (char *)(b.base) + b.used; + gnba->aliaslen[naliases] = + client->recv_buffer.used - b.used; + gnba->naliases++; + } + } + + dns_byaddr_destroy(&client->byaddr); + isc_event_free(&event); + + /* + * Render the packet. + */ + client->pkt.recvlength = LWRES_RECVLENGTH; + client->pkt.authtype = 0; /* XXXMLG */ + client->pkt.authlength = 0; + client->pkt.result = LWRES_R_SUCCESS; + + lwres = lwres_gnbaresponse_render(cm->lwctx, + gnba, &client->pkt, &lwb); + if (lwres != LWRES_R_SUCCESS) + goto out; + + r.base = lwb.base; + r.length = lwb.used; + client->sendbuf = r.base; + client->sendlength = r.length; + result = ns_lwdclient_sendreply(client, &r); + if (result != ISC_R_SUCCESS) + goto out; + + NS_LWDCLIENT_SETSEND(client); + + return; + + out: + if (client->byaddr != NULL) + dns_byaddr_destroy(&client->byaddr); + if (lwb.base != NULL) + lwres_context_freemem(cm->lwctx, + lwb.base, lwb.length); + + if (event != NULL) + isc_event_free(&event); +} + +static void +start_byaddr(ns_lwdclient_t *client) { + isc_result_t result; + ns_lwdclientmgr_t *cm; + + cm = client->clientmgr; + + INSIST(client->byaddr == NULL); + + result = dns_byaddr_create(cm->mctx, &client->na, cm->view, + client->options, cm->task, byaddr_done, + client, &client->byaddr); + if (result != ISC_R_SUCCESS) { + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); + return; + } +} + +static void +init_gnba(ns_lwdclient_t *client) { + int i; + + /* + * Initialize the real name and alias arrays in the reply we're + * going to build up. + */ + for (i = 0; i < LWRES_MAX_ALIASES; i++) { + client->aliases[i] = NULL; + client->aliaslen[i] = 0; + } + for (i = 0; i < LWRES_MAX_ADDRS; i++) { + client->addrs[i].family = 0; + client->addrs[i].length = 0; + memset(client->addrs[i].address, 0, LWRES_ADDR_MAXLEN); + LWRES_LINK_INIT(&client->addrs[i], link); + } + + client->gnba.naliases = 0; + client->gnba.realname = NULL; + client->gnba.aliases = client->aliases; + client->gnba.realnamelen = 0; + client->gnba.aliaslen = client->aliaslen; + client->gnba.base = NULL; + client->gnba.baselen = 0; + isc_buffer_init(&client->recv_buffer, client->buffer, LWRES_RECVLENGTH); +} + +void +ns_lwdclient_processgnba(ns_lwdclient_t *client, lwres_buffer_t *b) { + lwres_gnbarequest_t *req; + isc_result_t result; + isc_sockaddr_t sa; + ns_lwdclientmgr_t *cm; + + REQUIRE(NS_LWDCLIENT_ISRECVDONE(client)); + INSIST(client->byaddr == NULL); + + cm = client->clientmgr; + req = NULL; + + result = lwres_gnbarequest_parse(cm->lwctx, + b, &client->pkt, &req); + if (result != LWRES_R_SUCCESS) + goto out; + if (req->addr.address == NULL) + goto out; + + client->options = 0; + if (req->addr.family == LWRES_ADDRTYPE_V4) { + client->na.family = AF_INET; + if (req->addr.length != 4) + goto out; + memcpy(&client->na.type.in, req->addr.address, 4); + } else if (req->addr.family == LWRES_ADDRTYPE_V6) { + client->na.family = AF_INET6; + if (req->addr.length != 16) + goto out; + memcpy(&client->na.type.in6, req->addr.address, 16); + } else { + goto out; + } + isc_sockaddr_fromnetaddr(&sa, &client->na, 53); + + ns_lwdclient_log(50, "client %p looking for addrtype %08x", + client, req->addr.family); + + /* + * We no longer need to keep this around. + */ + lwres_gnbarequest_free(cm->lwctx, &req); + + /* + * Initialize the real name and alias arrays in the reply we're + * going to build up. + */ + init_gnba(client); + client->options = 0; + + /* + * Start the find. + */ + start_byaddr(client); + + return; + + /* + * We're screwed. Return an error packet to our caller. + */ + out: + if (req != NULL) + lwres_gnbarequest_free(cm->lwctx, &req); + + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); +} diff --git a/contrib/bind9/bin/named/lwdgrbn.c b/contrib/bind9/bin/named/lwdgrbn.c new file mode 100644 index 000000000000..665226539b4f --- /dev/null +++ b/contrib/bind9/bin/named/lwdgrbn.c @@ -0,0 +1,513 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001, 2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwdgrbn.c,v 1.11.208.3 2004/03/08 04:04:19 marka Exp $ */ + +#include + +#include +#include +#include /* Required for HP/UX (and others?) */ +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +static void start_lookup(ns_lwdclient_t *); + +static isc_result_t +fill_array(int *pos, dns_rdataset_t *rdataset, + int size, unsigned char **rdatas, lwres_uint16_t *rdatalen) +{ + dns_rdata_t rdata; + isc_result_t result; + isc_region_t r; + + UNUSED(size); + + dns_rdata_init(&rdata); + for (result = dns_rdataset_first(rdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(rdataset)) + { + INSIST(*pos < size); + dns_rdataset_current(rdataset, &rdata); + dns_rdata_toregion(&rdata, &r); + rdatas[*pos] = r.base; + rdatalen[*pos] = r.length; + dns_rdata_reset(&rdata); + (*pos)++; + } + if (result == ISC_R_NOMORE) + result = ISC_R_SUCCESS; + return (result); +} + +static isc_result_t +iterate_node(lwres_grbnresponse_t *grbn, dns_db_t *db, dns_dbnode_t *node, + isc_mem_t *mctx) +{ + int used = 0, count; + int size = 8, oldsize = 0; + unsigned char **rdatas = NULL, **oldrdatas = NULL, **newrdatas = NULL; + lwres_uint16_t *lens = NULL, *oldlens = NULL, *newlens = NULL; + dns_rdatasetiter_t *iter = NULL; + dns_rdataset_t set; + dns_ttl_t ttl = ISC_INT32_MAX; + lwres_uint32_t flags = LWRDATA_VALIDATED; + isc_result_t result = ISC_R_NOMEMORY; + + result = dns_db_allrdatasets(db, node, NULL, 0, &iter); + if (result != ISC_R_SUCCESS) + goto out; + + rdatas = isc_mem_get(mctx, size * sizeof(*rdatas)); + if (rdatas == NULL) + goto out; + lens = isc_mem_get(mctx, size * sizeof(*lens)); + if (lens == NULL) + goto out; + + for (result = dns_rdatasetiter_first(iter); + result == ISC_R_SUCCESS; + result = dns_rdatasetiter_next(iter)) + { + result = ISC_R_NOMEMORY; + dns_rdataset_init(&set); + dns_rdatasetiter_current(iter, &set); + + if (set.type != dns_rdatatype_rrsig) { + dns_rdataset_disassociate(&set); + continue; + } + + count = dns_rdataset_count(&set); + if (used + count > size) { + /* copy & reallocate */ + oldsize = size; + oldrdatas = rdatas; + oldlens = lens; + rdatas = NULL; + lens = NULL; + + size *= 2; + + rdatas = isc_mem_get(mctx, size * sizeof(*rdatas)); + if (rdatas == NULL) + goto out; + lens = isc_mem_get(mctx, size * sizeof(*lens)); + if (lens == NULL) + goto out; + memcpy(rdatas, oldrdatas, used * sizeof(*rdatas)); + memcpy(lens, oldlens, used * sizeof(*lens)); + isc_mem_put(mctx, oldrdatas, + oldsize * sizeof(*oldrdatas)); + isc_mem_put(mctx, oldlens, oldsize * sizeof(*oldlens)); + oldrdatas = NULL; + oldlens = NULL; + } + if (set.ttl < ttl) + ttl = set.ttl; + if (set.trust != dns_trust_secure) + flags &= (~LWRDATA_VALIDATED); + result = fill_array(&used, &set, size, rdatas, lens); + dns_rdataset_disassociate(&set); + if (result != ISC_R_SUCCESS) + goto out; + } + if (result == ISC_R_NOMORE) + result = ISC_R_SUCCESS; + if (result != ISC_R_SUCCESS) + goto out; + dns_rdatasetiter_destroy(&iter); + + /* + * If necessary, shrink and copy the arrays. + */ + if (size != used) { + result = ISC_R_NOMEMORY; + newrdatas = isc_mem_get(mctx, used * sizeof(*rdatas)); + if (newrdatas == NULL) + goto out; + newlens = isc_mem_get(mctx, used * sizeof(*lens)); + if (newlens == NULL) + goto out; + memcpy(newrdatas, rdatas, used * sizeof(*rdatas)); + memcpy(newlens, lens, used * sizeof(*lens)); + isc_mem_put(mctx, rdatas, size * sizeof(*rdatas)); + isc_mem_put(mctx, lens, size * sizeof(*lens)); + grbn->rdatas = newrdatas; + grbn->rdatalen = newlens; + } else { + grbn->rdatas = rdatas; + grbn->rdatalen = lens; + } + grbn->nrdatas = used; + grbn->ttl = ttl; + grbn->flags = flags; + return (ISC_R_SUCCESS); + + out: + dns_rdatasetiter_destroy(&iter); + if (rdatas != NULL) + isc_mem_put(mctx, rdatas, size * sizeof(*rdatas)); + if (lens != NULL) + isc_mem_put(mctx, lens, size * sizeof(*lens)); + if (oldrdatas != NULL) + isc_mem_put(mctx, oldrdatas, oldsize * sizeof(*oldrdatas)); + if (oldlens != NULL) + isc_mem_put(mctx, oldlens, oldsize * sizeof(*oldlens)); + if (newrdatas != NULL) + isc_mem_put(mctx, newrdatas, used * sizeof(*oldrdatas)); + if (newlens != NULL) + isc_mem_put(mctx, newlens, used * sizeof(*oldlens)); + return (result); +} + +static void +lookup_done(isc_task_t *task, isc_event_t *event) { + ns_lwdclient_t *client; + ns_lwdclientmgr_t *cm; + dns_lookupevent_t *levent; + lwres_buffer_t lwb; + dns_name_t *name; + dns_rdataset_t *rdataset; + dns_rdataset_t *sigrdataset; + isc_result_t result; + lwres_result_t lwresult; + isc_region_t r; + isc_buffer_t b; + lwres_grbnresponse_t *grbn; + int i; + + UNUSED(task); + + lwb.base = NULL; + client = event->ev_arg; + cm = client->clientmgr; + INSIST(client->lookup == (dns_lookup_t *)event->ev_sender); + + levent = (dns_lookupevent_t *)event; + grbn = &client->grbn; + + ns_lwdclient_log(50, "lookup event result = %s", + isc_result_totext(levent->result)); + + result = levent->result; + if (result != ISC_R_SUCCESS) { + dns_lookup_destroy(&client->lookup); + isc_event_free(&event); + levent = NULL; + + switch (result) { + case DNS_R_NXDOMAIN: + case DNS_R_NCACHENXDOMAIN: + result = ns_lwsearchctx_next(&client->searchctx); + if (result != ISC_R_SUCCESS) + lwresult = LWRES_R_NOTFOUND; + else { + start_lookup(client); + return; + } + break; + case DNS_R_NXRRSET: + case DNS_R_NCACHENXRRSET: + lwresult = LWRES_R_TYPENOTFOUND; + break; + default: + lwresult = LWRES_R_FAILURE; + } + ns_lwdclient_errorpktsend(client, lwresult); + return; + } + + name = levent->name; + b = client->recv_buffer; + + grbn->flags = 0; + + grbn->nrdatas = 0; + grbn->rdatas = NULL; + grbn->rdatalen = NULL; + + grbn->nsigs = 0; + grbn->sigs = NULL; + grbn->siglen = NULL; + + result = dns_name_totext(name, ISC_TRUE, &client->recv_buffer); + if (result != ISC_R_SUCCESS) + goto out; + grbn->realname = (char *)isc_buffer_used(&b); + grbn->realnamelen = isc_buffer_usedlength(&client->recv_buffer) - + isc_buffer_usedlength(&b); + ns_lwdclient_log(50, "found name '%.*s'", grbn->realnamelen, + grbn->realname); + + grbn->rdclass = cm->view->rdclass; + grbn->rdtype = client->rdtype; + + rdataset = levent->rdataset; + if (rdataset != NULL) { + /* The normal case */ + grbn->nrdatas = dns_rdataset_count(rdataset); + grbn->rdatas = isc_mem_get(cm->mctx, grbn->nrdatas * + sizeof(unsigned char *)); + if (grbn->rdatas == NULL) + goto out; + grbn->rdatalen = isc_mem_get(cm->mctx, grbn->nrdatas * + sizeof(lwres_uint16_t)); + if (grbn->rdatalen == NULL) + goto out; + + i = 0; + result = fill_array(&i, rdataset, grbn->nrdatas, grbn->rdatas, + grbn->rdatalen); + if (result != ISC_R_SUCCESS) + goto out; + INSIST(i == grbn->nrdatas); + grbn->ttl = rdataset->ttl; + if (rdataset->trust == dns_trust_secure) + grbn->flags |= LWRDATA_VALIDATED; + } else { + /* The SIG query case */ + result = iterate_node(grbn, levent->db, levent->node, + cm->mctx); + if (result != ISC_R_SUCCESS) + goto out; + } + ns_lwdclient_log(50, "filled in %d rdata%s", grbn->nrdatas, + (grbn->nrdatas == 1) ? "" : "s"); + + sigrdataset = levent->sigrdataset; + if (sigrdataset != NULL) { + grbn->nsigs = dns_rdataset_count(sigrdataset); + grbn->sigs = isc_mem_get(cm->mctx, grbn->nsigs * + sizeof(unsigned char *)); + if (grbn->sigs == NULL) + goto out; + grbn->siglen = isc_mem_get(cm->mctx, grbn->nsigs * + sizeof(lwres_uint16_t)); + if (grbn->siglen == NULL) + goto out; + + i = 0; + result = fill_array(&i, sigrdataset, grbn->nsigs, grbn->sigs, + grbn->siglen); + if (result != ISC_R_SUCCESS) + goto out; + INSIST(i == grbn->nsigs); + ns_lwdclient_log(50, "filled in %d signature%s", grbn->nsigs, + (grbn->nsigs == 1) ? "" : "s"); + } + + dns_lookup_destroy(&client->lookup); + isc_event_free(&event); + + /* + * Render the packet. + */ + client->pkt.recvlength = LWRES_RECVLENGTH; + client->pkt.authtype = 0; /* XXXMLG */ + client->pkt.authlength = 0; + client->pkt.result = LWRES_R_SUCCESS; + + lwresult = lwres_grbnresponse_render(cm->lwctx, + grbn, &client->pkt, &lwb); + if (lwresult != LWRES_R_SUCCESS) + goto out; + + isc_mem_put(cm->mctx, grbn->rdatas, + grbn->nrdatas * sizeof(unsigned char *)); + isc_mem_put(cm->mctx, grbn->rdatalen, + grbn->nrdatas * sizeof(lwres_uint16_t)); + + if (grbn->sigs != NULL) + isc_mem_put(cm->mctx, grbn->sigs, + grbn->nsigs * sizeof(unsigned char *)); + if (grbn->siglen != NULL) + isc_mem_put(cm->mctx, grbn->siglen, + grbn->nsigs * sizeof(lwres_uint16_t)); + + r.base = lwb.base; + r.length = lwb.used; + client->sendbuf = r.base; + client->sendlength = r.length; + result = ns_lwdclient_sendreply(client, &r); + if (result != ISC_R_SUCCESS) + goto out; + + NS_LWDCLIENT_SETSEND(client); + + return; + + out: + if (grbn->rdatas != NULL) + isc_mem_put(cm->mctx, grbn->rdatas, + grbn->nrdatas * sizeof(unsigned char *)); + if (grbn->rdatalen != NULL) + isc_mem_put(cm->mctx, grbn->rdatalen, + grbn->nrdatas * sizeof(lwres_uint16_t)); + + if (grbn->sigs != NULL) + isc_mem_put(cm->mctx, grbn->sigs, + grbn->nsigs * sizeof(unsigned char *)); + if (grbn->siglen != NULL) + isc_mem_put(cm->mctx, grbn->siglen, + grbn->nsigs * sizeof(lwres_uint16_t)); + + if (client->lookup != NULL) + dns_lookup_destroy(&client->lookup); + if (lwb.base != NULL) + lwres_context_freemem(cm->lwctx, lwb.base, lwb.length); + + if (event != NULL) + isc_event_free(&event); + + ns_lwdclient_log(50, "error constructing getrrsetbyname response"); + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); +} + +static void +start_lookup(ns_lwdclient_t *client) { + isc_result_t result; + ns_lwdclientmgr_t *cm; + dns_fixedname_t absname; + + cm = client->clientmgr; + + INSIST(client->lookup == NULL); + + dns_fixedname_init(&absname); + result = ns_lwsearchctx_current(&client->searchctx, + dns_fixedname_name(&absname)); + /* + * This will return failure if relative name + suffix is too long. + * In this case, just go on to the next entry in the search path. + */ + if (result != ISC_R_SUCCESS) + start_lookup(client); + + result = dns_lookup_create(cm->mctx, + dns_fixedname_name(&absname), + client->rdtype, cm->view, + client->options, cm->task, lookup_done, + client, &client->lookup); + if (result != ISC_R_SUCCESS) { + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); + return; + } +} + +static void +init_grbn(ns_lwdclient_t *client) { + client->grbn.rdclass = 0; + client->grbn.rdtype = 0; + client->grbn.ttl = 0; + client->grbn.nrdatas = 0; + client->grbn.realname = NULL; + client->grbn.realnamelen = 0; + client->grbn.rdatas = 0; + client->grbn.rdatalen = 0; + client->grbn.base = NULL; + client->grbn.baselen = 0; + isc_buffer_init(&client->recv_buffer, client->buffer, LWRES_RECVLENGTH); +} + +void +ns_lwdclient_processgrbn(ns_lwdclient_t *client, lwres_buffer_t *b) { + lwres_grbnrequest_t *req; + isc_result_t result; + ns_lwdclientmgr_t *cm; + isc_buffer_t namebuf; + + REQUIRE(NS_LWDCLIENT_ISRECVDONE(client)); + INSIST(client->byaddr == NULL); + + cm = client->clientmgr; + req = NULL; + + result = lwres_grbnrequest_parse(cm->lwctx, + b, &client->pkt, &req); + if (result != LWRES_R_SUCCESS) + goto out; + if (req->name == NULL) + goto out; + + client->options = 0; + if (req->rdclass != cm->view->rdclass) + goto out; + + if (req->rdclass == dns_rdataclass_any || + req->rdtype == dns_rdatatype_any) + goto out; + + client->rdtype = req->rdtype; + + isc_buffer_init(&namebuf, req->name, req->namelen); + isc_buffer_add(&namebuf, req->namelen); + + dns_fixedname_init(&client->query_name); + result = dns_name_fromtext(dns_fixedname_name(&client->query_name), + &namebuf, NULL, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) + goto out; + ns_lwsearchctx_init(&client->searchctx, + cm->listener->manager->search, + dns_fixedname_name(&client->query_name), + cm->listener->manager->ndots); + ns_lwsearchctx_first(&client->searchctx); + + ns_lwdclient_log(50, "client %p looking for type %d", + client, client->rdtype); + + /* + * We no longer need to keep this around. + */ + lwres_grbnrequest_free(cm->lwctx, &req); + + /* + * Initialize the real name and alias arrays in the reply we're + * going to build up. + */ + init_grbn(client); + + /* + * Start the find. + */ + start_lookup(client); + + return; + + /* + * We're screwed. Return an error packet to our caller. + */ + out: + if (req != NULL) + lwres_grbnrequest_free(cm->lwctx, &req); + + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); +} diff --git a/contrib/bind9/bin/named/lwdnoop.c b/contrib/bind9/bin/named/lwdnoop.c new file mode 100644 index 000000000000..30d95ee8d8e2 --- /dev/null +++ b/contrib/bind9/bin/named/lwdnoop.c @@ -0,0 +1,86 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwdnoop.c,v 1.6.208.1 2004/03/06 10:21:19 marka Exp $ */ + +#include + +#include +#include + +#include +#include + +void +ns_lwdclient_processnoop(ns_lwdclient_t *client, lwres_buffer_t *b) { + lwres_nooprequest_t *req; + lwres_noopresponse_t resp; + isc_result_t result; + lwres_result_t lwres; + isc_region_t r; + lwres_buffer_t lwb; + + REQUIRE(NS_LWDCLIENT_ISRECVDONE(client)); + INSIST(client->byaddr == NULL); + + req = NULL; + + result = lwres_nooprequest_parse(client->clientmgr->lwctx, + b, &client->pkt, &req); + if (result != LWRES_R_SUCCESS) + goto out; + + client->pkt.recvlength = LWRES_RECVLENGTH; + client->pkt.authtype = 0; /* XXXMLG */ + client->pkt.authlength = 0; + client->pkt.result = LWRES_R_SUCCESS; + + resp.datalength = req->datalength; + resp.data = req->data; + + lwres = lwres_noopresponse_render(client->clientmgr->lwctx, &resp, + &client->pkt, &lwb); + if (lwres != LWRES_R_SUCCESS) + goto out; + + r.base = lwb.base; + r.length = lwb.used; + client->sendbuf = r.base; + client->sendlength = r.length; + result = ns_lwdclient_sendreply(client, &r); + if (result != ISC_R_SUCCESS) + goto out; + + /* + * We can now destroy request. + */ + lwres_nooprequest_free(client->clientmgr->lwctx, &req); + + NS_LWDCLIENT_SETSEND(client); + + return; + + out: + if (req != NULL) + lwres_nooprequest_free(client->clientmgr->lwctx, &req); + + if (lwb.base != NULL) + lwres_context_freemem(client->clientmgr->lwctx, + lwb.base, lwb.length); + + ns_lwdclient_errorpktsend(client, LWRES_R_FAILURE); +} diff --git a/contrib/bind9/bin/named/lwresd.8 b/contrib/bind9/bin/named/lwresd.8 new file mode 100644 index 000000000000..bbc177d0ff69 --- /dev/null +++ b/contrib/bind9/bin/named/lwresd.8 @@ -0,0 +1,140 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: lwresd.8,v 1.13.208.2 2004/06/03 05:35:47 marka Exp $ +.\" +.TH "LWRESD" "8" "June 30, 2000" "BIND9" "" +.SH NAME +lwresd \- lightweight resolver daemon +.SH SYNOPSIS +.sp +\fBlwresd\fR [ \fB-C \fIconfig-file\fB\fR ] [ \fB-d \fIdebug-level\fB\fR ] [ \fB-f\fR ] [ \fB-g\fR ] [ \fB-i \fIpid-file\fB\fR ] [ \fB-n \fI#cpus\fB\fR ] [ \fB-P \fIport\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-s\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-u \fIuser\fB\fR ] [ \fB-v\fR ] +.SH "DESCRIPTION" +.PP +\fBlwresd\fR is the daemon providing name lookup +services to clients that use the BIND 9 lightweight resolver +library. It is essentially a stripped-down, caching-only name +server that answers queries using the BIND 9 lightweight +resolver protocol rather than the DNS protocol. +.PP +\fBlwresd\fR listens for resolver queries on a +UDP port on the IPv4 loopback interface, 127.0.0.1. This +means that \fBlwresd\fR can only be used by +processes running on the local machine. By default UDP port +number 921 is used for lightweight resolver requests and +responses. +.PP +Incoming lightweight resolver requests are decoded by the +server which then resolves them using the DNS protocol. When +the DNS lookup completes, \fBlwresd\fR encodes +the answers in the lightweight resolver format and returns +them to the client that made the request. +.PP +If \fI/etc/resolv.conf\fR contains any +\fBnameserver\fR entries, \fBlwresd\fR +sends recursive DNS queries to those servers. This is similar +to the use of forwarders in a caching name server. If no +\fBnameserver\fR entries are present, or if +forwarding fails, \fBlwresd\fR resolves the +queries autonomously starting at the root name servers, using +a built-in list of root server hints. +.SH "OPTIONS" +.TP +\fB-C \fIconfig-file\fB\fR +Use \fIconfig-file\fR as the +configuration file instead of the default, +\fI/etc/resolv.conf\fR. +.TP +\fB-d \fIdebug-level\fB\fR +Set the daemon's debug level to \fIdebug-level\fR. +Debugging traces from \fBlwresd\fR become +more verbose as the debug level increases. +.TP +\fB-f\fR +Run the server in the foreground (i.e. do not daemonize). +.TP +\fB-g\fR +Run the server in the foreground and force all logging +to \fIstderr\fR. +.TP +\fB-n \fI#cpus\fB\fR +Create \fI#cpus\fR worker threads +to take advantage of multiple CPUs. If not specified, +\fBlwresd\fR will try to determine the +number of CPUs present and create one thread per CPU. +If it is unable to determine the number of CPUs, a +single worker thread will be created. +.TP +\fB-P \fIport\fB\fR +Listen for lightweight resolver queries on port +\fIport\fR. If +not specified, the default is port 921. +.TP +\fB-p \fIport\fB\fR +Send DNS lookups to port \fIport\fR. If not +specified, the default is port 53. This provides a +way of testing the lightweight resolver daemon with a +name server that listens for queries on a non-standard +port number. +.TP +\fB-s\fR +Write memory usage statistics to \fIstdout\fR +on exit. +.sp +.RS +.B "Note:" +This option is mainly of interest to BIND 9 developers +and may be removed or changed in a future release. +.RE +.sp +.TP +\fB-t \fIdirectory\fB\fR +\fBchroot()\fR to \fIdirectory\fR after +processing the command line arguments, but before +reading the configuration file. +.sp +.RS +.B "Warning:" +This option should be used in conjunction with the +\fB-u\fR option, as chrooting a process +running as root doesn't enhance security on most +systems; the way \fBchroot()\fR is +defined allows a process with root privileges to +escape a chroot jail. +.RE +.sp +.TP +\fB-u \fIuser\fB\fR +\fBsetuid()\fR to \fIuser\fR after completing +privileged operations, such as creating sockets that +listen on privileged ports. +.TP +\fB-v\fR +Report the version number and exit. +.SH "FILES" +.TP +\fB\fI/etc/resolv.conf\fB\fR +The default configuration file. +.TP +\fB\fI/var/run/lwresd.pid\fB\fR +The default process-id file. +.SH "SEE ALSO" +.PP +\fBnamed\fR(8), +\fBlwres\fR(3), +\fBresolver\fR(5). +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/named/lwresd.c b/contrib/bind9/bin/named/lwresd.c new file mode 100644 index 000000000000..9da41681a533 --- /dev/null +++ b/contrib/bind9/bin/named/lwresd.c @@ -0,0 +1,861 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwresd.c,v 1.37.2.2.2.5 2004/03/08 04:04:19 marka Exp $ */ + +/* + * Main program for the Lightweight Resolver Daemon. + * + * To paraphrase the old saying about X11, "It's not a lightweight deamon + * for resolvers, it's a deamon for lightweight resolvers". + */ + +#include + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#define LWRESD_MAGIC ISC_MAGIC('L', 'W', 'R', 'D') +#define VALID_LWRESD(l) ISC_MAGIC_VALID(l, LWRESD_MAGIC) + +#define LWRESLISTENER_MAGIC ISC_MAGIC('L', 'W', 'R', 'L') +#define VALID_LWRESLISTENER(l) ISC_MAGIC_VALID(l, LWRESLISTENER_MAGIC) + +/* + * The total number of clients we can handle will be NTASKS * NRECVS. + */ +#define NTASKS 2 /* tasks to create to handle lwres queries */ +#define NRECVS 2 /* max clients per task */ + +typedef ISC_LIST(ns_lwreslistener_t) ns_lwreslistenerlist_t; + +static ns_lwreslistenerlist_t listeners; +static isc_mutex_t listeners_lock; +static isc_once_t once = ISC_ONCE_INIT; + + +static void +initialize_mutex(void) { + RUNTIME_CHECK(isc_mutex_init(&listeners_lock) == ISC_R_SUCCESS); +} + + +/* + * Wrappers around our memory management stuff, for the lwres functions. + */ +void * +ns__lwresd_memalloc(void *arg, size_t size) { + return (isc_mem_get(arg, size)); +} + +void +ns__lwresd_memfree(void *arg, void *mem, size_t size) { + isc_mem_put(arg, mem, size); +} + + +#define CHECK(op) \ + do { result = (op); \ + if (result != ISC_R_SUCCESS) goto cleanup; \ + } while (0) + +static isc_result_t +buffer_putstr(isc_buffer_t *b, const char *s) { + unsigned int len = strlen(s); + if (isc_buffer_availablelength(b) <= len) + return (ISC_R_NOSPACE); + isc_buffer_putmem(b, (const unsigned char *)s, len); + return (ISC_R_SUCCESS); +} + +/* + * Convert a resolv.conf file into a config structure. + */ +isc_result_t +ns_lwresd_parseeresolvconf(isc_mem_t *mctx, cfg_parser_t *pctx, + cfg_obj_t **configp) +{ + char text[4096]; + char str[16]; + isc_buffer_t b; + lwres_context_t *lwctx = NULL; + lwres_conf_t *lwc = NULL; + isc_sockaddr_t sa; + isc_netaddr_t na; + int i; + isc_result_t result; + lwres_result_t lwresult; + + lwctx = NULL; + lwresult = lwres_context_create(&lwctx, mctx, ns__lwresd_memalloc, + ns__lwresd_memfree, + LWRES_CONTEXT_SERVERMODE); + if (lwresult != LWRES_R_SUCCESS) { + result = ISC_R_NOMEMORY; + goto cleanup; + } + + lwresult = lwres_conf_parse(lwctx, lwresd_g_resolvconffile); + if (lwresult != LWRES_R_SUCCESS) { + result = DNS_R_SYNTAX; + goto cleanup; + } + + lwc = lwres_conf_get(lwctx); + INSIST(lwc != NULL); + + isc_buffer_init(&b, text, sizeof(text)); + + CHECK(buffer_putstr(&b, "options {\n")); + + /* + * Build the list of forwarders. + */ + if (lwc->nsnext > 0) { + CHECK(buffer_putstr(&b, "\tforwarders {\n")); + + for (i = 0; i < lwc->nsnext; i++) { + CHECK(lwaddr_sockaddr_fromlwresaddr( + &sa, + &lwc->nameservers[i], + ns_g_port)); + isc_netaddr_fromsockaddr(&na, &sa); + CHECK(buffer_putstr(&b, "\t\t")); + CHECK(isc_netaddr_totext(&na, &b)); + CHECK(buffer_putstr(&b, ";\n")); + } + CHECK(buffer_putstr(&b, "\t};\n")); + } + + /* + * Build the sortlist + */ + if (lwc->sortlistnxt > 0) { + CHECK(buffer_putstr(&b, "\tsortlist {\n")); + CHECK(buffer_putstr(&b, "\t\t{\n")); + CHECK(buffer_putstr(&b, "\t\t\tany;\n")); + CHECK(buffer_putstr(&b, "\t\t\t{\n")); + for (i = 0; i < lwc->sortlistnxt; i++) { + lwres_addr_t *lwaddr = &lwc->sortlist[i].addr; + lwres_addr_t *lwmask = &lwc->sortlist[i].mask; + unsigned int mask; + + CHECK(lwaddr_sockaddr_fromlwresaddr(&sa, lwmask, 0)); + isc_netaddr_fromsockaddr(&na, &sa); + result = isc_netaddr_masktoprefixlen(&na, &mask); + if (result != ISC_R_SUCCESS) { + char addrtext[ISC_NETADDR_FORMATSIZE]; + isc_netaddr_format(&na, addrtext, + sizeof(addrtext)); + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, + ISC_LOG_ERROR, + "processing sortlist: '%s' is " + "not a valid netmask", + addrtext); + goto cleanup; + } + + CHECK(lwaddr_sockaddr_fromlwresaddr(&sa, lwaddr, 0)); + isc_netaddr_fromsockaddr(&na, &sa); + + CHECK(buffer_putstr(&b, "\t\t\t\t")); + CHECK(isc_netaddr_totext(&na, &b)); + snprintf(str, sizeof(str), "%u", mask); + CHECK(buffer_putstr(&b, "/")); + CHECK(buffer_putstr(&b, str)); + CHECK(buffer_putstr(&b, ";\n")); + } + CHECK(buffer_putstr(&b, "\t\t\t};\n")); + CHECK(buffer_putstr(&b, "\t\t};\n")); + CHECK(buffer_putstr(&b, "\t};\n")); + } + + CHECK(buffer_putstr(&b, "};\n\n")); + + CHECK(buffer_putstr(&b, "lwres {\n")); + + /* + * Build the search path + */ + if (lwc->searchnxt > 0) { + if (lwc->searchnxt > 0) { + CHECK(buffer_putstr(&b, "\tsearch {\n")); + for (i = 0; i < lwc->searchnxt; i++) { + CHECK(buffer_putstr(&b, "\t\t\"")); + CHECK(buffer_putstr(&b, lwc->search[i])); + CHECK(buffer_putstr(&b, "\";\n")); + } + CHECK(buffer_putstr(&b, "\t};\n")); + } + } + + /* + * Build the ndots line + */ + if (lwc->ndots != 1) { + CHECK(buffer_putstr(&b, "\tndots ")); + snprintf(str, sizeof(str), "%u", lwc->ndots); + CHECK(buffer_putstr(&b, str)); + CHECK(buffer_putstr(&b, ";\n")); + } + + /* + * Build the listen-on line + */ + if (lwc->lwnext > 0) { + CHECK(buffer_putstr(&b, "\tlisten-on {\n")); + + for (i = 0; i < lwc->lwnext; i++) { + CHECK(lwaddr_sockaddr_fromlwresaddr(&sa, + &lwc->lwservers[i], + 0)); + isc_netaddr_fromsockaddr(&na, &sa); + CHECK(buffer_putstr(&b, "\t\t")); + CHECK(isc_netaddr_totext(&na, &b)); + CHECK(buffer_putstr(&b, ";\n")); + } + CHECK(buffer_putstr(&b, "\t};\n")); + } + + CHECK(buffer_putstr(&b, "};\n")); + +#if 0 + printf("%.*s\n", + (int)isc_buffer_usedlength(&b), + (char *)isc_buffer_base(&b)); +#endif + + lwres_conf_clear(lwctx); + lwres_context_destroy(&lwctx); + + return (cfg_parse_buffer(pctx, &b, &cfg_type_namedconf, configp)); + + cleanup: + + if (lwctx != NULL) { + lwres_conf_clear(lwctx); + lwres_context_destroy(&lwctx); + } + + return (result); +} + + +/* + * Handle lwresd manager objects + */ +isc_result_t +ns_lwdmanager_create(isc_mem_t *mctx, cfg_obj_t *lwres, + ns_lwresd_t **lwresdp) +{ + ns_lwresd_t *lwresd; + const char *vname; + dns_rdataclass_t vclass; + cfg_obj_t *obj, *viewobj, *searchobj; + cfg_listelt_t *element; + isc_result_t result; + + INSIST(lwresdp != NULL && *lwresdp == NULL); + + lwresd = isc_mem_get(mctx, sizeof(ns_lwresd_t)); + if (lwresd == NULL) + return (ISC_R_NOMEMORY); + + lwresd->mctx = NULL; + isc_mem_attach(mctx, &lwresd->mctx); + lwresd->view = NULL; + lwresd->search = NULL; + lwresd->refs = 1; + + obj = NULL; + (void)cfg_map_get(lwres, "ndots", &obj); + if (obj != NULL) + lwresd->ndots = cfg_obj_asuint32(obj); + else + lwresd->ndots = 1; + + RUNTIME_CHECK(isc_mutex_init(&lwresd->lock) == ISC_R_SUCCESS); + + lwresd->shutting_down = ISC_FALSE; + + viewobj = NULL; + (void)cfg_map_get(lwres, "view", &viewobj); + if (viewobj != NULL) { + vname = cfg_obj_asstring(cfg_tuple_get(viewobj, "name")); + obj = cfg_tuple_get(viewobj, "class"); + result = ns_config_getclass(obj, dns_rdataclass_in, &vclass); + if (result != ISC_R_SUCCESS) + goto fail; + } else { + vname = "_default"; + vclass = dns_rdataclass_in; + } + + result = dns_viewlist_find(&ns_g_server->viewlist, vname, vclass, + &lwresd->view); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_WARNING, + "couldn't find view %s", vname); + goto fail; + } + + searchobj = NULL; + (void)cfg_map_get(lwres, "search", &searchobj); + if (searchobj != NULL) { + lwresd->search = NULL; + result = ns_lwsearchlist_create(lwresd->mctx, + &lwresd->search); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_WARNING, + "couldn't create searchlist"); + goto fail; + } + for (element = cfg_list_first(searchobj); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *search; + char *searchstr; + isc_buffer_t namebuf; + dns_fixedname_t fname; + dns_name_t *name; + + search = cfg_listelt_value(element); + searchstr = cfg_obj_asstring(search); + + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + isc_buffer_init(&namebuf, searchstr, + strlen(searchstr)); + isc_buffer_add(&namebuf, strlen(searchstr)); + result = dns_name_fromtext(name, &namebuf, + dns_rootname, ISC_FALSE, + NULL); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, + ISC_LOG_WARNING, + "invalid name %s in searchlist", + searchstr); + continue; + } + + result = ns_lwsearchlist_append(lwresd->search, name); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, + ISC_LOG_WARNING, + "couldn't update searchlist"); + goto fail; + } + } + } + + lwresd->magic = LWRESD_MAGIC; + + *lwresdp = lwresd; + return (ISC_R_SUCCESS); + + fail: + if (lwresd->view != NULL) + dns_view_detach(&lwresd->view); + if (lwresd->search != NULL) + ns_lwsearchlist_detach(&lwresd->search); + if (lwresd->mctx != NULL) + isc_mem_detach(&lwresd->mctx); + return (result); +} + +void +ns_lwdmanager_attach(ns_lwresd_t *source, ns_lwresd_t **targetp) { + INSIST(VALID_LWRESD(source)); + INSIST(targetp != NULL && *targetp == NULL); + + LOCK(&source->lock); + source->refs++; + UNLOCK(&source->lock); + + *targetp = source; +} + +void +ns_lwdmanager_detach(ns_lwresd_t **lwresdp) { + ns_lwresd_t *lwresd; + isc_mem_t *mctx; + isc_boolean_t done = ISC_FALSE; + + INSIST(lwresdp != NULL && *lwresdp != NULL); + INSIST(VALID_LWRESD(*lwresdp)); + + lwresd = *lwresdp; + *lwresdp = NULL; + + LOCK(&lwresd->lock); + INSIST(lwresd->refs > 0); + lwresd->refs--; + if (lwresd->refs == 0) + done = ISC_TRUE; + UNLOCK(&lwresd->lock); + + if (!done) + return; + + dns_view_detach(&lwresd->view); + if (lwresd->search != NULL) + ns_lwsearchlist_detach(&lwresd->search); + mctx = lwresd->mctx; + lwresd->magic = 0; + isc_mem_put(mctx, lwresd, sizeof(*lwresd)); + isc_mem_detach(&mctx); +} + + +/* + * Handle listener objects + */ +void +ns_lwreslistener_attach(ns_lwreslistener_t *source, + ns_lwreslistener_t **targetp) +{ + INSIST(VALID_LWRESLISTENER(source)); + INSIST(targetp != NULL && *targetp == NULL); + + LOCK(&source->lock); + source->refs++; + UNLOCK(&source->lock); + + *targetp = source; +} + +void +ns_lwreslistener_detach(ns_lwreslistener_t **listenerp) { + ns_lwreslistener_t *listener; + isc_mem_t *mctx; + isc_boolean_t done = ISC_FALSE; + + INSIST(listenerp != NULL && *listenerp != NULL); + INSIST(VALID_LWRESLISTENER(*listenerp)); + + listener = *listenerp; + + LOCK(&listener->lock); + INSIST(listener->refs > 0); + listener->refs--; + if (listener->refs == 0) + done = ISC_TRUE; + UNLOCK(&listener->lock); + + if (!done) + return; + + if (listener->manager != NULL) + ns_lwdmanager_detach(&listener->manager); + + if (listener->sock != NULL) + isc_socket_detach(&listener->sock); + + listener->magic = 0; + mctx = listener->mctx; + isc_mem_put(mctx, listener, sizeof(*listener)); + isc_mem_detach(&mctx); + listenerp = NULL; +} + +static isc_result_t +listener_create(isc_mem_t *mctx, ns_lwresd_t *lwresd, + ns_lwreslistener_t **listenerp) +{ + ns_lwreslistener_t *listener; + + REQUIRE(listenerp != NULL && *listenerp == NULL); + + listener = isc_mem_get(mctx, sizeof(ns_lwreslistener_t)); + if (listener == NULL) + return (ISC_R_NOMEMORY); + RUNTIME_CHECK(isc_mutex_init(&listener->lock) == ISC_R_SUCCESS); + + listener->magic = LWRESLISTENER_MAGIC; + listener->refs = 1; + + listener->sock = NULL; + + listener->manager = NULL; + ns_lwdmanager_attach(lwresd, &listener->manager); + + listener->mctx = NULL; + isc_mem_attach(mctx, &listener->mctx); + + ISC_LINK_INIT(listener, link); + ISC_LIST_INIT(listener->cmgrs); + + *listenerp = listener; + return (ISC_R_SUCCESS); +} + +static isc_result_t +listener_bind(ns_lwreslistener_t *listener, isc_sockaddr_t *address) { + isc_socket_t *sock = NULL; + isc_result_t result = ISC_R_SUCCESS; + int pf; + + pf = isc_sockaddr_pf(address); + if ((pf == AF_INET && isc_net_probeipv4() != ISC_R_SUCCESS) || + (pf == AF_INET6 && isc_net_probeipv6() != ISC_R_SUCCESS)) + return (ISC_R_FAMILYNOSUPPORT); + + listener->address = *address; + + if (isc_sockaddr_getport(&listener->address) == 0) { + in_port_t port; + port = lwresd_g_listenport; + if (port == 0) + port = LWRES_UDP_PORT; + isc_sockaddr_setport(&listener->address, port); + } + + sock = NULL; + result = isc_socket_create(ns_g_socketmgr, pf, + isc_sockettype_udp, &sock); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_WARNING, + "failed to create lwres socket: %s", + isc_result_totext(result)); + return (result); + } + + result = isc_socket_bind(sock, &listener->address); + if (result != ISC_R_SUCCESS) { + char socktext[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_format(&listener->address, socktext, + sizeof(socktext)); + isc_socket_detach(&sock); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_WARNING, + "failed to add lwres socket: %s: %s", + socktext, isc_result_totext(result)); + return (result); + } + listener->sock = sock; + return (ISC_R_SUCCESS); +} + +static void +listener_copysock(ns_lwreslistener_t *oldlistener, + ns_lwreslistener_t *newlistener) +{ + newlistener->address = oldlistener->address; + isc_socket_attach(oldlistener->sock, &newlistener->sock); +} + +static isc_result_t +listener_startclients(ns_lwreslistener_t *listener) { + ns_lwdclientmgr_t *cm; + unsigned int i; + isc_result_t result; + + /* + * Create the client managers. + */ + result = ISC_R_SUCCESS; + for (i = 0; i < NTASKS && result == ISC_R_SUCCESS; i++) + result = ns_lwdclientmgr_create(listener, NRECVS, + ns_g_taskmgr); + + /* + * Ensure that we have created at least one. + */ + if (ISC_LIST_EMPTY(listener->cmgrs)) + return (result); + + /* + * Walk the list of clients and start each one up. + */ + LOCK(&listener->lock); + cm = ISC_LIST_HEAD(listener->cmgrs); + while (cm != NULL) { + result = ns_lwdclient_startrecv(cm); + if (result != ISC_R_SUCCESS) + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_ERROR, + "could not start lwres " + "client handler: %s", + isc_result_totext(result)); + cm = ISC_LIST_NEXT(cm, link); + } + UNLOCK(&listener->lock); + + return (ISC_R_SUCCESS); +} + +static void +listener_shutdown(ns_lwreslistener_t *listener) { + ns_lwdclientmgr_t *cm; + + cm = ISC_LIST_HEAD(listener->cmgrs); + while (cm != NULL) { + isc_task_shutdown(cm->task); + cm = ISC_LIST_NEXT(cm, link); + } +} + +static isc_result_t +find_listener(isc_sockaddr_t *address, ns_lwreslistener_t **listenerp) { + ns_lwreslistener_t *listener; + + INSIST(listenerp != NULL && *listenerp == NULL); + + for (listener = ISC_LIST_HEAD(listeners); + listener != NULL; + listener = ISC_LIST_NEXT(listener, link)) + { + if (!isc_sockaddr_equal(address, &listener->address)) + continue; + *listenerp = listener; + return (ISC_R_SUCCESS); + } + return (ISC_R_NOTFOUND); +} + +void +ns_lwreslistener_unlinkcm(ns_lwreslistener_t *listener, ns_lwdclientmgr_t *cm) +{ + REQUIRE(VALID_LWRESLISTENER(listener)); + + LOCK(&listener->lock); + ISC_LIST_UNLINK(listener->cmgrs, cm, link); + UNLOCK(&listener->lock); +} + +void +ns_lwreslistener_linkcm(ns_lwreslistener_t *listener, ns_lwdclientmgr_t *cm) { + REQUIRE(VALID_LWRESLISTENER(listener)); + + /* + * This does no locking, since it's called early enough that locking + * isn't needed. + */ + ISC_LIST_APPEND(listener->cmgrs, cm, link); +} + +static isc_result_t +configure_listener(isc_sockaddr_t *address, ns_lwresd_t *lwresd, + isc_mem_t *mctx, ns_lwreslistenerlist_t *newlisteners) +{ + ns_lwreslistener_t *listener, *oldlistener = NULL; + char socktext[ISC_SOCKADDR_FORMATSIZE]; + isc_result_t result; + + (void)find_listener(address, &oldlistener); + listener = NULL; + result = listener_create(mctx, lwresd, &listener); + if (result != ISC_R_SUCCESS) { + isc_sockaddr_format(address, socktext, sizeof(socktext)); + isc_log_write(ns_g_lctx, ISC_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_WARNING, + "lwres failed to configure %s: %s", + socktext, isc_result_totext(result)); + return (result); + } + + /* + * If there's already a listener, don't rebind the socket. + */ + if (oldlistener == NULL) { + result = listener_bind(listener, address); + if (result != ISC_R_SUCCESS) { + ns_lwreslistener_detach(&listener); + return (ISC_R_SUCCESS); + } + } else + listener_copysock(oldlistener, listener); + + result = listener_startclients(listener); + if (result != ISC_R_SUCCESS) { + isc_sockaddr_format(address, socktext, sizeof(socktext)); + isc_log_write(ns_g_lctx, ISC_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_WARNING, + "lwres: failed to start %s: %s", socktext, + isc_result_totext(result)); + ns_lwreslistener_detach(&listener); + return (ISC_R_SUCCESS); + } + + if (oldlistener != NULL) { + /* + * Remove the old listener from the old list and shut it down. + */ + ISC_LIST_UNLINK(listeners, oldlistener, link); + listener_shutdown(oldlistener); + ns_lwreslistener_detach(&oldlistener); + } else { + isc_sockaddr_format(address, socktext, sizeof(socktext)); + isc_log_write(ns_g_lctx, ISC_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_NOTICE, + "lwres listening on %s", socktext); + } + + ISC_LIST_APPEND(*newlisteners, listener, link); + return (result); +} + +isc_result_t +ns_lwresd_configure(isc_mem_t *mctx, cfg_obj_t *config) { + cfg_obj_t *lwreslist = NULL; + cfg_obj_t *lwres = NULL; + cfg_obj_t *listenerslist = NULL; + cfg_listelt_t *element = NULL; + ns_lwreslistener_t *listener; + ns_lwreslistenerlist_t newlisteners; + isc_result_t result; + char socktext[ISC_SOCKADDR_FORMATSIZE]; + isc_sockaddr_t *addrs = NULL; + ns_lwresd_t *lwresd = NULL; + isc_uint32_t count = 0; + + REQUIRE(mctx != NULL); + REQUIRE(config != NULL); + + RUNTIME_CHECK(isc_once_do(&once, initialize_mutex) == ISC_R_SUCCESS); + + ISC_LIST_INIT(newlisteners); + + result = cfg_map_get(config, "lwres", &lwreslist); + if (result != ISC_R_SUCCESS) + return (ISC_R_SUCCESS); + + LOCK(&listeners_lock); + /* + * Run through the new lwres address list, noting sockets that + * are already being listened on and moving them to the new list. + * + * Identifying duplicates addr/port combinations is left to either + * the underlying config code, or to the bind attempt getting an + * address-in-use error. + */ + for (element = cfg_list_first(lwreslist); + element != NULL; + element = cfg_list_next(element)) + { + in_port_t port; + + lwres = cfg_listelt_value(element); + CHECK(ns_lwdmanager_create(mctx, lwres, &lwresd)); + + port = lwresd_g_listenport; + if (port == 0) + port = LWRES_UDP_PORT; + + listenerslist = NULL; + (void)cfg_map_get(lwres, "listen-on", &listenerslist); + if (listenerslist == NULL) { + struct in_addr localhost; + isc_sockaddr_t address; + + localhost.s_addr = htonl(INADDR_LOOPBACK); + isc_sockaddr_fromin(&address, &localhost, port); + CHECK(configure_listener(&address, lwresd, mctx, + &newlisteners)); + } else { + isc_uint32_t i; + + CHECK(ns_config_getiplist(config, listenerslist, + port, mctx, &addrs, &count)); + for (i = 0; i < count; i++) + CHECK(configure_listener(&addrs[i], lwresd, + mctx, &newlisteners)); + ns_config_putiplist(mctx, &addrs, count); + } + ns_lwdmanager_detach(&lwresd); + } + + /* + * Shutdown everything on the listeners list, and remove them from + * the list. Then put all of the new listeners on it. + */ + + while (!ISC_LIST_EMPTY(listeners)) { + listener = ISC_LIST_HEAD(listeners); + ISC_LIST_UNLINK(listeners, listener, link); + + isc_sockaddr_format(&listener->address, + socktext, sizeof(socktext)); + + listener_shutdown(listener); + ns_lwreslistener_detach(&listener); + + isc_log_write(ns_g_lctx, ISC_LOGCATEGORY_GENERAL, + NS_LOGMODULE_LWRESD, ISC_LOG_NOTICE, + "lwres no longer listening on %s", socktext); + } + + cleanup: + ISC_LIST_APPENDLIST(listeners, newlisteners, link); + + if (addrs != NULL) + ns_config_putiplist(mctx, &addrs, count); + + if (lwresd != NULL) + ns_lwdmanager_detach(&lwresd); + + UNLOCK(&listeners_lock); + + return (result); +} + +void +ns_lwresd_shutdown(void) { + ns_lwreslistener_t *listener; + + RUNTIME_CHECK(isc_once_do(&once, initialize_mutex) == ISC_R_SUCCESS); + + while (!ISC_LIST_EMPTY(listeners)) { + listener = ISC_LIST_HEAD(listeners); + ISC_LIST_UNLINK(listeners, listener, link); + ns_lwreslistener_detach(&listener); + } +} diff --git a/contrib/bind9/bin/named/lwresd.docbook b/contrib/bind9/bin/named/lwresd.docbook new file mode 100644 index 000000000000..46314c2614ea --- /dev/null +++ b/contrib/bind9/bin/named/lwresd.docbook @@ -0,0 +1,300 @@ + + + + + + + + June 30, 2000 + + + + lwresd + 8 + BIND9 + + + + lwresd + lightweight resolver daemon + + + + + lwresd + + + + + + + + + + + + + + + + + DESCRIPTION + + lwresd is the daemon providing name lookup + services to clients that use the BIND 9 lightweight resolver + library. It is essentially a stripped-down, caching-only name + server that answers queries using the BIND 9 lightweight + resolver protocol rather than the DNS protocol. + + + lwresd listens for resolver queries on a + UDP port on the IPv4 loopback interface, 127.0.0.1. This + means that lwresd can only be used by + processes running on the local machine. By default UDP port + number 921 is used for lightweight resolver requests and + responses. + + + Incoming lightweight resolver requests are decoded by the + server which then resolves them using the DNS protocol. When + the DNS lookup completes, lwresd encodes + the answers in the lightweight resolver format and returns + them to the client that made the request. + + + If /etc/resolv.conf contains any + entries, lwresd + sends recursive DNS queries to those servers. This is similar + to the use of forwarders in a caching name server. If no + entries are present, or if + forwarding fails, lwresd resolves the + queries autonomously starting at the root name servers, using + a built-in list of root server hints. + + + + + OPTIONS + + + + -C config-file + + + Use config-file as the + configuration file instead of the default, + /etc/resolv.conf. + + + + + + -d debug-level + + + Set the daemon's debug level to debug-level. + Debugging traces from lwresd become + more verbose as the debug level increases. + + + + + + -f + + + Run the server in the foreground (i.e. do not daemonize). + + + + + + -g + + + Run the server in the foreground and force all logging + to stderr. + + + + + + -n #cpus + + + Create #cpus worker threads + to take advantage of multiple CPUs. If not specified, + lwresd will try to determine the + number of CPUs present and create one thread per CPU. + If it is unable to determine the number of CPUs, a + single worker thread will be created. + + + + + + -P port + + + Listen for lightweight resolver queries on port + port. If + not specified, the default is port 921. + + + + + + -p port + + + Send DNS lookups to port port. If not + specified, the default is port 53. This provides a + way of testing the lightweight resolver daemon with a + name server that listens for queries on a non-standard + port number. + + + + + + -s + + + Write memory usage statistics to stdout + on exit. + + + + This option is mainly of interest to BIND 9 developers + and may be removed or changed in a future release. + + + + + + + -t directory + + + chroot() to directory after + processing the command line arguments, but before + reading the configuration file. + + + + This option should be used in conjunction with the + option, as chrooting a process + running as root doesn't enhance security on most + systems; the way chroot() is + defined allows a process with root privileges to + escape a chroot jail. + + + + + + + -u user + + + setuid() to user after completing + privileged operations, such as creating sockets that + listen on privileged ports. + + + + + + -v + + + Report the version number and exit. + + + + + + + + + + FILES + + + + + /etc/resolv.conf + + + The default configuration file. + + + + + + /var/run/lwresd.pid + + + The default process-id file. + + + + + + + + + + SEE ALSO + + + named + 8 + , + + lwres + 3 + , + + resolver + 5 + . + + + + + AUTHOR + + Internet Systems Consortium + + + + + + + diff --git a/contrib/bind9/bin/named/lwresd.html b/contrib/bind9/bin/named/lwresd.html new file mode 100644 index 000000000000..afe7af22f480 --- /dev/null +++ b/contrib/bind9/bin/named/lwresd.html @@ -0,0 +1,497 @@ + + + + + +lwresd

lwresd

Name

lwresd -- lightweight resolver daemon

Synopsis

lwresd [-C config-file] [-d debug-level] [-f] [-g] [-i pid-file] [-n #cpus] [-P port] [-p port] [-s] [-t directory] [-u user] [-v]

DESCRIPTION

lwresd is the daemon providing name lookup + services to clients that use the BIND 9 lightweight resolver + library. It is essentially a stripped-down, caching-only name + server that answers queries using the BIND 9 lightweight + resolver protocol rather than the DNS protocol. +

lwresd listens for resolver queries on a + UDP port on the IPv4 loopback interface, 127.0.0.1. This + means that lwresd can only be used by + processes running on the local machine. By default UDP port + number 921 is used for lightweight resolver requests and + responses. +

Incoming lightweight resolver requests are decoded by the + server which then resolves them using the DNS protocol. When + the DNS lookup completes, lwresd encodes + the answers in the lightweight resolver format and returns + them to the client that made the request. +

If /etc/resolv.conf contains any + nameserver entries, lwresd + sends recursive DNS queries to those servers. This is similar + to the use of forwarders in a caching name server. If no + nameserver entries are present, or if + forwarding fails, lwresd resolves the + queries autonomously starting at the root name servers, using + a built-in list of root server hints. +

OPTIONS

-C config-file

Use config-file as the + configuration file instead of the default, + /etc/resolv.conf. +

-d debug-level

Set the daemon's debug level to debug-level. + Debugging traces from lwresd become + more verbose as the debug level increases. +

-f

Run the server in the foreground (i.e. do not daemonize). +

-g

Run the server in the foreground and force all logging + to stderr. +

-n #cpus

Create #cpus worker threads + to take advantage of multiple CPUs. If not specified, + lwresd will try to determine the + number of CPUs present and create one thread per CPU. + If it is unable to determine the number of CPUs, a + single worker thread will be created. +

-P port

Listen for lightweight resolver queries on port + port. If + not specified, the default is port 921. +

-p port

Send DNS lookups to port port. If not + specified, the default is port 53. This provides a + way of testing the lightweight resolver daemon with a + name server that listens for queries on a non-standard + port number. +

-s

Write memory usage statistics to stdout + on exit. +

Note: This option is mainly of interest to BIND 9 developers + and may be removed or changed in a future release. +

-t directory

chroot() to directory after + processing the command line arguments, but before + reading the configuration file. +

Warning

This option should be used in conjunction with the + -u option, as chrooting a process + running as root doesn't enhance security on most + systems; the way chroot() is + defined allows a process with root privileges to + escape a chroot jail. +

-u user

setuid() to user after completing + privileged operations, such as creating sockets that + listen on privileged ports. +

-v

Report the version number and exit. +

FILES

/etc/resolv.conf

The default configuration file. +

/var/run/lwresd.pid

The default process-id file. +

SEE ALSO

named(8), + lwres(3), + resolver(5). +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/named/lwsearch.c b/contrib/bind9/bin/named/lwsearch.c new file mode 100644 index 000000000000..8b9ea526f1e5 --- /dev/null +++ b/contrib/bind9/bin/named/lwsearch.c @@ -0,0 +1,199 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: lwsearch.c,v 1.7.208.1 2004/03/06 10:21:20 marka Exp $ */ + +#include + +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + +#define LWSEARCHLIST_MAGIC ISC_MAGIC('L', 'W', 'S', 'L') +#define VALID_LWSEARCHLIST(l) ISC_MAGIC_VALID(l, LWSEARCHLIST_MAGIC) + +isc_result_t +ns_lwsearchlist_create(isc_mem_t *mctx, ns_lwsearchlist_t **listp) { + ns_lwsearchlist_t *list; + + REQUIRE(mctx != NULL); + REQUIRE(listp != NULL && *listp == NULL); + + list = isc_mem_get(mctx, sizeof(ns_lwsearchlist_t)); + if (list == NULL) + return (ISC_R_NOMEMORY); + + RUNTIME_CHECK(isc_mutex_init(&list->lock) == ISC_R_SUCCESS); + list->mctx = NULL; + isc_mem_attach(mctx, &list->mctx); + list->refs = 1; + ISC_LIST_INIT(list->names); + list->magic = LWSEARCHLIST_MAGIC; + + *listp = list; + return (ISC_R_SUCCESS); +} + +void +ns_lwsearchlist_attach(ns_lwsearchlist_t *source, ns_lwsearchlist_t **target) { + REQUIRE(VALID_LWSEARCHLIST(source)); + REQUIRE(target != NULL && *target == NULL); + + LOCK(&source->lock); + INSIST(source->refs > 0); + source->refs++; + INSIST(source->refs != 0); + UNLOCK(&source->lock); + + *target = source; +} + +void +ns_lwsearchlist_detach(ns_lwsearchlist_t **listp) { + ns_lwsearchlist_t *list; + isc_mem_t *mctx; + + REQUIRE(listp != NULL); + list = *listp; + REQUIRE(VALID_LWSEARCHLIST(list)); + + LOCK(&list->lock); + INSIST(list->refs > 0); + list->refs--; + UNLOCK(&list->lock); + + *listp = NULL; + if (list->refs != 0) + return; + + mctx = list->mctx; + while (!ISC_LIST_EMPTY(list->names)) { + dns_name_t *name = ISC_LIST_HEAD(list->names); + ISC_LIST_UNLINK(list->names, name, link); + dns_name_free(name, list->mctx); + isc_mem_put(list->mctx, name, sizeof(dns_name_t)); + } + list->magic = 0; + isc_mem_put(mctx, list, sizeof(ns_lwsearchlist_t)); + isc_mem_detach(&mctx); +} + +isc_result_t +ns_lwsearchlist_append(ns_lwsearchlist_t *list, dns_name_t *name) { + dns_name_t *newname; + isc_result_t result; + + REQUIRE(VALID_LWSEARCHLIST(list)); + REQUIRE(name != NULL); + + newname = isc_mem_get(list->mctx, sizeof(dns_name_t)); + if (newname == NULL) + return (ISC_R_NOMEMORY); + dns_name_init(newname, NULL); + result = dns_name_dup(name, list->mctx, newname); + if (result != ISC_R_SUCCESS) { + isc_mem_put(list->mctx, newname, sizeof(dns_name_t)); + return (result); + } + ISC_LINK_INIT(newname, link); + ISC_LIST_APPEND(list->names, newname, link); + return (ISC_R_SUCCESS); +} + +void +ns_lwsearchctx_init(ns_lwsearchctx_t *sctx, ns_lwsearchlist_t *list, + dns_name_t *name, unsigned int ndots) +{ + INSIST(sctx != NULL); + sctx->relname = name; + sctx->searchname = NULL; + sctx->doneexact = ISC_FALSE; + sctx->exactfirst = ISC_FALSE; + sctx->ndots = ndots; + if (dns_name_isabsolute(name) || list == NULL) { + sctx->list = NULL; + return; + } + sctx->list = list; + sctx->searchname = ISC_LIST_HEAD(sctx->list->names); + if (dns_name_countlabels(name) > ndots) + sctx->exactfirst = ISC_TRUE; +} + +void +ns_lwsearchctx_first(ns_lwsearchctx_t *sctx) { + REQUIRE(sctx != NULL); + UNUSED(sctx); +} + +isc_result_t +ns_lwsearchctx_next(ns_lwsearchctx_t *sctx) { + REQUIRE(sctx != NULL); + + if (sctx->list == NULL) + return (ISC_R_NOMORE); + + if (sctx->searchname == NULL) { + INSIST (!sctx->exactfirst || sctx->doneexact); + if (sctx->exactfirst || sctx->doneexact) + return (ISC_R_NOMORE); + sctx->doneexact = ISC_TRUE; + } else { + if (sctx->exactfirst && !sctx->doneexact) + sctx->doneexact = ISC_TRUE; + else { + sctx->searchname = ISC_LIST_NEXT(sctx->searchname, + link); + if (sctx->searchname == NULL && sctx->doneexact) + return (ISC_R_NOMORE); + } + } + + return (ISC_R_SUCCESS); +} + +isc_result_t +ns_lwsearchctx_current(ns_lwsearchctx_t *sctx, dns_name_t *absname) { + dns_name_t *tname; + isc_boolean_t useexact = ISC_FALSE; + + REQUIRE(sctx != NULL); + + if (sctx->list == NULL || + sctx->searchname == NULL || + (sctx->exactfirst && !sctx->doneexact)) + useexact = ISC_TRUE; + + if (useexact) { + if (dns_name_isabsolute(sctx->relname)) + tname = NULL; + else + tname = dns_rootname; + } else + tname = sctx->searchname; + + return (dns_name_concatenate(sctx->relname, tname, absname, NULL)); +} diff --git a/contrib/bind9/bin/named/main.c b/contrib/bind9/bin/named/main.c new file mode 100644 index 000000000000..432afe528607 --- /dev/null +++ b/contrib/bind9/bin/named/main.c @@ -0,0 +1,884 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: main.c,v 1.119.2.3.2.16 2004/09/01 07:16:35 marka Exp $ */ + +#include + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include + +#include + +#ifdef HAVE_LIBSCF +#include +#endif + +/* + * Defining NS_MAIN provides storage declarations (rather than extern) + * for variables in named/globals.h. + */ +#define NS_MAIN 1 + +#include +#include +#include /* Explicit, though named/log.h includes it. */ +#include +#include +#include +#include +#include +#include + +/* + * Include header files for database drivers here. + */ +/* #include "xxdb.h" */ + +static isc_boolean_t want_stats = ISC_FALSE; +static char program_name[ISC_DIR_NAMEMAX] = "named"; +static char absolute_conffile[ISC_DIR_PATHMAX]; +static char saved_command_line[512]; +static char version[512]; + +void +ns_main_earlywarning(const char *format, ...) { + va_list args; + + va_start(args, format); + if (ns_g_lctx != NULL) { + isc_log_vwrite(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_WARNING, + format, args); + } else { + fprintf(stderr, "%s: ", program_name); + vfprintf(stderr, format, args); + fprintf(stderr, "\n"); + fflush(stderr); + } + va_end(args); +} + +void +ns_main_earlyfatal(const char *format, ...) { + va_list args; + + va_start(args, format); + if (ns_g_lctx != NULL) { + isc_log_vwrite(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_CRITICAL, + format, args); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_CRITICAL, + "exiting (due to early fatal error)"); + } else { + fprintf(stderr, "%s: ", program_name); + vfprintf(stderr, format, args); + fprintf(stderr, "\n"); + fflush(stderr); + } + va_end(args); + + exit(1); +} + +static void +assertion_failed(const char *file, int line, isc_assertiontype_t type, + const char *cond) +{ + /* + * Handle assertion failures. + */ + + if (ns_g_lctx != NULL) { + /* + * Reset the assetion callback in case it is the log + * routines causing the assertion. + */ + isc_assertion_setcallback(NULL); + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_CRITICAL, + "%s:%d: %s(%s) failed", file, line, + isc_assertion_typetotext(type), cond); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_CRITICAL, + "exiting (due to assertion failure)"); + } else { + fprintf(stderr, "%s:%d: %s(%s) failed\n", + file, line, isc_assertion_typetotext(type), cond); + fflush(stderr); + } + + if (ns_g_coreok) + abort(); + exit(1); +} + +static void +library_fatal_error(const char *file, int line, const char *format, + va_list args) ISC_FORMAT_PRINTF(3, 0); + +static void +library_fatal_error(const char *file, int line, const char *format, + va_list args) +{ + /* + * Handle isc_error_fatal() calls from our libraries. + */ + + if (ns_g_lctx != NULL) { + /* + * Reset the error callback in case it is the log + * routines causing the assertion. + */ + isc_error_setfatal(NULL); + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_CRITICAL, + "%s:%d: fatal error:", file, line); + isc_log_vwrite(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_CRITICAL, + format, args); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_CRITICAL, + "exiting (due to fatal error in library)"); + } else { + fprintf(stderr, "%s:%d: fatal error: ", file, line); + vfprintf(stderr, format, args); + fprintf(stderr, "\n"); + fflush(stderr); + } + + if (ns_g_coreok) + abort(); + exit(1); +} + +static void +library_unexpected_error(const char *file, int line, const char *format, + va_list args) ISC_FORMAT_PRINTF(3, 0); + +static void +library_unexpected_error(const char *file, int line, const char *format, + va_list args) +{ + /* + * Handle isc_error_unexpected() calls from our libraries. + */ + + if (ns_g_lctx != NULL) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_ERROR, + "%s:%d: unexpected error:", file, line); + isc_log_vwrite(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_ERROR, + format, args); + } else { + fprintf(stderr, "%s:%d: fatal error: ", file, line); + vfprintf(stderr, format, args); + fprintf(stderr, "\n"); + fflush(stderr); + } +} + +static void +lwresd_usage(void) { + fprintf(stderr, + "usage: lwresd [-4|-6] [-c conffile | -C resolvconffile] " + "[-d debuglevel]\n" + " [-f|-g] [-n number_of_cpus] [-p port] " + "[-P listen-port] [-s]\n" + " [-t chrootdir] [-u username] [-i pidfile]\n" + " [-m {usage|trace|record}]\n"); +} + +static void +usage(void) { + if (ns_g_lwresdonly) { + lwresd_usage(); + return; + } + fprintf(stderr, + "usage: named [-4|-6] [-c conffile] [-d debuglevel] " + "[-f|-g] [-n number_of_cpus]\n" + " [-p port] [-s] [-t chrootdir] [-u username]\n" + " [-m {usage|trace|record}]\n"); +} + +static void +save_command_line(int argc, char *argv[]) { + int i; + char *src; + char *dst; + char *eob; + const char truncated[] = "..."; + isc_boolean_t quoted = ISC_FALSE; + + dst = saved_command_line; + eob = saved_command_line + sizeof(saved_command_line); + + for (i = 1; i < argc && dst < eob; i++) { + *dst++ = ' '; + + src = argv[i]; + while (*src != '\0' && dst < eob) { + /* + * This won't perfectly produce a shell-independent + * pastable command line in all circumstances, but + * comes close, and for practical purposes will + * nearly always be fine. + */ + if (quoted || isalnum(*src & 0xff) || + *src == '-' || *src == '_' || + *src == '.' || *src == '/') { + *dst++ = *src++; + quoted = ISC_FALSE; + } else { + *dst++ = '\\'; + quoted = ISC_TRUE; + } + } + } + + INSIST(sizeof(saved_command_line) >= sizeof(truncated)); + + if (dst == eob) + strcpy(eob - sizeof(truncated), truncated); + else + *dst = '\0'; +} + +static int +parse_int(char *arg, const char *desc) { + char *endp; + int tmp; + long int ltmp; + + ltmp = strtol(arg, &endp, 10); + tmp = (int) ltmp; + if (*endp != '\0') + ns_main_earlyfatal("%s '%s' must be numeric", desc, arg); + if (tmp < 0 || tmp != ltmp) + ns_main_earlyfatal("%s '%s' out of range", desc, arg); + return (tmp); +} + +static struct flag_def { + const char *name; + unsigned int value; +} mem_debug_flags[] = { + { "trace", ISC_MEM_DEBUGTRACE }, + { "record", ISC_MEM_DEBUGRECORD }, + { "usage", ISC_MEM_DEBUGUSAGE }, + { NULL, 0 } +}; + +static void +set_flags(const char *arg, struct flag_def *defs, unsigned int *ret) { + for (;;) { + const struct flag_def *def; + const char *end = strchr(arg, ','); + int arglen; + if (end == NULL) + end = arg + strlen(arg); + arglen = end - arg; + for (def = defs; def->name != NULL; def++) { + if (arglen == (int)strlen(def->name) && + memcmp(arg, def->name, arglen) == 0) { + *ret |= def->value; + goto found; + } + } + ns_main_earlyfatal("unrecognized flag '%.*s'", arglen, arg); + found: + if (*end == '\0') + break; + arg = end + 1; + } +} + +static void +parse_command_line(int argc, char *argv[]) { + int ch; + int port; + isc_boolean_t disable6 = ISC_FALSE; + isc_boolean_t disable4 = ISC_FALSE; + + save_command_line(argc, argv); + + isc_commandline_errprint = ISC_FALSE; + while ((ch = isc_commandline_parse(argc, argv, + "46c:C:d:fgi:lm:n:N:p:P:st:u:vx:")) != -1) { + switch (ch) { + case '4': + if (disable4) + ns_main_earlyfatal("cannot specify -4 and -6"); + if (isc_net_probeipv4() != ISC_R_SUCCESS) + ns_main_earlyfatal("IPv4 not supported by OS"); + isc_net_disableipv6(); + disable6 = ISC_TRUE; + break; + case '6': + if (disable6) + ns_main_earlyfatal("cannot specify -4 and -6"); + if (isc_net_probeipv6() != ISC_R_SUCCESS) + ns_main_earlyfatal("IPv6 not supported by OS"); + isc_net_disableipv4(); + disable4 = ISC_TRUE; + break; + case 'c': + ns_g_conffile = isc_commandline_argument; + lwresd_g_conffile = isc_commandline_argument; + if (lwresd_g_useresolvconf) + ns_main_earlyfatal("cannot specify -c and -C"); + ns_g_conffileset = ISC_TRUE; + break; + case 'C': + lwresd_g_resolvconffile = isc_commandline_argument; + if (ns_g_conffileset) + ns_main_earlyfatal("cannot specify -c and -C"); + lwresd_g_useresolvconf = ISC_TRUE; + break; + case 'd': + ns_g_debuglevel = parse_int(isc_commandline_argument, + "debug level"); + break; + case 'f': + ns_g_foreground = ISC_TRUE; + break; + case 'g': + ns_g_foreground = ISC_TRUE; + ns_g_logstderr = ISC_TRUE; + break; + /* XXXBEW -i should be removed */ + case 'i': + lwresd_g_defaultpidfile = isc_commandline_argument; + break; + case 'l': + ns_g_lwresdonly = ISC_TRUE; + break; + case 'm': + set_flags(isc_commandline_argument, mem_debug_flags, + &isc_mem_debugging); + break; + case 'N': /* Deprecated. */ + case 'n': + ns_g_cpus = parse_int(isc_commandline_argument, + "number of cpus"); + if (ns_g_cpus == 0) + ns_g_cpus = 1; + break; + case 'p': + port = parse_int(isc_commandline_argument, "port"); + if (port < 1 || port > 65535) + ns_main_earlyfatal("port '%s' out of range", + isc_commandline_argument); + ns_g_port = port; + break; + /* XXXBEW Should -P be removed? */ + case 'P': + port = parse_int(isc_commandline_argument, "port"); + if (port < 1 || port > 65535) + ns_main_earlyfatal("port '%s' out of range", + isc_commandline_argument); + lwresd_g_listenport = port; + break; + case 's': + /* XXXRTH temporary syntax */ + want_stats = ISC_TRUE; + break; + case 't': + /* XXXJAB should we make a copy? */ + ns_g_chrootdir = isc_commandline_argument; + break; + case 'u': + ns_g_username = isc_commandline_argument; + break; + case 'v': + printf("BIND %s\n", ns_g_version); + exit(0); + case '?': + usage(); + ns_main_earlyfatal("unknown option '-%c'", + isc_commandline_option); + default: + ns_main_earlyfatal("parsing options returned %d", ch); + } + } + + argc -= isc_commandline_index; + argv += isc_commandline_index; + + if (argc > 0) { + usage(); + ns_main_earlyfatal("extra command line arguments"); + } +} + +static isc_result_t +create_managers(void) { + isc_result_t result; +#ifdef ISC_PLATFORM_USETHREADS + unsigned int cpus_detected; +#endif + +#ifdef ISC_PLATFORM_USETHREADS + cpus_detected = isc_os_ncpus(); + if (ns_g_cpus == 0) + ns_g_cpus = cpus_detected; + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + ISC_LOG_INFO, "found %u CPU%s, using %u worker thread%s", + cpus_detected, cpus_detected == 1 ? "" : "s", + ns_g_cpus, ns_g_cpus == 1 ? "" : "s"); +#else + ns_g_cpus = 1; +#endif + result = isc_taskmgr_create(ns_g_mctx, ns_g_cpus, 0, &ns_g_taskmgr); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "ns_taskmgr_create() failed: %s", + isc_result_totext(result)); + return (ISC_R_UNEXPECTED); + } + + result = isc_timermgr_create(ns_g_mctx, &ns_g_timermgr); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "ns_timermgr_create() failed: %s", + isc_result_totext(result)); + return (ISC_R_UNEXPECTED); + } + + result = isc_socketmgr_create(ns_g_mctx, &ns_g_socketmgr); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_socketmgr_create() failed: %s", + isc_result_totext(result)); + return (ISC_R_UNEXPECTED); + } + + result = isc_entropy_create(ns_g_mctx, &ns_g_entropy); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_entropy_create() failed: %s", + isc_result_totext(result)); + return (ISC_R_UNEXPECTED); + } + + result = isc_hash_create(ns_g_mctx, ns_g_entropy, DNS_NAME_MAXWIRE); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_hash_create() failed: %s", + isc_result_totext(result)); + return (ISC_R_UNEXPECTED); + } + + return (ISC_R_SUCCESS); +} + +static void +destroy_managers(void) { + ns_lwresd_shutdown(); + + isc_entropy_detach(&ns_g_entropy); + if (ns_g_fallbackentropy != NULL) + isc_entropy_detach(&ns_g_fallbackentropy); + + /* + * isc_taskmgr_destroy() will block until all tasks have exited, + */ + isc_taskmgr_destroy(&ns_g_taskmgr); + isc_timermgr_destroy(&ns_g_timermgr); + isc_socketmgr_destroy(&ns_g_socketmgr); + + /* + * isc_hash_destroy() cannot be called as long as a resolver may be + * running. Calling this after isc_taskmgr_destroy() ensures the + * call is safe. + */ + isc_hash_destroy(); +} + +static void +setup(void) { + isc_result_t result; + + /* + * Get the user and group information before changing the root + * directory, so the administrator does not need to keep a copy + * of the user and group databases in the chroot'ed environment. + */ + ns_os_inituserinfo(ns_g_username); + + /* + * Initialize time conversion information + */ + ns_os_tzset(); + + ns_os_opendevnull(); + +#ifdef PATH_RANDOMDEV + /* + * Initialize system's random device as fallback entropy source + * if running chroot'ed. + */ + if (ns_g_chrootdir != NULL) { + result = isc_entropy_create(ns_g_mctx, &ns_g_fallbackentropy); + if (result != ISC_R_SUCCESS) + ns_main_earlyfatal("isc_entropy_create() failed: %s", + isc_result_totext(result)); + + result = isc_entropy_createfilesource(ns_g_fallbackentropy, + PATH_RANDOMDEV); + if (result != ISC_R_SUCCESS) { + ns_main_earlywarning("could not open pre-chroot " + "entropy source %s: %s", + PATH_RANDOMDEV, + isc_result_totext(result)); + isc_entropy_detach(&ns_g_fallbackentropy); + } + } +#endif + + ns_os_chroot(ns_g_chrootdir); + + /* + * For operating systems which have a capability mechanism, now + * is the time to switch to minimal privs and change our user id. + * On traditional UNIX systems, this call will be a no-op, and we + * will change the user ID after reading the config file the first + * time. (We need to read the config file to know which possibly + * privileged ports to bind() to.) + */ + ns_os_minprivs(); + + result = ns_log_init(ISC_TF(ns_g_username != NULL)); + if (result != ISC_R_SUCCESS) + ns_main_earlyfatal("ns_log_init() failed: %s", + isc_result_totext(result)); + + /* + * Now is the time to daemonize (if we're not running in the + * foreground). We waited until now because we wanted to get + * a valid logging context setup. We cannot daemonize any later, + * because calling create_managers() will create threads, which + * would be lost after fork(). + */ + if (!ns_g_foreground) + ns_os_daemonize(); + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_MAIN, + ISC_LOG_NOTICE, "starting BIND %s%s", ns_g_version, + saved_command_line); + + /* + * Get the initial resource limits. + */ + (void)isc_resource_getlimit(isc_resource_stacksize, + &ns_g_initstacksize); + (void)isc_resource_getlimit(isc_resource_datasize, + &ns_g_initdatasize); + (void)isc_resource_getlimit(isc_resource_coresize, + &ns_g_initcoresize); + (void)isc_resource_getlimit(isc_resource_openfiles, + &ns_g_initopenfiles); + + /* + * If the named configuration filename is relative, prepend the current + * directory's name before possibly changing to another directory. + */ + if (! isc_file_isabsolute(ns_g_conffile)) { + result = isc_file_absolutepath(ns_g_conffile, + absolute_conffile, + sizeof(absolute_conffile)); + if (result != ISC_R_SUCCESS) + ns_main_earlyfatal("could not construct absolute path of " + "configuration file: %s", + isc_result_totext(result)); + ns_g_conffile = absolute_conffile; + } + + result = create_managers(); + if (result != ISC_R_SUCCESS) + ns_main_earlyfatal("create_managers() failed: %s", + isc_result_totext(result)); + + ns_builtin_init(); + + /* + * Add calls to register sdb drivers here. + */ + /* xxdb_init(); */ + + ns_server_create(ns_g_mctx, &ns_g_server); +} + +static void +cleanup(void) { + destroy_managers(); + + ns_server_destroy(&ns_g_server); + + ns_builtin_deinit(); + + /* + * Add calls to unregister sdb drivers here. + */ + /* xxdb_clear(); */ + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_MAIN, + ISC_LOG_NOTICE, "exiting"); + ns_log_shutdown(); +} + +static char *memstats = NULL; + +void +ns_main_setmemstats(const char *filename) { + /* + * Caller has to ensure locking. + */ + + if (memstats != NULL) { + free(memstats); + memstats = NULL; + } + if (filename == NULL) + return; + memstats = malloc(strlen(filename) + 1); + if (memstats) + strcpy(memstats, filename); +} + +#ifdef HAVE_LIBSCF +/* + * Get FMRI for the current named process + */ +static char * +scf_get_ins_name(void) { + scf_handle_t *h = NULL; + int namelen; + char *ins_name; + + if ((h = scf_handle_create(SCF_VERSION)) == NULL) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "scf_handle_create() failed: %s", + scf_strerror(scf_error())); + return (NULL); + } + + if (scf_handle_bind(h) == -1) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "scf_handle_bind() failed: %s", + scf_strerror(scf_error())); + scf_handle_destroy(h); + return (NULL); + } + + if ((namelen = scf_myname(h, NULL, 0)) == -1) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_MAIN, ISC_LOG_INFO, + "scf_myname() failed: %s", + scf_strerror(scf_error())); + scf_handle_destroy(h); + return (NULL); + } + + if ((ins_name = malloc(namelen + 1)) == NULL) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "scf_get_ins_named() memory " + "allocation failed: %s", + isc_result_totext(ISC_R_NOMEMORY)); + scf_handle_destroy(h); + return (NULL); + } + + if (scf_myname(h, ins_name, namelen + 1) == -1) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "scf_myname() failed: %s", + scf_strerror(scf_error())); + scf_handle_destroy(h); + free(ins_name); + return (NULL); + } + + scf_handle_destroy(h); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_MAIN, + ISC_LOG_INFO, "instance name:%s", ins_name); + + return (ins_name); +} + +static void +scf_cleanup(void) { + char *s; + char *ins_name; + + if ((ins_name = scf_get_ins_name()) != NULL) { + if ((s = smf_get_state(ins_name)) != NULL) { + if ((strcmp(SCF_STATE_STRING_ONLINE, s) == 0) || + (strcmp(SCF_STATE_STRING_DEGRADED, s) == 0)) { + if (smf_disable_instance(ins_name, 0) != 0) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "smf_disable_instance() failed: %s", + scf_strerror(scf_error())); + } + } + free(s); + } else { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "smf_get_state() failed: %s", + scf_strerror(scf_error())); + } + free(ins_name); + } +} +#endif + +int +main(int argc, char *argv[]) { + isc_result_t result; + + /* + * Record version in core image. + * strings named.core | grep "named version:" + */ + strlcat(version, +#ifdef __DATE__ + "named version: BIND " VERSION " (" __DATE__ ")", +#else + "named version: BIND " VERSION, +#endif + sizeof(version)); + result = isc_file_progname(*argv, program_name, sizeof(program_name)); + if (result != ISC_R_SUCCESS) + ns_main_earlyfatal("program name too long"); + + if (strcmp(program_name, "lwresd") == 0) + ns_g_lwresdonly = ISC_TRUE; + + isc_assertion_setcallback(assertion_failed); + isc_error_setfatal(library_fatal_error); + isc_error_setunexpected(library_unexpected_error); + + ns_os_init(program_name); + + result = isc_app_start(); + if (result != ISC_R_SUCCESS) + ns_main_earlyfatal("isc_app_start() failed: %s", + isc_result_totext(result)); + + dns_result_register(); + dst_result_register(); + isccc_result_register(); + + parse_command_line(argc, argv); + + /* + * Warn about common configuration error. + */ + if (ns_g_chrootdir != NULL) { + int len = strlen(ns_g_chrootdir); + if (strncmp(ns_g_chrootdir, ns_g_conffile, len) == 0 && + (ns_g_conffile[len] == '/' || ns_g_conffile[len] == '\\')) + ns_main_earlywarning("config filename (-c %s) contains " + "chroot path (-t %s)", + ns_g_conffile, ns_g_chrootdir); + } + + result = isc_mem_create(0, 0, &ns_g_mctx); + if (result != ISC_R_SUCCESS) + ns_main_earlyfatal("isc_mem_create() failed: %s", + isc_result_totext(result)); + + setup(); + + /* + * Start things running and then wait for a shutdown request + * or reload. + */ + do { + result = isc_app_run(); + + if (result == ISC_R_RELOAD) { + ns_server_reloadwanted(ns_g_server); + } else if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_app_run(): %s", + isc_result_totext(result)); + /* + * Force exit. + */ + result = ISC_R_SUCCESS; + } + } while (result != ISC_R_SUCCESS); + +#ifdef HAVE_LIBSCF + scf_cleanup(); +#endif + + cleanup(); + + if (want_stats) { + isc_mem_stats(ns_g_mctx, stdout); + isc_mutex_stats(stdout); + } + if (memstats != NULL) { + FILE *fp = NULL; + result = isc_stdio_open(memstats, "w", &fp); + if (result == ISC_R_SUCCESS) { + isc_mem_stats(ns_g_mctx, fp); + isc_mutex_stats(fp); + isc_stdio_close(fp); + } + } + isc_mem_destroy(&ns_g_mctx); + + ns_main_setmemstats(NULL); + + isc_app_finish(); + + ns_os_closedevnull(); + + ns_os_shutdown(); + + return (0); +} diff --git a/contrib/bind9/bin/named/named.8 b/contrib/bind9/bin/named/named.8 new file mode 100644 index 000000000000..cd120ddc6f63 --- /dev/null +++ b/contrib/bind9/bin/named/named.8 @@ -0,0 +1,177 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: named.8,v 1.17.208.3 2004/06/03 05:35:47 marka Exp $ +.\" +.TH "NAMED" "8" "June 30, 2000" "BIND9" "" +.SH NAME +named \- Internet domain name server +.SH SYNOPSIS +.sp +\fBnamed\fR [ \fB-4\fR ] [ \fB-6\fR ] [ \fB-c \fIconfig-file\fB\fR ] [ \fB-d \fIdebug-level\fB\fR ] [ \fB-f\fR ] [ \fB-g\fR ] [ \fB-n \fI#cpus\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-s\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-u \fIuser\fB\fR ] [ \fB-v\fR ] [ \fB-x \fIcache-file\fB\fR ] +.SH "DESCRIPTION" +.PP +\fBnamed\fR is a Domain Name System (DNS) server, +part of the BIND 9 distribution from ISC. For more +information on the DNS, see RFCs 1033, 1034, and 1035. +.PP +When invoked without arguments, \fBnamed\fR will +read the default configuration file +\fI/etc/named.conf\fR, read any initial +data, and listen for queries. +.SH "OPTIONS" +.TP +\fB-4\fR +Use IPv4 only even if the host machine is capable of IPv6. +\fB-4\fR and \fB-6\fR are mutually +exclusive. +.TP +\fB-6\fR +Use IPv6 only even if the host machine is capable of IPv4. +\fB-4\fR and \fB-6\fR are mutually +exclusive. +.TP +\fB-c \fIconfig-file\fB\fR +Use \fIconfig-file\fR as the +configuration file instead of the default, +\fI/etc/named.conf\fR. To +ensure that reloading the configuration file continues +to work after the server has changed its working +directory due to to a possible +\fBdirectory\fR option in the configuration +file, \fIconfig-file\fR should be +an absolute pathname. +.TP +\fB-d \fIdebug-level\fB\fR +Set the daemon's debug level to \fIdebug-level\fR. +Debugging traces from \fBnamed\fR become +more verbose as the debug level increases. +.TP +\fB-f\fR +Run the server in the foreground (i.e. do not daemonize). +.TP +\fB-g\fR +Run the server in the foreground and force all logging +to \fIstderr\fR. +.TP +\fB-n \fI#cpus\fB\fR +Create \fI#cpus\fR worker threads +to take advantage of multiple CPUs. If not specified, +\fBnamed\fR will try to determine the +number of CPUs present and create one thread per CPU. +If it is unable to determine the number of CPUs, a +single worker thread will be created. +.TP +\fB-p \fIport\fB\fR +Listen for queries on port \fIport\fR. If not +specified, the default is port 53. +.TP +\fB-s\fR +Write memory usage statistics to \fIstdout\fR on exit. +.sp +.RS +.B "Note:" +This option is mainly of interest to BIND 9 developers +and may be removed or changed in a future release. +.RE +.sp +.TP +\fB-t \fIdirectory\fB\fR +\fBchroot()\fR to \fIdirectory\fR after +processing the command line arguments, but before +reading the configuration file. +.sp +.RS +.B "Warning:" +This option should be used in conjunction with the +\fB-u\fR option, as chrooting a process +running as root doesn't enhance security on most +systems; the way \fBchroot()\fR is +defined allows a process with root privileges to +escape a chroot jail. +.RE +.sp +.TP +\fB-u \fIuser\fB\fR +\fBsetuid()\fR to \fIuser\fR after completing +privileged operations, such as creating sockets that +listen on privileged ports. +.sp +.RS +.B "Note:" +On Linux, \fBnamed\fR uses the kernel's +capability mechanism to drop all root privileges +except the ability to \fBbind()\fR to a +privileged port and set process resource limits. +Unfortunately, this means that the \fB-u\fR +option only works when \fBnamed\fR is run +on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or +later, since previous kernels did not allow privileges +to be retained after \fBsetuid()\fR. +.RE +.sp +.TP +\fB-v\fR +Report the version number and exit. +.TP +\fB-x \fIcache-file\fB\fR +Load data from \fIcache-file\fR into the +cache of the default view. +.sp +.RS +.B "Warning:" +This option must not be used. It is only of interest +to BIND 9 developers and may be removed or changed in a +future release. +.RE +.sp +.SH "SIGNALS" +.PP +In routine operation, signals should not be used to control +the nameserver; \fBrndc\fR should be used +instead. +.TP +\fBSIGHUP\fR +Force a reload of the server. +.TP +\fBSIGINT, SIGTERM\fR +Shut down the server. +.PP +The result of sending any other signals to the server is undefined. +.PP +.SH "CONFIGURATION" +.PP +The \fBnamed\fR configuration file is too complex +to describe in detail here. A complete description is +provided in the \fIBIND 9 Administrator Reference +Manual\fR. +.SH "FILES" +.TP +\fB\fI/etc/named.conf\fB\fR +The default configuration file. +.TP +\fB\fI/var/run/named.pid\fB\fR +The default process-id file. +.SH "SEE ALSO" +.PP +\fIRFC 1033\fR, +\fIRFC 1034\fR, +\fIRFC 1035\fR, +\fBrndc\fR(8), +\fBlwresd\fR(8), +\fIBIND 9 Administrator Reference Manual\fR. +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/named/named.conf.5 b/contrib/bind9/bin/named/named.conf.5 new file mode 100644 index 000000000000..1755d5c14ac1 --- /dev/null +++ b/contrib/bind9/bin/named/named.conf.5 @@ -0,0 +1,474 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: named.conf.5,v 1.1.4.2 2004/08/21 07:35:01 marka Exp $ +.\" +.TH "NAMED.CONF" "5" "Aug 13, 2004" "BIND9" "" +.SH NAME +named.conf \- configuration file for named +.SH SYNOPSIS +.sp +\fBnamed.conf\fR +.SH "DESCRIPTION" +.PP +\fInamed.conf\fR is the configuration file for +\fBnamed\fR. Statements are enclosed +in braces and terminated with a semi-colon. Clauses in +the statements are also semi-colon terminated. The usual +comment styles are supported: +.PP +C style: /* */ +.PP +C++ style: // to end of line +.PP +Unix style: # to end of line +.SH "ACL" +.sp +.nf +acl \fIstring\fR { \fIaddress_match_element\fR; ... }; +.sp +.fi +.SH "KEY" +.sp +.nf +key \fIdomain_name\fR { + algorithm \fIstring\fR; + secret \fIstring\fR; +}; +.sp +.fi +.SH "MASTERS" +.sp +.nf +masters \fIstring\fR [ port \fIinteger\fR ] { + ( \fImasters\fR | \fIipv4_address\fR [port \fIinteger\fR] | + \fIipv6_address\fR [port \fIinteger\fR] ) [ key \fIstring\fR ]; ... +}; +.sp +.fi +.SH "SERVER" +.sp +.nf +server ( \fIipv4_address\fR | \fIipv6_address\fR ) { + bogus \fIboolean\fR; + edns \fIboolean\fR; + provide-ixfr \fIboolean\fR; + request-ixfr \fIboolean\fR; + keys \fIserver_key\fR; + transfers \fIinteger\fR; + transfer-format ( many-answers | one-answer ); + transfer-source ( \fIipv4_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + transfer-source-v6 ( \fIipv6_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + + support-ixfr \fIboolean\fR; // obsolete +}; +.sp +.fi +.SH "TRUSTED-KEYS" +.sp +.nf +trusted-keys { + \fIdomain_name\fR \fIflags\fR \fIprotocol\fR \fIalgorithm\fR \fIkey\fR; ... +}; +.sp +.fi +.SH "CONTROLS" +.sp +.nf +controls { + inet ( \fIipv4_address\fR | \fIipv6_address\fR | * ) + [ port ( \fIinteger\fR | * ) ] + allow { \fIaddress_match_element\fR; ... } + [ keys { \fIstring\fR; ... } ]; + unix \fIunsupported\fR; // not implemented +}; +.sp +.fi +.SH "LOGGING" +.sp +.nf +logging { + channel \fIstring\fR { + file \fIlog_file\fR; + syslog \fIoptional_facility\fR; + null; + stderr; + severity \fIlog_severity\fR; + print-time \fIboolean\fR; + print-severity \fIboolean\fR; + print-category \fIboolean\fR; + }; + category \fIstring\fR { \fIstring\fR; ... }; +}; +.sp +.fi +.SH "LWRES" +.sp +.nf +lwres { + listen-on [ port \fIinteger\fR ] { + ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... + }; + view \fIstring\fR \fIoptional_class\fR; + search { \fIstring\fR; ... }; + ndots \fIinteger\fR; +}; +.sp +.fi +.SH "OPTIONS" +.sp +.nf +options { + avoid-v4-udp-ports { \fIport\fR; ... }; + avoid-v6-udp-ports { \fIport\fR; ... }; + blackhole { \fIaddress_match_element\fR; ... }; + coresize \fIsize\fR; + datasize \fIsize\fR; + directory \fIquoted_string\fR; + dump-file \fIquoted_string\fR; + files \fIsize\fR; + heartbeat-interval \fIinteger\fR; + host-statistics \fIboolean\fR; // not implemented + hostname ( \fIquoted_string\fR | none ); + interface-interval \fIinteger\fR; + listen-on [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... }; + listen-on-v6 [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... }; + match-mapped-addresses \fIboolean\fR; + memstatistics-file \fIquoted_string\fR; + pid-file ( \fIquoted_string\fR | none ); + port \fIinteger\fR; + querylog \fIboolean\fR; + recursing-file \fIquoted_string\fR; + random-device \fIquoted_string\fR; + recursive-clients \fIinteger\fR; + serial-query-rate \fIinteger\fR; + server-id ( \fIquoted_string\fR | none |; + stacksize \fIsize\fR; + statistics-file \fIquoted_string\fR; + statistics-interval \fIinteger\fR; // not yet implemented + tcp-clients \fIinteger\fR; + tcp-listen-queue \fIinteger\fR; + tkey-dhkey \fIquoted_string\fR \fIinteger\fR; + tkey-gssapi-credential \fIquoted_string\fR; + tkey-domain \fIquoted_string\fR; + transfers-per-ns \fIinteger\fR; + transfers-in \fIinteger\fR; + transfers-out \fIinteger\fR; + use-ixfr \fIboolean\fR; + version ( \fIquoted_string\fR | none ); + allow-recursion { \fIaddress_match_element\fR; ... }; + sortlist { \fIaddress_match_element\fR; ... }; + topology { \fIaddress_match_element\fR; ... }; // not implemented + auth-nxdomain \fIboolean\fR; // default changed + minimal-responses \fIboolean\fR; + recursion \fIboolean\fR; + rrset-order { + [ class \fIstring\fR ] [ type \fIstring\fR ] + [ name \fIquoted_string\fR ] \fIstring\fR \fIstring\fR; ... + }; + provide-ixfr \fIboolean\fR; + request-ixfr \fIboolean\fR; + rfc2308-type1 \fIboolean\fR; // not yet implemented + additional-from-auth \fIboolean\fR; + additional-from-cache \fIboolean\fR; + query-source \fIquerysource4\fR; + query-source-v6 \fIquerysource6\fR; + cleaning-interval \fIinteger\fR; + min-roots \fIinteger\fR; // not implemented + lame-ttl \fIinteger\fR; + max-ncache-ttl \fIinteger\fR; + max-cache-ttl \fIinteger\fR; + transfer-format ( many-answers | one-answer ); + max-cache-size \fIsize_no_default\fR; + check-names ( master | slave | response ) + ( fail | warn | ignore ); + cache-file \fIquoted_string\fR; + suppress-initial-notify \fIboolean\fR; // not yet implemented + preferred-glue \fIstring\fR; + dual-stack-servers [ port \fIinteger\fR ] { + ( \fIquoted_string\fR [port \fIinteger\fR] | + \fIipv4_address\fR [port \fIinteger\fR] | + \fIipv6_address\fR [port \fIinteger\fR] ); ... + } + edns-udp-size \fIinteger\fR; + root-delegation-only [ exclude { \fIquoted_string\fR; ... } ]; + disable-algorithms \fIstring\fR { \fIstring\fR; ... }; + dnssec-enable \fIboolean\fR; + dnssec-lookaside \fIstring\fR trust-anchor \fIstring\fR; + dnssec-must-be-secure \fIstring\fR \fIboolean\fR; + + dialup \fIdialuptype\fR; + ixfr-from-differences \fIixfrdiff\fR; + + allow-query { \fIaddress_match_element\fR; ... }; + allow-transfer { \fIaddress_match_element\fR; ... }; + allow-update-forwarding { \fIaddress_match_element\fR; ... }; + + notify \fInotifytype\fR; + notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) + [ port \fIinteger\fR ]; ... }; + allow-notify { \fIaddress_match_element\fR; ... }; + + forward ( first | only ); + forwarders [ port \fIinteger\fR ] { + ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... + }; + + max-journal-size \fIsize_no_default\fR; + max-transfer-time-in \fIinteger\fR; + max-transfer-time-out \fIinteger\fR; + max-transfer-idle-in \fIinteger\fR; + max-transfer-idle-out \fIinteger\fR; + max-retry-time \fIinteger\fR; + min-retry-time \fIinteger\fR; + max-refresh-time \fIinteger\fR; + min-refresh-time \fIinteger\fR; + multi-master \fIboolean\fR; + sig-validity-interval \fIinteger\fR; + + transfer-source ( \fIipv4_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + transfer-source-v6 ( \fIipv6_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + + alt-transfer-source ( \fIipv4_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + alt-transfer-source-v6 ( \fIipv6_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + use-alt-transfer-source \fIboolean\fR; + + zone-statistics \fIboolean\fR; + key-directory \fIquoted_string\fR; + + allow-v6-synthesis { \fIaddress_match_element\fR; ... }; // obsolete + deallocate-on-exit \fIboolean\fR; // obsolete + fake-iquery \fIboolean\fR; // obsolete + fetch-glue \fIboolean\fR; // obsolete + has-old-clients \fIboolean\fR; // obsolete + maintain-ixfr-base \fIboolean\fR; // obsolete + max-ixfr-log-size \fIsize\fR; // obsolete + multiple-cnames \fIboolean\fR; // obsolete + named-xfer \fIquoted_string\fR; // obsolete + serial-queries \fIinteger\fR; // obsolete + treat-cr-as-space \fIboolean\fR; // obsolete + use-id-pool \fIboolean\fR; // obsolete +}; +.sp +.fi +.SH "VIEW" +.sp +.nf +view \fIstring\fR \fIoptional_class\fR { + match-clients { \fIaddress_match_element\fR; ... }; + match-destinations { \fIaddress_match_element\fR; ... }; + match-recursive-only \fIboolean\fR; + + key \fIstring\fR { + algorithm \fIstring\fR; + secret \fIstring\fR; + }; + + zone \fIstring\fR \fIoptional_class\fR { + ... + }; + + server ( \fIipv4_address\fR | \fIipv6_address\fR ) { + ... + }; + + trusted-keys { + \fIstring\fR \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; ... + }; + + allow-recursion { \fIaddress_match_element\fR; ... }; + sortlist { \fIaddress_match_element\fR; ... }; + topology { \fIaddress_match_element\fR; ... }; // not implemented + auth-nxdomain \fIboolean\fR; // default changed + minimal-responses \fIboolean\fR; + recursion \fIboolean\fR; + rrset-order { + [ class \fIstring\fR ] [ type \fIstring\fR ] + [ name \fIquoted_string\fR ] \fIstring\fR \fIstring\fR; ... + }; + provide-ixfr \fIboolean\fR; + request-ixfr \fIboolean\fR; + rfc2308-type1 \fIboolean\fR; // not yet implemented + additional-from-auth \fIboolean\fR; + additional-from-cache \fIboolean\fR; + query-source \fIquerysource4\fR; + query-source-v6 \fIquerysource6\fR; + cleaning-interval \fIinteger\fR; + min-roots \fIinteger\fR; // not implemented + lame-ttl \fIinteger\fR; + max-ncache-ttl \fIinteger\fR; + max-cache-ttl \fIinteger\fR; + transfer-format ( many-answers | one-answer ); + max-cache-size \fIsize_no_default\fR; + check-names ( master | slave | response ) + ( fail | warn | ignore ); + cache-file \fIquoted_string\fR; + suppress-initial-notify \fIboolean\fR; // not yet implemented + preferred-glue \fIstring\fR; + dual-stack-servers [ port \fIinteger\fR ] { + ( \fIquoted_string\fR [port \fIinteger\fR] | + \fIipv4_address\fR [port \fIinteger\fR] | + \fIipv6_address\fR [port \fIinteger\fR] ); ... + }; + edns-udp-size \fIinteger\fR; + root-delegation-only [ exclude { \fIquoted_string\fR; ... } ]; + disable-algorithms \fIstring\fR { \fIstring\fR; ... }; + dnssec-enable \fIboolean\fR; + dnssec-lookaside \fIstring\fR trust-anchor \fIstring\fR; + + dnssec-must-be-secure \fIstring\fR \fIboolean\fR; + dialup \fIdialuptype\fR; + ixfr-from-differences \fIixfrdiff\fR; + + allow-query { \fIaddress_match_element\fR; ... }; + allow-transfer { \fIaddress_match_element\fR; ... }; + allow-update-forwarding { \fIaddress_match_element\fR; ... }; + + notify \fInotifytype\fR; + notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) + [ port \fIinteger\fR ]; ... }; + allow-notify { \fIaddress_match_element\fR; ... }; + + forward ( first | only ); + forwarders [ port \fIinteger\fR ] { + ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... + }; + + max-journal-size \fIsize_no_default\fR; + max-transfer-time-in \fIinteger\fR; + max-transfer-time-out \fIinteger\fR; + max-transfer-idle-in \fIinteger\fR; + max-transfer-idle-out \fIinteger\fR; + max-retry-time \fIinteger\fR; + min-retry-time \fIinteger\fR; + max-refresh-time \fIinteger\fR; + min-refresh-time \fIinteger\fR; + multi-master \fIboolean\fR; + sig-validity-interval \fIinteger\fR; + + transfer-source ( \fIipv4_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + transfer-source-v6 ( \fIipv6_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + + alt-transfer-source ( \fIipv4_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + alt-transfer-source-v6 ( \fIipv6_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + use-alt-transfer-source \fIboolean\fR; + + zone-statistics \fIboolean\fR; + key-directory \fIquoted_string\fR; + + allow-v6-synthesis { \fIaddress_match_element\fR; ... }; // obsolete + fetch-glue \fIboolean\fR; // obsolete + maintain-ixfr-base \fIboolean\fR; // obsolete + max-ixfr-log-size \fIsize\fR; // obsolete +}; +.sp +.fi +.SH "ZONE" +.sp +.nf +zone \fIstring\fR \fIoptional_class\fR { + type ( master | slave | stub | hint | + forward | delegation-only ); + file \fIquoted_string\fR; + + masters [ port \fIinteger\fR ] { + ( \fImasters\fR | + \fIipv4_address\fR [port \fIinteger\fR] | + \fIipv6_address\fR [ port \fIinteger\fR ] ) [ key \fIstring\fR ]; ... + }; + + database \fIstring\fR; + delegation-only \fIboolean\fR; + check-names ( fail | warn | ignore ); + dialup \fIdialuptype\fR; + ixfr-from-differences \fIboolean\fR; + + allow-query { \fIaddress_match_element\fR; ... }; + allow-transfer { \fIaddress_match_element\fR; ... }; + allow-update { \fIaddress_match_element\fR; ... }; + allow-update-forwarding { \fIaddress_match_element\fR; ... }; + update-policy { + ( grant | deny ) \fIstring\fR + ( name | subdomain | wildcard | self ) \fIstring\fR + \fIrrtypelist\fR; ... + }; + + notify \fInotifytype\fR; + notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) + [ port \fIinteger\fR ]; ... }; + allow-notify { \fIaddress_match_element\fR; ... }; + + forward ( first | only ); + forwarders [ port \fIinteger\fR ] { + ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... + }; + + max-journal-size \fIsize_no_default\fR; + max-transfer-time-in \fIinteger\fR; + max-transfer-time-out \fIinteger\fR; + max-transfer-idle-in \fIinteger\fR; + max-transfer-idle-out \fIinteger\fR; + max-retry-time \fIinteger\fR; + min-retry-time \fIinteger\fR; + max-refresh-time \fIinteger\fR; + min-refresh-time \fIinteger\fR; + multi-master \fIboolean\fR; + sig-validity-interval \fIinteger\fR; + + transfer-source ( \fIipv4_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + transfer-source-v6 ( \fIipv6_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + + alt-transfer-source ( \fIipv4_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + alt-transfer-source-v6 ( \fIipv6_address\fR | * ) + [ port ( \fIinteger\fR | * ) ]; + use-alt-transfer-source \fIboolean\fR; + + zone-statistics \fIboolean\fR; + key-directory \fIquoted_string\fR; + + ixfr-base \fIquoted_string\fR; // obsolete + ixfr-tmp-file \fIquoted_string\fR; // obsolete + maintain-ixfr-base \fIboolean\fR; // obsolete + max-ixfr-log-size \fIsize\fR; // obsolete + pubkey \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; // obsolete +}; +.sp +.fi +.SH "FILES" +.PP +\fI/etc/named.conf\fR +.SH "SEE ALSO" +.PP +\fBnamed\fR(8), +\fBrndc\fR(8), +\fBBIND 9 Adminstrators Reference Manual\fR. diff --git a/contrib/bind9/bin/named/named.conf.docbook b/contrib/bind9/bin/named/named.conf.docbook new file mode 100644 index 000000000000..ba6ac12d3734 --- /dev/null +++ b/contrib/bind9/bin/named/named.conf.docbook @@ -0,0 +1,532 @@ + + + + + + + + Aug 13, 2004 + + + + named.conf + 5 + BIND9 + + + + named.conf + configuration file for named + + + + + named.conf + + + + + DESCRIPTION + + named.conf is the configuration file for + named. Statements are enclosed + in braces and terminated with a semi-colon. Clauses in + the statements are also semi-colon terminated. The usual + comment styles are supported: + + + C style: /* */ + + + C++ style: // to end of line + + + Unix style: # to end of line + + + + +ACL + +acl string { address_match_element; ... }; + + + + + +KEY + +key domain_name { + algorithm string; + secret string; +}; + + + + +MASTERS + +masters string port integer { + ( masters | ipv4_address port integer | + ipv6_address port integer ) key string ; ... +}; + + + + +SERVER + +server ( ipv4_address | ipv6_address ) { + bogus boolean; + edns boolean; + provide-ixfr boolean; + request-ixfr boolean; + keys server_key; + transfers integer; + transfer-format ( many-answers | one-answer ); + transfer-source ( ipv4_address | * ) + port ( integer | * ) ; + transfer-source-v6 ( ipv6_address | * ) + port ( integer | * ) ; + + support-ixfr boolean; // obsolete +}; + + + + +TRUSTED-KEYS + +trusted-keys { + domain_name flags protocol algorithm key; ... +}; + + + + +CONTROLS + +controls { + inet ( ipv4_address | ipv6_address | * ) + port ( integer | * ) + allow { address_match_element; ... } + keys { string; ... } ; + unix unsupported; // not implemented +}; + + + + +LOGGING + +logging { + channel string { + file log_file; + syslog optional_facility; + null; + stderr; + severity log_severity; + print-time boolean; + print-severity boolean; + print-category boolean; + }; + category string { string; ... }; +}; + + + + +LWRES + +lwres { + listen-on port integer { + ( ipv4_address | ipv6_address ) port integer ; ... + }; + view string optional_class; + search { string; ... }; + ndots integer; +}; + + + + +OPTIONS + +options { + avoid-v4-udp-ports { port; ... }; + avoid-v6-udp-ports { port; ... }; + blackhole { address_match_element; ... }; + coresize size; + datasize size; + directory quoted_string; + dump-file quoted_string; + files size; + heartbeat-interval integer; + host-statistics boolean; // not implemented + hostname ( quoted_string | none ); + interface-interval integer; + listen-on port integer { address_match_element; ... }; + listen-on-v6 port integer { address_match_element; ... }; + match-mapped-addresses boolean; + memstatistics-file quoted_string; + pid-file ( quoted_string | none ); + port integer; + querylog boolean; + recursing-file quoted_string; + random-device quoted_string; + recursive-clients integer; + serial-query-rate integer; + server-id ( quoted_string | none |; + stacksize size; + statistics-file quoted_string; + statistics-interval integer; // not yet implemented + tcp-clients integer; + tcp-listen-queue integer; + tkey-dhkey quoted_string integer; + tkey-gssapi-credential quoted_string; + tkey-domain quoted_string; + transfers-per-ns integer; + transfers-in integer; + transfers-out integer; + use-ixfr boolean; + version ( quoted_string | none ); + allow-recursion { address_match_element; ... }; + sortlist { address_match_element; ... }; + topology { address_match_element; ... }; // not implemented + auth-nxdomain boolean; // default changed + minimal-responses boolean; + recursion boolean; + rrset-order { + class string type string + name quoted_string string string; ... + }; + provide-ixfr boolean; + request-ixfr boolean; + rfc2308-type1 boolean; // not yet implemented + additional-from-auth boolean; + additional-from-cache boolean; + query-source querysource4; + query-source-v6 querysource6; + cleaning-interval integer; + min-roots integer; // not implemented + lame-ttl integer; + max-ncache-ttl integer; + max-cache-ttl integer; + transfer-format ( many-answers | one-answer ); + max-cache-size size_no_default; + check-names ( master | slave | response ) + ( fail | warn | ignore ); + cache-file quoted_string; + suppress-initial-notify boolean; // not yet implemented + preferred-glue string; + dual-stack-servers port integer { + ( quoted_string port integer | + ipv4_address port integer | + ipv6_address port integer ); ... + } + edns-udp-size integer; + root-delegation-only exclude { quoted_string; ... } ; + disable-algorithms string { string; ... }; + dnssec-enable boolean; + dnssec-lookaside string trust-anchor string; + dnssec-must-be-secure string boolean; + + dialup dialuptype; + ixfr-from-differences ixfrdiff; + + allow-query { address_match_element; ... }; + allow-transfer { address_match_element; ... }; + allow-update-forwarding { address_match_element; ... }; + + notify notifytype; + notify-source ( ipv4_address | * ) port ( integer | * ) ; + notify-source-v6 ( ipv6_address | * ) port ( integer | * ) ; + also-notify port integer { ( ipv4_address | ipv6_address ) + port integer ; ... }; + allow-notify { address_match_element; ... }; + + forward ( first | only ); + forwarders port integer { + ( ipv4_address | ipv6_address ) port integer ; ... + }; + + max-journal-size size_no_default; + max-transfer-time-in integer; + max-transfer-time-out integer; + max-transfer-idle-in integer; + max-transfer-idle-out integer; + max-retry-time integer; + min-retry-time integer; + max-refresh-time integer; + min-refresh-time integer; + multi-master boolean; + sig-validity-interval integer; + + transfer-source ( ipv4_address | * ) + port ( integer | * ) ; + transfer-source-v6 ( ipv6_address | * ) + port ( integer | * ) ; + + alt-transfer-source ( ipv4_address | * ) + port ( integer | * ) ; + alt-transfer-source-v6 ( ipv6_address | * ) + port ( integer | * ) ; + use-alt-transfer-source boolean; + + zone-statistics boolean; + key-directory quoted_string; + + allow-v6-synthesis { address_match_element; ... }; // obsolete + deallocate-on-exit boolean; // obsolete + fake-iquery boolean; // obsolete + fetch-glue boolean; // obsolete + has-old-clients boolean; // obsolete + maintain-ixfr-base boolean; // obsolete + max-ixfr-log-size size; // obsolete + multiple-cnames boolean; // obsolete + named-xfer quoted_string; // obsolete + serial-queries integer; // obsolete + treat-cr-as-space boolean; // obsolete + use-id-pool boolean; // obsolete +}; + + + + +VIEW + +view string optional_class { + match-clients { address_match_element; ... }; + match-destinations { address_match_element; ... }; + match-recursive-only boolean; + + key string { + algorithm string; + secret string; + }; + + zone string optional_class { + ... + }; + + server ( ipv4_address | ipv6_address ) { + ... + }; + + trusted-keys { + string integer integer integer quoted_string; ... + }; + + allow-recursion { address_match_element; ... }; + sortlist { address_match_element; ... }; + topology { address_match_element; ... }; // not implemented + auth-nxdomain boolean; // default changed + minimal-responses boolean; + recursion boolean; + rrset-order { + class string type string + name quoted_string string string; ... + }; + provide-ixfr boolean; + request-ixfr boolean; + rfc2308-type1 boolean; // not yet implemented + additional-from-auth boolean; + additional-from-cache boolean; + query-source querysource4; + query-source-v6 querysource6; + cleaning-interval integer; + min-roots integer; // not implemented + lame-ttl integer; + max-ncache-ttl integer; + max-cache-ttl integer; + transfer-format ( many-answers | one-answer ); + max-cache-size size_no_default; + check-names ( master | slave | response ) + ( fail | warn | ignore ); + cache-file quoted_string; + suppress-initial-notify boolean; // not yet implemented + preferred-glue string; + dual-stack-servers port integer { + ( quoted_string port integer | + ipv4_address port integer | + ipv6_address port integer ); ... + }; + edns-udp-size integer; + root-delegation-only exclude { quoted_string; ... } ; + disable-algorithms string { string; ... }; + dnssec-enable boolean; + dnssec-lookaside string trust-anchor string; + + dnssec-must-be-secure string boolean; + dialup dialuptype; + ixfr-from-differences ixfrdiff; + + allow-query { address_match_element; ... }; + allow-transfer { address_match_element; ... }; + allow-update-forwarding { address_match_element; ... }; + + notify notifytype; + notify-source ( ipv4_address | * ) port ( integer | * ) ; + notify-source-v6 ( ipv6_address | * ) port ( integer | * ) ; + also-notify port integer { ( ipv4_address | ipv6_address ) + port integer ; ... }; + allow-notify { address_match_element; ... }; + + forward ( first | only ); + forwarders port integer { + ( ipv4_address | ipv6_address ) port integer ; ... + }; + + max-journal-size size_no_default; + max-transfer-time-in integer; + max-transfer-time-out integer; + max-transfer-idle-in integer; + max-transfer-idle-out integer; + max-retry-time integer; + min-retry-time integer; + max-refresh-time integer; + min-refresh-time integer; + multi-master boolean; + sig-validity-interval integer; + + transfer-source ( ipv4_address | * ) + port ( integer | * ) ; + transfer-source-v6 ( ipv6_address | * ) + port ( integer | * ) ; + + alt-transfer-source ( ipv4_address | * ) + port ( integer | * ) ; + alt-transfer-source-v6 ( ipv6_address | * ) + port ( integer | * ) ; + use-alt-transfer-source boolean; + + zone-statistics boolean; + key-directory quoted_string; + + allow-v6-synthesis { address_match_element; ... }; // obsolete + fetch-glue boolean; // obsolete + maintain-ixfr-base boolean; // obsolete + max-ixfr-log-size size; // obsolete +}; + + + + +ZONE + +zone string optional_class { + type ( master | slave | stub | hint | + forward | delegation-only ); + file quoted_string; + + masters port integer { + ( masters | + ipv4_address port integer | + ipv6_address port integer ) key string ; ... + }; + + database string; + delegation-only boolean; + check-names ( fail | warn | ignore ); + dialup dialuptype; + ixfr-from-differences boolean; + + allow-query { address_match_element; ... }; + allow-transfer { address_match_element; ... }; + allow-update { address_match_element; ... }; + allow-update-forwarding { address_match_element; ... }; + update-policy { + ( grant | deny ) string + ( name | subdomain | wildcard | self ) string + rrtypelist; ... + }; + + notify notifytype; + notify-source ( ipv4_address | * ) port ( integer | * ) ; + notify-source-v6 ( ipv6_address | * ) port ( integer | * ) ; + also-notify port integer { ( ipv4_address | ipv6_address ) + port integer ; ... }; + allow-notify { address_match_element; ... }; + + forward ( first | only ); + forwarders port integer { + ( ipv4_address | ipv6_address ) port integer ; ... + }; + + max-journal-size size_no_default; + max-transfer-time-in integer; + max-transfer-time-out integer; + max-transfer-idle-in integer; + max-transfer-idle-out integer; + max-retry-time integer; + min-retry-time integer; + max-refresh-time integer; + min-refresh-time integer; + multi-master boolean; + sig-validity-interval integer; + + transfer-source ( ipv4_address | * ) + port ( integer | * ) ; + transfer-source-v6 ( ipv6_address | * ) + port ( integer | * ) ; + + alt-transfer-source ( ipv4_address | * ) + port ( integer | * ) ; + alt-transfer-source-v6 ( ipv6_address | * ) + port ( integer | * ) ; + use-alt-transfer-source boolean; + + zone-statistics boolean; + key-directory quoted_string; + + ixfr-base quoted_string; // obsolete + ixfr-tmp-file quoted_string; // obsolete + maintain-ixfr-base boolean; // obsolete + max-ixfr-log-size size; // obsolete + pubkey integer integer integer quoted_string; // obsolete +}; + + + + +FILES + +/etc/named.conf + + + + +SEE ALSO + + +named8 +, + +rndc8 +, + +BIND 9 Adminstrators Reference Manual +. + + + + + diff --git a/contrib/bind9/bin/named/named.conf.html b/contrib/bind9/bin/named/named.conf.html new file mode 100644 index 000000000000..999152291832 --- /dev/null +++ b/contrib/bind9/bin/named/named.conf.html @@ -0,0 +1,1893 @@ + + + + + +named.conf

named.conf

Name

named.conf -- configuration file for named

Synopsis

named.conf

DESCRIPTION

named.conf is the configuration file for + named. Statements are enclosed + in braces and terminated with a semi-colon. Clauses in + the statements are also semi-colon terminated. The usual + comment styles are supported: +

C style: /* */ +

C++ style: // to end of line +

Unix style: # to end of line +

ACL

acl string { address_match_element; ... };

KEY

key domain_name {
+ algorithm string;
+ secret string;
+};

MASTERS

masters string [ port integer ] {
+ ( masters | ipv4_address [port integer] |
+ ipv6_address [port integer] ) [ key string ]; ...
+};

SERVER

server ( ipv4_address | ipv6_address ) {
+ bogus boolean;
+ edns boolean;
+ provide-ixfr boolean;
+ request-ixfr boolean;
+ keys server_key;
+ transfers integer;
+ transfer-format ( many-answers | one-answer );
+ transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+
+ support-ixfr boolean; // obsolete
+};

TRUSTED-KEYS

trusted-keys {
+ domain_name flags protocol algorithm key; ... 
+};

CONTROLS

controls {
+ inet ( ipv4_address | ipv6_address | * )
+ [ port ( integer | * ) ]
+ allow { address_match_element; ... }
+ [ keys { string; ... } ];
+ unix unsupported; // not implemented
+};

LOGGING

logging {
+ channel string {
+ file log_file;
+ syslog optional_facility;
+ null;
+ stderr;
+ severity log_severity;
+ print-time boolean;
+ print-severity boolean;
+ print-category boolean;
+ };
+ category string { string; ... };
+};

LWRES

lwres {
+ listen-on [ port integer ] {
+ ( ipv4_address | ipv6_address ) [ port integer ]; ...
+ };
+ view string optional_class;
+ search { string; ... };
+ ndots integer;
+};

OPTIONS

options {
+ avoid-v4-udp-ports { port; ... };
+ avoid-v6-udp-ports { port; ... };
+ blackhole { address_match_element; ... };
+ coresize size;
+ datasize size;
+ directory quoted_string;
+ dump-file quoted_string;
+ files size;
+ heartbeat-interval integer;
+ host-statistics boolean; // not implemented
+ hostname ( quoted_string | none );
+ interface-interval integer;
+ listen-on [ port integer ] { address_match_element; ... };
+ listen-on-v6 [ port integer ] { address_match_element; ... };
+ match-mapped-addresses boolean;
+ memstatistics-file quoted_string;
+ pid-file ( quoted_string | none );
+ port integer;
+ querylog boolean;
+ recursing-file quoted_string;
+ random-device quoted_string;
+ recursive-clients integer;
+ serial-query-rate integer;
+ server-id ( quoted_string | none |;
+ stacksize size;
+ statistics-file quoted_string;
+ statistics-interval integer; // not yet implemented
+ tcp-clients integer;
+ tcp-listen-queue integer;
+ tkey-dhkey quoted_string integer;
+ tkey-gssapi-credential quoted_string;
+ tkey-domain quoted_string;
+ transfers-per-ns integer;
+ transfers-in integer;
+ transfers-out integer;
+ use-ixfr boolean;
+ version ( quoted_string | none );
+ allow-recursion { address_match_element; ... };
+ sortlist { address_match_element; ... };
+ topology { address_match_element; ... }; // not implemented
+ auth-nxdomain boolean; // default changed
+ minimal-responses boolean;
+ recursion boolean;
+ rrset-order {
+ [ class string ] [ type string ]
+ [ name quoted_string ] string string; ...
+ };
+ provide-ixfr boolean;
+ request-ixfr boolean;
+ rfc2308-type1 boolean; // not yet implemented
+ additional-from-auth boolean;
+ additional-from-cache boolean;
+ query-source querysource4;
+ query-source-v6 querysource6;
+ cleaning-interval integer;
+ min-roots integer; // not implemented
+ lame-ttl integer;
+ max-ncache-ttl integer;
+ max-cache-ttl integer;
+ transfer-format ( many-answers | one-answer );
+ max-cache-size size_no_default;
+ check-names ( master | slave | response )
+ ( fail | warn | ignore );
+ cache-file quoted_string;
+ suppress-initial-notify boolean; // not yet implemented
+ preferred-glue string;
+ dual-stack-servers [ port integer ] {
+ ( quoted_string [port integer] |
+ ipv4_address [port integer] |
+ ipv6_address [port integer] ); ...
+ }
+ edns-udp-size integer;
+ root-delegation-only [ exclude { quoted_string; ... } ];
+ disable-algorithms string { string; ... };
+ dnssec-enable boolean;
+ dnssec-lookaside string trust-anchor string;
+ dnssec-must-be-secure string boolean;
+
+ dialup dialuptype;
+ ixfr-from-differences ixfrdiff;
+
+ allow-query { address_match_element; ... };
+ allow-transfer { address_match_element; ... };
+ allow-update-forwarding { address_match_element; ... };
+
+ notify notifytype;
+ notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
+ notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
+ also-notify [ port integer ] { ( ipv4_address | ipv6_address )
+ [ port integer ]; ... };
+ allow-notify { address_match_element; ... };
+
+ forward ( first | only );
+ forwarders [ port integer ] {
+ ( ipv4_address | ipv6_address ) [ port integer ]; ...
+ };
+
+ max-journal-size size_no_default;
+ max-transfer-time-in integer;
+ max-transfer-time-out integer;
+ max-transfer-idle-in integer;
+ max-transfer-idle-out integer;
+ max-retry-time integer;
+ min-retry-time integer;
+ max-refresh-time integer;
+ min-refresh-time integer;
+ multi-master boolean;
+ sig-validity-interval integer;
+
+ transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+
+ alt-transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ alt-transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+ use-alt-transfer-source boolean;
+
+ zone-statistics boolean;
+ key-directory quoted_string;
+
+ allow-v6-synthesis { address_match_element; ... }; // obsolete
+ deallocate-on-exit boolean; // obsolete
+ fake-iquery boolean; // obsolete
+ fetch-glue boolean; // obsolete
+ has-old-clients boolean; // obsolete
+ maintain-ixfr-base boolean; // obsolete
+ max-ixfr-log-size size; // obsolete
+ multiple-cnames boolean; // obsolete
+ named-xfer quoted_string; // obsolete
+ serial-queries integer; // obsolete
+ treat-cr-as-space boolean; // obsolete
+ use-id-pool boolean; // obsolete
+};

VIEW

view string optional_class {
+ match-clients { address_match_element; ... };
+ match-destinations { address_match_element; ... };
+ match-recursive-only boolean;
+
+ key string {
+ algorithm string;
+ secret string;
+ };
+
+ zone string optional_class {
+ ...
+ };
+
+ server ( ipv4_address | ipv6_address ) {
+ ...
+ };
+
+ trusted-keys {
+ string integer integer integer quoted_string; ...
+ };
+
+ allow-recursion { address_match_element; ... };
+ sortlist { address_match_element; ... };
+ topology { address_match_element; ... }; // not implemented
+ auth-nxdomain boolean; // default changed
+ minimal-responses boolean;
+ recursion boolean;
+ rrset-order {
+ [ class string ] [ type string ]
+ [ name quoted_string ] string string; ...
+ };
+ provide-ixfr boolean;
+ request-ixfr boolean;
+ rfc2308-type1 boolean; // not yet implemented
+ additional-from-auth boolean;
+ additional-from-cache boolean;
+ query-source querysource4;
+ query-source-v6 querysource6;
+ cleaning-interval integer;
+ min-roots integer; // not implemented
+ lame-ttl integer;
+ max-ncache-ttl integer;
+ max-cache-ttl integer;
+ transfer-format ( many-answers | one-answer );
+ max-cache-size size_no_default;
+ check-names ( master | slave | response )
+ ( fail | warn | ignore );
+ cache-file quoted_string;
+ suppress-initial-notify boolean; // not yet implemented
+ preferred-glue string;
+ dual-stack-servers [ port integer ] {
+ ( quoted_string [port integer] |
+ ipv4_address [port integer] |
+ ipv6_address [port integer] ); ...
+ };
+ edns-udp-size integer;
+ root-delegation-only [ exclude { quoted_string; ... } ];
+ disable-algorithms string { string; ... };
+ dnssec-enable boolean;
+ dnssec-lookaside string trust-anchor string;
+
+ dnssec-must-be-secure string boolean;
+ dialup dialuptype;
+ ixfr-from-differences ixfrdiff;
+
+ allow-query { address_match_element; ... };
+ allow-transfer { address_match_element; ... };
+ allow-update-forwarding { address_match_element; ... };
+
+ notify notifytype;
+ notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
+ notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
+ also-notify [ port integer ] { ( ipv4_address | ipv6_address )
+ [ port integer ]; ... };
+ allow-notify { address_match_element; ... };
+
+ forward ( first | only );
+ forwarders [ port integer ] {
+ ( ipv4_address | ipv6_address ) [ port integer ]; ...
+ };
+
+ max-journal-size size_no_default;
+ max-transfer-time-in integer;
+ max-transfer-time-out integer;
+ max-transfer-idle-in integer;
+ max-transfer-idle-out integer;
+ max-retry-time integer;
+ min-retry-time integer;
+ max-refresh-time integer;
+ min-refresh-time integer;
+ multi-master boolean;
+ sig-validity-interval integer;
+
+ transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+
+ alt-transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ alt-transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+ use-alt-transfer-source boolean;
+
+ zone-statistics boolean;
+ key-directory quoted_string;
+
+ allow-v6-synthesis { address_match_element; ... }; // obsolete
+ fetch-glue boolean; // obsolete
+ maintain-ixfr-base boolean; // obsolete
+ max-ixfr-log-size size; // obsolete
+};

ZONE

zone string optional_class {
+ type ( master | slave | stub | hint |
+ forward | delegation-only );
+ file quoted_string;
+
+ masters [ port integer ] {
+ ( masters |
+ ipv4_address [port integer] |
+ ipv6_address [ port integer ] ) [ key string ]; ...
+ };
+
+ database string;
+ delegation-only boolean;
+ check-names ( fail | warn | ignore );
+ dialup dialuptype;
+ ixfr-from-differences boolean;
+
+ allow-query { address_match_element; ... };
+ allow-transfer { address_match_element; ... };
+ allow-update { address_match_element; ... };
+ allow-update-forwarding { address_match_element; ... };
+ update-policy {
+ ( grant | deny ) string
+ ( name | subdomain | wildcard | self ) string
+ rrtypelist; ...
+ };
+
+ notify notifytype;
+ notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
+ notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
+ also-notify [ port integer ] { ( ipv4_address | ipv6_address )
+ [ port integer ]; ... };
+ allow-notify { address_match_element; ... };
+
+ forward ( first | only );
+ forwarders [ port integer ] {
+ ( ipv4_address | ipv6_address ) [ port integer ]; ...
+ };
+
+ max-journal-size size_no_default;
+ max-transfer-time-in integer;
+ max-transfer-time-out integer;
+ max-transfer-idle-in integer;
+ max-transfer-idle-out integer;
+ max-retry-time integer;
+ min-retry-time integer;
+ max-refresh-time integer;
+ min-refresh-time integer;
+ multi-master boolean;
+ sig-validity-interval integer;
+
+ transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+
+ alt-transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ alt-transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+ use-alt-transfer-source boolean;
+
+ zone-statistics boolean;
+ key-directory quoted_string;
+
+ ixfr-base quoted_string; // obsolete
+ ixfr-tmp-file quoted_string; // obsolete
+ maintain-ixfr-base boolean; // obsolete
+ max-ixfr-log-size size; // obsolete
+ pubkey integer integer integer quoted_string; // obsolete
+};

FILES

/etc/named.conf

SEE ALSO

named(8), +rndc(8), +BIND 9 Adminstrators Reference Manual.

diff --git a/contrib/bind9/bin/named/named.docbook b/contrib/bind9/bin/named/named.docbook new file mode 100644 index 000000000000..754f1a07c141 --- /dev/null +++ b/contrib/bind9/bin/named/named.docbook @@ -0,0 +1,370 @@ + + + + + + + + June 30, 2000 + + + + named + 8 + BIND9 + + + + named + Internet domain name server + + + + + named + + + + + + + + + + + + + + + + + + DESCRIPTION + + named is a Domain Name System (DNS) server, + part of the BIND 9 distribution from ISC. For more + information on the DNS, see RFCs 1033, 1034, and 1035. + + + When invoked without arguments, named will + read the default configuration file + /etc/named.conf, read any initial + data, and listen for queries. + + + + + OPTIONS + + + + -4 + + + Use IPv4 only even if the host machine is capable of IPv6. + and are mutually + exclusive. + + + + + + -6 + + + Use IPv6 only even if the host machine is capable of IPv4. + and are mutually + exclusive. + + + + + -c config-file + + + Use config-file as the + configuration file instead of the default, + /etc/named.conf. To + ensure that reloading the configuration file continues + to work after the server has changed its working + directory due to to a possible + option in the configuration + file, config-file should be + an absolute pathname. + + + + + + -d debug-level + + + Set the daemon's debug level to debug-level. + Debugging traces from named become + more verbose as the debug level increases. + + + + + + -f + + + Run the server in the foreground (i.e. do not daemonize). + + + + + + -g + + + Run the server in the foreground and force all logging + to stderr. + + + + + + -n #cpus + + + Create #cpus worker threads + to take advantage of multiple CPUs. If not specified, + named will try to determine the + number of CPUs present and create one thread per CPU. + If it is unable to determine the number of CPUs, a + single worker thread will be created. + + + + + + -p port + + + Listen for queries on port port. If not + specified, the default is port 53. + + + + + + -s + + + Write memory usage statistics to stdout on exit. + + + + This option is mainly of interest to BIND 9 developers + and may be removed or changed in a future release. + + + + + + + -t directory + + + chroot() to directory after + processing the command line arguments, but before + reading the configuration file. + + + + This option should be used in conjunction with the + option, as chrooting a process + running as root doesn't enhance security on most + systems; the way chroot() is + defined allows a process with root privileges to + escape a chroot jail. + + + + + + + -u user + + + setuid() to user after completing + privileged operations, such as creating sockets that + listen on privileged ports. + + + + On Linux, named uses the kernel's + capability mechanism to drop all root privileges + except the ability to bind() to a + privileged port and set process resource limits. + Unfortunately, this means that the + option only works when named is run + on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or + later, since previous kernels did not allow privileges + to be retained after setuid(). + + + + + + + -v + + + Report the version number and exit. + + + + + + -x cache-file + + + Load data from cache-file into the + cache of the default view. + + + + This option must not be used. It is only of interest + to BIND 9 developers and may be removed or changed in a + future release. + + + + + + + + + + + SIGNALS + + In routine operation, signals should not be used to control + the nameserver; rndc should be used + instead. + + + + + + SIGHUP + + + Force a reload of the server. + + + + + + SIGINT, SIGTERM + + + Shut down the server. + + + + + + + + The result of sending any other signals to the server is undefined. + + + + + + CONFIGURATION + + The named configuration file is too complex + to describe in detail here. A complete description is + provided in the BIND 9 Administrator Reference + Manual. + + + + + FILES + + + + + /etc/named.conf + + + The default configuration file. + + + + + + /var/run/named.pid + + + The default process-id file. + + + + + + + + + + SEE ALSO + + RFC 1033, + RFC 1034, + RFC 1035, + + rndc + 8 + , + + lwresd + 8 + , + BIND 9 Administrator Reference Manual. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + + diff --git a/contrib/bind9/bin/named/named.html b/contrib/bind9/bin/named/named.html new file mode 100644 index 000000000000..8ee16e684f1d --- /dev/null +++ b/contrib/bind9/bin/named/named.html @@ -0,0 +1,625 @@ + + + + + +named

named

Name

named -- Internet domain name server

Synopsis

named [-4] [-6] [-c config-file] [-d debug-level] [-f] [-g] [-n #cpus] [-p port] [-s] [-t directory] [-u user] [-v] [-x cache-file]

DESCRIPTION

named is a Domain Name System (DNS) server, + part of the BIND 9 distribution from ISC. For more + information on the DNS, see RFCs 1033, 1034, and 1035. +

When invoked without arguments, named will + read the default configuration file + /etc/named.conf, read any initial + data, and listen for queries. +

OPTIONS

-4

Use IPv4 only even if the host machine is capable of IPv6. + -4 and -6 are mutually + exclusive. +

-6

Use IPv6 only even if the host machine is capable of IPv4. + -4 and -6 are mutually + exclusive. +

-c config-file

Use config-file as the + configuration file instead of the default, + /etc/named.conf. To + ensure that reloading the configuration file continues + to work after the server has changed its working + directory due to to a possible + directory option in the configuration + file, config-file should be + an absolute pathname. +

-d debug-level

Set the daemon's debug level to debug-level. + Debugging traces from named become + more verbose as the debug level increases. +

-f

Run the server in the foreground (i.e. do not daemonize). +

-g

Run the server in the foreground and force all logging + to stderr. +

-n #cpus

Create #cpus worker threads + to take advantage of multiple CPUs. If not specified, + named will try to determine the + number of CPUs present and create one thread per CPU. + If it is unable to determine the number of CPUs, a + single worker thread will be created. +

-p port

Listen for queries on port port. If not + specified, the default is port 53. +

-s

Write memory usage statistics to stdout on exit. +

Note: This option is mainly of interest to BIND 9 developers + and may be removed or changed in a future release. +

-t directory

chroot() to directory after + processing the command line arguments, but before + reading the configuration file. +

Warning

This option should be used in conjunction with the + -u option, as chrooting a process + running as root doesn't enhance security on most + systems; the way chroot() is + defined allows a process with root privileges to + escape a chroot jail. +

-u user

setuid() to user after completing + privileged operations, such as creating sockets that + listen on privileged ports. +

Note: On Linux, named uses the kernel's + capability mechanism to drop all root privileges + except the ability to bind() to a + privileged port and set process resource limits. + Unfortunately, this means that the -u + option only works when named is run + on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or + later, since previous kernels did not allow privileges + to be retained after setuid(). +

-v

Report the version number and exit. +

-x cache-file

Load data from cache-file into the + cache of the default view. +

Warning

This option must not be used. It is only of interest + to BIND 9 developers and may be removed or changed in a + future release. +

SIGNALS

In routine operation, signals should not be used to control + the nameserver; rndc should be used + instead. +

SIGHUP

Force a reload of the server. +

SIGINT, SIGTERM

Shut down the server. +

The result of sending any other signals to the server is undefined. +

CONFIGURATION

The named configuration file is too complex + to describe in detail here. A complete description is + provided in the BIND 9 Administrator Reference + Manual. +

FILES

/etc/named.conf

The default configuration file. +

/var/run/named.pid

The default process-id file. +

SEE ALSO

RFC 1033, + RFC 1034, + RFC 1035, + rndc(8), + lwresd(8), + BIND 9 Administrator Reference Manual. +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/named/notify.c b/contrib/bind9/bin/named/notify.c new file mode 100644 index 000000000000..e3c5b2a8987e --- /dev/null +++ b/contrib/bind9/bin/named/notify.c @@ -0,0 +1,162 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: notify.c,v 1.24.2.2.2.7 2004/08/28 06:25:30 marka Exp $ */ + +#include + +#include +#include + +#include +#include +#include +#include +#include +#include + +#include +#include + +/* + * This module implements notify as in RFC 1996. + */ + +static void +notify_log(ns_client_t *client, int level, const char *fmt, ...) { + va_list ap; + + va_start(ap, fmt); + ns_client_logv(client, DNS_LOGCATEGORY_NOTIFY, NS_LOGMODULE_NOTIFY, + level, fmt, ap); + va_end(ap); +} + +static void +respond(ns_client_t *client, isc_result_t result) { + dns_rcode_t rcode; + dns_message_t *message; + isc_result_t msg_result; + + message = client->message; + rcode = dns_result_torcode(result); + + msg_result = dns_message_reply(message, ISC_TRUE); + if (msg_result != ISC_R_SUCCESS) + msg_result = dns_message_reply(message, ISC_FALSE); + if (msg_result != ISC_R_SUCCESS) { + ns_client_next(client, msg_result); + return; + } + message->rcode = rcode; + if (rcode == dns_rcode_noerror) + message->flags |= DNS_MESSAGEFLAG_AA; + else + message->flags &= ~DNS_MESSAGEFLAG_AA; + ns_client_send(client); +} + +void +ns_notify_start(ns_client_t *client) { + dns_message_t *request = client->message; + isc_result_t result; + dns_name_t *zonename; + dns_rdataset_t *zone_rdataset; + dns_zone_t *zone = NULL; + char namebuf[DNS_NAME_FORMATSIZE]; + char tsigbuf[DNS_NAME_FORMATSIZE + sizeof(": TSIG ''")]; + dns_name_t *tsigname; + + /* + * Interpret the question section. + */ + result = dns_message_firstname(request, DNS_SECTION_QUESTION); + if (result != ISC_R_SUCCESS) { + notify_log(client, ISC_LOG_NOTICE, + "notify question section empty"); + goto formerr; + } + + /* + * The question section must contain exactly one question. + */ + zonename = NULL; + dns_message_currentname(request, DNS_SECTION_QUESTION, &zonename); + zone_rdataset = ISC_LIST_HEAD(zonename->list); + if (ISC_LIST_NEXT(zone_rdataset, link) != NULL) { + notify_log(client, ISC_LOG_NOTICE, + "notify question section contains multiple RRs"); + goto formerr; + } + + /* The zone section must have exactly one name. */ + result = dns_message_nextname(request, DNS_SECTION_ZONE); + if (result != ISC_R_NOMORE) { + notify_log(client, ISC_LOG_NOTICE, + "notify question section contains multiple RRs"); + goto formerr; + } + + /* The one rdataset must be an SOA. */ + if (zone_rdataset->type != dns_rdatatype_soa) { + notify_log(client, ISC_LOG_NOTICE, + "notify question section contains no SOA"); + goto formerr; + } + + tsigname = NULL; + if (dns_message_gettsig(request, &tsigname) != NULL) { + dns_name_format(tsigname, namebuf, sizeof(namebuf)); + snprintf(tsigbuf, sizeof(tsigbuf), ": TSIG '%s'", namebuf); + } else + tsigbuf[0] = '\0'; + dns_name_format(zonename, namebuf, sizeof(namebuf)); + result = dns_zt_find(client->view->zonetable, zonename, 0, NULL, + &zone); + if (result != ISC_R_SUCCESS) + goto notauth; + + switch (dns_zone_gettype(zone)) { + case dns_zone_master: + case dns_zone_slave: + case dns_zone_stub: /* Allow dialup passive to work. */ + notify_log(client, ISC_LOG_INFO, + "received notify for zone '%s'%s", namebuf, tsigbuf); + respond(client, dns_zone_notifyreceive(zone, + ns_client_getsockaddr(client), request)); + break; + default: + goto notauth; + } + dns_zone_detach(&zone); + return; + + notauth: + notify_log(client, ISC_LOG_NOTICE, + "received notify for zone '%s'%s: not authoritative", + namebuf, tsigbuf); + result = DNS_R_NOTAUTH; + goto failure; + + formerr: + result = DNS_R_FORMERR; + + failure: + if (zone != NULL) + dns_zone_detach(&zone); + respond(client, result); +} diff --git a/contrib/bind9/bin/named/query.c b/contrib/bind9/bin/named/query.c new file mode 100644 index 000000000000..a5411af3433f --- /dev/null +++ b/contrib/bind9/bin/named/query.c @@ -0,0 +1,3539 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: query.c,v 1.198.2.13.4.30 2004/06/30 14:13:05 marka Exp $ */ + +#include + +#include + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#define PARTIALANSWER(c) (((c)->query.attributes & \ + NS_QUERYATTR_PARTIALANSWER) != 0) +#define USECACHE(c) (((c)->query.attributes & \ + NS_QUERYATTR_CACHEOK) != 0) +#define RECURSIONOK(c) (((c)->query.attributes & \ + NS_QUERYATTR_RECURSIONOK) != 0) +#define RECURSING(c) (((c)->query.attributes & \ + NS_QUERYATTR_RECURSING) != 0) +#define CACHEGLUEOK(c) (((c)->query.attributes & \ + NS_QUERYATTR_CACHEGLUEOK) != 0) +#define WANTRECURSION(c) (((c)->query.attributes & \ + NS_QUERYATTR_WANTRECURSION) != 0) +#define WANTDNSSEC(c) (((c)->attributes & \ + NS_CLIENTATTR_WANTDNSSEC) != 0) +#define NOAUTHORITY(c) (((c)->query.attributes & \ + NS_QUERYATTR_NOAUTHORITY) != 0) +#define NOADDITIONAL(c) (((c)->query.attributes & \ + NS_QUERYATTR_NOADDITIONAL) != 0) +#define SECURE(c) (((c)->query.attributes & \ + NS_QUERYATTR_SECURE) != 0) + +#if 0 +#define CTRACE(m) isc_log_write(ns_g_lctx, \ + NS_LOGCATEGORY_CLIENT, \ + NS_LOGMODULE_QUERY, \ + ISC_LOG_DEBUG(3), \ + "client %p: %s", client, (m)) +#define QTRACE(m) isc_log_write(ns_g_lctx, \ + NS_LOGCATEGORY_GENERAL, \ + NS_LOGMODULE_QUERY, \ + ISC_LOG_DEBUG(3), \ + "query %p: %s", query, (m)) +#else +#define CTRACE(m) ((void)m) +#define QTRACE(m) ((void)m) +#endif + +#define DNS_GETDB_NOEXACT 0x01U +#define DNS_GETDB_NOLOG 0x02U +#define DNS_GETDB_PARTIAL 0x04U + +static void +query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype); + +/* + * Increment query statistics counters. + */ +static inline void +inc_stats(ns_client_t *client, dns_statscounter_t counter) { + dns_zone_t *zone = client->query.authzone; + + REQUIRE(counter < DNS_STATS_NCOUNTERS); + + ns_g_server->querystats[counter]++; + + if (zone != NULL) { + isc_uint64_t *zonestats = dns_zone_getstatscounters(zone); + if (zonestats != NULL) + zonestats[counter]++; + } +} + +static void +query_send(ns_client_t *client) { + dns_statscounter_t counter; + if (client->message->rcode == dns_rcode_noerror) { + if (ISC_LIST_EMPTY(client->message->sections[DNS_SECTION_ANSWER])) { + if (client->query.isreferral) { + counter = dns_statscounter_referral; + } else { + counter = dns_statscounter_nxrrset; + } + } else { + counter = dns_statscounter_success; + } + } else if (client->message->rcode == dns_rcode_nxdomain) { + counter = dns_statscounter_nxdomain; + } else { + /* We end up here in case of YXDOMAIN, and maybe others */ + counter = dns_statscounter_failure; + } + inc_stats(client, counter); + ns_client_send(client); +} + +static void +query_error(ns_client_t *client, isc_result_t result) { + inc_stats(client, dns_statscounter_failure); + ns_client_error(client, result); +} + +static void +query_next(ns_client_t *client, isc_result_t result) { + inc_stats(client, dns_statscounter_failure); + ns_client_next(client, result); +} + +static inline void +query_maybeputqname(ns_client_t *client) { + if (client->query.restarts > 0) { + /* + * client->query.qname was dynamically allocated. + */ + dns_message_puttempname(client->message, + &client->query.qname); + client->query.qname = NULL; + } +} + +static inline void +query_freefreeversions(ns_client_t *client, isc_boolean_t everything) { + ns_dbversion_t *dbversion, *dbversion_next; + unsigned int i; + + for (dbversion = ISC_LIST_HEAD(client->query.freeversions), i = 0; + dbversion != NULL; + dbversion = dbversion_next, i++) + { + dbversion_next = ISC_LIST_NEXT(dbversion, link); + /* + * If we're not freeing everything, we keep the first three + * dbversions structures around. + */ + if (i > 3 || everything) { + ISC_LIST_UNLINK(client->query.freeversions, dbversion, + link); + isc_mem_put(client->mctx, dbversion, + sizeof(*dbversion)); + } + } +} + +void +ns_query_cancel(ns_client_t *client) { + LOCK(&client->query.fetchlock); + if (client->query.fetch != NULL) { + dns_resolver_cancelfetch(client->query.fetch); + + client->query.fetch = NULL; + } + UNLOCK(&client->query.fetchlock); +} + +static inline void +query_reset(ns_client_t *client, isc_boolean_t everything) { + isc_buffer_t *dbuf, *dbuf_next; + ns_dbversion_t *dbversion, *dbversion_next; + + /* + * Reset the query state of a client to its default state. + */ + + /* + * Cancel the fetch if it's running. + */ + ns_query_cancel(client); + + /* + * Cleanup any active versions. + */ + for (dbversion = ISC_LIST_HEAD(client->query.activeversions); + dbversion != NULL; + dbversion = dbversion_next) { + dbversion_next = ISC_LIST_NEXT(dbversion, link); + dns_db_closeversion(dbversion->db, &dbversion->version, + ISC_FALSE); + dns_db_detach(&dbversion->db); + ISC_LIST_INITANDAPPEND(client->query.freeversions, + dbversion, link); + } + ISC_LIST_INIT(client->query.activeversions); + + if (client->query.authdb != NULL) + dns_db_detach(&client->query.authdb); + if (client->query.authzone != NULL) + dns_zone_detach(&client->query.authzone); + + query_freefreeversions(client, everything); + + for (dbuf = ISC_LIST_HEAD(client->query.namebufs); + dbuf != NULL; + dbuf = dbuf_next) { + dbuf_next = ISC_LIST_NEXT(dbuf, link); + if (dbuf_next != NULL || everything) { + ISC_LIST_UNLINK(client->query.namebufs, dbuf, link); + isc_buffer_free(&dbuf); + } + } + + query_maybeputqname(client); + + client->query.attributes = (NS_QUERYATTR_RECURSIONOK | + NS_QUERYATTR_CACHEOK | + NS_QUERYATTR_SECURE); + client->query.restarts = 0; + client->query.timerset = ISC_FALSE; + client->query.origqname = NULL; + client->query.qname = NULL; + client->query.dboptions = 0; + client->query.fetchoptions = 0; + client->query.gluedb = NULL; + client->query.authdbset = ISC_FALSE; + client->query.isreferral = ISC_FALSE; +} + +static void +query_next_callback(ns_client_t *client) { + query_reset(client, ISC_FALSE); +} + +void +ns_query_free(ns_client_t *client) { + query_reset(client, ISC_TRUE); +} + +static inline isc_result_t +query_newnamebuf(ns_client_t *client) { + isc_buffer_t *dbuf; + isc_result_t result; + + CTRACE("query_newnamebuf"); + /* + * Allocate a name buffer. + */ + + dbuf = NULL; + result = isc_buffer_allocate(client->mctx, &dbuf, 1024); + if (result != ISC_R_SUCCESS) { + CTRACE("query_newnamebuf: isc_buffer_allocate failed: done"); + return (result); + } + ISC_LIST_APPEND(client->query.namebufs, dbuf, link); + + CTRACE("query_newnamebuf: done"); + return (ISC_R_SUCCESS); +} + +static inline isc_buffer_t * +query_getnamebuf(ns_client_t *client) { + isc_buffer_t *dbuf; + isc_result_t result; + isc_region_t r; + + CTRACE("query_getnamebuf"); + /* + * Return a name buffer with space for a maximal name, allocating + * a new one if necessary. + */ + + if (ISC_LIST_EMPTY(client->query.namebufs)) { + result = query_newnamebuf(client); + if (result != ISC_R_SUCCESS) { + CTRACE("query_getnamebuf: query_newnamebuf failed: done"); + return (NULL); + } + } + + dbuf = ISC_LIST_TAIL(client->query.namebufs); + INSIST(dbuf != NULL); + isc_buffer_availableregion(dbuf, &r); + if (r.length < 255) { + result = query_newnamebuf(client); + if (result != ISC_R_SUCCESS) { + CTRACE("query_getnamebuf: query_newnamebuf failed: done"); + return (NULL); + + } + dbuf = ISC_LIST_TAIL(client->query.namebufs); + isc_buffer_availableregion(dbuf, &r); + INSIST(r.length >= 255); + } + CTRACE("query_getnamebuf: done"); + return (dbuf); +} + +static inline void +query_keepname(ns_client_t *client, dns_name_t *name, isc_buffer_t *dbuf) { + isc_region_t r; + + CTRACE("query_keepname"); + /* + * 'name' is using space in 'dbuf', but 'dbuf' has not yet been + * adjusted to take account of that. We do the adjustment. + */ + + REQUIRE((client->query.attributes & NS_QUERYATTR_NAMEBUFUSED) != 0); + + dns_name_toregion(name, &r); + isc_buffer_add(dbuf, r.length); + dns_name_setbuffer(name, NULL); + client->query.attributes &= ~NS_QUERYATTR_NAMEBUFUSED; +} + +static inline void +query_releasename(ns_client_t *client, dns_name_t **namep) { + dns_name_t *name = *namep; + + /* + * 'name' is no longer needed. Return it to our pool of temporary + * names. If it is using a name buffer, relinquish its exclusive + * rights on the buffer. + */ + + CTRACE("query_releasename"); + if (dns_name_hasbuffer(name)) { + INSIST((client->query.attributes & NS_QUERYATTR_NAMEBUFUSED) + != 0); + client->query.attributes &= ~NS_QUERYATTR_NAMEBUFUSED; + } + dns_message_puttempname(client->message, namep); + CTRACE("query_releasename: done"); +} + +static inline dns_name_t * +query_newname(ns_client_t *client, isc_buffer_t *dbuf, + isc_buffer_t *nbuf) +{ + dns_name_t *name; + isc_region_t r; + isc_result_t result; + + REQUIRE((client->query.attributes & NS_QUERYATTR_NAMEBUFUSED) == 0); + + CTRACE("query_newname"); + name = NULL; + result = dns_message_gettempname(client->message, &name); + if (result != ISC_R_SUCCESS) { + CTRACE("query_newname: dns_message_gettempname failed: done"); + return (NULL); + } + isc_buffer_availableregion(dbuf, &r); + isc_buffer_init(nbuf, r.base, r.length); + dns_name_init(name, NULL); + dns_name_setbuffer(name, nbuf); + client->query.attributes |= NS_QUERYATTR_NAMEBUFUSED; + + CTRACE("query_newname: done"); + return (name); +} + +static inline dns_rdataset_t * +query_newrdataset(ns_client_t *client) { + dns_rdataset_t *rdataset; + isc_result_t result; + + CTRACE("query_newrdataset"); + rdataset = NULL; + result = dns_message_gettemprdataset(client->message, &rdataset); + if (result != ISC_R_SUCCESS) { + CTRACE("query_newrdataset: " + "dns_message_gettemprdataset failed: done"); + return (NULL); + } + dns_rdataset_init(rdataset); + + CTRACE("query_newrdataset: done"); + return (rdataset); +} + +static inline void +query_putrdataset(ns_client_t *client, dns_rdataset_t **rdatasetp) { + dns_rdataset_t *rdataset = *rdatasetp; + + CTRACE("query_putrdataset"); + if (rdataset != NULL) { + if (dns_rdataset_isassociated(rdataset)) + dns_rdataset_disassociate(rdataset); + dns_message_puttemprdataset(client->message, rdatasetp); + } + CTRACE("query_putrdataset: done"); +} + + +static inline isc_result_t +query_newdbversion(ns_client_t *client, unsigned int n) { + unsigned int i; + ns_dbversion_t *dbversion; + + for (i = 0; i < n; i++) { + dbversion = isc_mem_get(client->mctx, sizeof(*dbversion)); + if (dbversion != NULL) { + dbversion->db = NULL; + dbversion->version = NULL; + ISC_LIST_INITANDAPPEND(client->query.freeversions, + dbversion, link); + } else { + /* + * We only return ISC_R_NOMEMORY if we couldn't + * allocate anything. + */ + if (i == 0) + return (ISC_R_NOMEMORY); + else + return (ISC_R_SUCCESS); + } + } + + return (ISC_R_SUCCESS); +} + +static inline ns_dbversion_t * +query_getdbversion(ns_client_t *client) { + isc_result_t result; + ns_dbversion_t *dbversion; + + if (ISC_LIST_EMPTY(client->query.freeversions)) { + result = query_newdbversion(client, 1); + if (result != ISC_R_SUCCESS) + return (NULL); + } + dbversion = ISC_LIST_HEAD(client->query.freeversions); + INSIST(dbversion != NULL); + ISC_LIST_UNLINK(client->query.freeversions, dbversion, link); + + return (dbversion); +} + +isc_result_t +ns_query_init(ns_client_t *client) { + isc_result_t result; + + ISC_LIST_INIT(client->query.namebufs); + ISC_LIST_INIT(client->query.activeversions); + ISC_LIST_INIT(client->query.freeversions); + client->query.restarts = 0; + client->query.timerset = ISC_FALSE; + client->query.qname = NULL; + result = isc_mutex_init(&client->query.fetchlock); + if (result != ISC_R_SUCCESS) + return (result); + client->query.fetch = NULL; + client->query.authdb = NULL; + client->query.authzone = NULL; + client->query.authdbset = ISC_FALSE; + client->query.isreferral = ISC_FALSE; + query_reset(client, ISC_FALSE); + result = query_newdbversion(client, 3); + if (result != ISC_R_SUCCESS) { + DESTROYLOCK(&client->query.fetchlock); + return (result); + } + result = query_newnamebuf(client); + if (result != ISC_R_SUCCESS) + query_freefreeversions(client, ISC_TRUE); + + return (result); +} + +static inline ns_dbversion_t * +query_findversion(ns_client_t *client, dns_db_t *db, + isc_boolean_t *newzonep) +{ + ns_dbversion_t *dbversion; + + /* + * We may already have done a query related to this + * database. If so, we must be sure to make subsequent + * queries from the same version. + */ + for (dbversion = ISC_LIST_HEAD(client->query.activeversions); + dbversion != NULL; + dbversion = ISC_LIST_NEXT(dbversion, link)) { + if (dbversion->db == db) + break; + } + + if (dbversion == NULL) { + /* + * This is a new zone for this query. Add it to + * the active list. + */ + dbversion = query_getdbversion(client); + if (dbversion == NULL) + return (NULL); + dns_db_attach(db, &dbversion->db); + dns_db_currentversion(db, &dbversion->version); + dbversion->queryok = ISC_FALSE; + ISC_LIST_APPEND(client->query.activeversions, + dbversion, link); + *newzonep = ISC_TRUE; + } else + *newzonep = ISC_FALSE; + + return (dbversion); +} + +static inline isc_result_t +query_getzonedb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype, + unsigned int options, dns_zone_t **zonep, dns_db_t **dbp, + dns_dbversion_t **versionp) +{ + isc_result_t result; + isc_boolean_t check_acl, new_zone; + dns_acl_t *queryacl; + ns_dbversion_t *dbversion; + unsigned int ztoptions; + dns_zone_t *zone = NULL; + dns_db_t *db = NULL; + isc_boolean_t partial = ISC_FALSE; + + REQUIRE(zonep != NULL && *zonep == NULL); + REQUIRE(dbp != NULL && *dbp == NULL); + + /* + * Find a zone database to answer the query. + */ + ztoptions = ((options & DNS_GETDB_NOEXACT) != 0) ? + DNS_ZTFIND_NOEXACT : 0; + + result = dns_zt_find(client->view->zonetable, name, ztoptions, NULL, + &zone); + if (result == DNS_R_PARTIALMATCH) + partial = ISC_TRUE; + if (result == ISC_R_SUCCESS || result == DNS_R_PARTIALMATCH) + result = dns_zone_getdb(zone, &db); + + if (result != ISC_R_SUCCESS) + goto fail; + + /* + * This limits our searching to the zone where the first name + * (the query target) was looked for. This prevents following + * CNAMES or DNAMES into other zones and prevents returning + * additional data from other zones. + */ + if (!client->view->additionalfromauth && + client->query.authdbset && + db != client->query.authdb) + goto refuse; + + /* + * If the zone has an ACL, we'll check it, otherwise + * we use the view's "allow-query" ACL. Each ACL is only checked + * once per query. + * + * Also, get the database version to use. + */ + + check_acl = ISC_TRUE; /* Keep compiler happy. */ + queryacl = NULL; + + /* + * Get the current version of this database. + */ + dbversion = query_findversion(client, db, &new_zone); + if (dbversion == NULL) { + result = DNS_R_SERVFAIL; + goto fail; + } + if (new_zone) { + check_acl = ISC_TRUE; + } else if (!dbversion->queryok) { + goto refuse; + } else { + check_acl = ISC_FALSE; + } + + queryacl = dns_zone_getqueryacl(zone); + if (queryacl == NULL) { + queryacl = client->view->queryacl; + if ((client->query.attributes & + NS_QUERYATTR_QUERYOKVALID) != 0) { + /* + * We've evaluated the view's queryacl already. If + * NS_QUERYATTR_QUERYOK is set, then the client is + * allowed to make queries, otherwise the query should + * be refused. + */ + check_acl = ISC_FALSE; + if ((client->query.attributes & + NS_QUERYATTR_QUERYOK) == 0) + goto refuse; + } else { + /* + * We haven't evaluated the view's queryacl yet. + */ + check_acl = ISC_TRUE; + } + } + + if (check_acl) { + isc_boolean_t log = ISC_TF((options & DNS_GETDB_NOLOG) == 0); + + result = ns_client_checkaclsilent(client, queryacl, ISC_TRUE); + if (log) { + char msg[NS_CLIENT_ACLMSGSIZE("query")]; + if (result == ISC_R_SUCCESS) { + if (isc_log_wouldlog(ns_g_lctx, + ISC_LOG_DEBUG(3))) + { + ns_client_aclmsg("query", name, qtype, + client->view->rdclass, + msg, sizeof(msg)); + ns_client_log(client, + DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_QUERY, + ISC_LOG_DEBUG(3), + "%s approved", msg); + } + } else { + ns_client_aclmsg("query", name, qtype, + client->view->rdclass, + msg, sizeof(msg)); + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_QUERY, ISC_LOG_INFO, + "%s denied", msg); + } + } + + if (queryacl == client->view->queryacl) { + if (result == ISC_R_SUCCESS) { + /* + * We were allowed by the default + * "allow-query" ACL. Remember this so we + * don't have to check again. + */ + client->query.attributes |= + NS_QUERYATTR_QUERYOK; + } + /* + * We've now evaluated the view's query ACL, and + * the NS_QUERYATTR_QUERYOK attribute is now valid. + */ + client->query.attributes |= NS_QUERYATTR_QUERYOKVALID; + } + + if (result != ISC_R_SUCCESS) + goto refuse; + } + + /* Approved. */ + + /* + * Remember the result of the ACL check so we + * don't have to check again. + */ + dbversion->queryok = ISC_TRUE; + + /* Transfer ownership. */ + *zonep = zone; + *dbp = db; + *versionp = dbversion->version; + + if (partial && (options & DNS_GETDB_PARTIAL) != 0) + return (DNS_R_PARTIALMATCH); + return (ISC_R_SUCCESS); + + refuse: + result = DNS_R_REFUSED; + fail: + if (zone != NULL) + dns_zone_detach(&zone); + if (db != NULL) + dns_db_detach(&db); + + return (result); +} + +static inline isc_result_t +query_getcachedb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype, + dns_db_t **dbp, unsigned int options) +{ + isc_result_t result; + isc_boolean_t check_acl; + dns_db_t *db = NULL; + + REQUIRE(dbp != NULL && *dbp == NULL); + + /* + * Find a cache database to answer the query. + * This may fail with DNS_R_REFUSED if the client + * is not allowed to use the cache. + */ + + if (!USECACHE(client)) + return (DNS_R_REFUSED); + dns_db_attach(client->view->cachedb, &db); + + if ((client->query.attributes & + NS_QUERYATTR_QUERYOKVALID) != 0) { + /* + * We've evaluated the view's queryacl already. If + * NS_QUERYATTR_QUERYOK is set, then the client is + * allowed to make queries, otherwise the query should + * be refused. + */ + check_acl = ISC_FALSE; + if ((client->query.attributes & + NS_QUERYATTR_QUERYOK) == 0) + goto refuse; + } else { + /* + * We haven't evaluated the view's queryacl yet. + */ + check_acl = ISC_TRUE; + } + + if (check_acl) { + isc_boolean_t log = ISC_TF((options & DNS_GETDB_NOLOG) == 0); + char msg[NS_CLIENT_ACLMSGSIZE("query (cache)")]; + + result = ns_client_checkaclsilent(client, + client->view->queryacl, + ISC_TRUE); + if (result == ISC_R_SUCCESS) { + /* + * We were allowed by the default + * "allow-query" ACL. Remember this so we + * don't have to check again. + */ + client->query.attributes |= + NS_QUERYATTR_QUERYOK; + if (log && isc_log_wouldlog(ns_g_lctx, + ISC_LOG_DEBUG(3))) + { + ns_client_aclmsg("query (cache)", name, qtype, + client->view->rdclass, + msg, sizeof(msg)); + ns_client_log(client, + DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_QUERY, + ISC_LOG_DEBUG(3), + "%s approved", msg); + } + } else if (log) { + ns_client_aclmsg("query (cache)", name, qtype, + client->view->rdclass, msg, + sizeof(msg)); + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_QUERY, ISC_LOG_INFO, + "%s denied", msg); + } + /* + * We've now evaluated the view's query ACL, and + * the NS_QUERYATTR_QUERYOK attribute is now valid. + */ + client->query.attributes |= NS_QUERYATTR_QUERYOKVALID; + + if (result != ISC_R_SUCCESS) + goto refuse; + } + + /* Approved. */ + + /* Transfer ownership. */ + *dbp = db; + + return (ISC_R_SUCCESS); + + refuse: + result = DNS_R_REFUSED; + + if (db != NULL) + dns_db_detach(&db); + + return (result); +} + + +static inline isc_result_t +query_getdb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype, + unsigned int options, dns_zone_t **zonep, dns_db_t **dbp, + dns_dbversion_t **versionp, isc_boolean_t *is_zonep) +{ + isc_result_t result; + + result = query_getzonedb(client, name, qtype, options, + zonep, dbp, versionp); + if (result == ISC_R_SUCCESS) { + *is_zonep = ISC_TRUE; + } else if (result == ISC_R_NOTFOUND) { + result = query_getcachedb(client, name, qtype, dbp, options); + *is_zonep = ISC_FALSE; + } + return (result); +} + +static inline isc_boolean_t +query_isduplicate(ns_client_t *client, dns_name_t *name, + dns_rdatatype_t type, dns_name_t **mnamep) +{ + dns_section_t section; + dns_name_t *mname = NULL; + isc_result_t result; + + CTRACE("query_isduplicate"); + + for (section = DNS_SECTION_ANSWER; + section <= DNS_SECTION_ADDITIONAL; + section++) { + result = dns_message_findname(client->message, section, + name, type, 0, &mname, NULL); + if (result == ISC_R_SUCCESS) { + /* + * We've already got this RRset in the response. + */ + CTRACE("query_isduplicate: true: done"); + return (ISC_TRUE); + } else if (result == DNS_R_NXRRSET) { + /* + * The name exists, but the rdataset does not. + */ + if (section == DNS_SECTION_ADDITIONAL) + break; + } else + RUNTIME_CHECK(result == DNS_R_NXDOMAIN); + mname = NULL; + } + + /* + * If the dns_name_t we're looking up is already in the message, + * we don't want to trigger the caller's name replacement logic. + */ + if (name == mname) + mname = NULL; + + *mnamep = mname; + + CTRACE("query_isduplicate: false: done"); + return (ISC_FALSE); +} + +static isc_result_t +query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) { + ns_client_t *client = arg; + isc_result_t result, eresult; + dns_dbnode_t *node; + dns_db_t *db; + dns_name_t *fname, *mname; + dns_rdataset_t *rdataset, *sigrdataset, *trdataset; + isc_buffer_t *dbuf; + isc_buffer_t b; + dns_dbversion_t *version; + isc_boolean_t added_something, need_addname; + dns_zone_t *zone; + dns_rdatatype_t type; + + REQUIRE(NS_CLIENT_VALID(client)); + REQUIRE(qtype != dns_rdatatype_any); + + if (!WANTDNSSEC(client) && dns_rdatatype_isdnssec(qtype)) + return (ISC_R_SUCCESS); + + CTRACE("query_addadditional"); + + /* + * Initialization. + */ + eresult = ISC_R_SUCCESS; + fname = NULL; + rdataset = NULL; + sigrdataset = NULL; + trdataset = NULL; + db = NULL; + version = NULL; + node = NULL; + added_something = ISC_FALSE; + need_addname = ISC_FALSE; + zone = NULL; + + /* + * We treat type A additional section processing as if it + * were "any address type" additional section processing. + * To avoid multiple lookups, we do an 'any' database + * lookup and iterate over the node. + */ + if (qtype == dns_rdatatype_a) + type = dns_rdatatype_any; + else + type = qtype; + + /* + * Get some resources. + */ + dbuf = query_getnamebuf(client); + if (dbuf == NULL) + goto cleanup; + fname = query_newname(client, dbuf, &b); + rdataset = query_newrdataset(client); + if (fname == NULL || rdataset == NULL) + goto cleanup; + if (WANTDNSSEC(client)) { + sigrdataset = query_newrdataset(client); + if (sigrdataset == NULL) + goto cleanup; + } + + /* + * Look for a zone database that might contain authoritative + * additional data. + */ + result = query_getzonedb(client, name, qtype, DNS_GETDB_NOLOG, + &zone, &db, &version); + if (result != ISC_R_SUCCESS) + goto try_cache; + + CTRACE("query_addadditional: db_find"); + + /* + * Since we are looking for authoritative data, we do not set + * the GLUEOK flag. Glue will be looked for later, but not + * necessarily in the same database. + */ + node = NULL; + result = dns_db_find(db, name, version, type, client->query.dboptions, + client->now, &node, fname, rdataset, + sigrdataset); + if (result == ISC_R_SUCCESS) + goto found; + + if (dns_rdataset_isassociated(rdataset)) + dns_rdataset_disassociate(rdataset); + if (sigrdataset != NULL && dns_rdataset_isassociated(sigrdataset)) + dns_rdataset_disassociate(sigrdataset); + if (node != NULL) + dns_db_detachnode(db, &node); + version = NULL; + dns_db_detach(&db); + + /* + * No authoritative data was found. The cache is our next best bet. + */ + + try_cache: + result = query_getcachedb(client, name, qtype, &db, DNS_GETDB_NOLOG); + if (result != ISC_R_SUCCESS) + /* + * Most likely the client isn't allowed to query the cache. + */ + goto try_glue; + + result = dns_db_find(db, name, version, type, client->query.dboptions, + client->now, &node, fname, rdataset, + sigrdataset); + if (result == ISC_R_SUCCESS) + goto found; + + if (dns_rdataset_isassociated(rdataset)) + dns_rdataset_disassociate(rdataset); + if (sigrdataset != NULL && dns_rdataset_isassociated(sigrdataset)) + dns_rdataset_disassociate(sigrdataset); + if (node != NULL) + dns_db_detachnode(db, &node); + dns_db_detach(&db); + + try_glue: + /* + * No cached data was found. Glue is our last chance. + * RFC1035 sayeth: + * + * NS records cause both the usual additional section + * processing to locate a type A record, and, when used + * in a referral, a special search of the zone in which + * they reside for glue information. + * + * This is the "special search". Note that we must search + * the zone where the NS record resides, not the zone it + * points to, and that we only do the search in the delegation + * case (identified by client->query.gluedb being set). + */ + + if (client->query.gluedb == NULL) + goto cleanup; + + /* + * Don't poision caches using the bailiwick protection model. + */ + if (!dns_name_issubdomain(name, dns_db_origin(client->query.gluedb))) + goto cleanup; + + dns_db_attach(client->query.gluedb, &db); + result = dns_db_find(db, name, version, type, + client->query.dboptions | DNS_DBFIND_GLUEOK, + client->now, &node, fname, rdataset, + sigrdataset); + if (!(result == ISC_R_SUCCESS || + result == DNS_R_ZONECUT || + result == DNS_R_GLUE)) + goto cleanup; + + found: + /* + * We have found a potential additional data rdataset, or + * at least a node to iterate over. + */ + query_keepname(client, fname, dbuf); + + /* + * If we have an rdataset, add it to the additional data + * section. + */ + mname = NULL; + if (dns_rdataset_isassociated(rdataset) && + !query_isduplicate(client, fname, type, &mname)) { + if (mname != NULL) { + query_releasename(client, &fname); + fname = mname; + } else + need_addname = ISC_TRUE; + ISC_LIST_APPEND(fname->list, rdataset, link); + trdataset = rdataset; + rdataset = NULL; + added_something = ISC_TRUE; + /* + * Note: we only add SIGs if we've added the type they cover, + * so we do not need to check if the SIG rdataset is already + * in the response. + */ + if (sigrdataset != NULL && + dns_rdataset_isassociated(sigrdataset)) + { + ISC_LIST_APPEND(fname->list, sigrdataset, link); + sigrdataset = NULL; + } + } + + if (qtype == dns_rdatatype_a) { + /* + * We now go looking for A and AAAA records, along with + * their signatures. + * + * XXXRTH This code could be more efficient. + */ + if (rdataset != NULL) { + if (dns_rdataset_isassociated(rdataset)) + dns_rdataset_disassociate(rdataset); + } else { + rdataset = query_newrdataset(client); + if (rdataset == NULL) + goto addname; + } + if (sigrdataset != NULL) { + if (dns_rdataset_isassociated(sigrdataset)) + dns_rdataset_disassociate(sigrdataset); + } else if (WANTDNSSEC(client)) { + sigrdataset = query_newrdataset(client); + if (sigrdataset == NULL) + goto addname; + } + result = dns_db_findrdataset(db, node, version, + dns_rdatatype_a, 0, + client->now, rdataset, + sigrdataset); + if (result == DNS_R_NCACHENXDOMAIN) + goto addname; + if (result == DNS_R_NCACHENXRRSET) { + dns_rdataset_disassociate(rdataset); + /* + * Negative cache entries don't have sigrdatasets. + */ + INSIST(sigrdataset == NULL || + ! dns_rdataset_isassociated(sigrdataset)); + } + if (result == ISC_R_SUCCESS) { + mname = NULL; + if (!query_isduplicate(client, fname, + dns_rdatatype_a, &mname)) { + if (mname != NULL) { + query_releasename(client, &fname); + fname = mname; + } else + need_addname = ISC_TRUE; + ISC_LIST_APPEND(fname->list, rdataset, link); + added_something = ISC_TRUE; + if (sigrdataset != NULL && + dns_rdataset_isassociated(sigrdataset)) + { + ISC_LIST_APPEND(fname->list, + sigrdataset, link); + sigrdataset = + query_newrdataset(client); + } + rdataset = query_newrdataset(client); + if (rdataset == NULL) + goto addname; + if (WANTDNSSEC(client) && sigrdataset == NULL) + goto addname; + } else { + dns_rdataset_disassociate(rdataset); + if (sigrdataset != NULL && + dns_rdataset_isassociated(sigrdataset)) + dns_rdataset_disassociate(sigrdataset); + } + } + result = dns_db_findrdataset(db, node, version, + dns_rdatatype_aaaa, 0, + client->now, rdataset, + sigrdataset); + if (result == DNS_R_NCACHENXDOMAIN) + goto addname; + if (result == DNS_R_NCACHENXRRSET) { + dns_rdataset_disassociate(rdataset); + INSIST(sigrdataset == NULL || + ! dns_rdataset_isassociated(sigrdataset)); + } + if (result == ISC_R_SUCCESS) { + mname = NULL; + if (!query_isduplicate(client, fname, + dns_rdatatype_aaaa, &mname)) { + if (mname != NULL) { + query_releasename(client, &fname); + fname = mname; + } else + need_addname = ISC_TRUE; + ISC_LIST_APPEND(fname->list, rdataset, link); + added_something = ISC_TRUE; + if (sigrdataset != NULL && + dns_rdataset_isassociated(sigrdataset)) + { + ISC_LIST_APPEND(fname->list, + sigrdataset, link); + sigrdataset = NULL; + } + rdataset = NULL; + } + } + } + + addname: + CTRACE("query_addadditional: addname"); + /* + * If we haven't added anything, then we're done. + */ + if (!added_something) + goto cleanup; + + /* + * We may have added our rdatasets to an existing name, if so, then + * need_addname will be ISC_FALSE. Whether we used an existing name + * or a new one, we must set fname to NULL to prevent cleanup. + */ + if (need_addname) + dns_message_addname(client->message, fname, + DNS_SECTION_ADDITIONAL); + fname = NULL; + + /* + * In a few cases, we want to add additional data for additional + * data. It's simpler to just deal with special cases here than + * to try to create a general purpose mechanism and allow the + * rdata implementations to do it themselves. + * + * This involves recursion, but the depth is limited. The + * most complex case is adding a SRV rdataset, which involves + * recursing to add address records, which in turn can cause + * recursion to add KEYs. + */ + if (type == dns_rdatatype_a || type == dns_rdatatype_aaaa) { + /* + * RFC 2535 section 3.5 says that when A or AAAA records are + * retrieved as additional data, any KEY RRs for the owner name + * should be added to the additional data section. + * + * XXXRTH We should lower the priority here. Alternatively, + * we could raise the priority of glue records. + */ + eresult = query_addadditional(client, name, dns_rdatatype_dnskey); + } else if (type == dns_rdatatype_srv && trdataset != NULL) { + /* + * If we're adding SRV records to the additional data + * section, it's helpful if we add the SRV additional data + * as well. + */ + eresult = dns_rdataset_additionaldata(trdataset, + query_addadditional, + client); + } + + cleanup: + CTRACE("query_addadditional: cleanup"); + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + if (fname != NULL) + query_releasename(client, &fname); + if (node != NULL) + dns_db_detachnode(db, &node); + if (db != NULL) + dns_db_detach(&db); + if (zone != NULL) + dns_zone_detach(&zone); + + CTRACE("query_addadditional: done"); + return (eresult); +} + +static inline void +query_addrdataset(ns_client_t *client, dns_name_t *fname, + dns_rdataset_t *rdataset) +{ + dns_rdatatype_t type = rdataset->type; + + /* + * Add 'rdataset' and any pertinent additional data to + * 'fname', a name in the response message for 'client'. + */ + + CTRACE("query_addrdataset"); + + ISC_LIST_APPEND(fname->list, rdataset, link); + + if (client->view->order != NULL) + rdataset->attributes |= dns_order_find(client->view->order, + fname, rdataset->type, + rdataset->rdclass); + if (NOADDITIONAL(client)) + return; + + /* + * Add additional data. + * + * We don't care if dns_rdataset_additionaldata() fails. + */ + (void)dns_rdataset_additionaldata(rdataset, + query_addadditional, client); + /* + * RFC 2535 section 3.5 says that when NS, SOA, A, or AAAA records + * are retrieved, any KEY RRs for the owner name should be added + * to the additional data section. We treat A6 records the same way. + * + * We don't care if query_addadditional() fails. + */ + if (type == dns_rdatatype_ns || type == dns_rdatatype_soa || + type == dns_rdatatype_a || type == dns_rdatatype_aaaa || + type == dns_rdatatype_a6) { + /* + * XXXRTH We should lower the priority here. Alternatively, + * we could raise the priority of glue records. + */ + (void)query_addadditional(client, fname, dns_rdatatype_dnskey); + } + CTRACE("query_addrdataset: done"); +} + +static void +query_addrrset(ns_client_t *client, dns_name_t **namep, + dns_rdataset_t **rdatasetp, dns_rdataset_t **sigrdatasetp, + isc_buffer_t *dbuf, dns_section_t section) +{ + dns_name_t *name, *mname; + dns_rdataset_t *rdataset, *mrdataset, *sigrdataset; + isc_result_t result; + + /* + * To the current response for 'client', add the answer RRset + * '*rdatasetp' and an optional signature set '*sigrdatasetp', with + * owner name '*namep', to section 'section', unless they are + * already there. Also add any pertinent additional data. + * + * If 'dbuf' is not NULL, then '*namep' is the name whose data is + * stored in 'dbuf'. In this case, query_addrrset() guarantees that + * when it returns the name will either have been kept or released. + */ + CTRACE("query_addrrset"); + name = *namep; + rdataset = *rdatasetp; + if (sigrdatasetp != NULL) + sigrdataset = *sigrdatasetp; + else + sigrdataset = NULL; + mname = NULL; + mrdataset = NULL; + result = dns_message_findname(client->message, section, + name, rdataset->type, rdataset->covers, + &mname, &mrdataset); + if (result == ISC_R_SUCCESS) { + /* + * We've already got an RRset of the given name and type. + * There's nothing else to do; + */ + CTRACE("query_addrrset: dns_message_findname succeeded: done"); + if (dbuf != NULL) + query_releasename(client, namep); + return; + } else if (result == DNS_R_NXDOMAIN) { + /* + * The name doesn't exist. + */ + if (dbuf != NULL) + query_keepname(client, name, dbuf); + dns_message_addname(client->message, name, section); + *namep = NULL; + mname = name; + } else { + RUNTIME_CHECK(result == DNS_R_NXRRSET); + if (dbuf != NULL) + query_releasename(client, namep); + } + + if (rdataset->trust != dns_trust_secure && + (section == DNS_SECTION_ANSWER || + section == DNS_SECTION_AUTHORITY)) + client->query.attributes &= ~NS_QUERYATTR_SECURE; + /* + * Note: we only add SIGs if we've added the type they cover, so + * we do not need to check if the SIG rdataset is already in the + * response. + */ + query_addrdataset(client, mname, rdataset); + *rdatasetp = NULL; + if (sigrdataset != NULL && dns_rdataset_isassociated(sigrdataset)) { + /* + * We have a signature. Add it to the response. + */ + ISC_LIST_APPEND(mname->list, sigrdataset, link); + *sigrdatasetp = NULL; + } + CTRACE("query_addrrset: done"); +} + +static inline isc_result_t +query_addsoa(ns_client_t *client, dns_db_t *db, isc_boolean_t zero_ttl) { + dns_name_t *name, *fname; + dns_dbnode_t *node; + isc_result_t result, eresult; + dns_fixedname_t foundname; + dns_rdataset_t *rdataset = NULL, *sigrdataset = NULL; + dns_rdataset_t **sigrdatasetp = NULL; + + CTRACE("query_addsoa"); + /* + * Initialization. + */ + eresult = ISC_R_SUCCESS; + name = NULL; + rdataset = NULL; + node = NULL; + dns_fixedname_init(&foundname); + fname = dns_fixedname_name(&foundname); + + /* + * Get resources and make 'name' be the database origin. + */ + result = dns_message_gettempname(client->message, &name); + if (result != ISC_R_SUCCESS) + return (result); + dns_name_init(name, NULL); + dns_name_clone(dns_db_origin(db), name); + rdataset = query_newrdataset(client); + if (rdataset == NULL) { + eresult = DNS_R_SERVFAIL; + goto cleanup; + } + if (WANTDNSSEC(client)) { + sigrdataset = query_newrdataset(client); + if (sigrdataset == NULL) { + eresult = DNS_R_SERVFAIL; + goto cleanup; + } + } + + /* + * Find the SOA. + */ + result = dns_db_find(db, name, NULL, dns_rdatatype_soa, + client->query.dboptions, 0, &node, + fname, rdataset, sigrdataset); + if (result != ISC_R_SUCCESS) { + /* + * This is bad. We tried to get the SOA RR at the zone top + * and it didn't work! + */ + eresult = DNS_R_SERVFAIL; + } else { + /* + * Extract the SOA MINIMUM. + */ + dns_rdata_soa_t soa; + dns_rdata_t rdata = DNS_RDATA_INIT; + result = dns_rdataset_first(rdataset); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + dns_rdataset_current(rdataset, &rdata); + result = dns_rdata_tostruct(&rdata, &soa, NULL); + if (result != ISC_R_SUCCESS) + goto cleanup; + + if (zero_ttl) { + rdataset->ttl = 0; + if (sigrdataset != NULL) + sigrdataset->ttl = 0; + } + + /* + * Add the SOA and its SIG to the response, with the + * TTLs adjusted per RFC2308 section 3. + */ + if (rdataset->ttl > soa.minimum) + rdataset->ttl = soa.minimum; + if (sigrdataset != NULL && sigrdataset->ttl > soa.minimum) + sigrdataset->ttl = soa.minimum; + + if (sigrdataset != NULL) + sigrdatasetp = &sigrdataset; + else + sigrdatasetp = NULL; + query_addrrset(client, &name, &rdataset, sigrdatasetp, NULL, + DNS_SECTION_AUTHORITY); + } + + cleanup: + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + if (name != NULL) + query_releasename(client, &name); + if (node != NULL) + dns_db_detachnode(db, &node); + + return (eresult); +} + +static inline isc_result_t +query_addns(ns_client_t *client, dns_db_t *db) { + dns_name_t *name, *fname; + dns_dbnode_t *node; + isc_result_t result, eresult; + dns_fixedname_t foundname; + dns_rdataset_t *rdataset = NULL, *sigrdataset = NULL; + dns_rdataset_t **sigrdatasetp = NULL; + + CTRACE("query_addns"); + /* + * Initialization. + */ + eresult = ISC_R_SUCCESS; + name = NULL; + rdataset = NULL; + node = NULL; + dns_fixedname_init(&foundname); + fname = dns_fixedname_name(&foundname); + + /* + * Get resources and make 'name' be the database origin. + */ + result = dns_message_gettempname(client->message, &name); + if (result != ISC_R_SUCCESS) { + CTRACE("query_addns: dns_message_gettempname failed: done"); + return (result); + } + dns_name_init(name, NULL); + dns_name_clone(dns_db_origin(db), name); + rdataset = query_newrdataset(client); + if (rdataset == NULL) { + CTRACE("query_addns: query_newrdataset failed"); + eresult = DNS_R_SERVFAIL; + goto cleanup; + } + if (WANTDNSSEC(client)) { + sigrdataset = query_newrdataset(client); + if (sigrdataset == NULL) { + CTRACE("query_addns: query_newrdataset failed"); + eresult = DNS_R_SERVFAIL; + goto cleanup; + } + } + + /* + * Find the NS rdataset. + */ + CTRACE("query_addns: calling dns_db_find"); + result = dns_db_find(db, name, NULL, dns_rdatatype_ns, + client->query.dboptions, 0, &node, + fname, rdataset, sigrdataset); + CTRACE("query_addns: dns_db_find complete"); + if (result != ISC_R_SUCCESS) { + CTRACE("query_addns: dns_db_find failed"); + /* + * This is bad. We tried to get the NS rdataset at the zone + * top and it didn't work! + */ + eresult = DNS_R_SERVFAIL; + } else { + if (sigrdataset != NULL) + sigrdatasetp = &sigrdataset; + else + sigrdatasetp = NULL; + query_addrrset(client, &name, &rdataset, sigrdatasetp, NULL, + DNS_SECTION_AUTHORITY); + } + + cleanup: + CTRACE("query_addns: cleanup"); + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + if (name != NULL) + query_releasename(client, &name); + if (node != NULL) + dns_db_detachnode(db, &node); + + CTRACE("query_addns: done"); + return (eresult); +} + +static inline isc_result_t +query_addcnamelike(ns_client_t *client, dns_name_t *qname, dns_name_t *tname, + dns_trust_t trust, dns_name_t **anamep, dns_rdatatype_t type) +{ + dns_rdataset_t *rdataset; + dns_rdatalist_t *rdatalist; + dns_rdata_t *rdata; + isc_result_t result; + isc_region_t r; + + /* + * We assume the name data referred to by tname won't go away. + */ + + REQUIRE(anamep != NULL); + + rdatalist = NULL; + result = dns_message_gettemprdatalist(client->message, &rdatalist); + if (result != ISC_R_SUCCESS) + return (result); + rdata = NULL; + result = dns_message_gettemprdata(client->message, &rdata); + if (result != ISC_R_SUCCESS) + return (result); + rdataset = NULL; + result = dns_message_gettemprdataset(client->message, &rdataset); + if (result != ISC_R_SUCCESS) + return (result); + dns_rdataset_init(rdataset); + result = dns_name_dup(qname, client->mctx, *anamep); + if (result != ISC_R_SUCCESS) { + dns_message_puttemprdataset(client->message, &rdataset); + return (result); + } + + rdatalist->type = type; + rdatalist->covers = 0; + rdatalist->rdclass = client->message->rdclass; + rdatalist->ttl = 0; + + dns_name_toregion(tname, &r); + rdata->data = r.base; + rdata->length = r.length; + rdata->rdclass = client->message->rdclass; + rdata->type = type; + + ISC_LIST_INIT(rdatalist->rdata); + ISC_LIST_APPEND(rdatalist->rdata, rdata, link); + RUNTIME_CHECK(dns_rdatalist_tordataset(rdatalist, rdataset) + == ISC_R_SUCCESS); + rdataset->trust = trust; + + query_addrrset(client, anamep, &rdataset, NULL, NULL, + DNS_SECTION_ANSWER); + + if (rdataset != NULL) { + if (dns_rdataset_isassociated(rdataset)) + dns_rdataset_disassociate(rdataset); + dns_message_puttemprdataset(client->message, &rdataset); + } + + return (ISC_R_SUCCESS); +} + +static void +query_addbestns(ns_client_t *client) { + dns_db_t *db, *zdb; + dns_dbnode_t *node; + dns_name_t *fname, *zfname; + dns_rdataset_t *rdataset, *sigrdataset, *zrdataset, *zsigrdataset; + isc_boolean_t is_zone, use_zone; + isc_buffer_t *dbuf; + isc_result_t result; + dns_dbversion_t *version; + dns_zone_t *zone; + isc_buffer_t b; + + CTRACE("query_addbestns"); + fname = NULL; + zfname = NULL; + rdataset = NULL; + zrdataset = NULL; + sigrdataset = NULL; + zsigrdataset = NULL; + node = NULL; + db = NULL; + zdb = NULL; + version = NULL; + zone = NULL; + is_zone = ISC_FALSE; + use_zone = ISC_FALSE; + + /* + * Find the right database. + */ + result = query_getdb(client, client->query.qname, dns_rdatatype_ns, 0, + &zone, &db, &version, &is_zone); + if (result != ISC_R_SUCCESS) + goto cleanup; + + db_find: + /* + * We'll need some resources... + */ + dbuf = query_getnamebuf(client); + if (dbuf == NULL) + goto cleanup; + fname = query_newname(client, dbuf, &b); + rdataset = query_newrdataset(client); + if (fname == NULL || rdataset == NULL) + goto cleanup; + if (WANTDNSSEC(client)) { + sigrdataset = query_newrdataset(client); + if (sigrdataset == NULL) + goto cleanup; + } + + /* + * Now look for the zonecut. + */ + if (is_zone) { + result = dns_db_find(db, client->query.qname, version, + dns_rdatatype_ns, client->query.dboptions, + client->now, &node, fname, + rdataset, sigrdataset); + if (result != DNS_R_DELEGATION) + goto cleanup; + if (USECACHE(client)) { + query_keepname(client, fname, dbuf); + zdb = db; + zfname = fname; + fname = NULL; + zrdataset = rdataset; + rdataset = NULL; + zsigrdataset = sigrdataset; + sigrdataset = NULL; + dns_db_detachnode(db, &node); + version = NULL; + db = NULL; + dns_db_attach(client->view->cachedb, &db); + is_zone = ISC_FALSE; + goto db_find; + } + } else { + result = dns_db_findzonecut(db, client->query.qname, + client->query.dboptions, + client->now, &node, fname, + rdataset, sigrdataset); + if (result == ISC_R_SUCCESS) { + if (zfname != NULL && + !dns_name_issubdomain(fname, zfname)) { + /* + * We found a zonecut in the cache, but our + * zone delegation is better. + */ + use_zone = ISC_TRUE; + } + } else if (result == ISC_R_NOTFOUND && zfname != NULL) { + /* + * We didn't find anything in the cache, but we + * have a zone delegation, so use it. + */ + use_zone = ISC_TRUE; + } else + goto cleanup; + } + + if (use_zone) { + query_releasename(client, &fname); + fname = zfname; + zfname = NULL; + /* + * We've already done query_keepname() on + * zfname, so we must set dbuf to NULL to + * prevent query_addrrset() from trying to + * call query_keepname() again. + */ + dbuf = NULL; + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + rdataset = zrdataset; + zrdataset = NULL; + sigrdataset = zsigrdataset; + zsigrdataset = NULL; + } + + if ((client->query.dboptions & DNS_DBFIND_PENDINGOK) == 0 && + (rdataset->trust == dns_trust_pending || + (sigrdataset != NULL && sigrdataset->trust == dns_trust_pending))) + goto cleanup; + + if (WANTDNSSEC(client) && SECURE(client) && + (rdataset->trust == dns_trust_glue || + (sigrdataset != NULL && sigrdataset->trust == dns_trust_glue))) + goto cleanup; + + query_addrrset(client, &fname, &rdataset, &sigrdataset, dbuf, + DNS_SECTION_AUTHORITY); + + cleanup: + if (rdataset != NULL) + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + if (fname != NULL) + query_releasename(client, &fname); + if (node != NULL) + dns_db_detachnode(db, &node); + if (db != NULL) + dns_db_detach(&db); + if (zone != NULL) + dns_zone_detach(&zone); + if (zdb != NULL) { + query_putrdataset(client, &zrdataset); + if (zsigrdataset != NULL) + query_putrdataset(client, &zsigrdataset); + if (zfname != NULL) + query_releasename(client, &zfname); + dns_db_detach(&zdb); + } +} + +static void +query_addds(ns_client_t *client, dns_db_t *db, dns_dbnode_t *node) { + dns_name_t *rname; + dns_rdataset_t *rdataset, *sigrdataset; + isc_result_t result; + + CTRACE("query_addds"); + rname = NULL; + rdataset = NULL; + sigrdataset = NULL; + + /* + * We'll need some resources... + */ + rdataset = query_newrdataset(client); + sigrdataset = query_newrdataset(client); + if (rdataset == NULL || sigrdataset == NULL) + goto cleanup; + + /* + * Look for the DS record, which may or may not be present. + */ + result = dns_db_findrdataset(db, node, NULL, dns_rdatatype_ds, 0, + client->now, rdataset, sigrdataset); + /* + * If we didn't find it, look for an NSEC. */ + if (result == ISC_R_NOTFOUND) + result = dns_db_findrdataset(db, node, NULL, + dns_rdatatype_nsec, 0, client->now, + rdataset, sigrdataset); + if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) + goto cleanup; + if (!dns_rdataset_isassociated(rdataset) || + !dns_rdataset_isassociated(sigrdataset)) + goto cleanup; + + /* + * We've already added the NS record, so if the name's not there, + * we have other problems. Use this name rather than calling + * query_addrrset(). + */ + result = dns_message_firstname(client->message, DNS_SECTION_AUTHORITY); + if (result != ISC_R_SUCCESS) + goto cleanup; + + rname = NULL; + dns_message_currentname(client->message, DNS_SECTION_AUTHORITY, + &rname); + result = dns_message_findtype(rname, dns_rdatatype_ns, 0, NULL); + if (result != ISC_R_SUCCESS) + goto cleanup; + + ISC_LIST_APPEND(rname->list, rdataset, link); + ISC_LIST_APPEND(rname->list, sigrdataset, link); + rdataset = NULL; + sigrdataset = NULL; + + cleanup: + if (rdataset != NULL) + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); +} + +static void +query_addwildcardproof(ns_client_t *client, dns_db_t *db, + dns_name_t *name, isc_boolean_t ispositive) +{ + isc_buffer_t *dbuf, b; + dns_name_t *fname; + dns_rdataset_t *rdataset, *sigrdataset; + dns_fixedname_t wfixed; + dns_name_t *wname; + dns_dbnode_t *node; + unsigned int options; + unsigned int olabels, nlabels; + isc_result_t result; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdata_nsec_t nsec; + isc_boolean_t have_wname; + int order; + + CTRACE("query_addwildcardproof"); + fname = NULL; + rdataset = NULL; + sigrdataset = NULL; + node = NULL; + + /* + * Get the NOQNAME proof then if !ispositve + * get the NOWILDCARD proof. + * + * DNS_DBFIND_NOWILD finds the NSEC records that covers the + * name ignoring any wildcard. From the owner and next names + * of this record you can compute which wildcard (if it exists) + * will match by finding the longest common suffix of the + * owner name and next names with the qname and prefixing that + * with the wildcard label. + * + * e.g. + * Given: + * example SOA + * example NSEC b.example + * b.example A + * b.example NSEC a.d.example + * a.d.example A + * a.d.example NSEC g.f.example + * g.f.example A + * g.f.example NSEC z.i.example + * z.i.example A + * z.i.example NSEC example + * + * QNAME: + * a.example -> example NSEC b.example + * owner common example + * next common example + * wild *.example + * d.b.example -> b.example NSEC a.d.example + * owner common b.example + * next common example + * wild *.b.example + * a.f.example -> a.d.example NSEC g.f.example + * owner common example + * next common f.example + * wild *.f.example + * j.example -> z.i.example NSEC example + * owner common example + * next common example + * wild *.f.example + */ + options = client->query.dboptions | DNS_DBFIND_NOWILD; + dns_fixedname_init(&wfixed); + wname = dns_fixedname_name(&wfixed); + again: + have_wname = ISC_FALSE; + /* + * We'll need some resources... + */ + dbuf = query_getnamebuf(client); + if (dbuf == NULL) + goto cleanup; + fname = query_newname(client, dbuf, &b); + rdataset = query_newrdataset(client); + sigrdataset = query_newrdataset(client); + if (fname == NULL || rdataset == NULL || sigrdataset == NULL) + goto cleanup; + + result = dns_db_find(db, name, NULL, dns_rdatatype_nsec, options, + 0, &node, fname, rdataset, sigrdataset); + if (node != NULL) + dns_db_detachnode(db, &node); + if (result == DNS_R_NXDOMAIN) { + if (!ispositive) + result = dns_rdataset_first(rdataset); + if (result == ISC_R_SUCCESS) { + dns_rdataset_current(rdataset, &rdata); + result = dns_rdata_tostruct(&rdata, &nsec, NULL); + } + if (result == ISC_R_SUCCESS) { + (void)dns_name_fullcompare(name, fname, &order, + &olabels); + (void)dns_name_fullcompare(name, &nsec.next, &order, + &nlabels); + if (olabels > nlabels) + dns_name_split(name, olabels, NULL, wname); + else + dns_name_split(name, nlabels, NULL, wname); + result = dns_name_concatenate(dns_wildcardname, + wname, wname, NULL); + if (result == ISC_R_SUCCESS) + have_wname = ISC_TRUE; + dns_rdata_freestruct(&nsec); + } + query_addrrset(client, &fname, &rdataset, &sigrdataset, + dbuf, DNS_SECTION_AUTHORITY); + } + if (rdataset != NULL) + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + if (fname != NULL) + query_releasename(client, &fname); + if (have_wname) { + ispositive = ISC_TRUE; /* prevent loop */ + if (!dns_name_equal(name, wname)) { + name = wname; + goto again; + } + } + cleanup: + if (rdataset != NULL) + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + if (fname != NULL) + query_releasename(client, &fname); +} + +static void +query_addnxrrsetnsec(ns_client_t *client, dns_db_t *db, dns_name_t **namep, + dns_rdataset_t **rdatasetp, dns_rdataset_t **sigrdatasetp) +{ + dns_name_t *name; + dns_rdataset_t *sigrdataset; + dns_rdata_t sigrdata; + dns_rdata_rrsig_t sig; + unsigned int labels; + isc_buffer_t *dbuf, b; + dns_name_t *fname; + isc_result_t result; + + name = *namep; + if ((name->attributes & DNS_NAMEATTR_WILDCARD) == 0) { + query_addrrset(client, namep, rdatasetp, sigrdatasetp, + NULL, DNS_SECTION_AUTHORITY); + return; + } + + if (sigrdatasetp == NULL) + return; + sigrdataset = *sigrdatasetp; + if (sigrdataset == NULL || !dns_rdataset_isassociated(sigrdataset)) + return; + result = dns_rdataset_first(sigrdataset); + if (result != ISC_R_SUCCESS) + return; + dns_rdata_init(&sigrdata); + dns_rdataset_current(sigrdataset, &sigrdata); + result = dns_rdata_tostruct(&sigrdata, &sig, NULL); + if (result != ISC_R_SUCCESS) + return; + + labels = dns_name_countlabels(name); + if ((unsigned int)sig.labels + 1 >= labels) + return; + + /* XXX */ + query_addwildcardproof(client, db, + client->query.qname, + ISC_TRUE); + + /* + * We'll need some resources... + */ + dbuf = query_getnamebuf(client); + if (dbuf == NULL) + return; + fname = query_newname(client, dbuf, &b); + if (fname == NULL) + return; + dns_name_split(name, sig.labels + 1, NULL, fname); + /* This will succeed, since we've stripped labels. */ + RUNTIME_CHECK(dns_name_concatenate(dns_wildcardname, fname, fname, + NULL) == ISC_R_SUCCESS); + query_addrrset(client, &fname, rdatasetp, sigrdatasetp, + dbuf, DNS_SECTION_AUTHORITY); +} + +static void +query_resume(isc_task_t *task, isc_event_t *event) { + dns_fetchevent_t *devent = (dns_fetchevent_t *)event; + ns_client_t *client; + isc_boolean_t fetch_cancelled, client_shuttingdown; + + /* + * Resume a query after recursion. + */ + + UNUSED(task); + + REQUIRE(event->ev_type == DNS_EVENT_FETCHDONE); + client = devent->ev_arg; + REQUIRE(NS_CLIENT_VALID(client)); + REQUIRE(task == client->task); + REQUIRE(RECURSING(client)); + + LOCK(&client->query.fetchlock); + if (client->query.fetch != NULL) { + /* + * This is the fetch we've been waiting for. + */ + INSIST(devent->fetch == client->query.fetch); + client->query.fetch = NULL; + fetch_cancelled = ISC_FALSE; + /* + * Update client->now. + */ + isc_stdtime_get(&client->now); + } else { + /* + * This is a fetch completion event for a cancelled fetch. + * Clean up and don't resume the find. + */ + fetch_cancelled = ISC_TRUE; + } + UNLOCK(&client->query.fetchlock); + INSIST(client->query.fetch == NULL); + + client->query.attributes &= ~NS_QUERYATTR_RECURSING; + dns_resolver_destroyfetch(&devent->fetch); + + /* + * If this client is shutting down, or this transaction + * has timed out, do not resume the find. + */ + client_shuttingdown = ns_client_shuttingdown(client); + if (fetch_cancelled || client_shuttingdown) { + if (devent->node != NULL) + dns_db_detachnode(devent->db, &devent->node); + if (devent->db != NULL) + dns_db_detach(&devent->db); + query_putrdataset(client, &devent->rdataset); + if (devent->sigrdataset != NULL) + query_putrdataset(client, &devent->sigrdataset); + isc_event_free(&event); + if (fetch_cancelled) + query_error(client, DNS_R_SERVFAIL); + else + query_next(client, ISC_R_CANCELED); + /* + * This may destroy the client. + */ + ns_client_detach(&client); + } else { + query_find(client, devent, 0); + } +} + +static isc_result_t +query_recurse(ns_client_t *client, dns_rdatatype_t qtype, dns_name_t *qdomain, + dns_rdataset_t *nameservers) +{ + isc_result_t result; + dns_rdataset_t *rdataset, *sigrdataset; + + inc_stats(client, dns_statscounter_recursion); + + /* + * We are about to recurse, which means that this client will + * be unavailable for serving new requests for an indeterminate + * amount of time. If this client is currently responsible + * for handling incoming queries, set up a new client + * object to handle them while we are waiting for a + * response. There is no need to replace TCP clients + * because those have already been replaced when the + * connection was accepted (if allowed by the TCP quota). + */ + if (client->recursionquota == NULL) { + isc_boolean_t killoldest = ISC_FALSE; + result = isc_quota_attach(&ns_g_server->recursionquota, + &client->recursionquota); + if (result == ISC_R_SOFTQUOTA) { + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_QUERY, ISC_LOG_WARNING, + "recursive-clients limit exceeded, " + "aborting oldest query"); + killoldest = ISC_TRUE; + result = ISC_R_SUCCESS; + } + if (dns_resolver_nrunning(client->view->resolver) > + (unsigned int)ns_g_server->recursionquota.max) + result = ISC_R_QUOTA; + if (result == ISC_R_SUCCESS && !client->mortal && + (client->attributes & NS_CLIENTATTR_TCP) == 0) + result = ns_client_replace(client); + if (result != ISC_R_SUCCESS) { + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_QUERY, ISC_LOG_WARNING, + "no more recursive clients: %s", + isc_result_totext(result)); + if (client->recursionquota != NULL) + isc_quota_detach(&client->recursionquota); + return (result); + } + ns_client_recursing(client, killoldest); + } + + /* + * Invoke the resolver. + */ + REQUIRE(nameservers == NULL || nameservers->type == dns_rdatatype_ns); + REQUIRE(client->query.fetch == NULL); + + rdataset = query_newrdataset(client); + if (rdataset == NULL) + return (ISC_R_NOMEMORY); + if (WANTDNSSEC(client)) { + sigrdataset = query_newrdataset(client); + if (sigrdataset == NULL) { + query_putrdataset(client, &rdataset); + return (ISC_R_NOMEMORY); + } + } else + sigrdataset = NULL; + + if (client->query.timerset == ISC_FALSE) + ns_client_settimeout(client, 60); + result = dns_resolver_createfetch(client->view->resolver, + client->query.qname, + qtype, qdomain, nameservers, + NULL, client->query.fetchoptions, + client->task, + query_resume, client, + rdataset, sigrdataset, + &client->query.fetch); + + if (result == ISC_R_SUCCESS) { + /* + * Record that we're waiting for an event. A client which + * is shutting down will not be destroyed until all the + * events have been received. + */ + } else { + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + } + + return (result); +} + +#define MAX_RESTARTS 16 + +#define QUERY_ERROR(r) \ +do { \ + eresult = r; \ + want_restart = ISC_FALSE; \ +} while (0) + +/* + * Extract a network address from the RDATA of an A or AAAA + * record. + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOTIMPLEMENTED The rdata is not a known address type. + */ +static isc_result_t +rdata_tonetaddr(dns_rdata_t *rdata, isc_netaddr_t *netaddr) { + struct in_addr ina; + struct in6_addr in6a; + + switch (rdata->type) { + case dns_rdatatype_a: + INSIST(rdata->length == 4); + memcpy(&ina.s_addr, rdata->data, 4); + isc_netaddr_fromin(netaddr, &ina); + return (ISC_R_SUCCESS); + case dns_rdatatype_aaaa: + INSIST(rdata->length == 16); + memcpy(in6a.s6_addr, rdata->data, 16); + isc_netaddr_fromin6(netaddr, &in6a); + return (ISC_R_SUCCESS); + default: + return (ISC_R_NOTIMPLEMENTED); + } +} + +/* + * Find the sort order of 'rdata' in the topology-like + * ACL forming the second element in a 2-element top-level + * sortlist statement. + */ +static int +query_sortlist_order_2element(dns_rdata_t *rdata, void *arg) { + isc_netaddr_t netaddr; + + if (rdata_tonetaddr(rdata, &netaddr) != ISC_R_SUCCESS) + return (INT_MAX); + return (ns_sortlist_addrorder2(&netaddr, arg)); +} + +/* + * Find the sort order of 'rdata' in the matching element + * of a 1-element top-level sortlist statement. + */ +static int +query_sortlist_order_1element(dns_rdata_t *rdata, void *arg) { + isc_netaddr_t netaddr; + + if (rdata_tonetaddr(rdata, &netaddr) != ISC_R_SUCCESS) + return (INT_MAX); + return (ns_sortlist_addrorder1(&netaddr, arg)); +} + +/* + * Find the sortlist statement that applies to 'client' and set up + * the sortlist info in in client->message appropriately. + */ +static void +setup_query_sortlist(ns_client_t *client) { + isc_netaddr_t netaddr; + dns_rdatasetorderfunc_t order = NULL; + void *order_arg = NULL; + + isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr); + switch (ns_sortlist_setup(client->view->sortlist, + &netaddr, &order_arg)) { + case NS_SORTLISTTYPE_1ELEMENT: + order = query_sortlist_order_1element; + break; + case NS_SORTLISTTYPE_2ELEMENT: + order = query_sortlist_order_2element; + break; + case NS_SORTLISTTYPE_NONE: + order = NULL; + break; + default: + INSIST(0); + break; + } + dns_message_setsortorder(client->message, order, order_arg); +} + +static void +query_addnoqnameproof(ns_client_t *client, dns_rdataset_t *rdataset) { + isc_buffer_t *dbuf, b; + dns_name_t *fname; + dns_rdataset_t *nsec, *nsecsig; + isc_result_t result = ISC_R_NOMEMORY; + + CTRACE("query_addnoqnameproof"); + + fname = NULL; + nsec = NULL; + nsecsig = NULL; + + dbuf = query_getnamebuf(client); + if (dbuf == NULL) + goto cleanup; + fname = query_newname(client, dbuf, &b); + nsec = query_newrdataset(client); + nsecsig = query_newrdataset(client); + if (fname == NULL || nsec == NULL || nsecsig == NULL) + goto cleanup; + + result = dns_rdataset_getnoqname(rdataset, fname, nsec, nsecsig); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + + query_addrrset(client, &fname, &nsec, &nsecsig, dbuf, + DNS_SECTION_AUTHORITY); + + cleanup: + if (nsec != NULL) + query_putrdataset(client, &nsec); + if (nsecsig != NULL) + query_putrdataset(client, &nsecsig); + if (fname != NULL) + query_releasename(client, &fname); +} + +/* + * Do the bulk of query processing for the current query of 'client'. + * If 'event' is non-NULL, we are returning from recursion and 'qtype' + * is ignored. Otherwise, 'qtype' is the query type. + */ +static void +query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) +{ + dns_db_t *db, *zdb; + dns_dbnode_t *node; + dns_rdatatype_t type; + dns_name_t *fname, *zfname, *tname, *prefix; + dns_rdataset_t *rdataset, *trdataset; + dns_rdataset_t *sigrdataset, *zrdataset, *zsigrdataset; + dns_rdataset_t **sigrdatasetp; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdatasetiter_t *rdsiter; + isc_boolean_t want_restart, authoritative, is_zone, need_wildcardproof; + unsigned int n, nlabels; + dns_namereln_t namereln; + int order; + isc_buffer_t *dbuf; + isc_buffer_t b; + isc_result_t result, eresult; + dns_fixedname_t fixed; + dns_fixedname_t wildcardname; + dns_dbversion_t *version; + dns_zone_t *zone; + dns_rdata_cname_t cname; + dns_rdata_dname_t dname; + unsigned int options; + isc_boolean_t empty_wild; + dns_rdataset_t *noqname; + + CTRACE("query_find"); + + /* + * One-time initialization. + * + * It's especially important to initialize anything that the cleanup + * code might cleanup. + */ + + eresult = ISC_R_SUCCESS; + fname = NULL; + zfname = NULL; + rdataset = NULL; + zrdataset = NULL; + sigrdataset = NULL; + zsigrdataset = NULL; + node = NULL; + db = NULL; + zdb = NULL; + version = NULL; + zone = NULL; + need_wildcardproof = ISC_FALSE; + empty_wild = ISC_FALSE; + options = 0; + + if (event != NULL) { + /* + * We're returning from recursion. Restore the query context + * and resume. + */ + + want_restart = ISC_FALSE; + authoritative = ISC_FALSE; + is_zone = ISC_FALSE; + + qtype = event->qtype; + if (qtype == dns_rdatatype_rrsig) + type = dns_rdatatype_any; + else + type = qtype; + db = event->db; + node = event->node; + rdataset = event->rdataset; + sigrdataset = event->sigrdataset; + + /* + * We'll need some resources... + */ + dbuf = query_getnamebuf(client); + if (dbuf == NULL) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + fname = query_newname(client, dbuf, &b); + if (fname == NULL) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + tname = dns_fixedname_name(&event->foundname); + result = dns_name_copy(tname, fname, NULL); + if (result != ISC_R_SUCCESS) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + + result = event->result; + + goto resume; + } + + /* + * Not returning from recursion. + */ + + /* + * If it's a SIG query, we'll iterate the node. + */ + if (qtype == dns_rdatatype_rrsig) + type = dns_rdatatype_any; + else + type = qtype; + + restart: + CTRACE("query_find: restart"); + want_restart = ISC_FALSE; + authoritative = ISC_FALSE; + version = NULL; + need_wildcardproof = ISC_FALSE; + + if (client->view->checknames && + !dns_rdata_checkowner(client->query.qname, + client->message->rdclass, + qtype, ISC_FALSE)) { + char namebuf[DNS_NAME_FORMATSIZE]; + char typename[DNS_RDATATYPE_FORMATSIZE]; + char classname[DNS_RDATACLASS_FORMATSIZE]; + + dns_name_format(client->query.qname, namebuf, sizeof(namebuf)); + dns_rdatatype_format(qtype, typename, sizeof(typename)); + dns_rdataclass_format(client->message->rdclass, classname, + sizeof(classname)); + ns_client_log(client, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_QUERY, ISC_LOG_ERROR, + "check-names failure %s/%s/%s", namebuf, + typename, classname); + QUERY_ERROR(DNS_R_REFUSED); + goto cleanup; + } + + /* + * First we must find the right database. + */ + options = 0; + if (dns_rdatatype_atparent(qtype) && + !dns_name_equal(client->query.qname, dns_rootname)) + options |= DNS_GETDB_NOEXACT; + result = query_getdb(client, client->query.qname, qtype, options, + &zone, &db, &version, &is_zone); + if ((result != ISC_R_SUCCESS || !is_zone) && !RECURSIONOK(client) && + (options & DNS_GETDB_NOEXACT) != 0 && qtype == dns_rdatatype_ds) { + /* + * Look to see if we are authoritative for the + * child zone if the query type is DS. + */ + dns_db_t *tdb = NULL; + dns_zone_t *tzone = NULL; + dns_dbversion_t *tversion = NULL; + isc_result_t tresult; + + tresult = query_getzonedb(client, client->query.qname, qtype, + DNS_GETDB_PARTIAL, &tzone, &tdb, + &tversion); + if (tresult == ISC_R_SUCCESS) { + options &= ~DNS_GETDB_NOEXACT; + query_putrdataset(client, &rdataset); + if (db != NULL) + dns_db_detach(&db); + if (zone != NULL) + dns_zone_detach(&zone); + version = tversion; + db = tdb; + zone = tzone; + is_zone = ISC_TRUE; + result = ISC_R_SUCCESS; + } else { + if (tdb != NULL) + dns_db_detach(&tdb); + if (tzone != NULL) + dns_zone_detach(&tzone); + } + } + if (result != ISC_R_SUCCESS) { + if (result == DNS_R_REFUSED) + QUERY_ERROR(DNS_R_REFUSED); + else + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + + if (is_zone) + authoritative = ISC_TRUE; + + if (event == NULL && client->query.restarts == 0) { + if (is_zone) { + dns_zone_attach(zone, &client->query.authzone); + dns_db_attach(db, &client->query.authdb); + } + client->query.authdbset = ISC_TRUE; + } + + db_find: + CTRACE("query_find: db_find"); + /* + * We'll need some resources... + */ + dbuf = query_getnamebuf(client); + if (dbuf == NULL) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + fname = query_newname(client, dbuf, &b); + rdataset = query_newrdataset(client); + if (fname == NULL || rdataset == NULL) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + if (WANTDNSSEC(client)) { + sigrdataset = query_newrdataset(client); + if (sigrdataset == NULL) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + } + + /* + * Now look for an answer in the database. + */ + result = dns_db_find(db, client->query.qname, version, type, + client->query.dboptions, client->now, + &node, fname, rdataset, sigrdataset); + + resume: + CTRACE("query_find: resume"); + switch (result) { + case ISC_R_SUCCESS: + /* + * This case is handled in the main line below. + */ + break; + case DNS_R_GLUE: + case DNS_R_ZONECUT: + /* + * These cases are handled in the main line below. + */ + INSIST(is_zone); + authoritative = ISC_FALSE; + break; + case ISC_R_NOTFOUND: + /* + * The cache doesn't even have the root NS. Get them from + * the hints DB. + */ + INSIST(!is_zone); + if (db != NULL) + dns_db_detach(&db); + + if (client->view->hints == NULL) { + /* We have no hints. */ + result = ISC_R_FAILURE; + } else { + dns_db_attach(client->view->hints, &db); + result = dns_db_find(db, dns_rootname, + NULL, dns_rdatatype_ns, + 0, client->now, &node, fname, + rdataset, sigrdataset); + } + if (result != ISC_R_SUCCESS) { + /* + * Nonsensical root hints may require cleanup. + */ + if (dns_rdataset_isassociated(rdataset)) + dns_rdataset_disassociate(rdataset); + if (sigrdataset != NULL && + dns_rdataset_isassociated(sigrdataset)) + dns_rdataset_disassociate(sigrdataset); + if (node != NULL) + dns_db_detachnode(db, &node); + + /* + * We don't have any root server hints, but + * we may have working forwarders, so try to + * recurse anyway. + */ + if (RECURSIONOK(client)) { + result = query_recurse(client, qtype, + NULL, NULL); + if (result == ISC_R_SUCCESS) + client->query.attributes |= + NS_QUERYATTR_RECURSING; + else { + /* Unable to recurse. */ + QUERY_ERROR(DNS_R_SERVFAIL); + } + goto cleanup; + } else { + /* Unable to give root server referral. */ + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + } + /* + * XXXRTH We should trigger root server priming here. + */ + /* FALLTHROUGH */ + case DNS_R_DELEGATION: + authoritative = ISC_FALSE; + if (is_zone) { + /* + * Look to see if we are authoritative for the + * child zone if the query type is DS. + */ + if (!RECURSIONOK(client) && + (options & DNS_GETDB_NOEXACT) != 0 && + qtype == dns_rdatatype_ds) { + dns_db_t *tdb = NULL; + dns_zone_t *tzone = NULL; + dns_dbversion_t *tversion = NULL; + result = query_getzonedb(client, + client->query.qname, + qtype, + DNS_GETDB_PARTIAL, + &tzone, &tdb, + &tversion); + if (result == ISC_R_SUCCESS) { + options &= ~DNS_GETDB_NOEXACT; + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, + &sigrdataset); + if (fname != NULL) + query_releasename(client, + &fname); + if (node != NULL) + dns_db_detachnode(db, &node); + if (db != NULL) + dns_db_detach(&db); + if (zone != NULL) + dns_zone_detach(&zone); + version = tversion; + db = tdb; + zone = tzone; + authoritative = ISC_TRUE; + goto db_find; + } + if (tdb != NULL) + dns_db_detach(&tdb); + if (tzone != NULL) + dns_zone_detach(&tzone); + } + /* + * We're authoritative for an ancestor of QNAME. + */ + if (!USECACHE(client) || !RECURSIONOK(client)) { + /* + * If we don't have a cache, this is the best + * answer. + * + * If the client is making a nonrecursive + * query we always give out the authoritative + * delegation. This way even if we get + * junk in our cache, we won't fail in our + * role as the delegating authority if another + * nameserver asks us about a delegated + * subzone. + * + * We enable the retrieval of glue for this + * database by setting client->query.gluedb. + */ + client->query.gluedb = db; + client->query.isreferral = ISC_TRUE; + /* + * We must ensure NOADDITIONAL is off, + * because the generation of + * additional data is required in + * delegations. + */ + client->query.attributes &= + ~NS_QUERYATTR_NOADDITIONAL; + if (sigrdataset != NULL) + sigrdatasetp = &sigrdataset; + else + sigrdatasetp = NULL; + query_addrrset(client, &fname, + &rdataset, sigrdatasetp, + dbuf, DNS_SECTION_AUTHORITY); + client->query.gluedb = NULL; + if (WANTDNSSEC(client) && dns_db_issecure(db)) + query_addds(client, db, node); + } else { + /* + * We might have a better answer or delegation + * in the cache. We'll remember the current + * values of fname, rdataset, and sigrdataset. + * We'll then go looking for QNAME in the + * cache. If we find something better, we'll + * use it instead. + */ + query_keepname(client, fname, dbuf); + zdb = db; + zfname = fname; + fname = NULL; + zrdataset = rdataset; + rdataset = NULL; + zsigrdataset = sigrdataset; + sigrdataset = NULL; + dns_db_detachnode(db, &node); + version = NULL; + db = NULL; + dns_db_attach(client->view->cachedb, &db); + is_zone = ISC_FALSE; + goto db_find; + } + } else { + if (zfname != NULL && + !dns_name_issubdomain(fname, zfname)) { + /* + * We've already got a delegation from + * authoritative data, and it is better + * than what we found in the cache. Use + * it instead of the cache delegation. + */ + query_releasename(client, &fname); + fname = zfname; + zfname = NULL; + /* + * We've already done query_keepname() on + * zfname, so we must set dbuf to NULL to + * prevent query_addrrset() from trying to + * call query_keepname() again. + */ + dbuf = NULL; + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, + &sigrdataset); + rdataset = zrdataset; + zrdataset = NULL; + sigrdataset = zsigrdataset; + zsigrdataset = NULL; + /* + * We don't clean up zdb here because we + * may still need it. It will get cleaned + * up by the main cleanup code. + */ + } + + if (RECURSIONOK(client)) { + /* + * Recurse! + */ + if (dns_rdatatype_atparent(type)) + result = query_recurse(client, qtype, + NULL, NULL); + else + result = query_recurse(client, qtype, + fname, rdataset); + if (result == ISC_R_SUCCESS) + client->query.attributes |= + NS_QUERYATTR_RECURSING; + else + QUERY_ERROR(DNS_R_SERVFAIL); + } else { + /* + * This is the best answer. + */ + client->query.attributes |= + NS_QUERYATTR_CACHEGLUEOK; + client->query.gluedb = zdb; + client->query.isreferral = ISC_TRUE; + /* + * We must ensure NOADDITIONAL is off, + * because the generation of + * additional data is required in + * delegations. + */ + client->query.attributes &= + ~NS_QUERYATTR_NOADDITIONAL; + if (sigrdataset != NULL) + sigrdatasetp = &sigrdataset; + else + sigrdatasetp = NULL; + query_addrrset(client, &fname, + &rdataset, sigrdatasetp, + dbuf, DNS_SECTION_AUTHORITY); + client->query.gluedb = NULL; + client->query.attributes &= + ~NS_QUERYATTR_CACHEGLUEOK; + if (WANTDNSSEC(client)) + query_addds(client, db, node); + } + } + goto cleanup; + case DNS_R_EMPTYNAME: + result = DNS_R_NXRRSET; + /* FALLTHROUGH */ + case DNS_R_NXRRSET: + INSIST(is_zone); + if (dns_rdataset_isassociated(rdataset)) { + /* + * If we've got a NSEC record, we need to save the + * name now because we're going call query_addsoa() + * below, and it needs to use the name buffer. + */ + query_keepname(client, fname, dbuf); + } else { + /* + * We're not going to use fname, and need to release + * our hold on the name buffer so query_addsoa() + * may use it. + */ + query_releasename(client, &fname); + } + /* + * Add SOA. + */ + result = query_addsoa(client, db, ISC_FALSE); + if (result != ISC_R_SUCCESS) { + QUERY_ERROR(result); + goto cleanup; + } + /* + * Add NSEC record if we found one. + */ + if (WANTDNSSEC(client)) { + if (dns_rdataset_isassociated(rdataset)) + query_addnxrrsetnsec(client, db, &fname, + &rdataset, &sigrdataset); + } + goto cleanup; + case DNS_R_EMPTYWILD: + empty_wild = ISC_TRUE; + /* FALLTHROUGH */ + case DNS_R_NXDOMAIN: + INSIST(is_zone); + if (dns_rdataset_isassociated(rdataset)) { + /* + * If we've got a NSEC record, we need to save the + * name now because we're going call query_addsoa() + * below, and it needs to use the name buffer. + */ + query_keepname(client, fname, dbuf); + } else { + /* + * We're not going to use fname, and need to release + * our hold on the name buffer so query_addsoa() + * may use it. + */ + query_releasename(client, &fname); + } + /* + * Add SOA. If the query was for a SOA record force the + * ttl to zero so that it is possible for clients to find + * the containing zone of a arbitary name with a stub + * resolver and not have it cached. + */ + if (qtype == dns_rdatatype_soa) + result = query_addsoa(client, db, ISC_TRUE); + else + result = query_addsoa(client, db, ISC_FALSE); + if (result != ISC_R_SUCCESS) { + QUERY_ERROR(result); + goto cleanup; + } + /* + * Add NSEC record if we found one. + */ + if (dns_rdataset_isassociated(rdataset)) { + if (WANTDNSSEC(client)) { + query_addrrset(client, &fname, &rdataset, + &sigrdataset, + NULL, DNS_SECTION_AUTHORITY); + query_addwildcardproof(client, db, + client->query.qname, + ISC_FALSE); + } + } + /* + * Set message rcode. + */ + if (empty_wild) + client->message->rcode = dns_rcode_noerror; + else + client->message->rcode = dns_rcode_nxdomain; + goto cleanup; + case DNS_R_NCACHENXDOMAIN: + case DNS_R_NCACHENXRRSET: + INSIST(!is_zone); + authoritative = ISC_FALSE; + /* + * Set message rcode, if required. + */ + if (result == DNS_R_NCACHENXDOMAIN) + client->message->rcode = dns_rcode_nxdomain; + /* + * We don't call query_addrrset() because we don't need any + * of its extra features (and things would probably break!). + */ + query_keepname(client, fname, dbuf); + dns_message_addname(client->message, fname, + DNS_SECTION_AUTHORITY); + ISC_LIST_APPEND(fname->list, rdataset, link); + fname = NULL; + rdataset = NULL; + goto cleanup; + case DNS_R_CNAME: + /* + * Keep a copy of the rdataset. We have to do this because + * query_addrrset may clear 'rdataset' (to prevent the + * cleanup code from cleaning it up). + */ + trdataset = rdataset; + /* + * Add the CNAME to the answer section. + */ + if (sigrdataset != NULL) + sigrdatasetp = &sigrdataset; + else + sigrdatasetp = NULL; + if (WANTDNSSEC(client) && + (fname->attributes & DNS_NAMEATTR_WILDCARD) != 0) + { + dns_fixedname_init(&wildcardname); + dns_name_copy(fname, dns_fixedname_name(&wildcardname), + NULL); + need_wildcardproof = ISC_TRUE; + } + if ((rdataset->attributes & DNS_RDATASETATTR_NOQNAME) != 0 && + WANTDNSSEC(client)) + noqname = rdataset; + else + noqname = NULL; + query_addrrset(client, &fname, &rdataset, sigrdatasetp, dbuf, + DNS_SECTION_ANSWER); + if (noqname != NULL) + query_addnoqnameproof(client, noqname); + /* + * We set the PARTIALANSWER attribute so that if anything goes + * wrong later on, we'll return what we've got so far. + */ + client->query.attributes |= NS_QUERYATTR_PARTIALANSWER; + /* + * Reset qname to be the target name of the CNAME and restart + * the query. + */ + tname = NULL; + result = dns_message_gettempname(client->message, &tname); + if (result != ISC_R_SUCCESS) + goto cleanup; + result = dns_rdataset_first(trdataset); + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(client->message, &tname); + goto cleanup; + } + dns_rdataset_current(trdataset, &rdata); + result = dns_rdata_tostruct(&rdata, &cname, NULL); + dns_rdata_reset(&rdata); + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(client->message, &tname); + goto cleanup; + } + dns_name_init(tname, NULL); + result = dns_name_dup(&cname.cname, client->mctx, tname); + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(client->message, &tname); + dns_rdata_freestruct(&cname); + goto cleanup; + } + dns_rdata_freestruct(&cname); + query_maybeputqname(client); + client->query.qname = tname; + want_restart = ISC_TRUE; + goto addauth; + case DNS_R_DNAME: + /* + * Compare the current qname to the found name. We need + * to know how many labels and bits are in common because + * we're going to have to split qname later on. + */ + namereln = dns_name_fullcompare(client->query.qname, fname, + &order, &nlabels); + INSIST(namereln == dns_namereln_subdomain); + /* + * Keep a copy of the rdataset. We have to do this because + * query_addrrset may clear 'rdataset' (to prevent the + * cleanup code from cleaning it up). + */ + trdataset = rdataset; + /* + * Add the DNAME to the answer section. + */ + if (sigrdataset != NULL) + sigrdatasetp = &sigrdataset; + else + sigrdatasetp = NULL; + if (WANTDNSSEC(client) && + (fname->attributes & DNS_NAMEATTR_WILDCARD) != 0) + { + dns_fixedname_init(&wildcardname); + dns_name_copy(fname, dns_fixedname_name(&wildcardname), + NULL); + need_wildcardproof = ISC_TRUE; + } + query_addrrset(client, &fname, &rdataset, sigrdatasetp, dbuf, + DNS_SECTION_ANSWER); + /* + * We set the PARTIALANSWER attribute so that if anything goes + * wrong later on, we'll return what we've got so far. + */ + client->query.attributes |= NS_QUERYATTR_PARTIALANSWER; + /* + * Get the target name of the DNAME. + */ + tname = NULL; + result = dns_message_gettempname(client->message, &tname); + if (result != ISC_R_SUCCESS) + goto cleanup; + result = dns_rdataset_first(trdataset); + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(client->message, &tname); + goto cleanup; + } + dns_rdataset_current(trdataset, &rdata); + result = dns_rdata_tostruct(&rdata, &dname, NULL); + dns_rdata_reset(&rdata); + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(client->message, &tname); + goto cleanup; + } + dns_name_init(tname, NULL); + dns_name_clone(&dname.dname, tname); + dns_rdata_freestruct(&dname); + /* + * Construct the new qname. + */ + dns_fixedname_init(&fixed); + prefix = dns_fixedname_name(&fixed); + dns_name_split(client->query.qname, nlabels, prefix, NULL); + INSIST(fname == NULL); + dbuf = query_getnamebuf(client); + if (dbuf == NULL) { + dns_message_puttempname(client->message, &tname); + goto cleanup; + } + fname = query_newname(client, dbuf, &b); + if (fname == NULL) { + dns_message_puttempname(client->message, &tname); + goto cleanup; + } + result = dns_name_concatenate(prefix, tname, fname, NULL); + if (result != ISC_R_SUCCESS) { + dns_message_puttempname(client->message, &tname); + if (result == ISC_R_NOSPACE) { + /* + * RFC 2672, section 4.1, subsection 3c says + * we should return YXDOMAIN if the constructed + * name would be too long. + */ + client->message->rcode = dns_rcode_yxdomain; + } + goto cleanup; + } + query_keepname(client, fname, dbuf); + /* + * Synthesize a CNAME for this DNAME. + * + * We want to synthesize a CNAME since if we don't + * then older software that doesn't understand DNAME + * will not chain like it should. + * + * We do not try to synthesize a signature because we hope + * that security aware servers will understand DNAME. Also, + * even if we had an online key, making a signature + * on-the-fly is costly, and not really legitimate anyway + * since the synthesized CNAME is NOT in the zone. + */ + dns_name_init(tname, NULL); + (void)query_addcnamelike(client, client->query.qname, fname, + trdataset->trust, &tname, + dns_rdatatype_cname); + if (tname != NULL) + dns_message_puttempname(client->message, &tname); + /* + * Switch to the new qname and restart. + */ + query_maybeputqname(client); + client->query.qname = fname; + fname = NULL; + want_restart = ISC_TRUE; + goto addauth; + default: + /* + * Something has gone wrong. + */ + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + + if (WANTDNSSEC(client) && + (fname->attributes & DNS_NAMEATTR_WILDCARD) != 0) + { + dns_fixedname_init(&wildcardname); + dns_name_copy(fname, dns_fixedname_name(&wildcardname), NULL); + need_wildcardproof = ISC_TRUE; + } + + if (type == dns_rdatatype_any) { + /* + * XXXRTH Need to handle zonecuts with special case + * code. + */ + n = 0; + rdsiter = NULL; + result = dns_db_allrdatasets(db, node, version, 0, &rdsiter); + if (result != ISC_R_SUCCESS) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + /* + * Calling query_addrrset() with a non-NULL dbuf is going + * to either keep or release the name. We don't want it to + * release fname, since we may have to call query_addrrset() + * more than once. That means we have to call query_keepname() + * now, and pass a NULL dbuf to query_addrrset(). + * + * If we do a query_addrrset() below, we must set fname to + * NULL before leaving this block, otherwise we might try to + * cleanup fname even though we're using it! + */ + query_keepname(client, fname, dbuf); + tname = fname; + result = dns_rdatasetiter_first(rdsiter); + while (result == ISC_R_SUCCESS) { + dns_rdatasetiter_current(rdsiter, rdataset); + if ((qtype == dns_rdatatype_any || + rdataset->type == qtype) && rdataset->type != 0) { + query_addrrset(client, + fname != NULL ? &fname : &tname, + &rdataset, NULL, + NULL, DNS_SECTION_ANSWER); + n++; + INSIST(tname != NULL); + /* + * rdataset is non-NULL only in certain pathological + * cases involving DNAMEs. + */ + if (rdataset != NULL) + query_putrdataset(client, &rdataset); + rdataset = query_newrdataset(client); + if (rdataset == NULL) + break; + } else { + /* + * We're not interested in this rdataset. + */ + dns_rdataset_disassociate(rdataset); + } + result = dns_rdatasetiter_next(rdsiter); + } + + if (fname != NULL) + dns_message_puttempname(client->message, &fname); + + if (n == 0) { + /* + * We didn't match any rdatasets. + */ + if (qtype == dns_rdatatype_rrsig && + result == ISC_R_NOMORE) { + /* + * XXXRTH If this is a secure zone and we + * didn't find any SIGs, we should generate + * an error unless we were searching for + * glue. Ugh. + */ + /* + * We were searching for SIG records in + * a nonsecure zone. Send a "no error, + * no data" response. + */ + /* + * Add SOA. + */ + result = query_addsoa(client, db, ISC_FALSE); + if (result == ISC_R_SUCCESS) + result = ISC_R_NOMORE; + } else { + /* + * Something went wrong. + */ + result = DNS_R_SERVFAIL; + } + } + dns_rdatasetiter_destroy(&rdsiter); + if (result != ISC_R_NOMORE) { + QUERY_ERROR(DNS_R_SERVFAIL); + goto cleanup; + } + } else { + /* + * This is the "normal" case -- an ordinary question to which + * we know the answer. + */ + if (sigrdataset != NULL) + sigrdatasetp = &sigrdataset; + else + sigrdatasetp = NULL; + if ((rdataset->attributes & DNS_RDATASETATTR_NOQNAME) != 0 && + WANTDNSSEC(client)) + noqname = rdataset; + else + noqname = NULL; + query_addrrset(client, &fname, &rdataset, sigrdatasetp, dbuf, + DNS_SECTION_ANSWER); + if (noqname != NULL) + query_addnoqnameproof(client, noqname); + /* + * We shouldn't ever fail to add 'rdataset' + * because it's already in the answer. + */ + INSIST(rdataset == NULL); + } + + addauth: + CTRACE("query_find: addauth"); + /* + * Add NS records to the authority section (if we haven't already + * added them to the answer section). + */ + if (!want_restart && !NOAUTHORITY(client)) { + if (is_zone) { + if (!((qtype == dns_rdatatype_ns || + qtype == dns_rdatatype_any) && + dns_name_equal(client->query.qname, + dns_db_origin(db)))) + (void)query_addns(client, db); + } else if (qtype != dns_rdatatype_ns) { + if (fname != NULL) + query_releasename(client, &fname); + query_addbestns(client); + } + } + + /* + * Add NSEC records to the authority section if they're needed for + * DNSSEC wildcard proofs. + */ + if (need_wildcardproof && dns_db_issecure(db)) + query_addwildcardproof(client, db, + dns_fixedname_name(&wildcardname), + ISC_TRUE); + cleanup: + CTRACE("query_find: cleanup"); + /* + * General cleanup. + */ + if (rdataset != NULL) + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + if (fname != NULL) + query_releasename(client, &fname); + if (node != NULL) + dns_db_detachnode(db, &node); + if (db != NULL) + dns_db_detach(&db); + if (zone != NULL) + dns_zone_detach(&zone); + if (zdb != NULL) { + query_putrdataset(client, &zrdataset); + if (zsigrdataset != NULL) + query_putrdataset(client, &zsigrdataset); + if (zfname != NULL) + query_releasename(client, &zfname); + dns_db_detach(&zdb); + } + if (event != NULL) + isc_event_free(ISC_EVENT_PTR(&event)); + + /* + * AA bit. + */ + if (client->query.restarts == 0 && !authoritative) { + /* + * We're not authoritative, so we must ensure the AA bit + * isn't set. + */ + client->message->flags &= ~DNS_MESSAGEFLAG_AA; + } + + /* + * Restart the query? + */ + if (want_restart && client->query.restarts < MAX_RESTARTS) { + client->query.restarts++; + goto restart; + } + + if (eresult != ISC_R_SUCCESS && + (!PARTIALANSWER(client) || WANTRECURSION(client))) { + /* + * If we don't have any answer to give the client, + * or if the client requested recursion and thus wanted + * the complete answer, send an error response. + */ + query_error(client, eresult); + ns_client_detach(&client); + } else if (!RECURSING(client)) { + /* + * We are done. Set up sortlist data for the message + * rendering code, make a final tweak to the AA bit if the + * auth-nxdomain config option says so, then render and + * send the response. + */ + setup_query_sortlist(client); + + if (client->message->rcode == dns_rcode_nxdomain && + client->view->auth_nxdomain == ISC_TRUE) + client->message->flags |= DNS_MESSAGEFLAG_AA; + + query_send(client); + ns_client_detach(&client); + } + CTRACE("query_find: done"); +} + +static inline void +log_query(ns_client_t *client) { + char namebuf[DNS_NAME_FORMATSIZE]; + char typename[DNS_RDATATYPE_FORMATSIZE]; + char classname[DNS_RDATACLASS_FORMATSIZE]; + dns_rdataset_t *rdataset; + int level = ISC_LOG_INFO; + + if (! isc_log_wouldlog(ns_g_lctx, level)) + return; + + rdataset = ISC_LIST_HEAD(client->query.qname->list); + INSIST(rdataset != NULL); + dns_name_format(client->query.qname, namebuf, sizeof(namebuf)); + dns_rdataclass_format(rdataset->rdclass, classname, sizeof(classname)); + dns_rdatatype_format(rdataset->type, typename, sizeof(typename)); + + ns_client_log(client, NS_LOGCATEGORY_QUERIES, NS_LOGMODULE_QUERY, + level, "query: %s %s %s %s%s%s", namebuf, classname, + typename, WANTRECURSION(client) ? "+" : "-", + (client->signer != NULL) ? "S": "", + (client->opt != NULL) ? "E" : ""); +} + +void +ns_query_start(ns_client_t *client) { + isc_result_t result; + dns_message_t *message = client->message; + dns_rdataset_t *rdataset; + ns_client_t *qclient; + dns_rdatatype_t qtype; + + CTRACE("ns_query_start"); + + /* + * Ensure that appropriate cleanups occur. + */ + client->next = query_next_callback; + + /* + * Behave as if we don't support DNSSEC if not enabled. + */ + if (!client->view->enablednssec) { + message->flags &= ~DNS_MESSAGEFLAG_CD; + client->extflags &= ~DNS_MESSAGEEXTFLAG_DO; + } + + if ((message->flags & DNS_MESSAGEFLAG_RD) != 0) + client->query.attributes |= NS_QUERYATTR_WANTRECURSION; + + if ((client->extflags & DNS_MESSAGEEXTFLAG_DO) != 0) + client->attributes |= NS_CLIENTATTR_WANTDNSSEC; + + if (client->view->minimalresponses) + client->query.attributes |= (NS_QUERYATTR_NOAUTHORITY | + NS_QUERYATTR_NOADDITIONAL); + + if ((client->view->cachedb == NULL) + || (!client->view->additionalfromcache)) { + /* + * We don't have a cache. Turn off cache support and + * recursion. + */ + client->query.attributes &= + ~(NS_QUERYATTR_RECURSIONOK|NS_QUERYATTR_CACHEOK); + } else if ((client->attributes & NS_CLIENTATTR_RA) == 0 || + (message->flags & DNS_MESSAGEFLAG_RD) == 0) { + /* + * If the client isn't allowed to recurse (due to + * "recursion no", the allow-recursion ACL, or the + * lack of a resolver in this view), or if it + * doesn't want recursion, turn recursion off. + */ + client->query.attributes &= ~NS_QUERYATTR_RECURSIONOK; + } + + /* + * Get the question name. + */ + result = dns_message_firstname(message, DNS_SECTION_QUESTION); + if (result != ISC_R_SUCCESS) { + query_error(client, result); + return; + } + dns_message_currentname(message, DNS_SECTION_QUESTION, + &client->query.qname); + client->query.origqname = client->query.qname; + result = dns_message_nextname(message, DNS_SECTION_QUESTION); + if (result != ISC_R_NOMORE) { + if (result == ISC_R_SUCCESS) { + /* + * There's more than one QNAME in the question + * section. + */ + query_error(client, DNS_R_FORMERR); + } else + query_error(client, result); + return; + } + + if (ns_g_server->log_queries) + log_query(client); + + /* + * Check for multiple question queries, since edns1 is dead. + */ + if (message->counts[DNS_SECTION_QUESTION] > 1) { + query_error(client, DNS_R_FORMERR); + return; + } + + /* + * Check for meta-queries like IXFR and AXFR. + */ + rdataset = ISC_LIST_HEAD(client->query.qname->list); + INSIST(rdataset != NULL); + qtype = rdataset->type; + if (dns_rdatatype_ismeta(qtype)) { + switch (qtype) { + case dns_rdatatype_any: + break; /* Let query_find handle it. */ + case dns_rdatatype_ixfr: + case dns_rdatatype_axfr: + ns_xfr_start(client, rdataset->type); + return; + case dns_rdatatype_maila: + case dns_rdatatype_mailb: + query_error(client, DNS_R_NOTIMP); + return; + case dns_rdatatype_tkey: + result = dns_tkey_processquery(client->message, + ns_g_server->tkeyctx, + client->view->dynamickeys); + if (result == ISC_R_SUCCESS) + query_send(client); + else + query_error(client, result); + return; + default: /* TSIG, etc. */ + query_error(client, DNS_R_FORMERR); + return; + } + } + + /* + * If the client has requested that DNSSEC checking be disabled, + * allow lookups to return pending data and instruct the resolver + * to return data before validation has completed. + */ + if (message->flags & DNS_MESSAGEFLAG_CD || + qtype == dns_rdatatype_rrsig) + { + client->query.dboptions |= DNS_DBFIND_PENDINGOK; + client->query.fetchoptions |= DNS_FETCHOPT_NOVALIDATE; + } + + /* + * Allow glue NS records to be added to the authority section + * if the answer is secure. + */ + if (message->flags & DNS_MESSAGEFLAG_CD) + client->query.attributes &= ~NS_QUERYATTR_SECURE; + + /* + * This is an ordinary query. + */ + result = dns_message_reply(message, ISC_TRUE); + if (result != ISC_R_SUCCESS) { + query_next(client, result); + return; + } + + /* + * Assume authoritative response until it is known to be + * otherwise. + */ + message->flags |= DNS_MESSAGEFLAG_AA; + + /* + * Set AD. We must clear it if we add non-validated data to a + * response. + */ + if (client->view->enablednssec) + message->flags |= DNS_MESSAGEFLAG_AD; + + qclient = NULL; + ns_client_attach(client, &qclient); + query_find(qclient, NULL, qtype); +} diff --git a/contrib/bind9/bin/named/server.c b/contrib/bind9/bin/named/server.c new file mode 100644 index 000000000000..9080376d2ded --- /dev/null +++ b/contrib/bind9/bin/named/server.c @@ -0,0 +1,4089 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: server.c,v 1.339.2.15.2.56 2004/06/18 04:39:48 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * Check an operation for failure. Assumes that the function + * using it has a 'result' variable and a 'cleanup' label. + */ +#define CHECK(op) \ + do { result = (op); \ + if (result != ISC_R_SUCCESS) goto cleanup; \ + } while (0) + +#define CHECKM(op, msg) \ + do { result = (op); \ + if (result != ISC_R_SUCCESS) { \ + isc_log_write(ns_g_lctx, \ + NS_LOGCATEGORY_GENERAL, \ + NS_LOGMODULE_SERVER, \ + ISC_LOG_ERROR, \ + "%s: %s", msg, \ + isc_result_totext(result)); \ + goto cleanup; \ + } \ + } while (0) \ + +#define CHECKMF(op, msg, file) \ + do { result = (op); \ + if (result != ISC_R_SUCCESS) { \ + isc_log_write(ns_g_lctx, \ + NS_LOGCATEGORY_GENERAL, \ + NS_LOGMODULE_SERVER, \ + ISC_LOG_ERROR, \ + "%s '%s': %s", msg, file, \ + isc_result_totext(result)); \ + goto cleanup; \ + } \ + } while (0) \ + +#define CHECKFATAL(op, msg) \ + do { result = (op); \ + if (result != ISC_R_SUCCESS) \ + fatal(msg, result); \ + } while (0) \ + +struct ns_dispatch { + isc_sockaddr_t addr; + unsigned int dispatchgen; + dns_dispatch_t *dispatch; + ISC_LINK(struct ns_dispatch) link; +}; + +struct dumpcontext { + isc_mem_t *mctx; + isc_boolean_t dumpcache; + isc_boolean_t dumpzones; + FILE *fp; + ISC_LIST(struct viewlistentry) viewlist; + struct viewlistentry *view; + struct zonelistentry *zone; + dns_dumpctx_t *mdctx; + dns_db_t *db; + dns_db_t *cache; + isc_task_t *task; + dns_dbversion_t *version; +}; + +struct viewlistentry { + dns_view_t *view; + ISC_LINK(struct viewlistentry) link; + ISC_LIST(struct zonelistentry) zonelist; +}; + +struct zonelistentry { + dns_zone_t *zone; + ISC_LINK(struct zonelistentry) link; +}; + +static void +fatal(const char *msg, isc_result_t result); + +static void +ns_server_reload(isc_task_t *task, isc_event_t *event); + +static isc_result_t +ns_listenelt_fromconfig(cfg_obj_t *listener, cfg_obj_t *config, + ns_aclconfctx_t *actx, + isc_mem_t *mctx, ns_listenelt_t **target); +static isc_result_t +ns_listenlist_fromconfig(cfg_obj_t *listenlist, cfg_obj_t *config, + ns_aclconfctx_t *actx, + isc_mem_t *mctx, ns_listenlist_t **target); + +static isc_result_t +configure_forward(cfg_obj_t *config, dns_view_t *view, dns_name_t *origin, + cfg_obj_t *forwarders, cfg_obj_t *forwardtype); + +static isc_result_t +configure_alternates(cfg_obj_t *config, dns_view_t *view, + cfg_obj_t *alternates); + +static isc_result_t +configure_zone(cfg_obj_t *config, cfg_obj_t *zconfig, cfg_obj_t *vconfig, + isc_mem_t *mctx, dns_view_t *view, + ns_aclconfctx_t *aclconf); + +static void +end_reserved_dispatches(ns_server_t *server, isc_boolean_t all); + +/* + * Configure a single view ACL at '*aclp'. Get its configuration by + * calling 'getvcacl' (for per-view configuration) and maybe 'getscacl' + * (for a global default). + */ +static isc_result_t +configure_view_acl(cfg_obj_t *vconfig, cfg_obj_t *config, + const char *aclname, ns_aclconfctx_t *actx, + isc_mem_t *mctx, dns_acl_t **aclp) +{ + isc_result_t result; + cfg_obj_t *maps[3]; + cfg_obj_t *aclobj = NULL; + int i = 0; + + if (*aclp != NULL) + dns_acl_detach(aclp); + if (vconfig != NULL) + maps[i++] = cfg_tuple_get(vconfig, "options"); + if (config != NULL) { + cfg_obj_t *options = NULL; + (void)cfg_map_get(config, "options", &options); + if (options != NULL) + maps[i++] = options; + } + maps[i] = NULL; + + result = ns_config_get(maps, aclname, &aclobj); + if (aclobj == NULL) + /* + * No value available. *aclp == NULL. + */ + return (ISC_R_SUCCESS); + + result = ns_acl_fromconfig(aclobj, config, actx, mctx, aclp); + + return (result); +} + +static isc_result_t +configure_view_dnsseckey(cfg_obj_t *vconfig, cfg_obj_t *key, + dns_keytable_t *keytable, isc_mem_t *mctx) +{ + dns_rdataclass_t viewclass; + dns_rdata_dnskey_t keystruct; + isc_uint32_t flags, proto, alg; + char *keystr, *keynamestr; + unsigned char keydata[4096]; + isc_buffer_t keydatabuf; + unsigned char rrdata[4096]; + isc_buffer_t rrdatabuf; + isc_region_t r; + dns_fixedname_t fkeyname; + dns_name_t *keyname; + isc_buffer_t namebuf; + isc_result_t result; + dst_key_t *dstkey = NULL; + + flags = cfg_obj_asuint32(cfg_tuple_get(key, "flags")); + proto = cfg_obj_asuint32(cfg_tuple_get(key, "protocol")); + alg = cfg_obj_asuint32(cfg_tuple_get(key, "algorithm")); + keyname = dns_fixedname_name(&fkeyname); + keynamestr = cfg_obj_asstring(cfg_tuple_get(key, "name")); + + if (vconfig == NULL) + viewclass = dns_rdataclass_in; + else { + cfg_obj_t *classobj = cfg_tuple_get(vconfig, "class"); + CHECK(ns_config_getclass(classobj, dns_rdataclass_in, + &viewclass)); + } + keystruct.common.rdclass = viewclass; + keystruct.common.rdtype = dns_rdatatype_dnskey; + /* + * The key data in keystruct is not dynamically allocated. + */ + keystruct.mctx = NULL; + + ISC_LINK_INIT(&keystruct.common, link); + + if (flags > 0xffff) + CHECKM(ISC_R_RANGE, "key flags"); + if (proto > 0xff) + CHECKM(ISC_R_RANGE, "key protocol"); + if (alg > 0xff) + CHECKM(ISC_R_RANGE, "key algorithm"); + keystruct.flags = (isc_uint16_t)flags; + keystruct.protocol = (isc_uint8_t)proto; + keystruct.algorithm = (isc_uint8_t)alg; + + isc_buffer_init(&keydatabuf, keydata, sizeof(keydata)); + isc_buffer_init(&rrdatabuf, rrdata, sizeof(rrdata)); + + keystr = cfg_obj_asstring(cfg_tuple_get(key, "key")); + CHECK(isc_base64_decodestring(keystr, &keydatabuf)); + isc_buffer_usedregion(&keydatabuf, &r); + keystruct.datalen = r.length; + keystruct.data = r.base; + + CHECK(dns_rdata_fromstruct(NULL, + keystruct.common.rdclass, + keystruct.common.rdtype, + &keystruct, &rrdatabuf)); + dns_fixedname_init(&fkeyname); + isc_buffer_init(&namebuf, keynamestr, strlen(keynamestr)); + isc_buffer_add(&namebuf, strlen(keynamestr)); + CHECK(dns_name_fromtext(keyname, &namebuf, + dns_rootname, ISC_FALSE, + NULL)); + CHECK(dst_key_fromdns(keyname, viewclass, &rrdatabuf, + mctx, &dstkey)); + + CHECK(dns_keytable_add(keytable, &dstkey)); + INSIST(dstkey == NULL); + return (ISC_R_SUCCESS); + + cleanup: + if (result == DST_R_NOCRYPTO) { + cfg_obj_log(key, ns_g_lctx, ISC_LOG_ERROR, + "ignoring trusted key for '%s': no crypto support", + keynamestr); + result = ISC_R_SUCCESS; + } else { + cfg_obj_log(key, ns_g_lctx, ISC_LOG_ERROR, + "configuring trusted key for '%s': %s", + keynamestr, isc_result_totext(result)); + result = ISC_R_FAILURE; + } + + if (dstkey != NULL) + dst_key_free(&dstkey); + + return (result); +} + +/* + * Configure DNSSEC keys for a view. Currently used only for + * the security roots. + * + * The per-view configuration values and the server-global defaults are read + * from 'vconfig' and 'config'. The variable to be configured is '*target'. + */ +static isc_result_t +configure_view_dnsseckeys(cfg_obj_t *vconfig, cfg_obj_t *config, + isc_mem_t *mctx, dns_keytable_t **target) +{ + isc_result_t result; + cfg_obj_t *keys = NULL; + cfg_obj_t *voptions = NULL; + cfg_listelt_t *element, *element2; + cfg_obj_t *keylist; + cfg_obj_t *key; + dns_keytable_t *keytable = NULL; + + CHECK(dns_keytable_create(mctx, &keytable)); + + if (vconfig != NULL) + voptions = cfg_tuple_get(vconfig, "options"); + + keys = NULL; + if (voptions != NULL) + (void)cfg_map_get(voptions, "trusted-keys", &keys); + if (keys == NULL) + (void)cfg_map_get(config, "trusted-keys", &keys); + + for (element = cfg_list_first(keys); + element != NULL; + element = cfg_list_next(element)) + { + keylist = cfg_listelt_value(element); + for (element2 = cfg_list_first(keylist); + element2 != NULL; + element2 = cfg_list_next(element2)) + { + key = cfg_listelt_value(element2); + CHECK(configure_view_dnsseckey(vconfig, key, + keytable, mctx)); + } + } + + dns_keytable_detach(target); + *target = keytable; /* Transfer ownership. */ + keytable = NULL; + result = ISC_R_SUCCESS; + + cleanup: + return (result); +} + +static isc_result_t +mustbesecure(cfg_obj_t *mbs, dns_resolver_t *resolver) +{ + cfg_listelt_t *element; + cfg_obj_t *obj; + const char *str; + dns_fixedname_t fixed; + dns_name_t *name; + isc_boolean_t value; + isc_result_t result; + isc_buffer_t b; + + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + for (element = cfg_list_first(mbs); + element != NULL; + element = cfg_list_next(element)) + { + obj = cfg_listelt_value(element); + str = cfg_obj_asstring(cfg_tuple_get(obj, "name")); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + CHECK(dns_name_fromtext(name, &b, dns_rootname, + ISC_FALSE, NULL)); + value = cfg_obj_asboolean(cfg_tuple_get(obj, "value")); + CHECK(dns_resolver_setmustbesecure(resolver, name, value)); + } + + result = ISC_R_SUCCESS; + + cleanup: + return (result); +} + +/* + * Get a dispatch appropriate for the resolver of a given view. + */ +static isc_result_t +get_view_querysource_dispatch(cfg_obj_t **maps, + int af, dns_dispatch_t **dispatchp) +{ + isc_result_t result; + dns_dispatch_t *disp; + isc_sockaddr_t sa; + unsigned int attrs, attrmask; + cfg_obj_t *obj = NULL; + + /* + * Make compiler happy. + */ + result = ISC_R_FAILURE; + + switch (af) { + case AF_INET: + result = ns_config_get(maps, "query-source", &obj); + INSIST(result == ISC_R_SUCCESS); + + break; + case AF_INET6: + result = ns_config_get(maps, "query-source-v6", &obj); + INSIST(result == ISC_R_SUCCESS); + break; + default: + INSIST(0); + } + + sa = *(cfg_obj_assockaddr(obj)); + INSIST(isc_sockaddr_pf(&sa) == af); + + /* + * If we don't support this address family, we're done! + */ + switch (af) { + case AF_INET: + result = isc_net_probeipv4(); + break; + case AF_INET6: + result = isc_net_probeipv6(); + break; + default: + INSIST(0); + } + if (result != ISC_R_SUCCESS) + return (ISC_R_SUCCESS); + + /* + * Try to find a dispatcher that we can share. + */ + attrs = 0; + attrs |= DNS_DISPATCHATTR_UDP; + switch (af) { + case AF_INET: + attrs |= DNS_DISPATCHATTR_IPV4; + break; + case AF_INET6: + attrs |= DNS_DISPATCHATTR_IPV6; + break; + } + attrmask = 0; + attrmask |= DNS_DISPATCHATTR_UDP; + attrmask |= DNS_DISPATCHATTR_TCP; + attrmask |= DNS_DISPATCHATTR_IPV4; + attrmask |= DNS_DISPATCHATTR_IPV6; + + disp = NULL; + result = dns_dispatch_getudp(ns_g_dispatchmgr, ns_g_socketmgr, + ns_g_taskmgr, &sa, 4096, + 1000, 32768, 16411, 16433, + attrs, attrmask, &disp); + if (result != ISC_R_SUCCESS) { + isc_sockaddr_t any; + char buf[ISC_SOCKADDR_FORMATSIZE]; + + switch (af) { + case AF_INET: + isc_sockaddr_any(&any); + break; + case AF_INET6: + isc_sockaddr_any6(&any); + break; + } + if (isc_sockaddr_equal(&sa, &any)) + return (ISC_R_SUCCESS); + isc_sockaddr_format(&sa, buf, sizeof(buf)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "could not get query source dispatcher (%s)", + buf); + return (result); + } + + *dispatchp = disp; + + return (ISC_R_SUCCESS); +} + +static isc_result_t +configure_order(dns_order_t *order, cfg_obj_t *ent) { + dns_rdataclass_t rdclass; + dns_rdatatype_t rdtype; + cfg_obj_t *obj; + dns_fixedname_t fixed; + unsigned int mode = 0; + const char *str; + isc_buffer_t b; + isc_result_t result; + + result = ns_config_getclass(cfg_tuple_get(ent, "class"), + dns_rdataclass_any, &rdclass); + if (result != ISC_R_SUCCESS) + return (result); + + result = ns_config_gettype(cfg_tuple_get(ent, "type"), + dns_rdatatype_any, &rdtype); + if (result != ISC_R_SUCCESS) + return (result); + + obj = cfg_tuple_get(ent, "name"); + if (cfg_obj_isstring(obj)) + str = cfg_obj_asstring(obj); + else + str = "*"; + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + dns_fixedname_init(&fixed); + result = dns_name_fromtext(dns_fixedname_name(&fixed), &b, + dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) + return (result); + + obj = cfg_tuple_get(ent, "ordering"); + INSIST(cfg_obj_isstring(obj)); + str = cfg_obj_asstring(obj); + if (!strcasecmp(str, "fixed")) + mode = DNS_RDATASETATTR_FIXEDORDER; + else if (!strcasecmp(str, "random")) + mode = DNS_RDATASETATTR_RANDOMIZE; + else if (!strcasecmp(str, "cyclic")) + mode = 0; + else + INSIST(0); + + return (dns_order_add(order, dns_fixedname_name(&fixed), + rdtype, rdclass, mode)); +} + +static isc_result_t +configure_peer(cfg_obj_t *cpeer, isc_mem_t *mctx, dns_peer_t **peerp) { + isc_sockaddr_t *sa; + isc_netaddr_t na; + dns_peer_t *peer; + cfg_obj_t *obj; + char *str; + isc_result_t result; + + sa = cfg_obj_assockaddr(cfg_map_getname(cpeer)); + isc_netaddr_fromsockaddr(&na, sa); + + peer = NULL; + result = dns_peer_new(mctx, &na, &peer); + if (result != ISC_R_SUCCESS) + return (result); + + obj = NULL; + (void)cfg_map_get(cpeer, "bogus", &obj); + if (obj != NULL) + CHECK(dns_peer_setbogus(peer, cfg_obj_asboolean(obj))); + + obj = NULL; + (void)cfg_map_get(cpeer, "provide-ixfr", &obj); + if (obj != NULL) + CHECK(dns_peer_setprovideixfr(peer, cfg_obj_asboolean(obj))); + + obj = NULL; + (void)cfg_map_get(cpeer, "request-ixfr", &obj); + if (obj != NULL) + CHECK(dns_peer_setrequestixfr(peer, cfg_obj_asboolean(obj))); + + obj = NULL; + (void)cfg_map_get(cpeer, "edns", &obj); + if (obj != NULL) + CHECK(dns_peer_setsupportedns(peer, cfg_obj_asboolean(obj))); + + obj = NULL; + (void)cfg_map_get(cpeer, "transfers", &obj); + if (obj != NULL) + CHECK(dns_peer_settransfers(peer, cfg_obj_asuint32(obj))); + + obj = NULL; + (void)cfg_map_get(cpeer, "transfer-format", &obj); + if (obj != NULL) { + str = cfg_obj_asstring(obj); + if (strcasecmp(str, "many-answers") == 0) + CHECK(dns_peer_settransferformat(peer, + dns_many_answers)); + else if (strcasecmp(str, "one-answer") == 0) + CHECK(dns_peer_settransferformat(peer, + dns_one_answer)); + else + INSIST(0); + } + + obj = NULL; + (void)cfg_map_get(cpeer, "keys", &obj); + if (obj != NULL) { + result = dns_peer_setkeybycharp(peer, cfg_obj_asstring(obj)); + if (result != ISC_R_SUCCESS) + goto cleanup; + } + + obj = NULL; + if (isc_sockaddr_pf(sa) == AF_INET) + (void)cfg_map_get(cpeer, "transfer-source", &obj); + else + (void)cfg_map_get(cpeer, "transfer-source-v6", &obj); + if (obj != NULL) { + result = dns_peer_settransfersource(peer, + cfg_obj_assockaddr(obj)); + if (result != ISC_R_SUCCESS) + goto cleanup; + } + *peerp = peer; + return (ISC_R_SUCCESS); + + cleanup: + dns_peer_detach(&peer); + return (result); +} + +static isc_result_t +disable_algorithms(cfg_obj_t *disabled, dns_resolver_t *resolver) { + isc_result_t result; + cfg_obj_t *algorithms; + cfg_listelt_t *element; + const char *str; + dns_fixedname_t fixed; + dns_name_t *name; + isc_buffer_t b; + + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + str = cfg_obj_asstring(cfg_tuple_get(disabled, "name")); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + CHECK(dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, NULL)); + + algorithms = cfg_tuple_get(disabled, "algorithms"); + for (element = cfg_list_first(algorithms); + element != NULL; + element = cfg_list_next(element)) + { + isc_textregion_t r; + dns_secalg_t alg; + + r.base = cfg_obj_asstring(cfg_listelt_value(element)); + r.length = strlen(r.base); + + result = dns_secalg_fromtext(&alg, &r); + if (result != ISC_R_SUCCESS) { + isc_uint8_t ui; + result = isc_parse_uint8(&ui, r.base, 10); + alg = ui; + } + if (result != ISC_R_SUCCESS) { + cfg_obj_log(cfg_listelt_value(element), + ns_g_lctx, ISC_LOG_ERROR, + "invalid algorithm"); + CHECK(result); + } + CHECK(dns_resolver_disable_algorithm(resolver, name, alg)); + } + cleanup: + return (result); +} + +/* + * Configure 'view' according to 'vconfig', taking defaults from 'config' + * where values are missing in 'vconfig'. + * + * When configuring the default view, 'vconfig' will be NULL and the + * global defaults in 'config' used exclusively. + */ +static isc_result_t +configure_view(dns_view_t *view, cfg_obj_t *config, cfg_obj_t *vconfig, + isc_mem_t *mctx, ns_aclconfctx_t *actx, + isc_boolean_t need_hints) +{ + cfg_obj_t *maps[4]; + cfg_obj_t *cfgmaps[3]; + cfg_obj_t *options = NULL; + cfg_obj_t *voptions = NULL; + cfg_obj_t *forwardtype; + cfg_obj_t *forwarders; + cfg_obj_t *alternates; + cfg_obj_t *zonelist; + cfg_obj_t *disabled; + cfg_obj_t *obj; + cfg_listelt_t *element; + in_port_t port; + dns_cache_t *cache = NULL; + isc_result_t result; + isc_uint32_t max_adb_size; + isc_uint32_t max_cache_size; + isc_uint32_t lame_ttl; + dns_tsig_keyring_t *ring; + dns_view_t *pview = NULL; /* Production view */ + isc_mem_t *cmctx; + dns_dispatch_t *dispatch4 = NULL; + dns_dispatch_t *dispatch6 = NULL; + isc_boolean_t reused_cache = ISC_FALSE; + int i; + const char *str; + dns_order_t *order = NULL; + isc_uint32_t udpsize; + unsigned int check = 0; + + REQUIRE(DNS_VIEW_VALID(view)); + + cmctx = NULL; + + if (config != NULL) + (void)cfg_map_get(config, "options", &options); + + i = 0; + if (vconfig != NULL) { + voptions = cfg_tuple_get(vconfig, "options"); + maps[i++] = voptions; + } + if (options != NULL) + maps[i++] = options; + maps[i++] = ns_g_defaults; + maps[i] = NULL; + + i = 0; + if (voptions != NULL) + cfgmaps[i++] = voptions; + if (config != NULL) + cfgmaps[i++] = config; + cfgmaps[i] = NULL; + + /* + * Set the view's port number for outgoing queries. + */ + CHECKM(ns_config_getport(config, &port), "port"); + dns_view_setdstport(view, port); + + /* + * Configure the zones. + */ + zonelist = NULL; + if (voptions != NULL) + (void)cfg_map_get(voptions, "zone", &zonelist); + else + (void)cfg_map_get(config, "zone", &zonelist); + for (element = cfg_list_first(zonelist); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *zconfig = cfg_listelt_value(element); + CHECK(configure_zone(config, zconfig, vconfig, mctx, view, + actx)); + } + + /* + * Configure the view's cache. Try to reuse an existing + * cache if possible, otherwise create a new cache. + * Note that the ADB is not preserved in either case. + * + * XXX Determining when it is safe to reuse a cache is + * tricky. When the view's configuration changes, the cached + * data may become invalid because it reflects our old + * view of the world. As more view attributes become + * configurable, we will have to add code here to check + * whether they have changed in ways that could + * invalidate the cache. + */ + result = dns_viewlist_find(&ns_g_server->viewlist, + view->name, view->rdclass, + &pview); + if (result != ISC_R_NOTFOUND && result != ISC_R_SUCCESS) + goto cleanup; + if (pview != NULL) { + INSIST(pview->cache != NULL); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_DEBUG(3), + "reusing existing cache"); + reused_cache = ISC_TRUE; + dns_cache_attach(pview->cache, &cache); + dns_view_detach(&pview); + } else { + CHECK(isc_mem_create(0, 0, &cmctx)); + CHECK(dns_cache_create(cmctx, ns_g_taskmgr, ns_g_timermgr, + view->rdclass, "rbt", 0, NULL, &cache)); + } + dns_view_setcache(view, cache); + + /* + * cache-file cannot be inherited if views are present, but this + * should be caught by the configuration checking stage. + */ + obj = NULL; + result = ns_config_get(maps, "cache-file", &obj); + if (result == ISC_R_SUCCESS && strcmp(view->name, "_bind") != 0) { + CHECK(dns_cache_setfilename(cache, cfg_obj_asstring(obj))); + if (!reused_cache) + CHECK(dns_cache_load(cache)); + } + + obj = NULL; + result = ns_config_get(maps, "cleaning-interval", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_cache_setcleaninginterval(cache, cfg_obj_asuint32(obj) * 60); + + obj = NULL; + result = ns_config_get(maps, "max-cache-size", &obj); + INSIST(result == ISC_R_SUCCESS); + if (cfg_obj_isstring(obj)) { + str = cfg_obj_asstring(obj); + INSIST(strcasecmp(str, "unlimited") == 0); + max_cache_size = ISC_UINT32_MAX; + } else { + isc_resourcevalue_t value; + value = cfg_obj_asuint64(obj); + if (value > ISC_UINT32_MAX) { + cfg_obj_log(obj, ns_g_lctx, ISC_LOG_ERROR, + "'max-cache-size " + "%" ISC_PRINT_QUADFORMAT "d' is too large", + value); + result = ISC_R_RANGE; + goto cleanup; + } + max_cache_size = (isc_uint32_t)value; + } + dns_cache_setcachesize(cache, max_cache_size); + + dns_cache_detach(&cache); + + /* + * Check-names. + */ + obj = NULL; + result = ns_checknames_get(maps, "response", &obj); + INSIST(result == ISC_R_SUCCESS); + + str = cfg_obj_asstring(obj); + if (strcasecmp(str, "fail") == 0) { + check = DNS_RESOLVER_CHECKNAMES | + DNS_RESOLVER_CHECKNAMESFAIL; + view->checknames = ISC_TRUE; + } else if (strcasecmp(str, "warn") == 0) { + check = DNS_RESOLVER_CHECKNAMES; + view->checknames = ISC_FALSE; + } else if (strcasecmp(str, "ignore") == 0) { + check = 0; + view->checknames = ISC_FALSE; + } else + INSIST(0); + + /* + * Resolver. + * + * XXXRTH Hardwired number of tasks. + */ + CHECK(get_view_querysource_dispatch(maps, AF_INET, &dispatch4)); + CHECK(get_view_querysource_dispatch(maps, AF_INET6, &dispatch6)); + if (dispatch4 == NULL && dispatch6 == NULL) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "unable to obtain neither an IPv4 nor" + " an IPv6 dispatch"); + result = ISC_R_UNEXPECTED; + goto cleanup; + } + CHECK(dns_view_createresolver(view, ns_g_taskmgr, 31, + ns_g_socketmgr, ns_g_timermgr, + check, ns_g_dispatchmgr, + dispatch4, dispatch6)); + + /* + * Set the ADB cache size to 1/8th of the max-cache-size. + */ + max_adb_size = 0; + if (max_cache_size != 0) { + max_adb_size = max_cache_size / 8; + if (max_adb_size == 0) + max_adb_size = 1; /* Force minimum. */ + } + dns_adb_setadbsize(view->adb, max_adb_size); + + /* + * Set resolver's lame-ttl. + */ + obj = NULL; + result = ns_config_get(maps, "lame-ttl", &obj); + INSIST(result == ISC_R_SUCCESS); + lame_ttl = cfg_obj_asuint32(obj); + if (lame_ttl > 1800) + lame_ttl = 1800; + dns_resolver_setlamettl(view->resolver, lame_ttl); + + /* + * Set the resolver's EDNS UDP size. + */ + obj = NULL; + result = ns_config_get(maps, "edns-udp-size", &obj); + INSIST(result == ISC_R_SUCCESS); + udpsize = cfg_obj_asuint32(obj); + if (udpsize < 512) + udpsize = 512; + if (udpsize > 4096) + udpsize = 4096; + dns_resolver_setudpsize(view->resolver, (isc_uint16_t)udpsize); + + /* + * Set supported DNSSEC algorithms. + */ + dns_resolver_reset_algorithms(view->resolver); + disabled = NULL; + (void)ns_config_get(maps, "disable-algorithms", &disabled); + if (disabled != NULL) { + for (element = cfg_list_first(disabled); + element != NULL; + element = cfg_list_next(element)) + CHECK(disable_algorithms(cfg_listelt_value(element), + view->resolver)); + } + + /* + * A global or view "forwarders" option, if present, + * creates an entry for "." in the forwarding table. + */ + forwardtype = NULL; + forwarders = NULL; + (void)ns_config_get(maps, "forward", &forwardtype); + (void)ns_config_get(maps, "forwarders", &forwarders); + if (forwarders != NULL) + CHECK(configure_forward(config, view, dns_rootname, + forwarders, forwardtype)); + + /* + * Dual Stack Servers. + */ + alternates = NULL; + (void)ns_config_get(maps, "dual-stack-servers", &alternates); + if (alternates != NULL) + CHECK(configure_alternates(config, view, alternates)); + + /* + * We have default hints for class IN if we need them. + */ + if (view->rdclass == dns_rdataclass_in && view->hints == NULL) + dns_view_sethints(view, ns_g_server->in_roothints); + + /* + * If we still have no hints, this is a non-IN view with no + * "hints zone" configured. Issue a warning, except if this + * is a root server. Root servers never need to consult + * their hints, so it's no point requiring users to configure + * them. + */ + if (view->hints == NULL) { + dns_zone_t *rootzone = NULL; + (void)dns_view_findzone(view, dns_rootname, &rootzone); + if (rootzone != NULL) { + dns_zone_detach(&rootzone); + need_hints = ISC_FALSE; + } + if (need_hints) + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_WARNING, + "no root hints for view '%s'", + view->name); + } + + /* + * Configure the view's TSIG keys. + */ + ring = NULL; + CHECK(ns_tsigkeyring_fromconfig(config, vconfig, view->mctx, &ring)); + dns_view_setkeyring(view, ring); + + /* + * Configure the view's peer list. + */ + { + cfg_obj_t *peers = NULL; + cfg_listelt_t *element; + dns_peerlist_t *newpeers = NULL; + + (void)ns_config_get(cfgmaps, "server", &peers); + CHECK(dns_peerlist_new(mctx, &newpeers)); + for (element = cfg_list_first(peers); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *cpeer = cfg_listelt_value(element); + dns_peer_t *peer; + + CHECK(configure_peer(cpeer, mctx, &peer)); + dns_peerlist_addpeer(newpeers, peer); + dns_peer_detach(&peer); + } + dns_peerlist_detach(&view->peers); + view->peers = newpeers; /* Transfer ownership. */ + } + + /* + * Configure the views rrset-order. + */ + { + cfg_obj_t *rrsetorder = NULL; + cfg_listelt_t *element; + + (void)ns_config_get(maps, "rrset-order", &rrsetorder); + CHECK(dns_order_create(mctx, &order)); + for (element = cfg_list_first(rrsetorder); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *ent = cfg_listelt_value(element); + + CHECK(configure_order(order, ent)); + } + if (view->order != NULL) + dns_order_detach(&view->order); + dns_order_attach(order, &view->order); + dns_order_detach(&order); + } + /* + * Copy the aclenv object. + */ + dns_aclenv_copy(&view->aclenv, &ns_g_server->aclenv); + + /* + * Configure the "match-clients" and "match-destinations" ACL. + */ + CHECK(configure_view_acl(vconfig, config, "match-clients", actx, + ns_g_mctx, &view->matchclients)); + CHECK(configure_view_acl(vconfig, config, "match-destinations", actx, + ns_g_mctx, &view->matchdestinations)); + + /* + * Configure the "match-recursive-only" option. + */ + obj = NULL; + (void) ns_config_get(maps, "match-recursive-only", &obj); + if (obj != NULL && cfg_obj_asboolean(obj)) + view->matchrecursiveonly = ISC_TRUE; + else + view->matchrecursiveonly = ISC_FALSE; + + /* + * Configure other configurable data. + */ + obj = NULL; + result = ns_config_get(maps, "recursion", &obj); + INSIST(result == ISC_R_SUCCESS); + view->recursion = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "auth-nxdomain", &obj); + INSIST(result == ISC_R_SUCCESS); + view->auth_nxdomain = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "minimal-responses", &obj); + INSIST(result == ISC_R_SUCCESS); + view->minimalresponses = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "transfer-format", &obj); + INSIST(result == ISC_R_SUCCESS); + str = cfg_obj_asstring(obj); + if (strcasecmp(str, "many-answers") == 0) + view->transfer_format = dns_many_answers; + else if (strcasecmp(str, "one-answer") == 0) + view->transfer_format = dns_one_answer; + else + INSIST(0); + + /* + * Set sources where additional data and CNAME/DNAME + * targets for authoritative answers may be found. + */ + obj = NULL; + result = ns_config_get(maps, "additional-from-auth", &obj); + INSIST(result == ISC_R_SUCCESS); + view->additionalfromauth = cfg_obj_asboolean(obj); + if (view->recursion && ! view->additionalfromauth) { + cfg_obj_log(obj, ns_g_lctx, ISC_LOG_WARNING, + "'additional-from-auth no' is only supported " + "with 'recursion no'"); + view->additionalfromauth = ISC_TRUE; + } + + obj = NULL; + result = ns_config_get(maps, "additional-from-cache", &obj); + INSIST(result == ISC_R_SUCCESS); + view->additionalfromcache = cfg_obj_asboolean(obj); + if (view->recursion && ! view->additionalfromcache) { + cfg_obj_log(obj, ns_g_lctx, ISC_LOG_WARNING, + "'additional-from-cache no' is only supported " + "with 'recursion no'"); + view->additionalfromcache = ISC_TRUE; + } + + CHECK(configure_view_acl(vconfig, config, "allow-query", + actx, ns_g_mctx, &view->queryacl)); + + if (strcmp(view->name, "_bind") != 0) + CHECK(configure_view_acl(vconfig, config, "allow-recursion", + actx, ns_g_mctx, &view->recursionacl)); + + /* + * Warning if both "recursion no;" and allow-recursion are active + * except for "allow-recursion { none; };". + */ + if (!view->recursion && view->recursionacl != NULL && + (view->recursionacl->length != 1 || + view->recursionacl->elements[0].type != dns_aclelementtype_any || + view->recursionacl->elements[0].negative != ISC_TRUE)) { + const char *forview = " for view "; + const char *viewname = view->name; + + if (!strcmp(view->name, "_bind") || + !strcmp(view->name, "_default")) { + forview = ""; + viewname = ""; + } + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_WARNING, + "both \"recursion no;\" and \"allow-recursion\" " + "active%s%s", forview, viewname); + } + + CHECK(configure_view_acl(vconfig, config, "sortlist", + actx, ns_g_mctx, &view->sortlist)); + + obj = NULL; + result = ns_config_get(maps, "request-ixfr", &obj); + INSIST(result == ISC_R_SUCCESS); + view->requestixfr = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "provide-ixfr", &obj); + INSIST(result == ISC_R_SUCCESS); + view->provideixfr = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "dnssec-enable", &obj); + INSIST(result == ISC_R_SUCCESS); + view->enablednssec = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "dnssec-lookaside", &obj); + if (result == ISC_R_SUCCESS) { + for (element = cfg_list_first(obj); + element != NULL; + element = cfg_list_next(element)) + { + const char *str; + isc_buffer_t b; + dns_name_t *dlv; + + obj = cfg_listelt_value(element); +#if 0 + dns_fixedname_t fixed; + dns_name_t *name; + + /* + * When we support multiple dnssec-lookaside + * entries this is how to find the domain to be + * checked. XXXMPA + */ + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + str = cfg_obj_asstring(cfg_tuple_get(obj, + "domain")); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + CHECK(dns_name_fromtext(name, &b, dns_rootname, + ISC_TRUE, NULL)); +#endif + str = cfg_obj_asstring(cfg_tuple_get(obj, + "trust-anchor")); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + dlv = dns_fixedname_name(&view->dlv_fixed); + CHECK(dns_name_fromtext(dlv, &b, dns_rootname, + ISC_TRUE, NULL)); + view->dlv = dns_fixedname_name(&view->dlv_fixed); + } + } else + view->dlv = NULL; + + /* + * For now, there is only one kind of trusted keys, the + * "security roots". + */ + if (view->enablednssec) { + CHECK(configure_view_dnsseckeys(vconfig, config, mctx, + &view->secroots)); + dns_resolver_resetmustbesecure(view->resolver); + obj = NULL; + result = ns_config_get(maps, "dnssec-must-be-secure", &obj); + if (result == ISC_R_SUCCESS) + CHECK(mustbesecure(obj, view->resolver)); + } + + obj = NULL; + result = ns_config_get(maps, "max-cache-ttl", &obj); + INSIST(result == ISC_R_SUCCESS); + view->maxcachettl = cfg_obj_asuint32(obj); + + obj = NULL; + result = ns_config_get(maps, "max-ncache-ttl", &obj); + INSIST(result == ISC_R_SUCCESS); + view->maxncachettl = cfg_obj_asuint32(obj); + if (view->maxncachettl > 7 * 24 * 3600) + view->maxncachettl = 7 * 24 * 3600; + + obj = NULL; + result = ns_config_get(maps, "preferred-glue", &obj); + if (result == ISC_R_SUCCESS) { + str = cfg_obj_asstring(obj); + if (strcasecmp(str, "a") == 0) + view->preferred_glue = dns_rdatatype_a; + else if (strcasecmp(str, "aaaa") == 0) + view->preferred_glue = dns_rdatatype_aaaa; + else + view->preferred_glue = 0; + } else + view->preferred_glue = 0; + + obj = NULL; + result = ns_config_get(maps, "root-delegation-only", &obj); + if (result == ISC_R_SUCCESS) { + dns_view_setrootdelonly(view, ISC_TRUE); + if (!cfg_obj_isvoid(obj)) { + dns_fixedname_t fixed; + dns_name_t *name; + isc_buffer_t b; + char *str; + cfg_obj_t *exclude; + + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + for (element = cfg_list_first(obj); + element != NULL; + element = cfg_list_next(element)) { + exclude = cfg_listelt_value(element); + str = cfg_obj_asstring(exclude); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + CHECK(dns_name_fromtext(name, &b, dns_rootname, + ISC_FALSE, NULL)); + CHECK(dns_view_excludedelegationonly(view, + name)); + } + } + } else + dns_view_setrootdelonly(view, ISC_FALSE); + + result = ISC_R_SUCCESS; + + cleanup: + if (dispatch4 != NULL) + dns_dispatch_detach(&dispatch4); + if (dispatch6 != NULL) + dns_dispatch_detach(&dispatch6); + if (order != NULL) + dns_order_detach(&order); + if (cmctx != NULL) + isc_mem_detach(&cmctx); + + if (cache != NULL) + dns_cache_detach(&cache); + + return (result); +} + +static isc_result_t +configure_hints(dns_view_t *view, const char *filename) { + isc_result_t result; + dns_db_t *db; + + db = NULL; + result = dns_rootns_create(view->mctx, view->rdclass, filename, &db); + if (result == ISC_R_SUCCESS) { + dns_view_sethints(view, db); + dns_db_detach(&db); + } + + return (result); +} + +static isc_result_t +configure_alternates(cfg_obj_t *config, dns_view_t *view, + cfg_obj_t *alternates) +{ + cfg_obj_t *portobj; + cfg_obj_t *addresses; + cfg_listelt_t *element; + isc_result_t result = ISC_R_SUCCESS; + in_port_t port; + + /* + * Determine which port to send requests to. + */ + if (ns_g_lwresdonly && ns_g_port != 0) + port = ns_g_port; + else + CHECKM(ns_config_getport(config, &port), "port"); + + if (alternates != NULL) { + portobj = cfg_tuple_get(alternates, "port"); + if (cfg_obj_isuint32(portobj)) { + isc_uint32_t val = cfg_obj_asuint32(portobj); + if (val > ISC_UINT16_MAX) { + cfg_obj_log(portobj, ns_g_lctx, ISC_LOG_ERROR, + "port '%u' out of range", val); + return (ISC_R_RANGE); + } + port = (in_port_t) val; + } + } + + addresses = NULL; + if (alternates != NULL) + addresses = cfg_tuple_get(alternates, "addresses"); + + for (element = cfg_list_first(addresses); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *alternate = cfg_listelt_value(element); + isc_sockaddr_t sa; + + if (!cfg_obj_issockaddr(alternate)) { + dns_fixedname_t fixed; + dns_name_t *name; + char *str = cfg_obj_asstring(cfg_tuple_get(alternate, + "name")); + isc_buffer_t buffer; + in_port_t myport = port; + + isc_buffer_init(&buffer, str, strlen(str)); + isc_buffer_add(&buffer, strlen(str)); + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + CHECK(dns_name_fromtext(name, &buffer, dns_rootname, + ISC_FALSE, NULL)); + + portobj = cfg_tuple_get(alternate, "port"); + if (cfg_obj_isuint32(portobj)) { + isc_uint32_t val = cfg_obj_asuint32(portobj); + if (val > ISC_UINT16_MAX) { + cfg_obj_log(portobj, ns_g_lctx, + ISC_LOG_ERROR, + "port '%u' out of range", + val); + return (ISC_R_RANGE); + } + myport = (in_port_t) val; + } + CHECK(dns_resolver_addalternate(view->resolver, NULL, + name, myport)); + continue; + } + + sa = *cfg_obj_assockaddr(alternate); + if (isc_sockaddr_getport(&sa) == 0) + isc_sockaddr_setport(&sa, port); + CHECK(dns_resolver_addalternate(view->resolver, &sa, + NULL, 0)); + } + + cleanup: + return (result); +} + +static isc_result_t +configure_forward(cfg_obj_t *config, dns_view_t *view, dns_name_t *origin, + cfg_obj_t *forwarders, cfg_obj_t *forwardtype) +{ + cfg_obj_t *portobj; + cfg_obj_t *faddresses; + cfg_listelt_t *element; + dns_fwdpolicy_t fwdpolicy = dns_fwdpolicy_none; + isc_sockaddrlist_t addresses; + isc_sockaddr_t *sa; + isc_result_t result; + in_port_t port; + + /* + * Determine which port to send forwarded requests to. + */ + if (ns_g_lwresdonly && ns_g_port != 0) + port = ns_g_port; + else + CHECKM(ns_config_getport(config, &port), "port"); + + if (forwarders != NULL) { + portobj = cfg_tuple_get(forwarders, "port"); + if (cfg_obj_isuint32(portobj)) { + isc_uint32_t val = cfg_obj_asuint32(portobj); + if (val > ISC_UINT16_MAX) { + cfg_obj_log(portobj, ns_g_lctx, ISC_LOG_ERROR, + "port '%u' out of range", val); + return (ISC_R_RANGE); + } + port = (in_port_t) val; + } + } + + faddresses = NULL; + if (forwarders != NULL) + faddresses = cfg_tuple_get(forwarders, "addresses"); + + ISC_LIST_INIT(addresses); + + for (element = cfg_list_first(faddresses); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *forwarder = cfg_listelt_value(element); + sa = isc_mem_get(view->mctx, sizeof(isc_sockaddr_t)); + if (sa == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup; + } + *sa = *cfg_obj_assockaddr(forwarder); + if (isc_sockaddr_getport(sa) == 0) + isc_sockaddr_setport(sa, port); + ISC_LINK_INIT(sa, link); + ISC_LIST_APPEND(addresses, sa, link); + } + + if (ISC_LIST_EMPTY(addresses)) { + if (forwardtype != NULL) + cfg_obj_log(forwarders, ns_g_lctx, ISC_LOG_WARNING, + "no forwarders seen; disabling " + "forwarding"); + fwdpolicy = dns_fwdpolicy_none; + } else { + if (forwardtype == NULL) + fwdpolicy = dns_fwdpolicy_first; + else { + char *forwardstr = cfg_obj_asstring(forwardtype); + if (strcasecmp(forwardstr, "first") == 0) + fwdpolicy = dns_fwdpolicy_first; + else if (strcasecmp(forwardstr, "only") == 0) + fwdpolicy = dns_fwdpolicy_only; + else + INSIST(0); + } + } + + result = dns_fwdtable_add(view->fwdtable, origin, &addresses, + fwdpolicy); + if (result != ISC_R_SUCCESS) { + char namebuf[DNS_NAME_FORMATSIZE]; + dns_name_format(origin, namebuf, sizeof(namebuf)); + cfg_obj_log(forwarders, ns_g_lctx, ISC_LOG_WARNING, + "could not set up forwarding for domain '%s': %s", + namebuf, isc_result_totext(result)); + goto cleanup; + } + + result = ISC_R_SUCCESS; + + cleanup: + + while (!ISC_LIST_EMPTY(addresses)) { + sa = ISC_LIST_HEAD(addresses); + ISC_LIST_UNLINK(addresses, sa, link); + isc_mem_put(view->mctx, sa, sizeof(isc_sockaddr_t)); + } + + return (result); +} + +/* + * Create a new view and add it to the list. + * + * If 'vconfig' is NULL, create the default view. + * + * The view created is attached to '*viewp'. + */ +static isc_result_t +create_view(cfg_obj_t *vconfig, dns_viewlist_t *viewlist, dns_view_t **viewp) { + isc_result_t result; + const char *viewname; + dns_rdataclass_t viewclass; + dns_view_t *view = NULL; + + if (vconfig != NULL) { + cfg_obj_t *classobj = NULL; + + viewname = cfg_obj_asstring(cfg_tuple_get(vconfig, "name")); + classobj = cfg_tuple_get(vconfig, "class"); + result = ns_config_getclass(classobj, dns_rdataclass_in, + &viewclass); + } else { + viewname = "_default"; + viewclass = dns_rdataclass_in; + } + result = dns_viewlist_find(viewlist, viewname, viewclass, &view); + if (result == ISC_R_SUCCESS) + return (ISC_R_EXISTS); + if (result != ISC_R_NOTFOUND) + return (result); + INSIST(view == NULL); + + result = dns_view_create(ns_g_mctx, viewclass, viewname, &view); + if (result != ISC_R_SUCCESS) + return (result); + + ISC_LIST_APPEND(*viewlist, view, link); + dns_view_attach(view, viewp); + return (ISC_R_SUCCESS); +} + +/* + * Configure or reconfigure a zone. + */ +static isc_result_t +configure_zone(cfg_obj_t *config, cfg_obj_t *zconfig, cfg_obj_t *vconfig, + isc_mem_t *mctx, dns_view_t *view, + ns_aclconfctx_t *aclconf) +{ + dns_view_t *pview = NULL; /* Production view */ + dns_zone_t *zone = NULL; /* New or reused zone */ + dns_zone_t *dupzone = NULL; + cfg_obj_t *options = NULL; + cfg_obj_t *zoptions = NULL; + cfg_obj_t *typeobj = NULL; + cfg_obj_t *forwarders = NULL; + cfg_obj_t *forwardtype = NULL; + cfg_obj_t *only = NULL; + isc_result_t result; + isc_result_t tresult; + isc_buffer_t buffer; + dns_fixedname_t fixorigin; + dns_name_t *origin; + const char *zname; + dns_rdataclass_t zclass; + const char *ztypestr; + + options = NULL; + (void)cfg_map_get(config, "options", &options); + + zoptions = cfg_tuple_get(zconfig, "options"); + + /* + * Get the zone origin as a dns_name_t. + */ + zname = cfg_obj_asstring(cfg_tuple_get(zconfig, "name")); + isc_buffer_init(&buffer, zname, strlen(zname)); + isc_buffer_add(&buffer, strlen(zname)); + dns_fixedname_init(&fixorigin); + CHECK(dns_name_fromtext(dns_fixedname_name(&fixorigin), + &buffer, dns_rootname, ISC_FALSE, NULL)); + origin = dns_fixedname_name(&fixorigin); + + CHECK(ns_config_getclass(cfg_tuple_get(zconfig, "class"), + view->rdclass, &zclass)); + if (zclass != view->rdclass) { + const char *vname = NULL; + if (vconfig != NULL) + vname = cfg_obj_asstring(cfg_tuple_get(vconfig, + "name")); + else + vname = ""; + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "zone '%s': wrong class for view '%s'", + zname, vname); + result = ISC_R_FAILURE; + goto cleanup; + } + + (void)cfg_map_get(zoptions, "type", &typeobj); + if (typeobj == NULL) { + cfg_obj_log(zconfig, ns_g_lctx, ISC_LOG_ERROR, + "zone '%s' 'type' not specified", zname); + return (ISC_R_FAILURE); + } + ztypestr = cfg_obj_asstring(typeobj); + + /* + * "hints zones" aren't zones. If we've got one, + * configure it and return. + */ + if (strcasecmp(ztypestr, "hint") == 0) { + cfg_obj_t *fileobj = NULL; + if (cfg_map_get(zoptions, "file", &fileobj) != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "zone '%s': 'file' not specified", + zname); + result = ISC_R_FAILURE; + goto cleanup; + } + if (dns_name_equal(origin, dns_rootname)) { + char *hintsfile = cfg_obj_asstring(fileobj); + + result = configure_hints(view, hintsfile); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, + ISC_LOG_ERROR, + "could not configure root hints " + "from '%s': %s", hintsfile, + isc_result_totext(result)); + goto cleanup; + } + /* + * Hint zones may also refer to delegation only points. + */ + only = NULL; + tresult = cfg_map_get(zoptions, "delegation-only", + &only); + if (tresult == ISC_R_SUCCESS && cfg_obj_asboolean(only)) + CHECK(dns_view_adddelegationonly(view, origin)); + } else { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_WARNING, + "ignoring non-root hint zone '%s'", + zname); + result = ISC_R_SUCCESS; + } + /* Skip ordinary zone processing. */ + goto cleanup; + } + + /* + * "forward zones" aren't zones either. Translate this syntax into + * the appropriate selective forwarding configuration and return. + */ + if (strcasecmp(ztypestr, "forward") == 0) { + forwardtype = NULL; + forwarders = NULL; + + (void)cfg_map_get(zoptions, "forward", &forwardtype); + (void)cfg_map_get(zoptions, "forwarders", &forwarders); + result = configure_forward(config, view, origin, forwarders, + forwardtype); + goto cleanup; + } + + /* + * "delegation-only zones" aren't zones either. + */ + if (strcasecmp(ztypestr, "delegation-only") == 0) { + result = dns_view_adddelegationonly(view, origin); + goto cleanup; + } + + /* + * Check for duplicates in the new zone table. + */ + result = dns_view_findzone(view, origin, &dupzone); + if (result == ISC_R_SUCCESS) { + /* + * We already have this zone! + */ + cfg_obj_log(zconfig, ns_g_lctx, ISC_LOG_ERROR, + "zone '%s' already exists", zname); + dns_zone_detach(&dupzone); + result = ISC_R_EXISTS; + goto cleanup; + } + INSIST(dupzone == NULL); + + /* + * See if we can reuse an existing zone. This is + * only possible if all of these are true: + * - The zone's view exists + * - A zone with the right name exists in the view + * - The zone is compatible with the config + * options (e.g., an existing master zone cannot + * be reused if the options specify a slave zone) + */ + result = dns_viewlist_find(&ns_g_server->viewlist, + view->name, view->rdclass, + &pview); + if (result != ISC_R_NOTFOUND && result != ISC_R_SUCCESS) + goto cleanup; + if (pview != NULL) + result = dns_view_findzone(pview, origin, &zone); + if (result != ISC_R_NOTFOUND && result != ISC_R_SUCCESS) + goto cleanup; + if (zone != NULL) { + if (! ns_zone_reusable(zone, zconfig)) + dns_zone_detach(&zone); + } + + if (zone != NULL) { + /* + * We found a reusable zone. Make it use the + * new view. + */ + dns_zone_setview(zone, view); + } else { + /* + * We cannot reuse an existing zone, we have + * to create a new one. + */ + CHECK(dns_zone_create(&zone, mctx)); + CHECK(dns_zone_setorigin(zone, origin)); + dns_zone_setview(zone, view); + CHECK(dns_zonemgr_managezone(ns_g_server->zonemgr, zone)); + } + + /* + * If the zone contains a 'forwarders' statement, configure + * selective forwarding. + */ + forwarders = NULL; + if (cfg_map_get(zoptions, "forwarders", &forwarders) == ISC_R_SUCCESS) + { + forwardtype = NULL; + (void)cfg_map_get(zoptions, "forward", &forwardtype); + CHECK(configure_forward(config, view, origin, forwarders, + forwardtype)); + } + + /* + * Stub and forward zones may also refer to delegation only points. + */ + only = NULL; + if (cfg_map_get(zoptions, "delegation-only", &only) == ISC_R_SUCCESS) + { + if (cfg_obj_asboolean(only)) + CHECK(dns_view_adddelegationonly(view, origin)); + } + + /* + * Configure the zone. + */ + CHECK(ns_zone_configure(config, vconfig, zconfig, aclconf, zone)); + + /* + * Add the zone to its view in the new view list. + */ + CHECK(dns_view_addzone(view, zone)); + + cleanup: + if (zone != NULL) + dns_zone_detach(&zone); + if (pview != NULL) + dns_view_detach(&pview); + + return (result); +} + +/* + * Configure a single server quota. + */ +static void +configure_server_quota(cfg_obj_t **maps, const char *name, isc_quota_t *quota) +{ + cfg_obj_t *obj = NULL; + isc_result_t result; + + result = ns_config_get(maps, name, &obj); + INSIST(result == ISC_R_SUCCESS); + quota->max = cfg_obj_asuint32(obj); +} + +/* + * This function is called as soon as the 'directory' statement has been + * parsed. This can be extended to support other options if necessary. + */ +static isc_result_t +directory_callback(const char *clausename, cfg_obj_t *obj, void *arg) { + isc_result_t result; + char *directory; + + REQUIRE(strcasecmp("directory", clausename) == 0); + + UNUSED(arg); + UNUSED(clausename); + + /* + * Change directory. + */ + directory = cfg_obj_asstring(obj); + + if (! isc_file_ischdiridempotent(directory)) + cfg_obj_log(obj, ns_g_lctx, ISC_LOG_WARNING, + "option 'directory' contains relative path '%s'", + directory); + + result = isc_dir_chdir(directory); + if (result != ISC_R_SUCCESS) { + cfg_obj_log(obj, ns_g_lctx, ISC_LOG_ERROR, + "change directory to '%s' failed: %s", + directory, isc_result_totext(result)); + return (result); + } + + return (ISC_R_SUCCESS); +} + +static void +scan_interfaces(ns_server_t *server, isc_boolean_t verbose) { + isc_boolean_t match_mapped = server->aclenv.match_mapped; + + ns_interfacemgr_scan(server->interfacemgr, verbose); + /* + * Update the "localhost" and "localnets" ACLs to match the + * current set of network interfaces. + */ + dns_aclenv_copy(&server->aclenv, + ns_interfacemgr_getaclenv(server->interfacemgr)); + + server->aclenv.match_mapped = match_mapped; +} + +static isc_result_t +add_listenelt(isc_mem_t *mctx, ns_listenlist_t *list, isc_sockaddr_t *addr) { + ns_listenelt_t *lelt = NULL; + dns_acl_t *src_acl = NULL; + dns_aclelement_t aelt; + isc_result_t result; + isc_sockaddr_t any_sa6; + + REQUIRE(isc_sockaddr_pf(addr) == AF_INET6); + + isc_sockaddr_any6(&any_sa6); + if (!isc_sockaddr_equal(&any_sa6, addr)) { + aelt.type = dns_aclelementtype_ipprefix; + aelt.negative = ISC_FALSE; + aelt.u.ip_prefix.prefixlen = 128; + isc_netaddr_fromin6(&aelt.u.ip_prefix.address, + &addr->type.sin6.sin6_addr); + + result = dns_acl_create(mctx, 1, &src_acl); + if (result != ISC_R_SUCCESS) + return (result); + result = dns_acl_appendelement(src_acl, &aelt); + if (result != ISC_R_SUCCESS) + goto clean; + + result = ns_listenelt_create(mctx, isc_sockaddr_getport(addr), + src_acl, &lelt); + if (result != ISC_R_SUCCESS) + goto clean; + ISC_LIST_APPEND(list->elts, lelt, link); + } + + return (ISC_R_SUCCESS); + + clean: + INSIST(lelt == NULL); + if (src_acl != NULL) + dns_acl_detach(&src_acl); + + return (result); +} + +/* + * Make a list of xxx-source addresses and call ns_interfacemgr_adjust() + * to update the listening interfaces accordingly. + * We currently only consider IPv6, because this only affects IPv6 wildcard + * sockets. + */ +static void +adjust_interfaces(ns_server_t *server, isc_mem_t *mctx) { + isc_result_t result; + ns_listenlist_t *list = NULL; + dns_view_t *view; + dns_zone_t *zone, *next; + isc_sockaddr_t addr, *addrp; + + result = ns_listenlist_create(mctx, &list); + if (result != ISC_R_SUCCESS) + return; + + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) { + dns_dispatch_t *dispatch6; + + dispatch6 = dns_resolver_dispatchv6(view->resolver); + INSIST(dispatch6 != NULL); + result = dns_dispatch_getlocaladdress(dispatch6, &addr); + if (result != ISC_R_SUCCESS) + goto fail; + result = add_listenelt(mctx, list, &addr); + if (result != ISC_R_SUCCESS) + goto fail; + } + + zone = NULL; + for (result = dns_zone_first(server->zonemgr, &zone); + result == ISC_R_SUCCESS; + next = NULL, result = dns_zone_next(zone, &next), zone = next) { + dns_view_t *zoneview; + + /* + * At this point the zone list may contain a stale zone + * just removed from the configuration. To see the validity, + * check if the corresponding view is in our current view list. + */ + zoneview = dns_zone_getview(zone); + INSIST(zoneview != NULL); + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL && view != zoneview; + view = ISC_LIST_NEXT(view, link)) + ; + if (view == NULL) + continue; + + addrp = dns_zone_getnotifysrc6(zone); + result = add_listenelt(mctx, list, addrp); + if (result != ISC_R_SUCCESS) + goto fail; + + addrp = dns_zone_getxfrsource6(zone); + result = add_listenelt(mctx, list, addrp); + if (result != ISC_R_SUCCESS) + goto fail; + } + + ns_interfacemgr_adjust(server->interfacemgr, list, ISC_TRUE); + + clean: + ns_listenlist_detach(&list); + return; + + fail: + /* + * Even when we failed the procedure, most of other interfaces + * should work correctly. We therefore just warn it. + */ + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_WARNING, + "could not adjust the listen-on list; " + "some interfaces may not work"); + goto clean; +} + +/* + * This event callback is invoked to do periodic network + * interface scanning. + */ +static void +interface_timer_tick(isc_task_t *task, isc_event_t *event) { + isc_result_t result; + ns_server_t *server = (ns_server_t *) event->ev_arg; + INSIST(task == server->task); + UNUSED(task); + isc_event_free(&event); + /* + * XXX should scan interfaces unlocked and get exclusive access + * only to replace ACLs. + */ + result = isc_task_beginexclusive(server->task); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + scan_interfaces(server, ISC_FALSE); + isc_task_endexclusive(server->task); +} + +static void +heartbeat_timer_tick(isc_task_t *task, isc_event_t *event) { + ns_server_t *server = (ns_server_t *) event->ev_arg; + dns_view_t *view; + + UNUSED(task); + isc_event_free(&event); + view = ISC_LIST_HEAD(server->viewlist); + while (view != NULL) { + dns_view_dialup(view); + view = ISC_LIST_NEXT(view, link); + } +} + +/* + * Replace the current value of '*field', a dynamically allocated + * string or NULL, with a dynamically allocated copy of the + * null-terminated string pointed to by 'value', or NULL. + */ +static isc_result_t +setstring(ns_server_t *server, char **field, const char *value) { + char *copy; + + if (value != NULL) { + copy = isc_mem_strdup(server->mctx, value); + if (copy == NULL) + return (ISC_R_NOMEMORY); + } else { + copy = NULL; + } + + if (*field != NULL) + isc_mem_free(server->mctx, *field); + + *field = copy; + return (ISC_R_SUCCESS); +} + +/* + * Replace the current value of '*field', a dynamically allocated + * string or NULL, with another dynamically allocated string + * or NULL if whether 'obj' is a string or void value, respectively. + */ +static isc_result_t +setoptstring(ns_server_t *server, char **field, cfg_obj_t *obj) { + if (cfg_obj_isvoid(obj)) + return (setstring(server, field, NULL)); + else + return (setstring(server, field, cfg_obj_asstring(obj))); +} + +static void +set_limit(cfg_obj_t **maps, const char *configname, const char *description, + isc_resource_t resourceid, isc_resourcevalue_t defaultvalue) +{ + cfg_obj_t *obj = NULL; + char *resource; + isc_resourcevalue_t value; + isc_result_t result; + + if (ns_config_get(maps, configname, &obj) != ISC_R_SUCCESS) + return; + + if (cfg_obj_isstring(obj)) { + resource = cfg_obj_asstring(obj); + if (strcasecmp(resource, "unlimited") == 0) + value = ISC_RESOURCE_UNLIMITED; + else { + INSIST(strcasecmp(resource, "default") == 0); + value = defaultvalue; + } + } else + value = cfg_obj_asuint64(obj); + + result = isc_resource_setlimit(resourceid, value); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + result == ISC_R_SUCCESS ? + ISC_LOG_DEBUG(3) : ISC_LOG_WARNING, + "set maximum %s to %" ISC_PRINT_QUADFORMAT "d: %s", + description, value, isc_result_totext(result)); +} + +#define SETLIMIT(cfgvar, resource, description) \ + set_limit(maps, cfgvar, description, isc_resource_ ## resource, \ + ns_g_init ## resource) + +static void +set_limits(cfg_obj_t **maps) { + SETLIMIT("stacksize", stacksize, "stack size"); + SETLIMIT("datasize", datasize, "data size"); + SETLIMIT("coresize", coresize, "core size"); + SETLIMIT("files", openfiles, "open files"); +} + +static isc_result_t +portlist_fromconf(dns_portlist_t *portlist, unsigned int family, + cfg_obj_t *ports) +{ + cfg_listelt_t *element; + isc_result_t result = ISC_R_SUCCESS; + + for (element = cfg_list_first(ports); + element != NULL; + element = cfg_list_next(element)) { + cfg_obj_t *obj = cfg_listelt_value(element); + in_port_t port = (in_port_t)cfg_obj_asuint32(obj); + + result = dns_portlist_add(portlist, family, port); + if (result != ISC_R_SUCCESS) + break; + } + return (result); +} + +static isc_result_t +load_configuration(const char *filename, ns_server_t *server, + isc_boolean_t first_time) +{ + isc_result_t result; + cfg_parser_t *parser = NULL; + cfg_obj_t *config; + cfg_obj_t *options; + cfg_obj_t *views; + cfg_obj_t *obj; + cfg_obj_t *v4ports, *v6ports; + cfg_obj_t *maps[3]; + cfg_obj_t *builtin_views; + cfg_listelt_t *element; + dns_view_t *view = NULL; + dns_view_t *view_next; + dns_viewlist_t viewlist; + dns_viewlist_t tmpviewlist; + ns_aclconfctx_t aclconfctx; + isc_uint32_t interface_interval; + isc_uint32_t heartbeat_interval; + isc_uint32_t udpsize; + in_port_t listen_port; + int i; + + ns_aclconfctx_init(&aclconfctx); + ISC_LIST_INIT(viewlist); + + /* Ensure exclusive access to configuration data. */ + result = isc_task_beginexclusive(server->task); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + + /* + * Parse the global default pseudo-config file. + */ + if (first_time) { + CHECK(ns_config_parsedefaults(ns_g_parser, &ns_g_config)); + RUNTIME_CHECK(cfg_map_get(ns_g_config, "options", + &ns_g_defaults) == + ISC_R_SUCCESS); + } + + /* + * Parse the configuration file using the new config code. + */ + result = ISC_R_FAILURE; + config = NULL; + + /* + * Unless this is lwresd with the -C option, parse the config file. + */ + if (!(ns_g_lwresdonly && lwresd_g_useresolvconf)) { + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + ISC_LOG_INFO, "loading configuration from '%s'", + filename); + CHECK(cfg_parser_create(ns_g_mctx, ns_g_lctx, &parser)); + cfg_parser_setcallback(parser, directory_callback, NULL); + result = cfg_parse_file(parser, filename, &cfg_type_namedconf, + &config); + } + + /* + * If this is lwresd with the -C option, or lwresd with no -C or -c + * option where the above parsing failed, parse resolv.conf. + */ + if (ns_g_lwresdonly && + (lwresd_g_useresolvconf || + (!ns_g_conffileset && result == ISC_R_FILENOTFOUND))) + { + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + ISC_LOG_INFO, "loading configuration from '%s'", + lwresd_g_resolvconffile); + if (parser != NULL) + cfg_parser_destroy(&parser); + CHECK(cfg_parser_create(ns_g_mctx, ns_g_lctx, &parser)); + result = ns_lwresd_parseeresolvconf(ns_g_mctx, parser, + &config); + } + CHECK(result); + + /* + * Check the validity of the configuration. + */ + CHECK(bind9_check_namedconf(config, ns_g_lctx, ns_g_mctx)); + + /* + * Fill in the maps array, used for resolving defaults. + */ + i = 0; + options = NULL; + result = cfg_map_get(config, "options", &options); + if (result == ISC_R_SUCCESS) + maps[i++] = options; + maps[i++] = ns_g_defaults; + maps[i++] = NULL; + + /* + * Set process limits, which (usually) needs to be done as root. + */ + set_limits(maps); + + /* + * Configure various server options. + */ + configure_server_quota(maps, "transfers-out", &server->xfroutquota); + configure_server_quota(maps, "tcp-clients", &server->tcpquota); + configure_server_quota(maps, "recursive-clients", + &server->recursionquota); + + CHECK(configure_view_acl(NULL, config, "blackhole", &aclconfctx, + ns_g_mctx, &server->blackholeacl)); + if (server->blackholeacl != NULL) + dns_dispatchmgr_setblackhole(ns_g_dispatchmgr, + server->blackholeacl); + + obj = NULL; + result = ns_config_get(maps, "match-mapped-addresses", &obj); + INSIST(result == ISC_R_SUCCESS); + server->aclenv.match_mapped = cfg_obj_asboolean(obj); + + v4ports = NULL; + v6ports = NULL; + (void)ns_config_get(maps, "avoid-v4-udp-ports", &v4ports); + (void)ns_config_get(maps, "avoid-v6-udp-ports", &v6ports); + if (v4ports != NULL || v6ports != NULL) { + dns_portlist_t *portlist = NULL; + result = dns_portlist_create(ns_g_mctx, &portlist); + if (result == ISC_R_SUCCESS && v4ports != NULL) + result = portlist_fromconf(portlist, AF_INET, v4ports); + if (result == ISC_R_SUCCESS && v6ports != NULL) + portlist_fromconf(portlist, AF_INET6, v6ports); + if (result == ISC_R_SUCCESS) + dns_dispatchmgr_setblackportlist(ns_g_dispatchmgr, portlist); + if (portlist != NULL) + dns_portlist_detach(&portlist); + CHECK(result); + } else + dns_dispatchmgr_setblackportlist(ns_g_dispatchmgr, NULL); + + /* + * Set the EDNS UDP size when we don't match a view. + */ + obj = NULL; + result = ns_config_get(maps, "edns-udp-size", &obj); + INSIST(result == ISC_R_SUCCESS); + udpsize = cfg_obj_asuint32(obj); + if (udpsize < 512) + udpsize = 512; + if (udpsize > 4096) + udpsize = 4096; + ns_g_udpsize = (isc_uint16_t)udpsize; + + /* + * Configure the zone manager. + */ + obj = NULL; + result = ns_config_get(maps, "transfers-in", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zonemgr_settransfersin(server->zonemgr, cfg_obj_asuint32(obj)); + + obj = NULL; + result = ns_config_get(maps, "transfers-per-ns", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zonemgr_settransfersperns(server->zonemgr, cfg_obj_asuint32(obj)); + + obj = NULL; + result = ns_config_get(maps, "serial-query-rate", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zonemgr_setserialqueryrate(server->zonemgr, cfg_obj_asuint32(obj)); + + /* + * Determine which port to use for listening for incoming connections. + */ + if (ns_g_port != 0) + listen_port = ns_g_port; + else + CHECKM(ns_config_getport(config, &listen_port), "port"); + + /* + * Find the listen queue depth. + */ + obj = NULL; + result = ns_config_get(maps, "tcp-listen-queue", &obj); + INSIST(result == ISC_R_SUCCESS); + ns_g_listen = cfg_obj_asuint32(obj); + if (ns_g_listen < 3) + ns_g_listen = 3; + + /* + * Configure the interface manager according to the "listen-on" + * statement. + */ + { + cfg_obj_t *clistenon = NULL; + ns_listenlist_t *listenon = NULL; + + clistenon = NULL; + /* + * Even though listen-on is present in the default + * configuration, we can't use it here, since it isn't + * used if we're in lwresd mode. This way is easier. + */ + if (options != NULL) + (void)cfg_map_get(options, "listen-on", &clistenon); + if (clistenon != NULL) { + result = ns_listenlist_fromconfig(clistenon, + config, + &aclconfctx, + ns_g_mctx, + &listenon); + } else if (!ns_g_lwresdonly) { + /* + * Not specified, use default. + */ + CHECK(ns_listenlist_default(ns_g_mctx, listen_port, + ISC_TRUE, &listenon)); + } + if (listenon != NULL) { + ns_interfacemgr_setlistenon4(server->interfacemgr, + listenon); + ns_listenlist_detach(&listenon); + } + } + /* + * Ditto for IPv6. + */ + { + cfg_obj_t *clistenon = NULL; + ns_listenlist_t *listenon = NULL; + + if (options != NULL) + (void)cfg_map_get(options, "listen-on-v6", &clistenon); + if (clistenon != NULL) { + result = ns_listenlist_fromconfig(clistenon, + config, + &aclconfctx, + ns_g_mctx, + &listenon); + } else if (!ns_g_lwresdonly) { + /* + * Not specified, use default. + */ + CHECK(ns_listenlist_default(ns_g_mctx, listen_port, + ISC_FALSE, &listenon)); + } + if (listenon != NULL) { + ns_interfacemgr_setlistenon6(server->interfacemgr, + listenon); + ns_listenlist_detach(&listenon); + } + } + + /* + * Rescan the interface list to pick up changes in the + * listen-on option. It's important that we do this before we try + * to configure the query source, since the dispatcher we use might + * be shared with an interface. + */ + scan_interfaces(server, ISC_TRUE); + + /* + * Arrange for further interface scanning to occur periodically + * as specified by the "interface-interval" option. + */ + obj = NULL; + result = ns_config_get(maps, "interface-interval", &obj); + INSIST(result == ISC_R_SUCCESS); + interface_interval = cfg_obj_asuint32(obj) * 60; + if (interface_interval == 0) { + CHECK(isc_timer_reset(server->interface_timer, + isc_timertype_inactive, + NULL, NULL, ISC_TRUE)); + } else if (server->interface_interval != interface_interval) { + isc_interval_t interval; + isc_interval_set(&interval, interface_interval, 0); + CHECK(isc_timer_reset(server->interface_timer, + isc_timertype_ticker, + NULL, &interval, ISC_FALSE)); + } + server->interface_interval = interface_interval; + + /* + * Configure the dialup heartbeat timer. + */ + obj = NULL; + result = ns_config_get(maps, "heartbeat-interval", &obj); + INSIST(result == ISC_R_SUCCESS); + heartbeat_interval = cfg_obj_asuint32(obj) * 60; + if (heartbeat_interval == 0) { + CHECK(isc_timer_reset(server->heartbeat_timer, + isc_timertype_inactive, + NULL, NULL, ISC_TRUE)); + } else if (server->heartbeat_interval != heartbeat_interval) { + isc_interval_t interval; + isc_interval_set(&interval, heartbeat_interval, 0); + CHECK(isc_timer_reset(server->heartbeat_timer, + isc_timertype_ticker, + NULL, &interval, ISC_FALSE)); + } + server->heartbeat_interval = heartbeat_interval; + + /* + * Configure and freeze all explicit views. Explicit + * views that have zones were already created at parsing + * time, but views with no zones must be created here. + */ + views = NULL; + (void)cfg_map_get(config, "view", &views); + for (element = cfg_list_first(views); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *vconfig = cfg_listelt_value(element); + view = NULL; + + CHECK(create_view(vconfig, &viewlist, &view)); + INSIST(view != NULL); + CHECK(configure_view(view, config, vconfig, + ns_g_mctx, &aclconfctx, ISC_TRUE)); + dns_view_freeze(view); + dns_view_detach(&view); + } + + /* + * Make sure we have a default view if and only if there + * were no explicit views. + */ + if (views == NULL) { + /* + * No explicit views; there ought to be a default view. + * There may already be one created as a side effect + * of zone statements, or we may have to create one. + * In either case, we need to configure and freeze it. + */ + CHECK(create_view(NULL, &viewlist, &view)); + CHECK(configure_view(view, config, NULL, ns_g_mctx, + &aclconfctx, ISC_TRUE)); + dns_view_freeze(view); + dns_view_detach(&view); + } + + /* + * Create (or recreate) the built-in views. Currently + * there is only one, the _bind view. + */ + builtin_views = NULL; + RUNTIME_CHECK(cfg_map_get(ns_g_config, "view", + &builtin_views) == ISC_R_SUCCESS); + for (element = cfg_list_first(builtin_views); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *vconfig = cfg_listelt_value(element); + CHECK(create_view(vconfig, &viewlist, &view)); + CHECK(configure_view(view, config, vconfig, ns_g_mctx, + &aclconfctx, ISC_FALSE)); + dns_view_freeze(view); + dns_view_detach(&view); + view = NULL; + } + + /* + * Swap our new view list with the production one. + */ + tmpviewlist = server->viewlist; + server->viewlist = viewlist; + viewlist = tmpviewlist; + + /* + * Load the TKEY information from the configuration. + */ + if (options != NULL) { + dns_tkeyctx_t *t = NULL; + CHECKM(ns_tkeyctx_fromconfig(options, ns_g_mctx, ns_g_entropy, + &t), + "configuring TKEY"); + if (server->tkeyctx != NULL) + dns_tkeyctx_destroy(&server->tkeyctx); + server->tkeyctx = t; + } + + /* + * Bind the control port(s). + */ + CHECKM(ns_controls_configure(ns_g_server->controls, config, + &aclconfctx), + "binding control channel(s)"); + + /* + * Bind the lwresd port(s). + */ + CHECKM(ns_lwresd_configure(ns_g_mctx, config), + "binding lightweight resolver ports"); + + /* + * Open the source of entropy. + */ + if (first_time) { + obj = NULL; + result = ns_config_get(maps, "random-device", &obj); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_INFO, + "no source of entropy found"); + } else { + const char *randomdev = cfg_obj_asstring(obj); + result = isc_entropy_createfilesource(ns_g_entropy, + randomdev); + if (result != ISC_R_SUCCESS) + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, + ISC_LOG_INFO, + "could not open entropy source " + "%s: %s", + randomdev, + isc_result_totext(result)); +#ifdef PATH_RANDOMDEV + if (ns_g_fallbackentropy != NULL) { + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, + ISC_LOG_INFO, + "using pre-chroot entropy source " + "%s", + PATH_RANDOMDEV); + isc_entropy_detach(&ns_g_entropy); + isc_entropy_attach(ns_g_fallbackentropy, + &ns_g_entropy); + } + isc_entropy_detach(&ns_g_fallbackentropy); + } +#endif + } + } + + /* + * Relinquish root privileges. + */ + if (first_time) + ns_os_changeuser(); + + /* + * Configure the logging system. + * + * Do this after changing UID to make sure that any log + * files specified in named.conf get created by the + * unprivileged user, not root. + */ + if (ns_g_logstderr) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_INFO, + "ignoring config file logging " + "statement due to -g option"); + } else { + cfg_obj_t *logobj = NULL; + isc_logconfig_t *logc = NULL; + + CHECKM(isc_logconfig_create(ns_g_lctx, &logc), + "creating new logging configuration"); + + logobj = NULL; + (void)cfg_map_get(config, "logging", &logobj); + if (logobj != NULL) { + CHECKM(ns_log_configure(logc, logobj), + "configuring logging"); + } else { + CHECKM(ns_log_setdefaultchannels(logc), + "setting up default logging channels"); + CHECKM(ns_log_setunmatchedcategory(logc), + "setting up default 'category unmatched'"); + CHECKM(ns_log_setdefaultcategory(logc), + "setting up default 'category default'"); + } + + result = isc_logconfig_use(ns_g_lctx, logc); + if (result != ISC_R_SUCCESS) { + isc_logconfig_destroy(&logc); + CHECKM(result, "installing logging configuration"); + } + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_DEBUG(1), + "now using logging configuration from " + "config file"); + } + + /* + * Set the default value of the query logging flag depending + * whether a "queries" category has been defined. This is + * a disgusting hack, but we need to do this for BIND 8 + * compatibility. + */ + if (first_time) { + cfg_obj_t *logobj = NULL; + cfg_obj_t *categories = NULL; + + obj = NULL; + if (ns_config_get(maps, "querylog", &obj) == ISC_R_SUCCESS) { + server->log_queries = cfg_obj_asboolean(obj); + } else { + + (void)cfg_map_get(config, "logging", &logobj); + if (logobj != NULL) + (void)cfg_map_get(logobj, "category", + &categories); + if (categories != NULL) { + cfg_listelt_t *element; + for (element = cfg_list_first(categories); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *catobj; + char *str; + + obj = cfg_listelt_value(element); + catobj = cfg_tuple_get(obj, "name"); + str = cfg_obj_asstring(catobj); + if (strcasecmp(str, "queries") == 0) + server->log_queries = ISC_TRUE; + } + } + } + } + + obj = NULL; + if (ns_config_get(maps, "pid-file", &obj) == ISC_R_SUCCESS) + if (cfg_obj_isvoid(obj)) + ns_os_writepidfile(NULL, first_time); + else + ns_os_writepidfile(cfg_obj_asstring(obj), first_time); + else if (ns_g_lwresdonly) + ns_os_writepidfile(lwresd_g_defaultpidfile, first_time); + else + ns_os_writepidfile(ns_g_defaultpidfile, first_time); + + obj = NULL; + if (options != NULL && + cfg_map_get(options, "memstatistics-file", &obj) == ISC_R_SUCCESS) + ns_main_setmemstats(cfg_obj_asstring(obj)); + else + ns_main_setmemstats(NULL); + + obj = NULL; + result = ns_config_get(maps, "statistics-file", &obj); + INSIST(result == ISC_R_SUCCESS); + CHECKM(setstring(server, &server->statsfile, cfg_obj_asstring(obj)), + "strdup"); + + obj = NULL; + result = ns_config_get(maps, "dump-file", &obj); + INSIST(result == ISC_R_SUCCESS); + CHECKM(setstring(server, &server->dumpfile, cfg_obj_asstring(obj)), + "strdup"); + + obj = NULL; + result = ns_config_get(maps, "recursing-file", &obj); + INSIST(result == ISC_R_SUCCESS); + CHECKM(setstring(server, &server->recfile, cfg_obj_asstring(obj)), + "strdup"); + + obj = NULL; + result = ns_config_get(maps, "version", &obj); + if (result == ISC_R_SUCCESS) { + CHECKM(setoptstring(server, &server->version, obj), "strdup"); + server->version_set = ISC_TRUE; + } else { + server->version_set = ISC_FALSE; + } + + obj = NULL; + result = ns_config_get(maps, "hostname", &obj); + if (result == ISC_R_SUCCESS) { + CHECKM(setoptstring(server, &server->hostname, obj), "strdup"); + server->hostname_set = ISC_TRUE; + } else { + server->hostname_set = ISC_FALSE; + } + + obj = NULL; + result = ns_config_get(maps, "server-id", &obj); + server->server_usehostname = ISC_FALSE; + if (result == ISC_R_SUCCESS && cfg_obj_isboolean(obj)) { + server->server_usehostname = ISC_TRUE; + } else if (result == ISC_R_SUCCESS) { + CHECKM(setoptstring(server, &server->server_id, obj), "strdup"); + } else { + result = setoptstring(server, &server->server_id, NULL); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + } + + obj = NULL; + result = ns_config_get(maps, "flush-zones-on-shutdown", &obj); + if (result == ISC_R_SUCCESS) { + server->flushonshutdown = cfg_obj_asboolean(obj); + } else { + server->flushonshutdown = ISC_FALSE; + } + + result = ISC_R_SUCCESS; + + cleanup: + ns_aclconfctx_destroy(&aclconfctx); + + if (parser != NULL) { + if (config != NULL) + cfg_obj_destroy(parser, &config); + cfg_parser_destroy(&parser); + } + + if (view != NULL) + dns_view_detach(&view); + + /* + * This cleans up either the old production view list + * or our temporary list depending on whether they + * were swapped above or not. + */ + for (view = ISC_LIST_HEAD(viewlist); + view != NULL; + view = view_next) { + view_next = ISC_LIST_NEXT(view, link); + ISC_LIST_UNLINK(viewlist, view, link); + dns_view_detach(&view); + + } + + /* + * Adjust the listening interfaces in accordance with the source + * addresses specified in views and zones. + */ + if (isc_net_probeipv6() == ISC_R_SUCCESS) + adjust_interfaces(server, ns_g_mctx); + + /* Relinquish exclusive access to configuration data. */ + isc_task_endexclusive(server->task); + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + ISC_LOG_DEBUG(1), "load_configuration: %s", + isc_result_totext(result)); + + return (result); +} + +static isc_result_t +load_zones(ns_server_t *server, isc_boolean_t stop) { + isc_result_t result; + dns_view_t *view; + + result = isc_task_beginexclusive(server->task); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + + /* + * Load zone data from disk. + */ + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) + { + CHECK(dns_view_load(view, stop)); + } + + /* + * Force zone maintenance. Do this after loading + * so that we know when we need to force AXFR of + * slave zones whose master files are missing. + */ + CHECK(dns_zonemgr_forcemaint(server->zonemgr)); + cleanup: + isc_task_endexclusive(server->task); + return (result); +} + +static isc_result_t +load_new_zones(ns_server_t *server, isc_boolean_t stop) { + isc_result_t result; + dns_view_t *view; + + result = isc_task_beginexclusive(server->task); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + + /* + * Load zone data from disk. + */ + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) + { + CHECK(dns_view_loadnew(view, stop)); + } + /* + * Force zone maintenance. Do this after loading + * so that we know when we need to force AXFR of + * slave zones whose master files are missing. + */ + dns_zonemgr_resumexfrs(server->zonemgr); + cleanup: + isc_task_endexclusive(server->task); + return (result); +} + +static void +run_server(isc_task_t *task, isc_event_t *event) { + isc_result_t result; + ns_server_t *server = (ns_server_t *)event->ev_arg; + + UNUSED(task); + + isc_event_free(&event); + + CHECKFATAL(dns_dispatchmgr_create(ns_g_mctx, ns_g_entropy, + &ns_g_dispatchmgr), + "creating dispatch manager"); + + CHECKFATAL(ns_interfacemgr_create(ns_g_mctx, ns_g_taskmgr, + ns_g_socketmgr, ns_g_dispatchmgr, + &server->interfacemgr), + "creating interface manager"); + + CHECKFATAL(isc_timer_create(ns_g_timermgr, isc_timertype_inactive, + NULL, NULL, server->task, + interface_timer_tick, + server, &server->interface_timer), + "creating interface timer"); + + CHECKFATAL(isc_timer_create(ns_g_timermgr, isc_timertype_inactive, + NULL, NULL, server->task, + heartbeat_timer_tick, + server, &server->heartbeat_timer), + "creating heartbeat timer"); + + CHECKFATAL(cfg_parser_create(ns_g_mctx, NULL, &ns_g_parser), + "creating default configuration parser"); + + if (ns_g_lwresdonly) + CHECKFATAL(load_configuration(lwresd_g_conffile, server, + ISC_TRUE), + "loading configuration"); + else + CHECKFATAL(load_configuration(ns_g_conffile, server, ISC_TRUE), + "loading configuration"); + + isc_hash_init(); + + CHECKFATAL(load_zones(server, ISC_FALSE), + "loading zones"); + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + ISC_LOG_INFO, "running"); +} + +void +ns_server_flushonshutdown(ns_server_t *server, isc_boolean_t flush) { + + REQUIRE(NS_SERVER_VALID(server)); + + server->flushonshutdown = flush; +} + +static void +shutdown_server(isc_task_t *task, isc_event_t *event) { + isc_result_t result; + dns_view_t *view, *view_next; + ns_server_t *server = (ns_server_t *)event->ev_arg; + isc_boolean_t flush = server->flushonshutdown; + + UNUSED(task); + INSIST(task == server->task); + + result = isc_task_beginexclusive(server->task); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + ISC_LOG_INFO, "shutting down%s", + flush ? ": flushing changes" : ""); + + ns_controls_shutdown(server->controls); + end_reserved_dispatches(server, ISC_TRUE); + + cfg_obj_destroy(ns_g_parser, &ns_g_config); + cfg_parser_destroy(&ns_g_parser); + + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL; + view = view_next) { + view_next = ISC_LIST_NEXT(view, link); + ISC_LIST_UNLINK(server->viewlist, view, link); + if (flush) + dns_view_flushanddetach(&view); + else + dns_view_detach(&view); + } + + isc_timer_detach(&server->interface_timer); + isc_timer_detach(&server->heartbeat_timer); + + ns_interfacemgr_shutdown(server->interfacemgr); + ns_interfacemgr_detach(&server->interfacemgr); + + dns_dispatchmgr_destroy(&ns_g_dispatchmgr); + + dns_zonemgr_shutdown(server->zonemgr); + + if (server->blackholeacl != NULL) + dns_acl_detach(&server->blackholeacl); + + dns_db_detach(&server->in_roothints); + + isc_task_endexclusive(server->task); + + isc_task_detach(&server->task); + + isc_event_free(&event); +} + +void +ns_server_create(isc_mem_t *mctx, ns_server_t **serverp) { + isc_result_t result; + + ns_server_t *server = isc_mem_get(mctx, sizeof(*server)); + if (server == NULL) + fatal("allocating server object", ISC_R_NOMEMORY); + + server->mctx = mctx; + server->task = NULL; + + /* Initialize configuration data with default values. */ + + result = isc_quota_init(&server->xfroutquota, 10); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + result = isc_quota_init(&server->tcpquota, 10); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + result = isc_quota_init(&server->recursionquota, 100); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + isc_quota_soft(&server->recursionquota, ISC_FALSE); + + result = dns_aclenv_init(mctx, &server->aclenv); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + + /* Initialize server data structures. */ + server->zonemgr = NULL; + server->interfacemgr = NULL; + ISC_LIST_INIT(server->viewlist); + server->in_roothints = NULL; + server->blackholeacl = NULL; + + CHECKFATAL(dns_rootns_create(mctx, dns_rdataclass_in, NULL, + &server->in_roothints), + "setting up root hints"); + + CHECKFATAL(isc_mutex_init(&server->reload_event_lock), + "initializing reload event lock"); + server->reload_event = + isc_event_allocate(ns_g_mctx, server, + NS_EVENT_RELOAD, + ns_server_reload, + server, + sizeof(isc_event_t)); + CHECKFATAL(server->reload_event == NULL ? + ISC_R_NOMEMORY : ISC_R_SUCCESS, + "allocating reload event"); + + CHECKFATAL(dst_lib_init(ns_g_mctx, ns_g_entropy, ISC_ENTROPY_GOODONLY), + "initializing DST"); + + server->tkeyctx = NULL; + CHECKFATAL(dns_tkeyctx_create(ns_g_mctx, ns_g_entropy, + &server->tkeyctx), + "creating TKEY context"); + + /* + * Setup the server task, which is responsible for coordinating + * startup and shutdown of the server. + */ + CHECKFATAL(isc_task_create(ns_g_taskmgr, 0, &server->task), + "creating server task"); + isc_task_setname(server->task, "server", server); + CHECKFATAL(isc_task_onshutdown(server->task, shutdown_server, server), + "isc_task_onshutdown"); + CHECKFATAL(isc_app_onrun(ns_g_mctx, server->task, run_server, server), + "isc_app_onrun"); + + server->interface_timer = NULL; + server->heartbeat_timer = NULL; + + server->interface_interval = 0; + server->heartbeat_interval = 0; + + CHECKFATAL(dns_zonemgr_create(ns_g_mctx, ns_g_taskmgr, ns_g_timermgr, + ns_g_socketmgr, &server->zonemgr), + "dns_zonemgr_create"); + + server->statsfile = isc_mem_strdup(server->mctx, "named.stats"); + CHECKFATAL(server->statsfile == NULL ? ISC_R_NOMEMORY : ISC_R_SUCCESS, + "isc_mem_strdup"); + server->querystats = NULL; + + server->dumpfile = isc_mem_strdup(server->mctx, "named_dump.db"); + CHECKFATAL(server->dumpfile == NULL ? ISC_R_NOMEMORY : ISC_R_SUCCESS, + "isc_mem_strdup"); + + server->recfile = isc_mem_strdup(server->mctx, "named.recursing"); + CHECKFATAL(server->recfile == NULL ? ISC_R_NOMEMORY : ISC_R_SUCCESS, + "isc_mem_strdup"); + + server->hostname_set = ISC_FALSE; + server->hostname = NULL; + server->version_set = ISC_FALSE; + server->version = NULL; + server->server_usehostname = ISC_FALSE; + server->server_id = NULL; + + CHECKFATAL(dns_stats_alloccounters(ns_g_mctx, &server->querystats), + "dns_stats_alloccounters"); + + server->flushonshutdown = ISC_FALSE; + server->log_queries = ISC_FALSE; + + server->controls = NULL; + CHECKFATAL(ns_controls_create(server, &server->controls), + "ns_controls_create"); + server->dispatchgen = 0; + ISC_LIST_INIT(server->dispatches); + + server->magic = NS_SERVER_MAGIC; + *serverp = server; +} + +void +ns_server_destroy(ns_server_t **serverp) { + ns_server_t *server = *serverp; + REQUIRE(NS_SERVER_VALID(server)); + + ns_controls_destroy(&server->controls); + + dns_stats_freecounters(server->mctx, &server->querystats); + + isc_mem_free(server->mctx, server->statsfile); + isc_mem_free(server->mctx, server->dumpfile); + isc_mem_free(server->mctx, server->recfile); + + if (server->version != NULL) + isc_mem_free(server->mctx, server->version); + if (server->hostname != NULL) + isc_mem_free(server->mctx, server->hostname); + if (server->server_id != NULL) + isc_mem_free(server->mctx, server->server_id); + + dns_zonemgr_detach(&server->zonemgr); + + if (server->tkeyctx != NULL) + dns_tkeyctx_destroy(&server->tkeyctx); + + dst_lib_destroy(); + + isc_event_free(&server->reload_event); + + INSIST(ISC_LIST_EMPTY(server->viewlist)); + + dns_aclenv_destroy(&server->aclenv); + + isc_quota_destroy(&server->recursionquota); + isc_quota_destroy(&server->tcpquota); + isc_quota_destroy(&server->xfroutquota); + + server->magic = 0; + isc_mem_put(server->mctx, server, sizeof(*server)); + *serverp = NULL; +} + +static void +fatal(const char *msg, isc_result_t result) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + ISC_LOG_CRITICAL, "%s: %s", msg, + isc_result_totext(result)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, + ISC_LOG_CRITICAL, "exiting (due to fatal error)"); + exit(1); +} + +static void +start_reserved_dispatches(ns_server_t *server) { + + REQUIRE(NS_SERVER_VALID(server)); + + server->dispatchgen++; +} + +static void +end_reserved_dispatches(ns_server_t *server, isc_boolean_t all) { + ns_dispatch_t *dispatch, *nextdispatch; + + REQUIRE(NS_SERVER_VALID(server)); + + for (dispatch = ISC_LIST_HEAD(server->dispatches); + dispatch != NULL; + dispatch = nextdispatch) { + nextdispatch = ISC_LIST_NEXT(dispatch, link); + if (!all && server->dispatchgen == dispatch-> dispatchgen) + continue; + ISC_LIST_UNLINK(server->dispatches, dispatch, link); + dns_dispatch_detach(&dispatch->dispatch); + isc_mem_put(server->mctx, dispatch, sizeof(*dispatch)); + } +} + +void +ns_add_reserved_dispatch(ns_server_t *server, isc_sockaddr_t *addr) { + ns_dispatch_t *dispatch; + in_port_t port; + char addrbuf[ISC_SOCKADDR_FORMATSIZE]; + isc_result_t result; + unsigned int attrs, attrmask; + + REQUIRE(NS_SERVER_VALID(server)); + + port = isc_sockaddr_getport(addr); + if (port == 0 || port >= 1024) + return; + + for (dispatch = ISC_LIST_HEAD(server->dispatches); + dispatch != NULL; + dispatch = ISC_LIST_NEXT(dispatch, link)) { + if (isc_sockaddr_equal(&dispatch->addr, addr)) + break; + } + if (dispatch != NULL) { + dispatch->dispatchgen = server->dispatchgen; + return; + } + + dispatch = isc_mem_get(server->mctx, sizeof(*dispatch)); + if (dispatch == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup; + } + + dispatch->addr = *addr; + dispatch->dispatchgen = server->dispatchgen; + dispatch->dispatch = NULL; + + attrs = 0; + attrs |= DNS_DISPATCHATTR_UDP; + switch (isc_sockaddr_pf(addr)) { + case AF_INET: + attrs |= DNS_DISPATCHATTR_IPV4; + break; + case AF_INET6: + attrs |= DNS_DISPATCHATTR_IPV6; + break; + default: + result = ISC_R_NOTIMPLEMENTED; + goto cleanup; + } + attrmask = 0; + attrmask |= DNS_DISPATCHATTR_UDP; + attrmask |= DNS_DISPATCHATTR_TCP; + attrmask |= DNS_DISPATCHATTR_IPV4; + attrmask |= DNS_DISPATCHATTR_IPV6; + + result = dns_dispatch_getudp(ns_g_dispatchmgr, ns_g_socketmgr, + ns_g_taskmgr, &dispatch->addr, 4096, + 1000, 32768, 16411, 16433, + attrs, attrmask, &dispatch->dispatch); + if (result != ISC_R_SUCCESS) + goto cleanup; + + ISC_LIST_INITANDPREPEND(server->dispatches, dispatch, link); + + return; + + cleanup: + if (dispatch != NULL) + isc_mem_put(server->mctx, dispatch, sizeof(*dispatch)); + isc_sockaddr_format(addr, addrbuf, sizeof(addrbuf)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_WARNING, + "unable to create dispatch for reserved port %s: %s", + addrbuf, isc_result_totext(result)); +} + + +static isc_result_t +loadconfig(ns_server_t *server) { + isc_result_t result; + start_reserved_dispatches(server); + result = load_configuration(ns_g_lwresdonly ? + lwresd_g_conffile : ns_g_conffile, + server, + ISC_FALSE); + if (result == ISC_R_SUCCESS) + end_reserved_dispatches(server, ISC_FALSE); + else + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "reloading configuration failed: %s", + isc_result_totext(result)); + return (result); +} + +static isc_result_t +reload(ns_server_t *server) { + isc_result_t result; + CHECK(loadconfig(server)); + + result = load_zones(server, ISC_FALSE); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "reloading zones failed: %s", + isc_result_totext(result)); + } + cleanup: + return (result); +} + +static void +reconfig(ns_server_t *server) { + isc_result_t result; + CHECK(loadconfig(server)); + + result = load_new_zones(server, ISC_FALSE); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "loading new zones failed: %s", + isc_result_totext(result)); + } + cleanup: ; +} + +/* + * Handle a reload event (from SIGHUP). + */ +static void +ns_server_reload(isc_task_t *task, isc_event_t *event) { + ns_server_t *server = (ns_server_t *)event->ev_arg; + + INSIST(task = server->task); + UNUSED(task); + + (void)reload(server); + + LOCK(&server->reload_event_lock); + INSIST(server->reload_event == NULL); + server->reload_event = event; + UNLOCK(&server->reload_event_lock); +} + +void +ns_server_reloadwanted(ns_server_t *server) { + LOCK(&server->reload_event_lock); + if (server->reload_event != NULL) + isc_task_send(server->task, &server->reload_event); + UNLOCK(&server->reload_event_lock); +} + +static char * +next_token(char **stringp, const char *delim) { + char *res; + + do { + res = strsep(stringp, delim); + if (res == NULL) + break; + } while (*res == '\0'); + return (res); +} + +/* + * Find the zone specified in the control channel command 'args', + * if any. If a zone is specified, point '*zonep' at it, otherwise + * set '*zonep' to NULL. + */ +static isc_result_t +zone_from_args(ns_server_t *server, char *args, dns_zone_t **zonep) { + char *input, *ptr; + const char *zonetxt; + char *classtxt; + const char *viewtxt = NULL; + dns_fixedname_t name; + isc_result_t result; + isc_buffer_t buf; + dns_view_t *view = NULL; + dns_rdataclass_t rdclass; + + REQUIRE(zonep != NULL && *zonep == NULL); + + input = args; + + /* Skip the command name. */ + ptr = next_token(&input, " \t"); + if (ptr == NULL) + return (ISC_R_UNEXPECTEDEND); + + /* Look for the zone name. */ + zonetxt = next_token(&input, " \t"); + if (zonetxt == NULL) + return (ISC_R_SUCCESS); + + /* Look for the optional class name. */ + classtxt = next_token(&input, " \t"); + if (classtxt != NULL) { + /* Look for the optional view name. */ + viewtxt = next_token(&input, " \t"); + } + + isc_buffer_init(&buf, zonetxt, strlen(zonetxt)); + isc_buffer_add(&buf, strlen(zonetxt)); + dns_fixedname_init(&name); + result = dns_name_fromtext(dns_fixedname_name(&name), + &buf, dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) + goto fail1; + + if (classtxt != NULL) { + isc_textregion_t r; + r.base = classtxt; + r.length = strlen(classtxt); + result = dns_rdataclass_fromtext(&rdclass, &r); + if (result != ISC_R_SUCCESS) + goto fail1; + } else { + rdclass = dns_rdataclass_in; + } + + if (viewtxt == NULL) + viewtxt = "_default"; + result = dns_viewlist_find(&server->viewlist, viewtxt, + rdclass, &view); + if (result != ISC_R_SUCCESS) + goto fail1; + + result = dns_zt_find(view->zonetable, dns_fixedname_name(&name), + 0, NULL, zonep); + /* Partial match? */ + if (result != ISC_R_SUCCESS && *zonep != NULL) + dns_zone_detach(zonep); + dns_view_detach(&view); + fail1: + return (result); +} + +/* + * Act on a "retransfer" command from the command channel. + */ +isc_result_t +ns_server_retransfercommand(ns_server_t *server, char *args) { + isc_result_t result; + dns_zone_t *zone = NULL; + dns_zonetype_t type; + + result = zone_from_args(server, args, &zone); + if (result != ISC_R_SUCCESS) + return (result); + if (zone == NULL) + return (ISC_R_UNEXPECTEDEND); + type = dns_zone_gettype(zone); + if (type == dns_zone_slave || type == dns_zone_stub) + dns_zone_forcereload(zone); + else + result = ISC_R_NOTFOUND; + dns_zone_detach(&zone); + return (result); +} + +/* + * Act on a "reload" command from the command channel. + */ +isc_result_t +ns_server_reloadcommand(ns_server_t *server, char *args, isc_buffer_t *text) { + isc_result_t result; + dns_zone_t *zone = NULL; + dns_zonetype_t type; + const char *msg = NULL; + + result = zone_from_args(server, args, &zone); + if (result != ISC_R_SUCCESS) + return (result); + if (zone == NULL) { + result = reload(server); + if (result == ISC_R_SUCCESS) + msg = "server reload successful"; + } else { + type = dns_zone_gettype(zone); + if (type == dns_zone_slave || type == dns_zone_stub) { + dns_zone_refresh(zone); + msg = "zone refresh queued"; + } else { + result = dns_zone_load(zone); + dns_zone_detach(&zone); + switch (result) { + case ISC_R_SUCCESS: + msg = "zone reload successful"; + break; + case DNS_R_CONTINUE: + msg = "zone reload queued"; + result = ISC_R_SUCCESS; + break; + case DNS_R_UPTODATE: + msg = "zone reload up-to-date"; + result = ISC_R_SUCCESS; + break; + default: + /* failure message will be generated by rndc */ + break; + } + } + } + if (msg != NULL && strlen(msg) < isc_buffer_availablelength(text)) + isc_buffer_putmem(text, (const unsigned char *)msg, + strlen(msg) + 1); + return (result); +} + +/* + * Act on a "reconfig" command from the command channel. + */ +isc_result_t +ns_server_reconfigcommand(ns_server_t *server, char *args) { + UNUSED(args); + + reconfig(server); + return (ISC_R_SUCCESS); +} + +/* + * Act on a "refresh" command from the command channel. + */ +isc_result_t +ns_server_refreshcommand(ns_server_t *server, char *args, isc_buffer_t *text) { + isc_result_t result; + dns_zone_t *zone = NULL; + const unsigned char msg[] = "zone refresh queued"; + + result = zone_from_args(server, args, &zone); + if (result != ISC_R_SUCCESS) + return (result); + if (zone == NULL) + return (ISC_R_UNEXPECTEDEND); + + dns_zone_refresh(zone); + dns_zone_detach(&zone); + if (sizeof(msg) <= isc_buffer_availablelength(text)) + isc_buffer_putmem(text, msg, sizeof(msg)); + + return (ISC_R_SUCCESS); +} + +isc_result_t +ns_server_togglequerylog(ns_server_t *server) { + server->log_queries = server->log_queries ? ISC_FALSE : ISC_TRUE; + + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_INFO, + "query logging is now %s", + server->log_queries ? "on" : "off"); + return (ISC_R_SUCCESS); +} + +static isc_result_t +ns_listenlist_fromconfig(cfg_obj_t *listenlist, cfg_obj_t *config, + ns_aclconfctx_t *actx, + isc_mem_t *mctx, ns_listenlist_t **target) +{ + isc_result_t result; + cfg_listelt_t *element; + ns_listenlist_t *dlist = NULL; + + REQUIRE(target != NULL && *target == NULL); + + result = ns_listenlist_create(mctx, &dlist); + if (result != ISC_R_SUCCESS) + return (result); + + for (element = cfg_list_first(listenlist); + element != NULL; + element = cfg_list_next(element)) + { + ns_listenelt_t *delt = NULL; + cfg_obj_t *listener = cfg_listelt_value(element); + result = ns_listenelt_fromconfig(listener, config, actx, + mctx, &delt); + if (result != ISC_R_SUCCESS) + goto cleanup; + ISC_LIST_APPEND(dlist->elts, delt, link); + } + *target = dlist; + return (ISC_R_SUCCESS); + + cleanup: + ns_listenlist_detach(&dlist); + return (result); +} + +/* + * Create a listen list from the corresponding configuration + * data structure. + */ +static isc_result_t +ns_listenelt_fromconfig(cfg_obj_t *listener, cfg_obj_t *config, + ns_aclconfctx_t *actx, + isc_mem_t *mctx, ns_listenelt_t **target) +{ + isc_result_t result; + cfg_obj_t *portobj; + in_port_t port; + ns_listenelt_t *delt = NULL; + REQUIRE(target != NULL && *target == NULL); + + portobj = cfg_tuple_get(listener, "port"); + if (!cfg_obj_isuint32(portobj)) { + if (ns_g_port != 0) { + port = ns_g_port; + } else { + result = ns_config_getport(config, &port); + if (result != ISC_R_SUCCESS) + return (result); + } + } else { + if (cfg_obj_asuint32(portobj) >= ISC_UINT16_MAX) { + cfg_obj_log(portobj, ns_g_lctx, ISC_LOG_ERROR, + "port value '%u' is out of range", + cfg_obj_asuint32(portobj)); + return (ISC_R_RANGE); + } + port = (in_port_t)cfg_obj_asuint32(portobj); + } + + result = ns_listenelt_create(mctx, port, NULL, &delt); + if (result != ISC_R_SUCCESS) + return (result); + + result = ns_acl_fromconfig(cfg_tuple_get(listener, "acl"), + config, actx, mctx, &delt->acl); + if (result != ISC_R_SUCCESS) { + ns_listenelt_destroy(delt); + return (result); + } + *target = delt; + return (ISC_R_SUCCESS); +} + +isc_result_t +ns_server_dumpstats(ns_server_t *server) { + isc_result_t result; + dns_zone_t *zone, *next; + isc_stdtime_t now; + FILE *fp = NULL; + int i; + int ncounters; + + isc_stdtime_get(&now); + + CHECKMF(isc_stdio_open(server->statsfile, "a", &fp), + "could not open statistics dump file", server->statsfile); + + ncounters = DNS_STATS_NCOUNTERS; + fprintf(fp, "+++ Statistics Dump +++ (%lu)\n", (unsigned long)now); + + for (i = 0; i < ncounters; i++) + fprintf(fp, "%s %" ISC_PRINT_QUADFORMAT "u\n", + dns_statscounter_names[i], + server->querystats[i]); + + zone = NULL; + for (result = dns_zone_first(server->zonemgr, &zone); + result == ISC_R_SUCCESS; + next = NULL, result = dns_zone_next(zone, &next), zone = next) + { + isc_uint64_t *zonestats = dns_zone_getstatscounters(zone); + if (zonestats != NULL) { + char zonename[DNS_NAME_FORMATSIZE]; + dns_view_t *view; + char *viewname; + + dns_name_format(dns_zone_getorigin(zone), + zonename, sizeof(zonename)); + view = dns_zone_getview(zone); + viewname = view->name; + for (i = 0; i < ncounters; i++) { + fprintf(fp, "%s %" ISC_PRINT_QUADFORMAT + "u %s", + dns_statscounter_names[i], + zonestats[i], + zonename); + if (strcmp(viewname, "_default") != 0) + fprintf(fp, " %s", viewname); + fprintf(fp, "\n"); + } + } + } + if (result == ISC_R_NOMORE) + result = ISC_R_SUCCESS; + CHECK(result); + + fprintf(fp, "--- Statistics Dump --- (%lu)\n", (unsigned long)now); + + cleanup: + if (fp != NULL) + (void)isc_stdio_close(fp); + return (result); +} + +static isc_result_t +add_zone_tolist(dns_zone_t *zone, void *uap) { + struct dumpcontext *dctx = uap; + struct zonelistentry *zle; + + zle = isc_mem_get(dctx->mctx, sizeof *zle); + if (zle == NULL) + return (ISC_R_NOMEMORY); + zle->zone = NULL; + dns_zone_attach(zone, &zle->zone); + ISC_LINK_INIT(zle, link); + ISC_LIST_APPEND(ISC_LIST_TAIL(dctx->viewlist)->zonelist, zle, link); + return (ISC_R_SUCCESS); +} + +static isc_result_t +add_view_tolist(struct dumpcontext *dctx, dns_view_t *view) { + struct viewlistentry *vle; + isc_result_t result = ISC_R_SUCCESS; + + vle = isc_mem_get(dctx->mctx, sizeof *vle); + if (vle == NULL) + return (ISC_R_NOMEMORY); + vle->view = NULL; + dns_view_attach(view, &vle->view); + ISC_LINK_INIT(vle, link); + ISC_LIST_INIT(vle->zonelist); + ISC_LIST_APPEND(dctx->viewlist, vle, link); + if (dctx->dumpzones) + result = dns_zt_apply(view->zonetable, ISC_TRUE, + add_zone_tolist, dctx); + return (result); +} + +static void +dumpcontext_destroy(struct dumpcontext *dctx) { + struct viewlistentry *vle; + struct zonelistentry *zle; + + vle = ISC_LIST_HEAD(dctx->viewlist); + while (vle != NULL) { + ISC_LIST_UNLINK(dctx->viewlist, vle, link); + zle = ISC_LIST_HEAD(vle->zonelist); + while (zle != NULL) { + ISC_LIST_UNLINK(vle->zonelist, zle, link); + dns_zone_detach(&zle->zone); + isc_mem_put(dctx->mctx, zle, sizeof *zle); + zle = ISC_LIST_HEAD(vle->zonelist); + } + dns_view_detach(&vle->view); + isc_mem_put(dctx->mctx, vle, sizeof *vle); + vle = ISC_LIST_HEAD(dctx->viewlist); + } + if (dctx->version != NULL) + dns_db_closeversion(dctx->db, &dctx->version, ISC_FALSE); + if (dctx->db != NULL) + dns_db_detach(&dctx->db); + if (dctx->cache != NULL) + dns_db_detach(&dctx->cache); + if (dctx->task != NULL) + isc_task_detach(&dctx->task); + if (dctx->fp != NULL) + (void)isc_stdio_close(dctx->fp); + if (dctx->mdctx != NULL) + dns_dumpctx_detach(&dctx->mdctx); + isc_mem_put(dctx->mctx, dctx, sizeof *dctx); +} + +static void +dumpdone(void *arg, isc_result_t result) { + struct dumpcontext *dctx = arg; + char buf[1024+32]; + const dns_master_style_t *style; + + if (result != ISC_R_SUCCESS) + goto cleanup; + if (dctx->mdctx != NULL) + dns_dumpctx_detach(&dctx->mdctx); + if (dctx->view == NULL) { + dctx->view = ISC_LIST_HEAD(dctx->viewlist); + if (dctx->view == NULL) + goto done; + INSIST(dctx->zone == NULL); + } + nextview: + fprintf(dctx->fp, ";\n; Start view %s\n;\n", dctx->view->view->name); + if (dctx->zone == NULL && dctx->cache == NULL && dctx->dumpcache) { + style = &dns_master_style_cache; + /* start cache dump */ + if (dctx->view->view->cachedb != NULL) + dns_db_attach(dctx->view->view->cachedb, &dctx->cache); + if (dctx->cache != NULL) { + + fprintf(dctx->fp, ";\n; Cache dump of view '%s'\n;\n", + dctx->view->view->name); + result = dns_master_dumptostreaminc(dctx->mctx, + dctx->cache, NULL, + style, dctx->fp, + dctx->task, + dumpdone, dctx, + &dctx->mdctx); + if (result == DNS_R_CONTINUE) + return; + if (result == ISC_R_NOTIMPLEMENTED) + fprintf(dctx->fp, "; %s\n", + dns_result_totext(result)); + else if (result != ISC_R_SUCCESS) + goto cleanup; + } + } + if (dctx->cache != NULL) { + dns_adb_dump(dctx->view->view->adb, dctx->fp); + dns_db_detach(&dctx->cache); + } + if (dctx->dumpzones) { + style = &dns_master_style_full; + nextzone: + if (dctx->version != NULL) + dns_db_closeversion(dctx->db, &dctx->version, + ISC_FALSE); + if (dctx->db != NULL) + dns_db_detach(&dctx->db); + if (dctx->zone == NULL) + dctx->zone = ISC_LIST_HEAD(dctx->view->zonelist); + else + dctx->zone = ISC_LIST_NEXT(dctx->zone, link); + if (dctx->zone != NULL) { + /* start zone dump */ + dns_zone_name(dctx->zone->zone, buf, sizeof(buf)); + fprintf(dctx->fp, ";\n; Zone dump of '%s'\n;\n", buf); + result = dns_zone_getdb(dctx->zone->zone, &dctx->db); + if (result != ISC_R_SUCCESS) { + fprintf(dctx->fp, "; %s\n", + dns_result_totext(result)); + goto nextzone; + } + dns_db_currentversion(dctx->db, &dctx->version); + result = dns_master_dumptostreaminc(dctx->mctx, + dctx->db, + dctx->version, + style, dctx->fp, + dctx->task, + dumpdone, dctx, + &dctx->mdctx); + if (result == DNS_R_CONTINUE) + return; + if (result == ISC_R_NOTIMPLEMENTED) + fprintf(dctx->fp, "; %s\n", + dns_result_totext(result)); + if (result != ISC_R_SUCCESS) + goto cleanup; + } + } + if (dctx->view != NULL) + dctx->view = ISC_LIST_NEXT(dctx->view, link); + if (dctx->view != NULL) + goto nextview; + done: + fprintf(dctx->fp, "; Dump complete\n"); + result = isc_stdio_flush(dctx->fp); + if (result == ISC_R_SUCCESS) + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_INFO, + "dumpdb complete"); + cleanup: + if (result != ISC_R_SUCCESS) + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_INFO, + "dumpdb failed: %s", dns_result_totext(result)); + dumpcontext_destroy(dctx); +} + + +isc_result_t +ns_server_dumpdb(ns_server_t *server, char *args) { + struct dumpcontext *dctx = NULL; + dns_view_t *view; + isc_result_t result; + char *ptr; + const char *sep; + + dctx = isc_mem_get(server->mctx, sizeof(*dctx)); + if (dctx == NULL) + return (ISC_R_NOMEMORY); + + dctx->mctx = server->mctx; + dctx->dumpcache = ISC_TRUE; + dctx->dumpzones = ISC_FALSE; + dctx->fp = NULL; + ISC_LIST_INIT(dctx->viewlist); + dctx->view = NULL; + dctx->zone = NULL; + dctx->cache = NULL; + dctx->mdctx = NULL; + dctx->db = NULL; + dctx->cache = NULL; + dctx->task = NULL; + dctx->version = NULL; + isc_task_attach(server->task, &dctx->task); + + CHECKMF(isc_stdio_open(server->dumpfile, "w", &dctx->fp), + "could not open dump file", server->dumpfile); + + /* Skip the command name. */ + ptr = next_token(&args, " \t"); + if (ptr == NULL) + return (ISC_R_UNEXPECTEDEND); + + sep = (args == NULL) ? "" : ": "; + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_INFO, + "dumpdb started%s%s", sep, (args != NULL) ? args : ""); + + ptr = next_token(&args, " \t"); + if (ptr != NULL && strcmp(ptr, "-all") == 0) { + dctx->dumpzones = ISC_TRUE; + dctx->dumpcache = ISC_TRUE; + ptr = next_token(&args, " \t"); + } else if (ptr != NULL && strcmp(ptr, "-cache") == 0) { + dctx->dumpzones = ISC_FALSE; + dctx->dumpcache = ISC_TRUE; + ptr = next_token(&args, " \t"); + } else if (ptr != NULL && strcmp(ptr, "-zones") == 0) { + dctx->dumpzones = ISC_TRUE; + dctx->dumpcache = ISC_FALSE; + ptr = next_token(&args, " \t"); + } + + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) + { + if (ptr != NULL && strcmp(view->name, ptr) != 0) + continue; + CHECK(add_view_tolist(dctx, view)); + } + dumpdone(dctx, ISC_R_SUCCESS); + return (ISC_R_SUCCESS); + + cleanup: + if (dctx != NULL) + dumpcontext_destroy(dctx); + return (result); +} + +isc_result_t +ns_server_dumprecursing(ns_server_t *server) { + FILE *fp = NULL; + isc_result_t result; + + CHECKMF(isc_stdio_open(server->recfile, "w", &fp), + "could not open dump file", server->recfile); + fprintf(fp,";\n; Recursing Queries\n;\n"); + ns_interfacemgr_dumprecursing(fp, server->interfacemgr); + fprintf(fp, "; Dump complete\n"); + + cleanup: + if (fp != NULL) + result = isc_stdio_close(fp); + return (result); +} + +isc_result_t +ns_server_setdebuglevel(ns_server_t *server, char *args) { + char *ptr; + char *levelstr; + char *endp; + long newlevel; + + UNUSED(server); + + /* Skip the command name. */ + ptr = next_token(&args, " \t"); + if (ptr == NULL) + return (ISC_R_UNEXPECTEDEND); + + /* Look for the new level name. */ + levelstr = next_token(&args, " \t"); + if (levelstr == NULL) { + if (ns_g_debuglevel < 99) + ns_g_debuglevel++; + } else { + newlevel = strtol(levelstr, &endp, 10); + if (*endp != '\0' || newlevel < 0 || newlevel > 99) + return (ISC_R_RANGE); + ns_g_debuglevel = (unsigned int)newlevel; + } + isc_log_setdebuglevel(ns_g_lctx, ns_g_debuglevel); + return (ISC_R_SUCCESS); +} + +isc_result_t +ns_server_flushcache(ns_server_t *server, char *args) { + char *ptr, *viewname; + dns_view_t *view; + isc_boolean_t flushed = ISC_FALSE; + isc_result_t result; + + /* Skip the command name. */ + ptr = next_token(&args, " \t"); + if (ptr == NULL) + return (ISC_R_UNEXPECTEDEND); + + /* Look for the view name. */ + viewname = next_token(&args, " \t"); + + result = isc_task_beginexclusive(server->task); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) + { + if (viewname != NULL && strcasecmp(viewname, view->name) != 0) + continue; + result = dns_view_flushcache(view); + if (result != ISC_R_SUCCESS) + goto out; + flushed = ISC_TRUE; + } + if (flushed) + result = ISC_R_SUCCESS; + else + result = ISC_R_FAILURE; + out: + isc_task_endexclusive(server->task); + return (result); +} + +isc_result_t +ns_server_flushname(ns_server_t *server, char *args) { + char *ptr, *target, *viewname; + dns_view_t *view; + isc_boolean_t flushed = ISC_FALSE; + isc_result_t result; + isc_buffer_t b; + dns_fixedname_t fixed; + dns_name_t *name; + + /* Skip the command name. */ + ptr = next_token(&args, " \t"); + if (ptr == NULL) + return (ISC_R_UNEXPECTEDEND); + + /* Find the domain name to flush. */ + target = next_token(&args, " \t"); + if (target == NULL) + return (ISC_R_UNEXPECTEDEND); + + isc_buffer_init(&b, target, strlen(target)); + isc_buffer_add(&b, strlen(target)); + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + result = dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) + return (result); + + /* Look for the view name. */ + viewname = next_token(&args, " \t"); + + result = isc_task_beginexclusive(server->task); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + flushed = ISC_TRUE; + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) + { + if (viewname != NULL && strcasecmp(viewname, view->name) != 0) + continue; + result = dns_view_flushname(view, name); + if (result != ISC_R_SUCCESS) + flushed = ISC_FALSE; + } + if (flushed) + result = ISC_R_SUCCESS; + else + result = ISC_R_FAILURE; + isc_task_endexclusive(server->task); + return (result); +} + +isc_result_t +ns_server_status(ns_server_t *server, isc_buffer_t *text) { + int zonecount, xferrunning, xferdeferred, soaqueries; + unsigned int n; + + zonecount = dns_zonemgr_getcount(server->zonemgr, DNS_ZONESTATE_ANY); + xferrunning = dns_zonemgr_getcount(server->zonemgr, + DNS_ZONESTATE_XFERRUNNING); + xferdeferred = dns_zonemgr_getcount(server->zonemgr, + DNS_ZONESTATE_XFERDEFERRED); + soaqueries = dns_zonemgr_getcount(server->zonemgr, + DNS_ZONESTATE_SOAQUERY); + n = snprintf((char *)isc_buffer_used(text), + isc_buffer_availablelength(text), + "number of zones: %u\n" + "debug level: %d\n" + "xfers running: %u\n" + "xfers deferred: %u\n" + "soa queries in progress: %u\n" + "query logging is %s\n" + "recursive clients: %d/%d\n" + "tcp clients: %d/%d\n" + "server is up and running", + zonecount, ns_g_debuglevel, xferrunning, xferdeferred, + soaqueries, server->log_queries ? "ON" : "OFF", + server->recursionquota.used, server->recursionquota.max, + server->tcpquota.used, server->tcpquota.max); + if (n >= isc_buffer_availablelength(text)) + return (ISC_R_NOSPACE); + isc_buffer_add(text, n); + return (ISC_R_SUCCESS); +} + +/* + * Act on a "freeze" or "unfreeze" command from the command channel. + */ +isc_result_t +ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) { + isc_result_t result; + dns_zone_t *zone = NULL; + dns_zonetype_t type; + char classstr[DNS_RDATACLASS_FORMATSIZE]; + char zonename[DNS_NAME_FORMATSIZE]; + dns_view_t *view; + char *journal; + const char *vname, *sep; + isc_boolean_t frozen; + + result = zone_from_args(server, args, &zone); + if (result != ISC_R_SUCCESS) + return (result); + if (zone == NULL) + return (ISC_R_UNEXPECTEDEND); + type = dns_zone_gettype(zone); + if (type != dns_zone_master) { + dns_zone_detach(&zone); + return (ISC_R_NOTFOUND); + } + + frozen = dns_zone_getupdatedisabled(zone); + if (freeze) { + if (frozen) + result = DNS_R_FROZEN; + if (result == ISC_R_SUCCESS) + result = dns_zone_flush(zone); + if (result == ISC_R_SUCCESS) { + journal = dns_zone_getjournal(zone); + if (journal != NULL) + (void)isc_file_remove(journal); + } + } else { + if (frozen) { + result = dns_zone_load(zone); + if (result == DNS_R_CONTINUE || + result == DNS_R_UPTODATE) + result = ISC_R_SUCCESS; + } + } + if (result == ISC_R_SUCCESS) + dns_zone_setupdatedisabled(zone, freeze); + + view = dns_zone_getview(zone); + if (strcmp(view->name, "_bind") == 0 || + strcmp(view->name, "_default") == 0) + { + vname = ""; + sep = ""; + } else { + vname = view->name; + sep = " "; + } + dns_rdataclass_format(dns_zone_getclass(zone), classstr, + sizeof(classstr)); + dns_name_format(dns_zone_getorigin(zone), + zonename, sizeof(zonename)); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_INFO, + "%s zone '%s/%s'%s%s: %s", + freeze ? "freezing" : "unfreezing", + zonename, classstr, sep, vname, + isc_result_totext(result)); + dns_zone_detach(&zone); + return (result); +} diff --git a/contrib/bind9/bin/named/sortlist.c b/contrib/bind9/bin/named/sortlist.c new file mode 100644 index 000000000000..0098fe779c89 --- /dev/null +++ b/contrib/bind9/bin/named/sortlist.c @@ -0,0 +1,162 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: sortlist.c,v 1.5.12.4 2004/03/08 04:04:19 marka Exp $ */ + +#include + +#include +#include + +#include +#include + +#include +#include +#include + +ns_sortlisttype_t +ns_sortlist_setup(dns_acl_t *acl, isc_netaddr_t *clientaddr, void **argp) { + unsigned int i; + + if (acl == NULL) + goto dont_sort; + + for (i = 0; i < acl->length; i++) { + /* + * 'e' refers to the current 'top level statement' + * in the sortlist (see ARM). + */ + dns_aclelement_t *e = &acl->elements[i]; + dns_aclelement_t *try_elt; + dns_aclelement_t *order_elt = NULL; + dns_aclelement_t *matched_elt = NULL; + + if (e->type == dns_aclelementtype_nestedacl) { + dns_acl_t *inner = e->u.nestedacl; + + if (inner->length < 1 || inner->length > 2) + goto dont_sort; + if (inner->elements[0].negative) + goto dont_sort; + try_elt = &inner->elements[0]; + if (inner->length == 2) + order_elt = &inner->elements[1]; + } else { + /* + * BIND 8 allows bare elements at the top level + * as an undocumented feature. + */ + try_elt = e; + } + + if (dns_aclelement_match(clientaddr, NULL, try_elt, + &ns_g_server->aclenv, + &matched_elt)) { + if (order_elt != NULL) { + if (order_elt->type == + dns_aclelementtype_nestedacl) { + *argp = order_elt->u.nestedacl; + return (NS_SORTLISTTYPE_2ELEMENT); + } else if (order_elt->type == + dns_aclelementtype_localhost && + ns_g_server->aclenv.localhost != NULL) { + *argp = ns_g_server->aclenv.localhost; + return (NS_SORTLISTTYPE_2ELEMENT); + } else if (order_elt->type == + dns_aclelementtype_localnets && + ns_g_server->aclenv.localnets != NULL) { + *argp = ns_g_server->aclenv.localnets; + return (NS_SORTLISTTYPE_2ELEMENT); + } else { + /* + * BIND 8 allows a bare IP prefix as + * the 2nd element of a 2-element + * sortlist statement. + */ + *argp = order_elt; + return (NS_SORTLISTTYPE_1ELEMENT); + } + } else { + INSIST(matched_elt != NULL); + *argp = matched_elt; + return (NS_SORTLISTTYPE_1ELEMENT); + } + } + } + + /* No match; don't sort. */ + dont_sort: + *argp = NULL; + return (NS_SORTLISTTYPE_NONE); +} + +int +ns_sortlist_addrorder2(isc_netaddr_t *addr, void *arg) { + dns_acl_t *sortacl = (dns_acl_t *) arg; + int match; + + (void)dns_acl_match(addr, NULL, sortacl, + &ns_g_server->aclenv, + &match, NULL); + if (match > 0) + return (match); + else if (match < 0) + return (INT_MAX - (-match)); + else + return (INT_MAX / 2); +} + +int +ns_sortlist_addrorder1(isc_netaddr_t *addr, void *arg) { + dns_aclelement_t *matchelt = (dns_aclelement_t *) arg; + if (dns_aclelement_match(addr, NULL, matchelt, + &ns_g_server->aclenv, + NULL)) { + return (0); + } else { + return (INT_MAX); + } +} + +void +ns_sortlist_byaddrsetup(dns_acl_t *sortlist_acl, isc_netaddr_t *client_addr, + dns_addressorderfunc_t *orderp, + void **argp) +{ + ns_sortlisttype_t sortlisttype; + + sortlisttype = ns_sortlist_setup(sortlist_acl, client_addr, argp); + + switch (sortlisttype) { + case NS_SORTLISTTYPE_1ELEMENT: + *orderp = ns_sortlist_addrorder1; + break; + case NS_SORTLISTTYPE_2ELEMENT: + *orderp = ns_sortlist_addrorder2; + break; + case NS_SORTLISTTYPE_NONE: + *orderp = NULL; + break; + default: + UNEXPECTED_ERROR(__FILE__, __LINE__, + "unexpected return from ns_sortlist_setup(): " + "%d", sortlisttype); + break; + } +} + diff --git a/contrib/bind9/bin/named/tkeyconf.c b/contrib/bind9/bin/named/tkeyconf.c new file mode 100644 index 000000000000..7fc13f3d9c0b --- /dev/null +++ b/contrib/bind9/bin/named/tkeyconf.c @@ -0,0 +1,118 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: tkeyconf.c,v 1.19.208.2 2004/06/11 00:30:51 marka Exp $ */ + +#include + +#include +#include /* Required for HP/UX (and others?) */ +#include + +#include + +#include +#include +#include +#include + +#include + +#include + +#define RETERR(x) do { \ + result = (x); \ + if (result != ISC_R_SUCCESS) \ + goto failure; \ + } while (0) + + +isc_result_t +ns_tkeyctx_fromconfig(cfg_obj_t *options, isc_mem_t *mctx, isc_entropy_t *ectx, + dns_tkeyctx_t **tctxp) +{ + isc_result_t result; + dns_tkeyctx_t *tctx = NULL; + char *s; + isc_uint32_t n; + dns_fixedname_t fname; + dns_name_t *name; + isc_buffer_t b; + cfg_obj_t *obj; + int type; + + result = dns_tkeyctx_create(mctx, ectx, &tctx); + if (result != ISC_R_SUCCESS) + return (result); + + obj = NULL; + result = cfg_map_get(options, "tkey-dhkey", &obj); + if (result == ISC_R_SUCCESS) { + s = cfg_obj_asstring(cfg_tuple_get(obj, "name")); + n = cfg_obj_asuint32(cfg_tuple_get(obj, "keyid")); + isc_buffer_init(&b, s, strlen(s)); + isc_buffer_add(&b, strlen(s)); + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + RETERR(dns_name_fromtext(name, &b, dns_rootname, + ISC_FALSE, NULL)); + type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE|DST_TYPE_KEY; + RETERR(dst_key_fromfile(name, (dns_keytag_t) n, DNS_KEYALG_DH, + type, NULL, mctx, &tctx->dhkey)); + } + + obj = NULL; + result = cfg_map_get(options, "tkey-domain", &obj); + if (result == ISC_R_SUCCESS) { + s = cfg_obj_asstring(obj); + isc_buffer_init(&b, s, strlen(s)); + isc_buffer_add(&b, strlen(s)); + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + RETERR(dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, + NULL)); + tctx->domain = isc_mem_get(mctx, sizeof(dns_name_t)); + if (tctx->domain == NULL) { + result = ISC_R_NOMEMORY; + goto failure; + } + dns_name_init(tctx->domain, NULL); + RETERR(dns_name_dup(name, mctx, tctx->domain)); + } + + obj = NULL; + result = cfg_map_get(options, "tkey-gssapi-credential", &obj); + if (result == ISC_R_SUCCESS) { + s = cfg_obj_asstring(obj); + isc_buffer_init(&b, s, strlen(s)); + isc_buffer_add(&b, strlen(s)); + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + RETERR(dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, + NULL)); + RETERR(dst_gssapi_acquirecred(name, ISC_FALSE, + &tctx->gsscred)); + } + + *tctxp = tctx; + return (ISC_R_SUCCESS); + + failure: + dns_tkeyctx_destroy(&tctx); + return (result); +} + diff --git a/contrib/bind9/bin/named/tsigconf.c b/contrib/bind9/bin/named/tsigconf.c new file mode 100644 index 000000000000..38524c37fad7 --- /dev/null +++ b/contrib/bind9/bin/named/tsigconf.c @@ -0,0 +1,170 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: tsigconf.c,v 1.21.208.4 2004/03/08 04:04:19 marka Exp $ */ + +#include + +#include +#include +#include +#include + +#include + +#include +#include + +#include + +#include +#include + +static isc_result_t +add_initial_keys(cfg_obj_t *list, dns_tsig_keyring_t *ring, isc_mem_t *mctx) { + cfg_listelt_t *element; + cfg_obj_t *key = NULL; + char *keyid = NULL; + unsigned char *secret = NULL; + int secretalloc = 0; + int secretlen = 0; + isc_result_t ret; + isc_stdtime_t now; + + for (element = cfg_list_first(list); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *algobj = NULL; + cfg_obj_t *secretobj = NULL; + dns_name_t keyname; + dns_name_t *alg; + char *algstr; + char keynamedata[1024]; + isc_buffer_t keynamesrc, keynamebuf; + char *secretstr; + isc_buffer_t secretbuf; + + key = cfg_listelt_value(element); + keyid = cfg_obj_asstring(cfg_map_getname(key)); + + algobj = NULL; + secretobj = NULL; + (void)cfg_map_get(key, "algorithm", &algobj); + (void)cfg_map_get(key, "secret", &secretobj); + INSIST(algobj != NULL && secretobj != NULL); + + /* + * Create the key name. + */ + dns_name_init(&keyname, NULL); + isc_buffer_init(&keynamesrc, keyid, strlen(keyid)); + isc_buffer_add(&keynamesrc, strlen(keyid)); + isc_buffer_init(&keynamebuf, keynamedata, sizeof(keynamedata)); + ret = dns_name_fromtext(&keyname, &keynamesrc, dns_rootname, + ISC_TRUE, &keynamebuf); + if (ret != ISC_R_SUCCESS) + goto failure; + + /* + * Create the algorithm. + */ + algstr = cfg_obj_asstring(algobj); + if (ns_config_getkeyalgorithm(algstr, &alg) != ISC_R_SUCCESS) { + cfg_obj_log(algobj, ns_g_lctx, ISC_LOG_ERROR, + "key '%s': the only supported algorithm " + "is hmac-md5", keyid); + ret = DNS_R_BADALG; + goto failure; + } + + secretstr = cfg_obj_asstring(secretobj); + secretalloc = secretlen = strlen(secretstr) * 3 / 4; + secret = isc_mem_get(mctx, secretlen); + if (secret == NULL) { + ret = ISC_R_NOMEMORY; + goto failure; + } + isc_buffer_init(&secretbuf, secret, secretlen); + ret = isc_base64_decodestring(secretstr, &secretbuf); + if (ret != ISC_R_SUCCESS) + goto failure; + secretlen = isc_buffer_usedlength(&secretbuf); + + isc_stdtime_get(&now); + ret = dns_tsigkey_create(&keyname, alg, secret, secretlen, + ISC_FALSE, NULL, now, now, + mctx, ring, NULL); + isc_mem_put(mctx, secret, secretalloc); + secret = NULL; + if (ret != ISC_R_SUCCESS) + goto failure; + } + + return (ISC_R_SUCCESS); + + failure: + cfg_obj_log(key, ns_g_lctx, ISC_LOG_ERROR, + "configuring key '%s': %s", keyid, + isc_result_totext(ret)); + + if (secret != NULL) + isc_mem_put(mctx, secret, secretalloc); + return (ret); + +} + +isc_result_t +ns_tsigkeyring_fromconfig(cfg_obj_t *config, cfg_obj_t *vconfig, + isc_mem_t *mctx, dns_tsig_keyring_t **ringp) +{ + cfg_obj_t *maps[3]; + cfg_obj_t *keylist; + dns_tsig_keyring_t *ring = NULL; + isc_result_t result; + int i; + + i = 0; + if (config != NULL) + maps[i++] = config; + if (vconfig != NULL) + maps[i++] = cfg_tuple_get(vconfig, "options"); + maps[i] = NULL; + + result = dns_tsigkeyring_create(mctx, &ring); + if (result != ISC_R_SUCCESS) + return (result); + + for (i = 0; ; i++) { + if (maps[i] == NULL) + break; + keylist = NULL; + result = cfg_map_get(maps[i], "key", &keylist); + if (result != ISC_R_SUCCESS) + continue; + result = add_initial_keys(keylist, ring, mctx); + if (result != ISC_R_SUCCESS) + goto failure; + } + + *ringp = ring; + return (ISC_R_SUCCESS); + + failure: + dns_tsigkeyring_destroy(&ring); + return (result); +} diff --git a/contrib/bind9/bin/named/unix/Makefile.in b/contrib/bind9/bin/named/unix/Makefile.in new file mode 100644 index 000000000000..60ce968865dc --- /dev/null +++ b/contrib/bind9/bin/named/unix/Makefile.in @@ -0,0 +1,36 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 1999-2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.6.12.3 2004/03/08 09:04:15 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_MAKE_INCLUDES@ + +CINCLUDES = -I${srcdir}/include -I${srcdir}/../include \ + ${DNS_INCLUDES} ${ISC_INCLUDES} + +CDEFINES = +CWARNINGS = + +OBJS = os.@O@ + +SRCS = os.c + +TARGETS = ${OBJS} + +@BIND9_MAKE_RULES@ diff --git a/contrib/bind9/bin/named/unix/include/named/os.h b/contrib/bind9/bin/named/unix/include/named/os.h new file mode 100644 index 000000000000..a9fbcb7bd34f --- /dev/null +++ b/contrib/bind9/bin/named/unix/include/named/os.h @@ -0,0 +1,64 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: os.h,v 1.14.2.2.8.8 2004/03/08 04:04:21 marka Exp $ */ + +#ifndef NS_OS_H +#define NS_OS_H 1 + +#include + +void +ns_os_init(const char *progname); + +void +ns_os_daemonize(void); + +void +ns_os_opendevnull(void); + +void +ns_os_closedevnull(void); + +void +ns_os_chroot(const char *root); + +void +ns_os_inituserinfo(const char *username); + +void +ns_os_changeuser(void); + +void +ns_os_minprivs(void); + +void +ns_os_writepidfile(const char *filename, isc_boolean_t first_time); + +void +ns_os_shutdown(void); + +isc_result_t +ns_os_gethostname(char *buf, size_t len); + +void +ns_os_shutdownmsg(char *command, isc_buffer_t *text); + +void +ns_os_tzset(void); + +#endif /* NS_OS_H */ diff --git a/contrib/bind9/bin/named/unix/os.c b/contrib/bind9/bin/named/unix/os.c new file mode 100644 index 000000000000..7df7f3b41b56 --- /dev/null +++ b/contrib/bind9/bin/named/unix/os.c @@ -0,0 +1,630 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: os.c,v 1.46.2.4.8.16 2004/05/04 03:19:42 marka Exp $ */ + +#include +#include + +#include /* dev_t FreeBSD 2.1 */ +#include + +#include +#include +#include +#include /* Required for initgroups() on IRIX. */ +#include +#include +#include +#include +#include +#ifdef HAVE_TZSET +#include +#endif +#include + +#include +#include +#include +#include +#include +#include + +#include +#include + +static char *pidfile = NULL; +static int devnullfd = -1; + +#ifndef ISC_FACILITY +#define ISC_FACILITY LOG_DAEMON +#endif + +/* + * If there's no , we don't care about + */ +#ifndef HAVE_LINUX_CAPABILITY_H +#undef HAVE_SYS_PRCTL_H +#endif + +/* + * Linux defines: + * (T) HAVE_LINUXTHREADS + * (C) HAVE_LINUX_CAPABILITY_H + * (P) HAVE_SYS_PRCTL_H + * The possible cases are: + * none: setuid() normally + * T: no setuid() + * C: setuid() normally, drop caps (keep CAP_SETUID) + * T+C: no setuid(), drop caps (don't keep CAP_SETUID) + * T+C+P: setuid() early, drop caps (keep CAP_SETUID) + * C+P: setuid() normally, drop caps (keep CAP_SETUID) + * P: not possible + * T+P: not possible + * + * if (C) + * caps = BIND_SERVICE + CHROOT + SETGID + * if ((T && C && P) || !T) + * caps += SETUID + * endif + * capset(caps) + * endif + * if (T && C && P && -u) + * setuid() + * else if (T && -u) + * fail + * --> start threads + * if (!T && -u) + * setuid() + * if (C && (P || !-u)) + * caps = BIND_SERVICE + * capset(caps) + * endif + * + * It will be nice when Linux threads work properly with setuid(). + */ + +#ifdef HAVE_LINUXTHREADS +static pid_t mainpid = 0; +#endif + +static struct passwd *runas_pw = NULL; +static isc_boolean_t done_setuid = ISC_FALSE; + +#ifdef HAVE_LINUX_CAPABILITY_H + +static isc_boolean_t non_root = ISC_FALSE; +static isc_boolean_t non_root_caps = ISC_FALSE; + +/* + * We define _LINUX_FS_H to prevent it from being included. We don't need + * anything from it, and the files it includes cause warnings with 2.2 + * kernels, and compilation failures (due to conflicts between + * and ) on 2.3 kernels. + */ +#define _LINUX_FS_H + +#include /* Required for syscall(). */ +#include /* Required for _LINUX_CAPABILITY_VERSION. */ + +#ifdef HAVE_SYS_PRCTL_H +#include /* Required for prctl(). */ + +/* + * If the value of PR_SET_KEEPCAPS is not in , define it + * here. This allows setuid() to work on systems running a new enough + * kernel but with /usr/include/linux pointing to "standard" kernel + * headers. + */ +#ifndef PR_SET_KEEPCAPS +#define PR_SET_KEEPCAPS 8 +#endif + +#endif /* HAVE_SYS_PRCTL_H */ + +#ifndef SYS_capset +#ifndef __NR_capset +#include /* Slackware 4.0 needs this. */ +#endif +#define SYS_capset __NR_capset +#endif + +static void +linux_setcaps(unsigned int caps) { + struct __user_cap_header_struct caphead; + struct __user_cap_data_struct cap; + char strbuf[ISC_STRERRORSIZE]; + + if ((getuid() != 0 && !non_root_caps) || non_root) + return; + + memset(&caphead, 0, sizeof(caphead)); + caphead.version = _LINUX_CAPABILITY_VERSION; + caphead.pid = 0; + memset(&cap, 0, sizeof(cap)); + cap.effective = caps; + cap.permitted = caps; + cap.inheritable = caps; + if (syscall(SYS_capset, &caphead, &cap) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("capset failed: %s", strbuf); + } +} + +static void +linux_initialprivs(void) { + unsigned int caps; + + /* + * We don't need most privileges, so we drop them right away. + * Later on linux_minprivs() will be called, which will drop our + * capabilities to the minimum needed to run the server. + */ + + caps = 0; + + /* + * We need to be able to bind() to privileged ports, notably port 53! + */ + caps |= (1 << CAP_NET_BIND_SERVICE); + + /* + * We need chroot() initially too. + */ + caps |= (1 << CAP_SYS_CHROOT); + +#if defined(HAVE_SYS_PRCTL_H) || !defined(HAVE_LINUXTHREADS) + /* + * We can setuid() only if either the kernel supports keeping + * capabilities after setuid() (which we don't know until we've + * tried) or we're not using threads. If either of these is + * true, we want the setuid capability. + */ + caps |= (1 << CAP_SETUID); +#endif + + /* + * Since we call initgroups, we need this. + */ + caps |= (1 << CAP_SETGID); + + /* + * Without this, we run into problems reading a configuration file + * owned by a non-root user and non-world-readable on startup. + */ + caps |= (1 << CAP_DAC_READ_SEARCH); + + /* + * XXX We might want to add CAP_SYS_RESOURCE, though it's not + * clear it would work right given the way linuxthreads work. + * XXXDCL But since we need to be able to set the maximum number + * of files, the stack size, data size, and core dump size to + * support named.conf options, this is now being added to test. + */ + caps |= (1 << CAP_SYS_RESOURCE); + + linux_setcaps(caps); +} + +static void +linux_minprivs(void) { + unsigned int caps; + + /* + * Drop all privileges except the ability to bind() to privileged + * ports. + * + * It's important that we drop CAP_SYS_CHROOT. If we didn't, it + * chroot() could be used to escape from the chrooted area. + */ + + caps = 0; + caps |= (1 << CAP_NET_BIND_SERVICE); + + /* + * XXX We might want to add CAP_SYS_RESOURCE, though it's not + * clear it would work right given the way linuxthreads work. + * XXXDCL But since we need to be able to set the maximum number + * of files, the stack size, data size, and core dump size to + * support named.conf options, this is now being added to test. + */ + caps |= (1 << CAP_SYS_RESOURCE); + + linux_setcaps(caps); +} + +#ifdef HAVE_SYS_PRCTL_H +static void +linux_keepcaps(void) { + char strbuf[ISC_STRERRORSIZE]; + /* + * Ask the kernel to allow us to keep our capabilities after we + * setuid(). + */ + + if (prctl(PR_SET_KEEPCAPS, 1, 0, 0, 0) < 0) { + if (errno != EINVAL) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("prctl() failed: %s", strbuf); + } + } else { + non_root_caps = ISC_TRUE; + if (getuid() != 0) + non_root = ISC_TRUE; + } +} +#endif + +#endif /* HAVE_LINUX_CAPABILITY_H */ + + +static void +setup_syslog(const char *progname) { + int options; + + options = LOG_PID; +#ifdef LOG_NDELAY + options |= LOG_NDELAY; +#endif + openlog(isc_file_basename(progname), options, ISC_FACILITY); +} + +void +ns_os_init(const char *progname) { + setup_syslog(progname); +#ifdef HAVE_LINUX_CAPABILITY_H + linux_initialprivs(); +#endif +#ifdef HAVE_LINUXTHREADS + mainpid = getpid(); +#endif +#ifdef SIGXFSZ + signal(SIGXFSZ, SIG_IGN); +#endif +} + +void +ns_os_daemonize(void) { + pid_t pid; + char strbuf[ISC_STRERRORSIZE]; + + pid = fork(); + if (pid == -1) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("fork(): %s", strbuf); + } + if (pid != 0) + _exit(0); + + /* + * We're the child. + */ + +#ifdef HAVE_LINUXTHREADS + mainpid = getpid(); +#endif + + if (setsid() == -1) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("setsid(): %s", strbuf); + } + + /* + * Try to set stdin, stdout, and stderr to /dev/null, but press + * on even if it fails. + * + * XXXMLG The close() calls here are unneeded on all but NetBSD, but + * are harmless to include everywhere. dup2() is supposed to close + * the FD if it is in use, but unproven-pthreads-0.16 is broken + * and will end up closing the wrong FD. This will be fixed eventually, + * and these calls will be removed. + */ + if (devnullfd != -1) { + if (devnullfd != STDIN_FILENO) { + (void)close(STDIN_FILENO); + (void)dup2(devnullfd, STDIN_FILENO); + } + if (devnullfd != STDOUT_FILENO) { + (void)close(STDOUT_FILENO); + (void)dup2(devnullfd, STDOUT_FILENO); + } + if (devnullfd != STDERR_FILENO) { + (void)close(STDERR_FILENO); + (void)dup2(devnullfd, STDERR_FILENO); + } + } +} + +void +ns_os_opendevnull(void) { + devnullfd = open("/dev/null", O_RDWR, 0); +} + +void +ns_os_closedevnull(void) { + if (devnullfd != STDIN_FILENO && + devnullfd != STDOUT_FILENO && + devnullfd != STDERR_FILENO) { + close(devnullfd); + devnullfd = -1; + } +} + +static isc_boolean_t +all_digits(const char *s) { + if (*s == '\0') + return (ISC_FALSE); + while (*s != '\0') { + if (!isdigit((*s)&0xff)) + return (ISC_FALSE); + s++; + } + return (ISC_TRUE); +} + +void +ns_os_chroot(const char *root) { + char strbuf[ISC_STRERRORSIZE]; + if (root != NULL) { + if (chroot(root) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("chroot(): %s", strbuf); + } + if (chdir("/") < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("chdir(/): %s", strbuf); + } + } +} + +void +ns_os_inituserinfo(const char *username) { + char strbuf[ISC_STRERRORSIZE]; + if (username == NULL) + return; + + if (all_digits(username)) + runas_pw = getpwuid((uid_t)atoi(username)); + else + runas_pw = getpwnam(username); + endpwent(); + + if (runas_pw == NULL) + ns_main_earlyfatal("user '%s' unknown", username); + + if (getuid() == 0) { + if (initgroups(runas_pw->pw_name, runas_pw->pw_gid) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("initgroups(): %s", strbuf); + } + } + +} + +void +ns_os_changeuser(void) { + char strbuf[ISC_STRERRORSIZE]; + if (runas_pw == NULL || done_setuid) + return; + + done_setuid = ISC_TRUE; + +#ifdef HAVE_LINUXTHREADS +#ifdef HAVE_LINUX_CAPABILITY_H + if (!non_root_caps) +#endif + ns_main_earlyfatal( + "-u not supported on Linux kernels older than " + "2.3.99-pre3 or 2.2.18 when using threads"); +#endif + + if (setgid(runas_pw->pw_gid) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("setgid(): %s", strbuf); + } + + if (setuid(runas_pw->pw_uid) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + ns_main_earlyfatal("setuid(): %s", strbuf); + } + +#if defined(HAVE_LINUX_CAPABILITY_H) && !defined(HAVE_LINUXTHREADS) + linux_minprivs(); +#endif +} + +void +ns_os_minprivs(void) { +#ifdef HAVE_SYS_PRCTL_H + linux_keepcaps(); +#endif + +#ifdef HAVE_LINUXTHREADS + ns_os_changeuser(); /* Call setuid() before threads are started */ +#endif + +#if defined(HAVE_LINUX_CAPABILITY_H) && defined(HAVE_LINUXTHREADS) + linux_minprivs(); +#endif +} + +static int +safe_open(const char *filename, isc_boolean_t append) { + int fd; + struct stat sb; + + if (stat(filename, &sb) == -1) { + if (errno != ENOENT) + return (-1); + } else if ((sb.st_mode & S_IFREG) == 0) { + errno = EOPNOTSUPP; + return (-1); + } + + if (append) + fd = open(filename, O_WRONLY|O_CREAT|O_APPEND, + S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH); + else { + (void)unlink(filename); + fd = open(filename, O_WRONLY|O_CREAT|O_EXCL, + S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH); + } + return (fd); +} + +static void +cleanup_pidfile(void) { + if (pidfile != NULL) { + (void)unlink(pidfile); + free(pidfile); + } + pidfile = NULL; +} + +void +ns_os_writepidfile(const char *filename, isc_boolean_t first_time) { + int fd; + FILE *lockfile; + size_t len; + pid_t pid; + char strbuf[ISC_STRERRORSIZE]; + void (*report)(const char *, ...); + + /* + * The caller must ensure any required synchronization. + */ + + report = first_time ? ns_main_earlyfatal : ns_main_earlywarning; + + cleanup_pidfile(); + + if (filename == NULL) + return; + + len = strlen(filename); + pidfile = malloc(len + 1); + if (pidfile == NULL) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + (*report)("couldn't malloc '%s': %s", filename, strbuf); + return; + } + /* This is safe. */ + strcpy(pidfile, filename); + + fd = safe_open(filename, ISC_FALSE); + if (fd < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + (*report)("couldn't open pid file '%s': %s", filename, strbuf); + free(pidfile); + pidfile = NULL; + return; + } + lockfile = fdopen(fd, "w"); + if (lockfile == NULL) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + (*report)("could not fdopen() pid file '%s': %s", + filename, strbuf); + (void)close(fd); + cleanup_pidfile(); + return; + } +#ifdef HAVE_LINUXTHREADS + pid = mainpid; +#else + pid = getpid(); +#endif + if (fprintf(lockfile, "%ld\n", (long)pid) < 0) { + (*report)("fprintf() to pid file '%s' failed", filename); + (void)fclose(lockfile); + cleanup_pidfile(); + return; + } + if (fflush(lockfile) == EOF) { + (*report)("fflush() to pid file '%s' failed", filename); + (void)fclose(lockfile); + cleanup_pidfile(); + return; + } + (void)fclose(lockfile); +} + +void +ns_os_shutdown(void) { + closelog(); + cleanup_pidfile(); +} + +isc_result_t +ns_os_gethostname(char *buf, size_t len) { + int n; + + n = gethostname(buf, len); + return ((n == 0) ? ISC_R_SUCCESS : ISC_R_FAILURE); +} + +static char * +next_token(char **stringp, const char *delim) { + char *res; + + do { + res = strsep(stringp, delim); + if (res == NULL) + break; + } while (*res == '\0'); + return (res); +} + +void +ns_os_shutdownmsg(char *command, isc_buffer_t *text) { + char *input, *ptr; + unsigned int n; + pid_t pid; + + input = command; + + /* Skip the command name. */ + ptr = next_token(&input, " \t"); + if (ptr == NULL) + return; + + ptr = next_token(&input, " \t"); + if (ptr == NULL) + return; + + if (strcmp(ptr, "-p") != 0) + return; + +#ifdef HAVE_LINUXTHREADS + pid = mainpid; +#else + pid = getpid(); +#endif + + n = snprintf((char *)isc_buffer_used(text), + isc_buffer_availablelength(text), + "pid: %ld", (long)pid); + /* Only send a message if it is complete. */ + if (n < isc_buffer_availablelength(text)) + isc_buffer_add(text, n); +} + +void +ns_os_tzset(void) { +#ifdef HAVE_TZSET + tzset(); +#endif +} diff --git a/contrib/bind9/bin/named/update.c b/contrib/bind9/bin/named/update.c new file mode 100644 index 000000000000..24779b304ffe --- /dev/null +++ b/contrib/bind9/bin/named/update.c @@ -0,0 +1,2811 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: update.c,v 1.88.2.5.2.23 2004/07/23 02:56:52 marka Exp $ */ + +#include + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* + * This module implements dynamic update as in RFC2136. + */ + +/* + XXX TODO: + - document strict minimality +*/ + +/**************************************************************************/ + +/* + * Log level for tracing dynamic update protocol requests. + */ +#define LOGLEVEL_PROTOCOL ISC_LOG_INFO + +/* + * Log level for low-level debug tracing. + */ +#define LOGLEVEL_DEBUG ISC_LOG_DEBUG(8) + +/* + * Check an operation for failure. These macros all assume that + * the function using them has a 'result' variable and a 'failure' + * label. + */ +#define CHECK(op) \ + do { result = (op); \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) + +/* + * Fail unconditionally with result 'code', which must not + * be ISC_R_SUCCESS. The reason for failure presumably has + * been logged already. + * + * The test against ISC_R_SUCCESS is there to keep the Solaris compiler + * from complaining about "end-of-loop code not reached". + */ + +#define FAIL(code) \ + do { \ + result = (code); \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) + +/* + * Fail unconditionally and log as a client error. + * The test against ISC_R_SUCCESS is there to keep the Solaris compiler + * from complaining about "end-of-loop code not reached". + */ +#define FAILC(code, msg) \ + do { \ + const char *_what = "failed"; \ + result = (code); \ + switch (result) { \ + case DNS_R_NXDOMAIN: \ + case DNS_R_YXDOMAIN: \ + case DNS_R_YXRRSET: \ + case DNS_R_NXRRSET: \ + _what = "unsuccessful"; \ + } \ + update_log(client, zone, LOGLEVEL_PROTOCOL, \ + "update %s: %s (%s)", _what, \ + msg, isc_result_totext(result)); \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) + +#define FAILN(code, name, msg) \ + do { \ + const char *_what = "failed"; \ + result = (code); \ + switch (result) { \ + case DNS_R_NXDOMAIN: \ + case DNS_R_YXDOMAIN: \ + case DNS_R_YXRRSET: \ + case DNS_R_NXRRSET: \ + _what = "unsuccessful"; \ + } \ + if (isc_log_wouldlog(ns_g_lctx, LOGLEVEL_PROTOCOL)) { \ + char _nbuf[DNS_NAME_FORMATSIZE]; \ + dns_name_format(name, _nbuf, sizeof(_nbuf)); \ + update_log(client, zone, LOGLEVEL_PROTOCOL, \ + "update %s: %s: %s (%s)", _what, _nbuf, \ + msg, isc_result_totext(result)); \ + } \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) + +#define FAILNT(code, name, type, msg) \ + do { \ + const char *_what = "failed"; \ + result = (code); \ + switch (result) { \ + case DNS_R_NXDOMAIN: \ + case DNS_R_YXDOMAIN: \ + case DNS_R_YXRRSET: \ + case DNS_R_NXRRSET: \ + _what = "unsuccessful"; \ + } \ + if (isc_log_wouldlog(ns_g_lctx, LOGLEVEL_PROTOCOL)) { \ + char _nbuf[DNS_NAME_FORMATSIZE]; \ + char _tbuf[DNS_RDATATYPE_FORMATSIZE]; \ + dns_name_format(name, _nbuf, sizeof(_nbuf)); \ + dns_rdatatype_format(type, _tbuf, sizeof(_tbuf)); \ + update_log(client, zone, LOGLEVEL_PROTOCOL, \ + "update %s: %s/%s: %s (%s)", \ + _what, _nbuf, _tbuf, msg, \ + isc_result_totext(result)); \ + } \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) +/* + * Fail unconditionally and log as a server error. + * The test against ISC_R_SUCCESS is there to keep the Solaris compiler + * from complaining about "end-of-loop code not reached". + */ +#define FAILS(code, msg) \ + do { \ + result = (code); \ + update_log(client, zone, LOGLEVEL_PROTOCOL, \ + "error: %s: %s", \ + msg, isc_result_totext(result)); \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) + +/**************************************************************************/ + +typedef struct rr rr_t; + +struct rr { + /* dns_name_t name; */ + isc_uint32_t ttl; + dns_rdata_t rdata; +}; + +typedef struct update_event update_event_t; + +struct update_event { + ISC_EVENT_COMMON(update_event_t); + dns_zone_t *zone; + isc_result_t result; + dns_message_t *answer; +}; + +/**************************************************************************/ +/* + * Forward declarations. + */ + +static void update_action(isc_task_t *task, isc_event_t *event); +static void updatedone_action(isc_task_t *task, isc_event_t *event); +static isc_result_t send_forward_event(ns_client_t *client, dns_zone_t *zone); +static void forward_done(isc_task_t *task, isc_event_t *event); + +/**************************************************************************/ + +static void +update_log(ns_client_t *client, dns_zone_t *zone, + int level, const char *fmt, ...) ISC_FORMAT_PRINTF(4, 5); + +static void +update_log(ns_client_t *client, dns_zone_t *zone, + int level, const char *fmt, ...) +{ + va_list ap; + char message[4096]; + char namebuf[DNS_NAME_FORMATSIZE]; + char classbuf[DNS_RDATACLASS_FORMATSIZE]; + + if (client == NULL || zone == NULL) + return; + + if (isc_log_wouldlog(ns_g_lctx, level) == ISC_FALSE) + return; + + dns_name_format(dns_zone_getorigin(zone), namebuf, + sizeof(namebuf)); + dns_rdataclass_format(dns_zone_getclass(zone), classbuf, + sizeof(classbuf)); + + va_start(ap, fmt); + vsnprintf(message, sizeof(message), fmt, ap); + va_end(ap); + + ns_client_log(client, NS_LOGCATEGORY_UPDATE, NS_LOGMODULE_UPDATE, + level, "updating zone '%s/%s': %s", + namebuf, classbuf, message); +} + +static isc_result_t +checkupdateacl(ns_client_t *client, dns_acl_t *acl, const char *message, + dns_name_t *zonename, isc_boolean_t slave) +{ + char namebuf[DNS_NAME_FORMATSIZE]; + char classbuf[DNS_RDATACLASS_FORMATSIZE]; + int level = ISC_LOG_ERROR; + const char *msg = "denied"; + isc_result_t result; + + if (slave && acl == NULL) { + result = DNS_R_NOTIMP; + level = ISC_LOG_DEBUG(3); + msg = "disabled"; + } else + result = ns_client_checkaclsilent(client, acl, ISC_FALSE); + + if (result == ISC_R_SUCCESS) { + level = ISC_LOG_DEBUG(3); + msg = "approved"; + } + + dns_name_format(zonename, namebuf, sizeof(namebuf)); + dns_rdataclass_format(client->view->rdclass, classbuf, + sizeof(classbuf)); + + ns_client_log(client, NS_LOGCATEGORY_UPDATE_SECURITY, + NS_LOGMODULE_UPDATE, level, "%s '%s/%s' %s", + message, namebuf, classbuf, msg); + return (result); +} + +/* + * Update a single RR in version 'ver' of 'db' and log the + * update in 'diff'. + * + * Ensures: + * '*tuple' == NULL. Either the tuple is freed, or its + * ownership has been transferred to the diff. + */ +static isc_result_t +do_one_tuple(dns_difftuple_t **tuple, + dns_db_t *db, dns_dbversion_t *ver, + dns_diff_t *diff) +{ + dns_diff_t temp_diff; + isc_result_t result; + + /* + * Create a singleton diff. + */ + dns_diff_init(diff->mctx, &temp_diff); + ISC_LIST_APPEND(temp_diff.tuples, *tuple, link); + + /* + * Apply it to the database. + */ + result = dns_diff_apply(&temp_diff, db, ver); + ISC_LIST_UNLINK(temp_diff.tuples, *tuple, link); + if (result != ISC_R_SUCCESS) { + dns_difftuple_free(tuple); + return (result); + } + + /* + * Merge it into the current pending journal entry. + */ + dns_diff_appendminimal(diff, tuple); + + /* + * Do not clear temp_diff. + */ + return (ISC_R_SUCCESS); +} + +/* + * Perform the updates in 'updates' in version 'ver' of 'db' and log the + * update in 'diff'. + * + * Ensures: + * 'updates' is empty. + */ +static isc_result_t +do_diff(dns_diff_t *updates, dns_db_t *db, dns_dbversion_t *ver, + dns_diff_t *diff) +{ + isc_result_t result; + while (! ISC_LIST_EMPTY(updates->tuples)) { + dns_difftuple_t *t = ISC_LIST_HEAD(updates->tuples); + ISC_LIST_UNLINK(updates->tuples, t, link); + CHECK(do_one_tuple(&t, db, ver, diff)); + } + return (ISC_R_SUCCESS); + + failure: + dns_diff_clear(diff); + return (result); +} + +static isc_result_t +update_one_rr(dns_db_t *db, dns_dbversion_t *ver, dns_diff_t *diff, + dns_diffop_t op, dns_name_t *name, + dns_ttl_t ttl, dns_rdata_t *rdata) +{ + dns_difftuple_t *tuple = NULL; + isc_result_t result; + result = dns_difftuple_create(diff->mctx, op, + name, ttl, rdata, &tuple); + if (result != ISC_R_SUCCESS) + return (result); + return (do_one_tuple(&tuple, db, ver, diff)); +} + +/**************************************************************************/ +/* + * Callback-style iteration over rdatasets and rdatas. + * + * foreach_rrset() can be used to iterate over the RRsets + * of a name and call a callback function with each + * one. Similarly, foreach_rr() can be used to iterate + * over the individual RRs at name, optionally restricted + * to RRs of a given type. + * + * The callback functions are called "actions" and take + * two arguments: a void pointer for passing arbitrary + * context information, and a pointer to the current RRset + * or RR. By convention, their names end in "_action". + */ + +/* + * XXXRTH We might want to make this public somewhere in libdns. + */ + +/* + * Function type for foreach_rrset() iterator actions. + */ +typedef isc_result_t rrset_func(void *data, dns_rdataset_t *rrset); + +/* + * Function type for foreach_rr() iterator actions. + */ +typedef isc_result_t rr_func(void *data, rr_t *rr); + +/* + * Internal context struct for foreach_node_rr(). + */ +typedef struct { + rr_func * rr_action; + void * rr_action_data; +} foreach_node_rr_ctx_t; + +/* + * Internal helper function for foreach_node_rr(). + */ +static isc_result_t +foreach_node_rr_action(void *data, dns_rdataset_t *rdataset) { + isc_result_t result; + foreach_node_rr_ctx_t *ctx = data; + for (result = dns_rdataset_first(rdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(rdataset)) + { + rr_t rr = { 0, DNS_RDATA_INIT }; + + dns_rdataset_current(rdataset, &rr.rdata); + rr.ttl = rdataset->ttl; + result = (*ctx->rr_action)(ctx->rr_action_data, &rr); + if (result != ISC_R_SUCCESS) + return (result); + } + if (result != ISC_R_NOMORE) + return (result); + return (ISC_R_SUCCESS); +} + +/* + * For each rdataset of 'name' in 'ver' of 'db', call 'action' + * with the rdataset and 'action_data' as arguments. If the name + * does not exist, do nothing. + * + * If 'action' returns an error, abort iteration and return the error. + */ +static isc_result_t +foreach_rrset(dns_db_t *db, + dns_dbversion_t *ver, + dns_name_t *name, + rrset_func *action, + void *action_data) +{ + isc_result_t result; + dns_dbnode_t *node; + dns_rdatasetiter_t *iter; + + node = NULL; + result = dns_db_findnode(db, name, ISC_FALSE, &node); + if (result == ISC_R_NOTFOUND) + return (ISC_R_SUCCESS); + if (result != ISC_R_SUCCESS) + return (result); + + iter = NULL; + result = dns_db_allrdatasets(db, node, ver, + (isc_stdtime_t) 0, &iter); + if (result != ISC_R_SUCCESS) + goto cleanup_node; + + for (result = dns_rdatasetiter_first(iter); + result == ISC_R_SUCCESS; + result = dns_rdatasetiter_next(iter)) + { + dns_rdataset_t rdataset; + + dns_rdataset_init(&rdataset); + dns_rdatasetiter_current(iter, &rdataset); + + result = (*action)(action_data, &rdataset); + + dns_rdataset_disassociate(&rdataset); + if (result != ISC_R_SUCCESS) + goto cleanup_iterator; + } + if (result == ISC_R_NOMORE) + result = ISC_R_SUCCESS; + + cleanup_iterator: + dns_rdatasetiter_destroy(&iter); + + cleanup_node: + dns_db_detachnode(db, &node); + + return (result); +} + +/* + * For each RR of 'name' in 'ver' of 'db', call 'action' + * with the RR and 'action_data' as arguments. If the name + * does not exist, do nothing. + * + * If 'action' returns an error, abort iteration + * and return the error. + */ +static isc_result_t +foreach_node_rr(dns_db_t *db, + dns_dbversion_t *ver, + dns_name_t *name, + rr_func *rr_action, + void *rr_action_data) +{ + foreach_node_rr_ctx_t ctx; + ctx.rr_action = rr_action; + ctx.rr_action_data = rr_action_data; + return (foreach_rrset(db, ver, name, + foreach_node_rr_action, &ctx)); +} + + +/* + * For each of the RRs specified by 'db', 'ver', 'name', 'type', + * (which can be dns_rdatatype_any to match any type), and 'covers', call + * 'action' with the RR and 'action_data' as arguments. If the name + * does not exist, or if no RRset of the given type exists at the name, + * do nothing. + * + * If 'action' returns an error, abort iteration and return the error. + */ +static isc_result_t +foreach_rr(dns_db_t *db, + dns_dbversion_t *ver, + dns_name_t *name, + dns_rdatatype_t type, + dns_rdatatype_t covers, + rr_func *rr_action, + void *rr_action_data) +{ + + isc_result_t result; + dns_dbnode_t *node; + dns_rdataset_t rdataset; + + if (type == dns_rdatatype_any) + return (foreach_node_rr(db, ver, name, + rr_action, rr_action_data)); + + node = NULL; + result = dns_db_findnode(db, name, ISC_FALSE, &node); + if (result == ISC_R_NOTFOUND) + return (ISC_R_SUCCESS); + if (result != ISC_R_SUCCESS) + return (result); + + dns_rdataset_init(&rdataset); + result = dns_db_findrdataset(db, node, ver, type, covers, + (isc_stdtime_t) 0, &rdataset, NULL); + if (result == ISC_R_NOTFOUND) { + result = ISC_R_SUCCESS; + goto cleanup_node; + } + if (result != ISC_R_SUCCESS) + goto cleanup_node; + + for (result = dns_rdataset_first(&rdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(&rdataset)) + { + rr_t rr = { 0, DNS_RDATA_INIT }; + dns_rdataset_current(&rdataset, &rr.rdata); + rr.ttl = rdataset.ttl; + result = (*rr_action)(rr_action_data, &rr); + if (result != ISC_R_SUCCESS) + goto cleanup_rdataset; + } + if (result != ISC_R_NOMORE) + goto cleanup_rdataset; + result = ISC_R_SUCCESS; + + cleanup_rdataset: + dns_rdataset_disassociate(&rdataset); + cleanup_node: + dns_db_detachnode(db, &node); + + return (result); +} + +/**************************************************************************/ +/* + * Various tests on the database contents (for prerequisites, etc). + */ + +/* + * Function type for predicate functions that compare a database RR 'db_rr' + * against an update RR 'update_rr'. + */ +typedef isc_boolean_t rr_predicate(dns_rdata_t *update_rr, dns_rdata_t *db_rr); + +/* + * Helper function for rrset_exists(). + */ +static isc_result_t +rrset_exists_action(void *data, rr_t *rr) { + UNUSED(data); + UNUSED(rr); + return (ISC_R_EXISTS); +} + +/* + * Utility macro for RR existence checking functions. + * + * If the variable 'result' has the value ISC_R_EXISTS or + * ISC_R_SUCCESS, set *exists to ISC_TRUE or ISC_FALSE, + * respectively, and return success. + * + * If 'result' has any other value, there was a failure. + * Return the failure result code and do not set *exists. + * + * This would be more readable as "do { if ... } while(0)", + * but that form generates tons of warnings on Solaris 2.6. + */ +#define RETURN_EXISTENCE_FLAG \ + return ((result == ISC_R_EXISTS) ? \ + (*exists = ISC_TRUE, ISC_R_SUCCESS) : \ + ((result == ISC_R_SUCCESS) ? \ + (*exists = ISC_FALSE, ISC_R_SUCCESS) : \ + result)) + +/* + * Set '*exists' to true iff an rrset of the given type exists, + * to false otherwise. + */ +static isc_result_t +rrset_exists(dns_db_t *db, dns_dbversion_t *ver, + dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers, + isc_boolean_t *exists) +{ + isc_result_t result; + result = foreach_rr(db, ver, name, type, covers, + rrset_exists_action, NULL); + RETURN_EXISTENCE_FLAG; +} + +/* + * Helper function for cname_incompatible_rrset_exists. + */ +static isc_result_t +cname_compatibility_action(void *data, dns_rdataset_t *rrset) { + UNUSED(data); + if (rrset->type != dns_rdatatype_cname && + ! dns_rdatatype_isdnssec(rrset->type)) + return (ISC_R_EXISTS); + return (ISC_R_SUCCESS); +} + +/* + * Check whether there is an rrset incompatible with adding a CNAME RR, + * i.e., anything but another CNAME (which can be replaced) or a + * DNSSEC RR (which can coexist). + * + * If such an incompatible rrset exists, set '*exists' to ISC_TRUE. + * Otherwise, set it to ISC_FALSE. + */ +static isc_result_t +cname_incompatible_rrset_exists(dns_db_t *db, dns_dbversion_t *ver, + dns_name_t *name, isc_boolean_t *exists) { + isc_result_t result; + result = foreach_rrset(db, ver, name, + cname_compatibility_action, NULL); + RETURN_EXISTENCE_FLAG; +} + +/* + * Helper function for rr_count(). + */ +static isc_result_t +count_rr_action(void *data, rr_t *rr) { + int *countp = data; + UNUSED(rr); + (*countp)++; + return (ISC_R_SUCCESS); +} + +/* + * Count the number of RRs of 'type' belonging to 'name' in 'ver' of 'db'. + */ +static isc_result_t +rr_count(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, + dns_rdatatype_t type, dns_rdatatype_t covers, int *countp) +{ + *countp = 0; + return (foreach_rr(db, ver, name, type, covers, + count_rr_action, countp)); +} + +/* + * Context struct and helper function for name_exists(). + */ + +static isc_result_t +name_exists_action(void *data, dns_rdataset_t *rrset) { + UNUSED(data); + UNUSED(rrset); + return (ISC_R_EXISTS); +} + +/* + * Set '*exists' to true iff the given name exists, to false otherwise. + */ +static isc_result_t +name_exists(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, + isc_boolean_t *exists) +{ + isc_result_t result; + result = foreach_rrset(db, ver, name, + name_exists_action, NULL); + RETURN_EXISTENCE_FLAG; +} + +typedef struct { + dns_name_t *name, *signer; + dns_ssutable_t *table; +} ssu_check_t; + +static isc_result_t +ssu_checkrule(void *data, dns_rdataset_t *rrset) { + ssu_check_t *ssuinfo = data; + isc_boolean_t result; + + /* + * If we're deleting all records, it's ok to delete RRSIG and NSEC even + * if we're normally not allowed to. + */ + if (rrset->type == dns_rdatatype_rrsig || + rrset->type == dns_rdatatype_nsec) + return (ISC_TRUE); + result = dns_ssutable_checkrules(ssuinfo->table, ssuinfo->signer, + ssuinfo->name, rrset->type); + return (result == ISC_TRUE ? ISC_R_SUCCESS : ISC_R_FAILURE); +} + +static isc_boolean_t +ssu_checkall(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, + dns_ssutable_t *ssutable, dns_name_t *signer) +{ + isc_result_t result; + ssu_check_t ssuinfo; + + ssuinfo.name = name; + ssuinfo.table = ssutable; + ssuinfo.signer = signer; + result = foreach_rrset(db, ver, name, ssu_checkrule, &ssuinfo); + return (ISC_TF(result == ISC_R_SUCCESS)); +} + +/**************************************************************************/ +/* + * Checking of "RRset exists (value dependent)" prerequisites. + * + * In the RFC2136 section 3.2.5, this is the pseudocode involving + * a variable called "temp", a mapping of tuples to rrsets. + * + * Here, we represent the "temp" data structure as (non-minimial) "dns_diff_t" + * where each typle has op==DNS_DIFFOP_EXISTS. + */ + + +/* + * Append a tuple asserting the existence of the RR with + * 'name' and 'rdata' to 'diff'. + */ +static isc_result_t +temp_append(dns_diff_t *diff, dns_name_t *name, dns_rdata_t *rdata) { + isc_result_t result; + dns_difftuple_t *tuple = NULL; + + REQUIRE(DNS_DIFF_VALID(diff)); + CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_EXISTS, + name, 0, rdata, &tuple)); + ISC_LIST_APPEND(diff->tuples, tuple, link); + failure: + return (result); +} + +/* + * Compare two rdatasets represented as sorted lists of tuples. + * All list elements must have the same owner name and type. + * Return ISC_R_SUCCESS if the rdatasets are equal, rcode(dns_rcode_nxrrset) + * if not. + */ +static isc_result_t +temp_check_rrset(dns_difftuple_t *a, dns_difftuple_t *b) { + for (;;) { + if (a == NULL || b == NULL) + break; + INSIST(a->op == DNS_DIFFOP_EXISTS && + b->op == DNS_DIFFOP_EXISTS); + INSIST(a->rdata.type == b->rdata.type); + INSIST(dns_name_equal(&a->name, &b->name)); + if (dns_rdata_compare(&a->rdata, &b->rdata) != 0) + return (DNS_R_NXRRSET); + a = ISC_LIST_NEXT(a, link); + b = ISC_LIST_NEXT(b, link); + } + if (a != NULL || b != NULL) + return (DNS_R_NXRRSET); + return (ISC_R_SUCCESS); +} + +/* + * A comparison function defining the sorting order for the entries + * in the "temp" data structure. The major sort key is the owner name, + * followed by the type and rdata. + */ +static int +temp_order(const void *av, const void *bv) { + dns_difftuple_t const * const *ap = av; + dns_difftuple_t const * const *bp = bv; + dns_difftuple_t const *a = *ap; + dns_difftuple_t const *b = *bp; + int r; + r = dns_name_compare(&a->name, &b->name); + if (r != 0) + return (r); + r = (b->rdata.type - a->rdata.type); + if (r != 0) + return (r); + r = dns_rdata_compare(&a->rdata, &b->rdata); + return (r); +} + +/* + * Check the "RRset exists (value dependent)" prerequisite information + * in 'temp' against the contents of the database 'db'. + * + * Return ISC_R_SUCCESS if the prerequisites are satisfied, + * rcode(dns_rcode_nxrrset) if not. + * + * 'temp' must be pre-sorted. + */ + +static isc_result_t +temp_check(isc_mem_t *mctx, dns_diff_t *temp, dns_db_t *db, + dns_dbversion_t *ver, dns_name_t *tmpname, dns_rdatatype_t *typep) +{ + isc_result_t result; + dns_name_t *name; + dns_dbnode_t *node; + dns_difftuple_t *t; + dns_diff_t trash; + + dns_diff_init(mctx, &trash); + + /* + * For each name and type in the prerequisites, + * construct a sorted rdata list of the corresponding + * database contents, and compare the lists. + */ + t = ISC_LIST_HEAD(temp->tuples); + while (t != NULL) { + name = &t->name; + (void)dns_name_copy(name, tmpname, NULL); + *typep = t->rdata.type; + + /* A new unique name begins here. */ + node = NULL; + result = dns_db_findnode(db, name, ISC_FALSE, &node); + if (result == ISC_R_NOTFOUND) + return (DNS_R_NXRRSET); + if (result != ISC_R_SUCCESS) + return (result); + + /* A new unique type begins here. */ + while (t != NULL && dns_name_equal(&t->name, name)) { + dns_rdatatype_t type, covers; + dns_rdataset_t rdataset; + dns_diff_t d_rrs; /* Database RRs with + this name and type */ + dns_diff_t u_rrs; /* Update RRs with + this name and type */ + + *typep = type = t->rdata.type; + if (type == dns_rdatatype_rrsig || + type == dns_rdatatype_sig) + covers = dns_rdata_covers(&t->rdata); + else + covers = 0; + + /* + * Collect all database RRs for this name and type + * onto d_rrs and sort them. + */ + dns_rdataset_init(&rdataset); + result = dns_db_findrdataset(db, node, ver, type, + covers, (isc_stdtime_t) 0, + &rdataset, NULL); + if (result != ISC_R_SUCCESS) { + dns_db_detachnode(db, &node); + return (DNS_R_NXRRSET); + } + + dns_diff_init(mctx, &d_rrs); + dns_diff_init(mctx, &u_rrs); + + for (result = dns_rdataset_first(&rdataset); + result == ISC_R_SUCCESS; + result = dns_rdataset_next(&rdataset)) + { + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdataset_current(&rdataset, &rdata); + result = temp_append(&d_rrs, name, &rdata); + if (result != ISC_R_SUCCESS) + goto failure; + } + if (result != ISC_R_NOMORE) + goto failure; + result = dns_diff_sort(&d_rrs, temp_order); + if (result != ISC_R_SUCCESS) + goto failure; + + /* + * Collect all update RRs for this name and type + * onto u_rrs. No need to sort them here - + * they are already sorted. + */ + while (t != NULL && + dns_name_equal(&t->name, name) && + t->rdata.type == type) + { + dns_difftuple_t *next = + ISC_LIST_NEXT(t, link); + ISC_LIST_UNLINK(temp->tuples, t, link); + ISC_LIST_APPEND(u_rrs.tuples, t, link); + t = next; + } + + /* Compare the two sorted lists. */ + result = temp_check_rrset(ISC_LIST_HEAD(u_rrs.tuples), + ISC_LIST_HEAD(d_rrs.tuples)); + if (result != ISC_R_SUCCESS) + goto failure; + + /* + * We are done with the tuples, but we can't free + * them yet because "name" still points into one + * of them. Move them on a temporary list. + */ + ISC_LIST_APPENDLIST(trash.tuples, u_rrs.tuples, link); + ISC_LIST_APPENDLIST(trash.tuples, d_rrs.tuples, link); + dns_rdataset_disassociate(&rdataset); + + continue; + + failure: + dns_diff_clear(&d_rrs); + dns_diff_clear(&u_rrs); + dns_diff_clear(&trash); + dns_rdataset_disassociate(&rdataset); + dns_db_detachnode(db, &node); + return (result); + } + + dns_db_detachnode(db, &node); + } + + dns_diff_clear(&trash); + return (ISC_R_SUCCESS); +} + +/**************************************************************************/ +/* + * Conditional deletion of RRs. + */ + +/* + * Context structure for delete_if(). + */ + +typedef struct { + rr_predicate *predicate; + dns_db_t *db; + dns_dbversion_t *ver; + dns_diff_t *diff; + dns_name_t *name; + dns_rdata_t *update_rr; +} conditional_delete_ctx_t; + +/* + * Predicate functions for delete_if(). + */ + +/* + * Return true iff 'update_rr' is neither a SOA nor an NS RR. + */ +static isc_boolean_t +type_not_soa_nor_ns_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) { + UNUSED(update_rr); + return ((db_rr->type != dns_rdatatype_soa && + db_rr->type != dns_rdatatype_ns) ? + ISC_TRUE : ISC_FALSE); +} + +/* + * Return true always. + */ +static isc_boolean_t +true_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) { + UNUSED(update_rr); + UNUSED(db_rr); + return (ISC_TRUE); +} + +/* + * Return true iff the two RRs have identical rdata. + */ +static isc_boolean_t +rr_equal_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) { + /* + * XXXRTH This is not a problem, but we should consider creating + * dns_rdata_equal() (that used dns_name_equal()), since it + * would be faster. Not a priority. + */ + return (dns_rdata_compare(update_rr, db_rr) == 0 ? + ISC_TRUE : ISC_FALSE); +} + +/* + * Return true iff 'update_rr' should replace 'db_rr' according + * to the special RFC2136 rules for CNAME, SOA, and WKS records. + * + * RFC2136 does not mention NSEC or DNAME, but multiple NSECs or DNAMEs + * make little sense, so we replace those, too. + */ +static isc_boolean_t +replaces_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) { + if (db_rr->type != update_rr->type) + return (ISC_FALSE); + if (db_rr->type == dns_rdatatype_cname) + return (ISC_TRUE); + if (db_rr->type == dns_rdatatype_dname) + return (ISC_TRUE); + if (db_rr->type == dns_rdatatype_soa) + return (ISC_TRUE); + if (db_rr->type == dns_rdatatype_nsec) + return (ISC_TRUE); + if (db_rr->type == dns_rdatatype_wks) { + /* + * Compare the address and protocol fields only. These + * form the first five bytes of the RR data. Do a + * raw binary comparison; unpacking the WKS RRs using + * dns_rdata_tostruct() might be cleaner in some ways, + * but it would require us to pass around an mctx. + */ + INSIST(db_rr->length >= 5 && update_rr->length >= 5); + return (memcmp(db_rr->data, update_rr->data, 5) == 0 ? + ISC_TRUE : ISC_FALSE); + } + return (ISC_FALSE); +} + +/* + * Internal helper function for delete_if(). + */ +static isc_result_t +delete_if_action(void *data, rr_t *rr) { + conditional_delete_ctx_t *ctx = data; + if ((*ctx->predicate)(ctx->update_rr, &rr->rdata)) { + isc_result_t result; + result = update_one_rr(ctx->db, ctx->ver, ctx->diff, + DNS_DIFFOP_DEL, ctx->name, + rr->ttl, &rr->rdata); + return (result); + } else { + return (ISC_R_SUCCESS); + } +} + +/* + * Conditionally delete RRs. Apply 'predicate' to the RRs + * specified by 'db', 'ver', 'name', and 'type' (which can + * be dns_rdatatype_any to match any type). Delete those + * RRs for which the predicate returns true, and log the + * deletions in 'diff'. + */ +static isc_result_t +delete_if(rr_predicate *predicate, + dns_db_t *db, + dns_dbversion_t *ver, + dns_name_t *name, + dns_rdatatype_t type, + dns_rdatatype_t covers, + dns_rdata_t *update_rr, + dns_diff_t *diff) +{ + conditional_delete_ctx_t ctx; + ctx.predicate = predicate; + ctx.db = db; + ctx.ver = ver; + ctx.diff = diff; + ctx.name = name; + ctx.update_rr = update_rr; + return (foreach_rr(db, ver, name, type, covers, + delete_if_action, &ctx)); +} + +/**************************************************************************/ +/* + * Prepare an RR for the addition of the new RR 'ctx->update_rr', + * with TTL 'ctx->update_rr_ttl', to its rdataset, by deleting + * the RRs if it is replaced by the new RR or has a conflicting TTL. + * The necessary changes are appended to ctx->del_diff and ctx->add_diff; + * we need to do all deletions before any additions so that we don't run + * into transient states with conflicting TTLs. + */ + +typedef struct { + dns_db_t *db; + dns_dbversion_t *ver; + dns_diff_t *diff; + dns_name_t *name; + dns_rdata_t *update_rr; + dns_ttl_t update_rr_ttl; + isc_boolean_t ignore_add; + dns_diff_t del_diff; + dns_diff_t add_diff; +} add_rr_prepare_ctx_t; + +static isc_result_t +add_rr_prepare_action(void *data, rr_t *rr) { + isc_result_t result = ISC_R_SUCCESS; + add_rr_prepare_ctx_t *ctx = data; + dns_difftuple_t *tuple = NULL; + isc_boolean_t equal; + + /* + * If the update RR is a "duplicate" of the update RR, + * the update should be silently ignored. + */ + equal = ISC_TF(dns_rdata_compare(&rr->rdata, ctx->update_rr) == 0); + if (equal && rr->ttl == ctx->update_rr_ttl) { + ctx->ignore_add = ISC_TRUE; + return (ISC_R_SUCCESS); + } + + /* + * If this RR is "equal" to the update RR, it should + * be deleted before the update RR is added. + */ + if (replaces_p(ctx->update_rr, &rr->rdata)) { + CHECK(dns_difftuple_create(ctx->del_diff.mctx, + DNS_DIFFOP_DEL, ctx->name, + rr->ttl, + &rr->rdata, + &tuple)); + dns_diff_append(&ctx->del_diff, &tuple); + return (ISC_R_SUCCESS); + } + + /* + * If this RR differs in TTL from the update RR, + * its TTL must be adjusted. + */ + if (rr->ttl != ctx->update_rr_ttl) { + CHECK(dns_difftuple_create(ctx->del_diff.mctx, + DNS_DIFFOP_DEL, ctx->name, + rr->ttl, + &rr->rdata, + &tuple)); + dns_diff_append(&ctx->del_diff, &tuple); + if (!equal) { + CHECK(dns_difftuple_create(ctx->add_diff.mctx, + DNS_DIFFOP_ADD, ctx->name, + ctx->update_rr_ttl, + &rr->rdata, + &tuple)); + dns_diff_append(&ctx->add_diff, &tuple); + } + } + failure: + return (result); +} + +/**************************************************************************/ +/* + * Miscellaneous subroutines. + */ + +/* + * Extract a single update RR from 'section' of dynamic update message + * 'msg', with consistency checking. + * + * Stores the owner name, rdata, and TTL of the update RR at 'name', + * 'rdata', and 'ttl', respectively. + */ +static void +get_current_rr(dns_message_t *msg, dns_section_t section, + dns_rdataclass_t zoneclass, + dns_name_t **name, dns_rdata_t *rdata, dns_rdatatype_t *covers, + dns_ttl_t *ttl, + dns_rdataclass_t *update_class) +{ + dns_rdataset_t *rdataset; + isc_result_t result; + dns_message_currentname(msg, section, name); + rdataset = ISC_LIST_HEAD((*name)->list); + INSIST(rdataset != NULL); + INSIST(ISC_LIST_NEXT(rdataset, link) == NULL); + *covers = rdataset->covers; + *ttl = rdataset->ttl; + result = dns_rdataset_first(rdataset); + INSIST(result == ISC_R_SUCCESS); + dns_rdataset_current(rdataset, rdata); + INSIST(dns_rdataset_next(rdataset) == ISC_R_NOMORE); + *update_class = rdata->rdclass; + rdata->rdclass = zoneclass; +} + +/* + * Increment the SOA serial number of database 'db', version 'ver'. + * Replace the SOA record in the database, and log the + * change in 'diff'. + */ + + /* + * XXXRTH Failures in this routine will be worth logging, when + * we have a logging system. Failure to find the zonename + * or the SOA rdataset warrant at least an UNEXPECTED_ERROR(). + */ + +static isc_result_t +increment_soa_serial(dns_db_t *db, dns_dbversion_t *ver, + dns_diff_t *diff, isc_mem_t *mctx) +{ + dns_difftuple_t *deltuple = NULL; + dns_difftuple_t *addtuple = NULL; + isc_uint32_t serial; + isc_result_t result; + + CHECK(dns_db_createsoatuple(db, ver, mctx, DNS_DIFFOP_DEL, &deltuple)); + CHECK(dns_difftuple_copy(deltuple, &addtuple)); + addtuple->op = DNS_DIFFOP_ADD; + + serial = dns_soa_getserial(&addtuple->rdata); + + /* RFC1982 */ + serial = (serial + 1) & 0xFFFFFFFF; + if (serial == 0) + serial = 1; + + dns_soa_setserial(serial, &addtuple->rdata); + CHECK(do_one_tuple(&deltuple, db, ver, diff)); + CHECK(do_one_tuple(&addtuple, db, ver, diff)); + result = ISC_R_SUCCESS; + + failure: + if (addtuple != NULL) + dns_difftuple_free(&addtuple); + if (deltuple != NULL) + dns_difftuple_free(&deltuple); + return (result); +} + +/* + * Check that the new SOA record at 'update_rdata' does not + * illegally cause the SOA serial number to decrease or stay + * unchanged relative to the existing SOA in 'db'. + * + * Sets '*ok' to ISC_TRUE if the update is legal, ISC_FALSE if not. + * + * William King points out that RFC2136 is inconsistent about + * the case where the serial number stays unchanged: + * + * section 3.4.2.2 requires a server to ignore a SOA update request + * if the serial number on the update SOA is less_than_or_equal to + * the zone SOA serial. + * + * section 3.6 requires a server to ignore a SOA update request if + * the serial is less_than the zone SOA serial. + * + * Paul says 3.4.2.2 is correct. + * + */ +static isc_result_t +check_soa_increment(dns_db_t *db, dns_dbversion_t *ver, + dns_rdata_t *update_rdata, + isc_boolean_t *ok) +{ + isc_uint32_t db_serial; + isc_uint32_t update_serial; + isc_result_t result; + + update_serial = dns_soa_getserial(update_rdata); + + result = dns_db_getsoaserial(db, ver, &db_serial); + if (result != ISC_R_SUCCESS) + return (result); + + if (DNS_SERIAL_GE(db_serial, update_serial)) { + *ok = ISC_FALSE; + } else { + *ok = ISC_TRUE; + } + + return (ISC_R_SUCCESS); + +} + +/**************************************************************************/ +/* + * Incremental updating of NSECs and RRSIGs. + */ + +#define MAXZONEKEYS 32 /* Maximum number of zone keys supported. */ + +/* + * We abuse the dns_diff_t type to represent a set of domain names + * affected by the update. + */ +static isc_result_t +namelist_append_name(dns_diff_t *list, dns_name_t *name) { + isc_result_t result; + dns_difftuple_t *tuple = NULL; + static dns_rdata_t dummy_rdata = { NULL, 0, 0, 0, 0, + { (void*)(-1), (void*)(-1) } }; + CHECK(dns_difftuple_create(list->mctx, DNS_DIFFOP_EXISTS, name, 0, + &dummy_rdata, &tuple)); + dns_diff_append(list, &tuple); + failure: + return (result); +} + +static isc_result_t +namelist_append_subdomain(dns_db_t *db, dns_name_t *name, dns_diff_t *affected) +{ + isc_result_t result; + dns_fixedname_t fixedname; + dns_name_t *child; + dns_dbiterator_t *dbit = NULL; + + dns_fixedname_init(&fixedname); + child = dns_fixedname_name(&fixedname); + + CHECK(dns_db_createiterator(db, ISC_FALSE, &dbit)); + + for (result = dns_dbiterator_seek(dbit, name); + result == ISC_R_SUCCESS; + result = dns_dbiterator_next(dbit)) + { + dns_dbnode_t *node = NULL; + CHECK(dns_dbiterator_current(dbit, &node, child)); + dns_db_detachnode(db, &node); + if (! dns_name_issubdomain(child, name)) + break; + CHECK(namelist_append_name(affected, child)); + } + if (result == ISC_R_NOMORE) + result = ISC_R_SUCCESS; + failure: + if (dbit != NULL) + dns_dbiterator_destroy(&dbit); + return (result); +} + + + +/* + * Helper function for non_nsec_rrset_exists(). + */ +static isc_result_t +is_non_nsec_action(void *data, dns_rdataset_t *rrset) { + UNUSED(data); + if (!(rrset->type == dns_rdatatype_nsec || + (rrset->type == dns_rdatatype_rrsig && + rrset->covers == dns_rdatatype_nsec))) + return (ISC_R_EXISTS); + return (ISC_R_SUCCESS); +} + +/* + * Check whether there is an rrset other than a NSEC or RRSIG NSEC, + * i.e., anything that justifies the continued existence of a name + * after a secure update. + * + * If such an rrset exists, set '*exists' to ISC_TRUE. + * Otherwise, set it to ISC_FALSE. + */ +static isc_result_t +non_nsec_rrset_exists(dns_db_t *db, dns_dbversion_t *ver, + dns_name_t *name, isc_boolean_t *exists) +{ + isc_result_t result; + result = foreach_rrset(db, ver, name, + is_non_nsec_action, NULL); + RETURN_EXISTENCE_FLAG; +} + +/* + * A comparison function for sorting dns_diff_t:s by name. + */ +static int +name_order(const void *av, const void *bv) { + dns_difftuple_t const * const *ap = av; + dns_difftuple_t const * const *bp = bv; + dns_difftuple_t const *a = *ap; + dns_difftuple_t const *b = *bp; + return (dns_name_compare(&a->name, &b->name)); +} + +static isc_result_t +uniqify_name_list(dns_diff_t *list) { + isc_result_t result; + dns_difftuple_t *p, *q; + + CHECK(dns_diff_sort(list, name_order)); + + p = ISC_LIST_HEAD(list->tuples); + while (p != NULL) { + do { + q = ISC_LIST_NEXT(p, link); + if (q == NULL || ! dns_name_equal(&p->name, &q->name)) + break; + ISC_LIST_UNLINK(list->tuples, q, link); + dns_difftuple_free(&q); + } while (1); + p = ISC_LIST_NEXT(p, link); + } + failure: + return (result); +} + + +static isc_result_t +is_glue(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, + isc_boolean_t *flag) +{ + isc_result_t result; + dns_fixedname_t foundname; + dns_fixedname_init(&foundname); + result = dns_db_find(db, name, ver, dns_rdatatype_any, + DNS_DBFIND_GLUEOK | DNS_DBFIND_NOWILD, + (isc_stdtime_t) 0, NULL, + dns_fixedname_name(&foundname), + NULL, NULL); + if (result == ISC_R_SUCCESS) { + *flag = ISC_FALSE; + return (ISC_R_SUCCESS); + } else if (result == DNS_R_ZONECUT) { + /* + * We are at the zonecut. The name will have an NSEC, but + * non-delegation will be omitted from the type bit map. + */ + *flag = ISC_FALSE; + return (ISC_R_SUCCESS); + } else if (result == DNS_R_GLUE || result == DNS_R_DNAME) { + *flag = ISC_TRUE; + return (ISC_R_SUCCESS); + } else { + return (result); + } +} + +/* + * Find the next/previous name that has a NSEC record. + * In other words, skip empty database nodes and names that + * have had their NSECs removed because they are obscured by + * a zone cut. + */ +static isc_result_t +next_active(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, + dns_dbversion_t *ver, dns_name_t *oldname, dns_name_t *newname, + isc_boolean_t forward) +{ + isc_result_t result; + dns_dbiterator_t *dbit = NULL; + isc_boolean_t has_nsec; + unsigned int wraps = 0; + + CHECK(dns_db_createiterator(db, ISC_FALSE, &dbit)); + + CHECK(dns_dbiterator_seek(dbit, oldname)); + do { + dns_dbnode_t *node = NULL; + + if (forward) + result = dns_dbiterator_next(dbit); + else + result = dns_dbiterator_prev(dbit); + if (result == ISC_R_NOMORE) { + /* + * Wrap around. + */ + if (forward) + CHECK(dns_dbiterator_first(dbit)); + else + CHECK(dns_dbiterator_last(dbit)); + wraps++; + if (wraps == 2) { + update_log(client, zone, ISC_LOG_ERROR, + "secure zone with no NSECs"); + result = DNS_R_BADZONE; + goto failure; + } + } + CHECK(dns_dbiterator_current(dbit, &node, newname)); + dns_db_detachnode(db, &node); + + /* + * The iterator may hold the tree lock, and + * rrset_exists() calls dns_db_findnode() which + * may try to reacquire it. To avoid deadlock + * we must pause the iterator first. + */ + CHECK(dns_dbiterator_pause(dbit)); + CHECK(rrset_exists(db, ver, newname, + dns_rdatatype_nsec, 0, &has_nsec)); + + } while (! has_nsec); + failure: + if (dbit != NULL) + dns_dbiterator_destroy(&dbit); + + return (result); +} + +/* + * Add a NSEC record for "name", recording the change in "diff". + * The existing NSEC is removed. + */ +static isc_result_t +add_nsec(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, + dns_dbversion_t *ver, dns_name_t *name, dns_diff_t *diff) +{ + isc_result_t result; + dns_dbnode_t *node = NULL; + unsigned char buffer[DNS_NSEC_BUFFERSIZE]; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_difftuple_t *tuple = NULL; + dns_fixedname_t fixedname; + dns_name_t *target; + + dns_fixedname_init(&fixedname); + target = dns_fixedname_name(&fixedname); + + /* + * Find the successor name, aka NSEC target. + */ + CHECK(next_active(client, zone, db, ver, name, target, ISC_TRUE)); + + /* + * Create the NSEC RDATA. + */ + CHECK(dns_db_findnode(db, name, ISC_FALSE, &node)); + dns_rdata_init(&rdata); + CHECK(dns_nsec_buildrdata(db, ver, node, target, buffer, &rdata)); + dns_db_detachnode(db, &node); + + /* + * Delete the old NSEC and record the change. + */ + CHECK(delete_if(true_p, db, ver, name, dns_rdatatype_nsec, 0, + NULL, diff)); + /* + * Add the new NSEC and record the change. + */ + CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD, name, + 3600, /* XXXRTH */ + &rdata, &tuple)); + CHECK(do_one_tuple(&tuple, db, ver, diff)); + INSIST(tuple == NULL); + + failure: + if (node != NULL) + dns_db_detachnode(db, &node); + return (result); +} + +/* + * Add a placeholder NSEC record for "name", recording the change in "diff". + */ +static isc_result_t +add_placeholder_nsec(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, + dns_diff_t *diff) { + isc_result_t result; + dns_difftuple_t *tuple = NULL; + isc_region_t r; + unsigned char data[1] = { 0 }; /* The root domain, no bits. */ + dns_rdata_t rdata = DNS_RDATA_INIT; + + r.base = data; + r.length = sizeof(data); + dns_rdata_fromregion(&rdata, dns_db_class(db), dns_rdatatype_nsec, &r); + CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD, name, 0, + &rdata, &tuple)); + CHECK(do_one_tuple(&tuple, db, ver, diff)); + failure: + return (result); +} + +static isc_result_t +find_zone_keys(dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *ver, + isc_mem_t *mctx, unsigned int maxkeys, + dst_key_t **keys, unsigned int *nkeys) +{ + isc_result_t result; + dns_dbnode_t *node = NULL; + const char *directory = dns_zone_getkeydirectory(zone); + CHECK(dns_db_findnode(db, dns_db_origin(db), ISC_FALSE, &node)); + CHECK(dns_dnssec_findzonekeys2(db, ver, node, dns_db_origin(db), + directory, mctx, maxkeys, keys, nkeys)); + failure: + if (node != NULL) + dns_db_detachnode(db, &node); + return (result); +} + +/* + * Add RRSIG records for an RRset, recording the change in "diff". + */ +static isc_result_t +add_sigs(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, + dns_rdatatype_t type, dns_diff_t *diff, dst_key_t **keys, + unsigned int nkeys, isc_mem_t *mctx, isc_stdtime_t inception, + isc_stdtime_t expire) +{ + isc_result_t result; + dns_dbnode_t *node = NULL; + dns_rdataset_t rdataset; + dns_rdata_t sig_rdata = DNS_RDATA_INIT; + isc_buffer_t buffer; + unsigned char data[1024]; /* XXX */ + unsigned int i; + + dns_rdataset_init(&rdataset); + isc_buffer_init(&buffer, data, sizeof(data)); + + /* Get the rdataset to sign. */ + CHECK(dns_db_findnode(db, name, ISC_FALSE, &node)); + CHECK(dns_db_findrdataset(db, node, ver, type, 0, + (isc_stdtime_t) 0, + &rdataset, NULL)); + dns_db_detachnode(db, &node); + + for (i = 0; i < nkeys; i++) { + /* Calculate the signature, creating a RRSIG RDATA. */ + CHECK(dns_dnssec_sign(name, &rdataset, keys[i], + &inception, &expire, + mctx, &buffer, &sig_rdata)); + + /* Update the database and journal with the RRSIG. */ + /* XXX inefficient - will cause dataset merging */ + CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_ADD, name, + rdataset.ttl, &sig_rdata)); + dns_rdata_reset(&sig_rdata); + } + + failure: + if (dns_rdataset_isassociated(&rdataset)) + dns_rdataset_disassociate(&rdataset); + if (node != NULL) + dns_db_detachnode(db, &node); + return (result); +} + +/* + * Update RRSIG and NSEC records affected by an update. The original + * update, including the SOA serial update but exluding the RRSIG & NSEC + * changes, is in "diff" and has already been applied to "newver" of "db". + * The database version prior to the update is "oldver". + * + * The necessary RRSIG and NSEC changes will be applied to "newver" + * and added (as a minimal diff) to "diff". + * + * The RRSIGs generated will be valid for 'sigvalidityinterval' seconds. + */ +static isc_result_t +update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, + dns_dbversion_t *oldver, dns_dbversion_t *newver, + dns_diff_t *diff, isc_uint32_t sigvalidityinterval) +{ + isc_result_t result; + dns_difftuple_t *t; + dns_diff_t diffnames; + dns_diff_t affected; + dns_diff_t sig_diff; + dns_diff_t nsec_diff; + dns_diff_t nsec_mindiff; + isc_boolean_t flag; + dst_key_t *zone_keys[MAXZONEKEYS]; + unsigned int nkeys = 0; + unsigned int i; + isc_stdtime_t now, inception, expire; + + dns_diff_init(client->mctx, &diffnames); + dns_diff_init(client->mctx, &affected); + + dns_diff_init(client->mctx, &sig_diff); + dns_diff_init(client->mctx, &nsec_diff); + dns_diff_init(client->mctx, &nsec_mindiff); + + result = find_zone_keys(zone, db, newver, client->mctx, + MAXZONEKEYS, zone_keys, &nkeys); + if (result != ISC_R_SUCCESS) { + update_log(client, zone, ISC_LOG_ERROR, + "could not get zone keys for secure dynamic update"); + goto failure; + } + + isc_stdtime_get(&now); + inception = now - 3600; /* Allow for some clock skew. */ + expire = now + sigvalidityinterval; + + /* + * Find all RRsets directly affected by the update, and + * update their RRSIGs. Also build a list of names affected + * by the update in "diffnames". + */ + CHECK(dns_diff_sort(diff, temp_order)); + + t = ISC_LIST_HEAD(diff->tuples); + while (t != NULL) { + dns_name_t *name = &t->name; + /* Now "name" is a new, unique name affected by the update. */ + + CHECK(namelist_append_name(&diffnames, name)); + + while (t != NULL && dns_name_equal(&t->name, name)) { + dns_rdatatype_t type; + type = t->rdata.type; + + /* + * Now "name" and "type" denote a new unique RRset + * affected by the update. + */ + + /* Don't sign RRSIGs. */ + if (type == dns_rdatatype_rrsig) + goto skip; + + /* + * Delete all old RRSIGs covering this type, since they + * are all invalid when the signed RRset has changed. + * We may not be able to recreate all of them - tough. + */ + CHECK(delete_if(true_p, db, newver, name, + dns_rdatatype_rrsig, type, + NULL, &sig_diff)); + + /* + * If this RRset still exists after the update, + * add a new signature for it. + */ + CHECK(rrset_exists(db, newver, name, type, 0, &flag)); + if (flag) { + CHECK(add_sigs(db, newver, name, type, + &sig_diff, zone_keys, nkeys, + client->mctx, inception, + expire)); + } + skip: + /* Skip any other updates to the same RRset. */ + while (t != NULL && + dns_name_equal(&t->name, name) && + t->rdata.type == type) + { + t = ISC_LIST_NEXT(t, link); + } + } + } + + /* Remove orphaned NSECs and RRSIG NSECs. */ + for (t = ISC_LIST_HEAD(diffnames.tuples); + t != NULL; + t = ISC_LIST_NEXT(t, link)) + { + CHECK(non_nsec_rrset_exists(db, newver, &t->name, &flag)); + if (! flag) { + CHECK(delete_if(true_p, db, newver, &t->name, + dns_rdatatype_any, 0, + NULL, &sig_diff)); + } + } + + /* + * When a name is created or deleted, its predecessor needs to + * have its NSEC updated. + */ + for (t = ISC_LIST_HEAD(diffnames.tuples); + t != NULL; + t = ISC_LIST_NEXT(t, link)) + { + isc_boolean_t existed, exists; + dns_fixedname_t fixedname; + dns_name_t *prevname; + + dns_fixedname_init(&fixedname); + prevname = dns_fixedname_name(&fixedname); + + CHECK(name_exists(db, oldver, &t->name, &existed)); + CHECK(name_exists(db, newver, &t->name, &exists)); + if (exists == existed) + continue; + + /* + * Find the predecessor. + * When names become obscured or unobscured in this update + * transaction, we may find the wrong predecessor because + * the NSECs have not yet been updated to reflect the delegation + * change. This should not matter because in this case, + * the correct predecessor is either the delegation node or + * a newly unobscured node, and those nodes are on the + * "affected" list in any case. + */ + CHECK(next_active(client, zone, db, newver, + &t->name, prevname, ISC_FALSE)); + CHECK(namelist_append_name(&affected, prevname)); + } + + /* + * Find names potentially affected by delegation changes + * (obscured by adding an NS or DNAME, or unobscured by + * removing one). + */ + for (t = ISC_LIST_HEAD(diffnames.tuples); + t != NULL; + t = ISC_LIST_NEXT(t, link)) + { + isc_boolean_t ns_existed, dname_existed; + isc_boolean_t ns_exists, dname_exists; + + CHECK(rrset_exists(db, oldver, &t->name, dns_rdatatype_ns, 0, + &ns_existed)); + CHECK(rrset_exists(db, oldver, &t->name, dns_rdatatype_dname, 0, + &dname_existed)); + CHECK(rrset_exists(db, newver, &t->name, dns_rdatatype_ns, 0, + &ns_exists)); + CHECK(rrset_exists(db, newver, &t->name, dns_rdatatype_dname, 0, + &dname_exists)); + if ((ns_exists || dname_exists) == (ns_existed || dname_existed)) + continue; + /* + * There was a delegation change. Mark all subdomains + * of t->name as potentially needing a NSEC update. + */ + CHECK(namelist_append_subdomain(db, &t->name, &affected)); + } + + ISC_LIST_APPENDLIST(affected.tuples, diffnames.tuples, link); + INSIST(ISC_LIST_EMPTY(diffnames.tuples)); + + CHECK(uniqify_name_list(&affected)); + + /* + * Determine which names should have NSECs, and delete/create + * NSECs to make it so. We don't know the final NSEC targets yet, + * so we just create placeholder NSECs with arbitrary contents + * to indicate that their respective owner names should be part of + * the NSEC chain. + */ + for (t = ISC_LIST_HEAD(affected.tuples); + t != NULL; + t = ISC_LIST_NEXT(t, link)) + { + isc_boolean_t exists; + CHECK(name_exists(db, newver, &t->name, &exists)); + if (! exists) + continue; + CHECK(is_glue(db, newver, &t->name, &flag)); + if (flag) { + /* + * This name is obscured. Delete any + * existing NSEC record. + */ + CHECK(delete_if(true_p, db, newver, &t->name, + dns_rdatatype_nsec, 0, + NULL, &nsec_diff)); + } else { + /* + * This name is not obscured. It should have a NSEC. + */ + CHECK(rrset_exists(db, newver, &t->name, + dns_rdatatype_nsec, 0, &flag)); + if (! flag) + CHECK(add_placeholder_nsec(db, newver, &t->name, + diff)); + } + } + + /* + * Now we know which names are part of the NSEC chain. + * Make them all point at their correct targets. + */ + for (t = ISC_LIST_HEAD(affected.tuples); + t != NULL; + t = ISC_LIST_NEXT(t, link)) + { + CHECK(rrset_exists(db, newver, &t->name, + dns_rdatatype_nsec, 0, &flag)); + if (flag) { + /* + * There is a NSEC, but we don't know if it is correct. + * Delete it and create a correct one to be sure. + * If the update was unnecessary, the diff minimization + * will take care of eliminating it from the journal, + * IXFRs, etc. + * + * The RRSIG bit should always be set in the NSECs + * we generate, because they will all get RRSIG NSECs. + * (XXX what if the zone keys are missing?). + * Because the RRSIG NSECs have not necessarily been + * created yet, the correctness of the bit mask relies + * on the assumption that NSECs are only created if + * there is other data, and if there is other data, + * there are other RRSIGs. + */ + CHECK(add_nsec(client, zone, db, newver, + &t->name, &nsec_diff)); + } + } + + /* + * Minimize the set of NSEC updates so that we don't + * have to regenerate the RRSIG NSECs for NSECs that were + * replaced with identical ones. + */ + while ((t = ISC_LIST_HEAD(nsec_diff.tuples)) != NULL) { + ISC_LIST_UNLINK(nsec_diff.tuples, t, link); + dns_diff_appendminimal(&nsec_mindiff, &t); + } + + /* Update RRSIG NSECs. */ + for (t = ISC_LIST_HEAD(nsec_mindiff.tuples); + t != NULL; + t = ISC_LIST_NEXT(t, link)) + { + if (t->op == DNS_DIFFOP_DEL) { + CHECK(delete_if(true_p, db, newver, &t->name, + dns_rdatatype_rrsig, dns_rdatatype_nsec, + NULL, &sig_diff)); + } else if (t->op == DNS_DIFFOP_ADD) { + CHECK(add_sigs(db, newver, &t->name, dns_rdatatype_nsec, + &sig_diff, zone_keys, nkeys, + client->mctx, inception, expire)); + } else { + INSIST(0); + } + } + + /* Record our changes for the journal. */ + while ((t = ISC_LIST_HEAD(sig_diff.tuples)) != NULL) { + ISC_LIST_UNLINK(sig_diff.tuples, t, link); + dns_diff_appendminimal(diff, &t); + } + while ((t = ISC_LIST_HEAD(nsec_mindiff.tuples)) != NULL) { + ISC_LIST_UNLINK(nsec_mindiff.tuples, t, link); + dns_diff_appendminimal(diff, &t); + } + + INSIST(ISC_LIST_EMPTY(sig_diff.tuples)); + INSIST(ISC_LIST_EMPTY(nsec_diff.tuples)); + INSIST(ISC_LIST_EMPTY(nsec_mindiff.tuples)); + + failure: + dns_diff_clear(&sig_diff); + dns_diff_clear(&nsec_diff); + dns_diff_clear(&nsec_mindiff); + + dns_diff_clear(&affected); + dns_diff_clear(&diffnames); + + for (i = 0; i < nkeys; i++) + dst_key_free(&zone_keys[i]); + + return (result); +} + + +/**************************************************************************/ +/* + * The actual update code in all its glory. We try to follow + * the RFC2136 pseudocode as closely as possible. + */ + +static isc_result_t +send_update_event(ns_client_t *client, dns_zone_t *zone) { + isc_result_t result = ISC_R_SUCCESS; + update_event_t *event = NULL; + isc_task_t *zonetask = NULL; + ns_client_t *evclient; + + event = (update_event_t *) + isc_event_allocate(client->mctx, client, DNS_EVENT_UPDATE, + update_action, NULL, sizeof(*event)); + if (event == NULL) + FAIL(ISC_R_NOMEMORY); + event->zone = zone; + event->result = ISC_R_SUCCESS; + + evclient = NULL; + ns_client_attach(client, &evclient); + INSIST(client->nupdates == 0); + client->nupdates++; + event->ev_arg = evclient; + + dns_zone_gettask(zone, &zonetask); + isc_task_send(zonetask, ISC_EVENT_PTR(&event)); + + failure: + if (event != NULL) + isc_event_free(ISC_EVENT_PTR(&event)); + return (result); +} + +static void +respond(ns_client_t *client, isc_result_t result) { + isc_result_t msg_result; + + msg_result = dns_message_reply(client->message, ISC_TRUE); + if (msg_result != ISC_R_SUCCESS) + goto msg_failure; + client->message->rcode = dns_result_torcode(result); + + ns_client_send(client); + return; + + msg_failure: + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_UPDATE, NS_LOGMODULE_UPDATE, + ISC_LOG_ERROR, + "could not create update response message: %s", + isc_result_totext(msg_result)); + ns_client_next(client, msg_result); +} + +void +ns_update_start(ns_client_t *client, isc_result_t sigresult) { + dns_message_t *request = client->message; + isc_result_t result; + dns_name_t *zonename; + dns_rdataset_t *zone_rdataset; + dns_zone_t *zone = NULL; + + /* + * Interpret the zone section. + */ + result = dns_message_firstname(request, DNS_SECTION_ZONE); + if (result != ISC_R_SUCCESS) + FAILC(DNS_R_FORMERR, + "update zone section empty"); + + /* + * The zone section must contain exactly one "question", and + * it must be of type SOA. + */ + zonename = NULL; + dns_message_currentname(request, DNS_SECTION_ZONE, &zonename); + zone_rdataset = ISC_LIST_HEAD(zonename->list); + if (zone_rdataset->type != dns_rdatatype_soa) + FAILC(DNS_R_FORMERR, + "update zone section contains non-SOA"); + if (ISC_LIST_NEXT(zone_rdataset, link) != NULL) + FAILC(DNS_R_FORMERR, + "update zone section contains multiple RRs"); + + /* The zone section must have exactly one name. */ + result = dns_message_nextname(request, DNS_SECTION_ZONE); + if (result != ISC_R_NOMORE) + FAILC(DNS_R_FORMERR, + "update zone section contains multiple RRs"); + + result = dns_zt_find(client->view->zonetable, zonename, 0, NULL, + &zone); + if (result != ISC_R_SUCCESS) + FAILC(DNS_R_NOTAUTH, + "not authoritative for update zone"); + + switch(dns_zone_gettype(zone)) { + case dns_zone_master: + /* + * We can now fail due to a bad signature as we now know + * that we are the master. + */ + if (sigresult != ISC_R_SUCCESS) + FAIL(sigresult); + CHECK(send_update_event(client, zone)); + break; + case dns_zone_slave: + CHECK(checkupdateacl(client, dns_zone_getforwardacl(zone), + "update forwarding", zonename, ISC_TRUE)); + CHECK(send_forward_event(client, zone)); + break; + default: + FAILC(DNS_R_NOTAUTH, + "not authoritative for update zone"); + } + return; + + failure: + /* + * We failed without having sent an update event to the zone. + * We are still in the client task context, so we can + * simply give an error response without switching tasks. + */ + respond(client, result); + if (zone != NULL) + dns_zone_detach(&zone); +} + +/* + * DS records are not allowed to exist without corresponding NS records, + * draft-ietf-dnsext-delegation-signer-11.txt, 2.2 Protocol Change, + * "DS RRsets MUST NOT appear at non-delegation points or at a zone's apex". + */ + +static isc_result_t +remove_orphaned_ds(dns_db_t *db, dns_dbversion_t *newver, dns_diff_t *diff) { + isc_result_t result; + isc_boolean_t ns_exists, ds_exists; + dns_difftuple_t *t; + + for (t = ISC_LIST_HEAD(diff->tuples); + t != NULL; + t = ISC_LIST_NEXT(t, link)) { + if (t->op != DNS_DIFFOP_DEL || + t->rdata.type != dns_rdatatype_ns) + continue; + CHECK(rrset_exists(db, newver, &t->name, dns_rdatatype_ns, 0, + &ns_exists)); + if (ns_exists) + continue; + CHECK(rrset_exists(db, newver, &t->name, dns_rdatatype_ds, 0, + &ds_exists)); + if (!ds_exists) + continue; + CHECK(delete_if(true_p, db, newver, &t->name, + dns_rdatatype_ds, 0, NULL, diff)); + } + return (ISC_R_SUCCESS); + + failure: + return (result); +} + +static void +update_action(isc_task_t *task, isc_event_t *event) { + update_event_t *uev = (update_event_t *) event; + dns_zone_t *zone = uev->zone; + ns_client_t *client = (ns_client_t *)event->ev_arg; + + isc_result_t result; + dns_db_t *db = NULL; + dns_dbversion_t *oldver = NULL; + dns_dbversion_t *ver = NULL; + dns_diff_t diff; /* Pending updates. */ + dns_diff_t temp; /* Pending RR existence assertions. */ + isc_boolean_t soa_serial_changed = ISC_FALSE; + isc_mem_t *mctx = client->mctx; + dns_rdatatype_t covers; + dns_message_t *request = client->message; + dns_rdataclass_t zoneclass; + dns_name_t *zonename; + dns_ssutable_t *ssutable = NULL; + dns_fixedname_t tmpnamefixed; + dns_name_t *tmpname = NULL; + + INSIST(event->ev_type == DNS_EVENT_UPDATE); + + dns_diff_init(mctx, &diff); + dns_diff_init(mctx, &temp); + + CHECK(dns_zone_getdb(zone, &db)); + zonename = dns_db_origin(db); + zoneclass = dns_db_class(db); + dns_zone_getssutable(zone, &ssutable); + dns_db_currentversion(db, &oldver); + CHECK(dns_db_newversion(db, &ver)); + + /* + * Check prerequisites. + */ + + for (result = dns_message_firstname(request, DNS_SECTION_PREREQUISITE); + result == ISC_R_SUCCESS; + result = dns_message_nextname(request, DNS_SECTION_PREREQUISITE)) + { + dns_name_t *name = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_ttl_t ttl; + dns_rdataclass_t update_class; + isc_boolean_t flag; + + get_current_rr(request, DNS_SECTION_PREREQUISITE, zoneclass, + &name, &rdata, &covers, &ttl, &update_class); + + if (ttl != 0) + FAILC(DNS_R_FORMERR, "prerequisite TTL is not zero"); + + if (! dns_name_issubdomain(name, zonename)) + FAILN(DNS_R_NOTZONE, name, + "prerequisite name is out of zone"); + + if (update_class == dns_rdataclass_any) { + if (rdata.length != 0) + FAILC(DNS_R_FORMERR, + "class ANY prerequisite " + "RDATA is not empty"); + if (rdata.type == dns_rdatatype_any) { + CHECK(name_exists(db, ver, name, &flag)); + if (! flag) { + FAILN(DNS_R_NXDOMAIN, name, + "'name in use' prerequisite " + "not satisfied"); + } + } else { + CHECK(rrset_exists(db, ver, name, + rdata.type, covers, &flag)); + if (! flag) { + /* RRset does not exist. */ + FAILNT(DNS_R_NXRRSET, name, rdata.type, + "'rrset exists (value independent)' " + "prerequisite not satisfied"); + } + } + } else if (update_class == dns_rdataclass_none) { + if (rdata.length != 0) + FAILC(DNS_R_FORMERR, + "class NONE prerequisite " + "RDATA is not empty"); + if (rdata.type == dns_rdatatype_any) { + CHECK(name_exists(db, ver, name, &flag)); + if (flag) { + FAILN(DNS_R_YXDOMAIN, name, + "'name not in use' prerequisite " + "not satisfied"); + } + } else { + CHECK(rrset_exists(db, ver, name, + rdata.type, covers, &flag)); + if (flag) { + /* RRset exists. */ + FAILNT(DNS_R_YXRRSET, name, rdata.type, + "'rrset does not exist' " + "prerequisite not satisfied"); + } + } + } else if (update_class == zoneclass) { + /* "temp += rr;" */ + result = temp_append(&temp, name, &rdata); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "temp entry creation failed: %s", + dns_result_totext(result)); + FAIL(ISC_R_UNEXPECTED); + } + } else { + FAILC(DNS_R_FORMERR, "malformed prerequisite"); + } + } + if (result != ISC_R_NOMORE) + FAIL(result); + + + /* + * Perform the final check of the "rrset exists (value dependent)" + * prerequisites. + */ + if (ISC_LIST_HEAD(temp.tuples) != NULL) { + dns_rdatatype_t type; + + /* + * Sort the prerequisite records by owner name, + * type, and rdata. + */ + result = dns_diff_sort(&temp, temp_order); + if (result != ISC_R_SUCCESS) + FAILC(result, "'RRset exists (value dependent)' " + "prerequisite not satisfied"); + + dns_fixedname_init(&tmpnamefixed); + tmpname = dns_fixedname_name(&tmpnamefixed); + result = temp_check(mctx, &temp, db, ver, tmpname, &type); + if (result != ISC_R_SUCCESS) + FAILNT(result, tmpname, type, + "'RRset exists (value dependent)' " + "prerequisite not satisfied"); + } + + update_log(client, zone, LOGLEVEL_DEBUG, + "prerequisites are OK"); + + /* + * Check Requestor's Permissions. It seems a bit silly to do this + * only after prerequisite testing, but that is what RFC2136 says. + */ + result = ISC_R_SUCCESS; + if (ssutable == NULL) + CHECK(checkupdateacl(client, dns_zone_getupdateacl(zone), + "update", zonename, ISC_FALSE)); + else if (client->signer == NULL) + CHECK(checkupdateacl(client, NULL, "update", zonename, + ISC_FALSE)); + + if (dns_zone_getupdatedisabled(zone)) + FAILC(DNS_R_REFUSED, "dynamic update temporarily disabled"); + + /* + * Perform the Update Section Prescan. + */ + + for (result = dns_message_firstname(request, DNS_SECTION_UPDATE); + result == ISC_R_SUCCESS; + result = dns_message_nextname(request, DNS_SECTION_UPDATE)) + { + dns_name_t *name = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_ttl_t ttl; + dns_rdataclass_t update_class; + get_current_rr(request, DNS_SECTION_UPDATE, zoneclass, + &name, &rdata, &covers, &ttl, &update_class); + + if (! dns_name_issubdomain(name, zonename)) + FAILC(DNS_R_NOTZONE, + "update RR is outside zone"); + if (update_class == zoneclass) { + /* + * Check for meta-RRs. The RFC2136 pseudocode says + * check for ANY|AXFR|MAILA|MAILB, but the text adds + * "or any other QUERY metatype" + */ + if (dns_rdatatype_ismeta(rdata.type)) { + FAILC(DNS_R_FORMERR, + "meta-RR in update"); + } + result = dns_zone_checknames(zone, name, &rdata); + if (result != ISC_R_SUCCESS) + FAIL(DNS_R_REFUSED); + } else if (update_class == dns_rdataclass_any) { + if (ttl != 0 || rdata.length != 0 || + (dns_rdatatype_ismeta(rdata.type) && + rdata.type != dns_rdatatype_any)) + FAILC(DNS_R_FORMERR, + "meta-RR in update"); + } else if (update_class == dns_rdataclass_none) { + if (ttl != 0 || + dns_rdatatype_ismeta(rdata.type)) + FAILC(DNS_R_FORMERR, + "meta-RR in update"); + } else { + update_log(client, zone, ISC_LOG_WARNING, + "update RR has incorrect class %d", + update_class); + FAIL(DNS_R_FORMERR); + } + /* + * draft-ietf-dnsind-simple-secure-update-01 says + * "Unlike traditional dynamic update, the client + * is forbidden from updating NSEC records." + */ + if (dns_db_issecure(db)) { + if (rdata.type == dns_rdatatype_nsec) { + FAILC(DNS_R_REFUSED, + "explicit NSEC updates are not allowed " + "in secure zones"); + } + else if (rdata.type == dns_rdatatype_rrsig) { + FAILC(DNS_R_REFUSED, + "explicit RRSIG updates are currently not " + "supported in secure zones"); + } + } + + if (ssutable != NULL && client->signer != NULL) { + if (rdata.type != dns_rdatatype_any) { + if (!dns_ssutable_checkrules(ssutable, + client->signer, + name, rdata.type)) + FAILC(DNS_R_REFUSED, + "rejected by secure update"); + } + else { + if (!ssu_checkall(db, ver, name, ssutable, + client->signer)) + FAILC(DNS_R_REFUSED, + "rejected by secure update"); + } + } + } + if (result != ISC_R_NOMORE) + FAIL(result); + + update_log(client, zone, LOGLEVEL_DEBUG, + "update section prescan OK"); + + /* + * Process the Update Section. + */ + + for (result = dns_message_firstname(request, DNS_SECTION_UPDATE); + result == ISC_R_SUCCESS; + result = dns_message_nextname(request, DNS_SECTION_UPDATE)) + { + dns_name_t *name = NULL; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_ttl_t ttl; + dns_rdataclass_t update_class; + isc_boolean_t flag; + + get_current_rr(request, DNS_SECTION_UPDATE, zoneclass, + &name, &rdata, &covers, &ttl, &update_class); + + if (update_class == zoneclass) { + + /* + * RFC 1123 doesn't allow MF and MD in master zones. */ + if (rdata.type == dns_rdatatype_md || + rdata.type == dns_rdatatype_mf) { + char typebuf[DNS_RDATATYPE_FORMATSIZE]; + + dns_rdatatype_format(rdata.type, typebuf, + sizeof(typebuf)); + update_log(client, zone, LOGLEVEL_PROTOCOL, + "attempt to add %s ignored", + typebuf); + continue; + } + if (rdata.type == dns_rdatatype_ns && + dns_name_iswildcard(name)) { + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "attempt to add wildcard NS record" + "ignored"); + continue; + } + if (rdata.type == dns_rdatatype_cname) { + CHECK(cname_incompatible_rrset_exists(db, ver, + name, + &flag)); + if (flag) { + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "attempt to add CNAME " + "alongside non-CNAME " + "ignored"); + continue; + } + } else { + CHECK(rrset_exists(db, ver, name, + dns_rdatatype_cname, 0, + &flag)); + if (flag && + ! dns_rdatatype_isdnssec(rdata.type)) + { + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "attempt to add non-CNAME " + "alongside CNAME ignored"); + continue; + } + } + if (rdata.type == dns_rdatatype_soa) { + isc_boolean_t ok; + CHECK(rrset_exists(db, ver, name, + dns_rdatatype_soa, 0, + &flag)); + if (! flag) { + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "attempt to create 2nd " + "SOA ignored"); + continue; + } + CHECK(check_soa_increment(db, ver, &rdata, + &ok)); + if (! ok) { + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "SOA update failed to " + "increment serial, " + "ignoring it"); + continue; + } + soa_serial_changed = ISC_TRUE; + } + + if (isc_log_wouldlog(ns_g_lctx, LOGLEVEL_PROTOCOL)) { + char namestr[DNS_NAME_FORMATSIZE]; + char typestr[DNS_RDATATYPE_FORMATSIZE]; + dns_name_format(name, namestr, + sizeof(namestr)); + dns_rdatatype_format(rdata.type, typestr, + sizeof(typestr)); + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "adding an RR at '%s' %s", + namestr, typestr); + } + + /* Prepare the affected RRset for the addition. */ + { + add_rr_prepare_ctx_t ctx; + ctx.db = db; + ctx.ver = ver; + ctx.diff = &diff; + ctx.name = name; + ctx.update_rr = &rdata; + ctx.update_rr_ttl = ttl; + ctx.ignore_add = ISC_FALSE; + dns_diff_init(mctx, &ctx.del_diff); + dns_diff_init(mctx, &ctx.add_diff); + CHECK(foreach_rr(db, ver, name, rdata.type, + covers, add_rr_prepare_action, + &ctx)); + + if (ctx.ignore_add) { + dns_diff_clear(&ctx.del_diff); + dns_diff_clear(&ctx.add_diff); + } else { + CHECK(do_diff(&ctx.del_diff, db, ver, &diff)); + CHECK(do_diff(&ctx.add_diff, db, ver, &diff)); + CHECK(update_one_rr(db, ver, &diff, + DNS_DIFFOP_ADD, + name, ttl, &rdata)); + } + } + } else if (update_class == dns_rdataclass_any) { + if (rdata.type == dns_rdatatype_any) { + if (isc_log_wouldlog(ns_g_lctx, + LOGLEVEL_PROTOCOL)) + { + char namestr[DNS_NAME_FORMATSIZE]; + dns_name_format(name, namestr, + sizeof(namestr)); + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "delete all rrsets from " + "name '%s'", namestr); + } + if (dns_name_equal(name, zonename)) { + CHECK(delete_if(type_not_soa_nor_ns_p, + db, ver, name, + dns_rdatatype_any, 0, + &rdata, &diff)); + } else { + CHECK(delete_if(true_p, db, ver, name, + dns_rdatatype_any, 0, + &rdata, &diff)); + } + } else if (dns_name_equal(name, zonename) && + (rdata.type == dns_rdatatype_soa || + rdata.type == dns_rdatatype_ns)) { + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "attempt to delete all SOA " + "or NS records ignored"); + continue; + } else { + if (isc_log_wouldlog(ns_g_lctx, + LOGLEVEL_PROTOCOL)) + { + char namestr[DNS_NAME_FORMATSIZE]; + char typestr[DNS_RDATATYPE_FORMATSIZE]; + dns_name_format(name, namestr, + sizeof(namestr)); + dns_rdatatype_format(rdata.type, + typestr, + sizeof(typestr)); + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "deleting rrset at '%s' %s", + namestr, typestr); + } + CHECK(delete_if(true_p, db, ver, name, + rdata.type, covers, &rdata, + &diff)); + } + } else if (update_class == dns_rdataclass_none) { + /* + * The (name == zonename) condition appears in + * RFC2136 3.4.2.4 but is missing from the pseudocode. + */ + if (dns_name_equal(name, zonename)) { + if (rdata.type == dns_rdatatype_soa) { + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "attempt to delete SOA " + "ignored"); + continue; + } + if (rdata.type == dns_rdatatype_ns) { + int count; + CHECK(rr_count(db, ver, name, + dns_rdatatype_ns, + 0, &count)); + if (count == 1) { + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "attempt to " + "delete last " + "NS ignored"); + continue; + } + } + } + update_log(client, zone, + LOGLEVEL_PROTOCOL, + "deleting an RR"); + CHECK(delete_if(rr_equal_p, db, ver, name, + rdata.type, covers, &rdata, &diff)); + } + } + if (result != ISC_R_NOMORE) + FAIL(result); + + /* + * If any changes were made, increment the SOA serial number, + * update RRSIGs and NSECs (if zone is secure), and write the update + * to the journal. + */ + if (! ISC_LIST_EMPTY(diff.tuples)) { + char *journalfile; + dns_journal_t *journal; + + /* + * Increment the SOA serial, but only if it was not + * changed as a result of an update operation. + */ + if (! soa_serial_changed) { + CHECK(increment_soa_serial(db, ver, &diff, mctx)); + } + + CHECK(remove_orphaned_ds(db, ver, &diff)); + + if (dns_db_issecure(db)) { + result = update_signatures(client, zone, db, oldver, + ver, &diff, + dns_zone_getsigvalidityinterval(zone)); + if (result != ISC_R_SUCCESS) { + update_log(client, zone, + ISC_LOG_ERROR, + "RRSIG/NSEC update failed: %s", + isc_result_totext(result)); + goto failure; + } + } + + journalfile = dns_zone_getjournal(zone); + if (journalfile != NULL) { + update_log(client, zone, LOGLEVEL_DEBUG, + "writing journal %s", journalfile); + + journal = NULL; + result = dns_journal_open(mctx, journalfile, + ISC_TRUE, &journal); + if (result != ISC_R_SUCCESS) + FAILS(result, "journal open failed"); + + result = dns_journal_write_transaction(journal, &diff); + if (result != ISC_R_SUCCESS) { + dns_journal_destroy(&journal); + FAILS(result, "journal write failed"); + } + + dns_journal_destroy(&journal); + } + + /* + * XXXRTH Just a note that this committing code will have + * to change to handle databases that need two-phase + * commit, but this isn't a priority. + */ + update_log(client, zone, LOGLEVEL_DEBUG, + "committing update transaction"); + dns_db_closeversion(db, &ver, ISC_TRUE); + + /* + * Mark the zone as dirty so that it will be written to disk. + */ + dns_zone_markdirty(zone); + + /* + * Notify slaves of the change we just made. + */ + dns_zone_notify(zone); + } else { + update_log(client, zone, LOGLEVEL_DEBUG, "redundant request"); + dns_db_closeversion(db, &ver, ISC_TRUE); + } + result = ISC_R_SUCCESS; + goto common; + + failure: + /* + * The reason for failure should have been logged at this point. + */ + if (ver != NULL) { + update_log(client, zone, LOGLEVEL_DEBUG, + "rolling back"); + dns_db_closeversion(db, &ver, ISC_FALSE); + } + + common: + dns_diff_clear(&temp); + dns_diff_clear(&diff); + + if (oldver != NULL) + dns_db_closeversion(db, &oldver, ISC_FALSE); + + if (db != NULL) + dns_db_detach(&db); + + if (ssutable != NULL) + dns_ssutable_detach(&ssutable); + + if (zone != NULL) + dns_zone_detach(&zone); + + isc_task_detach(&task); + uev->result = result; + uev->ev_type = DNS_EVENT_UPDATEDONE; + uev->ev_action = updatedone_action; + isc_task_send(client->task, &event); + INSIST(event == NULL); +} + +static void +updatedone_action(isc_task_t *task, isc_event_t *event) { + update_event_t *uev = (update_event_t *) event; + ns_client_t *client = (ns_client_t *) event->ev_arg; + + UNUSED(task); + + INSIST(event->ev_type == DNS_EVENT_UPDATEDONE); + INSIST(task == client->task); + + INSIST(client->nupdates > 0); + client->nupdates--; + respond(client, uev->result); + ns_client_detach(&client); + isc_event_free(&event); +} + +/* + * Update forwarding support. + */ + +static void +forward_fail(isc_task_t *task, isc_event_t *event) { + ns_client_t *client = (ns_client_t *)event->ev_arg; + + UNUSED(task); + + INSIST(client->nupdates > 0); + client->nupdates--; + respond(client, DNS_R_SERVFAIL); + ns_client_detach(&client); + isc_event_free(&event); +} + + +static void +forward_callback(void *arg, isc_result_t result, dns_message_t *answer) { + update_event_t *uev = arg; + ns_client_t *client = uev->ev_arg; + + if (result != ISC_R_SUCCESS) { + INSIST(answer == NULL); + uev->ev_type = DNS_EVENT_UPDATEDONE; + uev->ev_action = forward_fail; + } else { + uev->ev_type = DNS_EVENT_UPDATEDONE; + uev->ev_action = forward_done; + uev->answer = answer; + } + isc_task_send(client->task, ISC_EVENT_PTR(&uev)); +} + +static void +forward_done(isc_task_t *task, isc_event_t *event) { + update_event_t *uev = (update_event_t *) event; + ns_client_t *client = (ns_client_t *)event->ev_arg; + + UNUSED(task); + + INSIST(client->nupdates > 0); + client->nupdates--; + ns_client_sendraw(client, uev->answer); + dns_message_destroy(&uev->answer); + isc_event_free(&event); + ns_client_detach(&client); +} + +static void +forward_action(isc_task_t *task, isc_event_t *event) { + update_event_t *uev = (update_event_t *) event; + dns_zone_t *zone = uev->zone; + ns_client_t *client = (ns_client_t *)event->ev_arg; + isc_result_t result; + + result = dns_zone_forwardupdate(zone, client->message, + forward_callback, event); + if (result != ISC_R_SUCCESS) { + uev->ev_type = DNS_EVENT_UPDATEDONE; + uev->ev_action = forward_fail; + isc_task_send(client->task, &event); + } + dns_zone_detach(&zone); + isc_task_detach(&task); +} + +static isc_result_t +send_forward_event(ns_client_t *client, dns_zone_t *zone) { + isc_result_t result = ISC_R_SUCCESS; + update_event_t *event = NULL; + isc_task_t *zonetask = NULL; + ns_client_t *evclient; + + event = (update_event_t *) + isc_event_allocate(client->mctx, client, DNS_EVENT_UPDATE, + forward_action, NULL, sizeof(*event)); + if (event == NULL) + FAIL(ISC_R_NOMEMORY); + event->zone = zone; + event->result = ISC_R_SUCCESS; + + evclient = NULL; + ns_client_attach(client, &evclient); + INSIST(client->nupdates == 0); + client->nupdates++; + event->ev_arg = evclient; + + dns_zone_gettask(zone, &zonetask); + isc_task_send(zonetask, ISC_EVENT_PTR(&event)); + + failure: + if (event != NULL) + isc_event_free(ISC_EVENT_PTR(&event)); + return (result); +} diff --git a/contrib/bind9/bin/named/xfrout.c b/contrib/bind9/bin/named/xfrout.c new file mode 100644 index 000000000000..9fb2697a45d6 --- /dev/null +++ b/contrib/bind9/bin/named/xfrout.c @@ -0,0 +1,1718 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: xfrout.c,v 1.101.2.5.2.10 2004/04/02 06:08:17 marka Exp $ */ + +#include + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +/* + * Outgoing AXFR and IXFR. + */ + +/* + * TODO: + * - IXFR over UDP + */ + +#define XFROUT_COMMON_LOGARGS \ + ns_g_lctx, DNS_LOGCATEGORY_XFER_OUT, NS_LOGMODULE_XFER_OUT + +#define XFROUT_PROTOCOL_LOGARGS \ + XFROUT_COMMON_LOGARGS, ISC_LOG_INFO + +#define XFROUT_DEBUG_LOGARGS(n) \ + XFROUT_COMMON_LOGARGS, ISC_LOG_DEBUG(n) + +#define XFROUT_RR_LOGARGS \ + XFROUT_COMMON_LOGARGS, XFROUT_RR_LOGLEVEL + +#define XFROUT_RR_LOGLEVEL ISC_LOG_DEBUG(8) + +/* + * Fail unconditionally and log as a client error. + * The test against ISC_R_SUCCESS is there to keep the Solaris compiler + * from complaining about "end-of-loop code not reached". + */ +#define FAILC(code, msg) \ + do { \ + result = (code); \ + ns_client_log(client, DNS_LOGCATEGORY_XFER_OUT, \ + NS_LOGMODULE_XFER_OUT, ISC_LOG_INFO, \ + "bad zone transfer request: %s (%s)", \ + msg, isc_result_totext(code)); \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) + +#define FAILQ(code, msg, question, rdclass) \ + do { \ + char _buf1[DNS_NAME_FORMATSIZE]; \ + char _buf2[DNS_RDATACLASS_FORMATSIZE]; \ + result = (code); \ + dns_name_format(question, _buf1, sizeof(_buf1)); \ + dns_rdataclass_format(rdclass, _buf2, sizeof(_buf2)); \ + ns_client_log(client, DNS_LOGCATEGORY_XFER_OUT, \ + NS_LOGMODULE_XFER_OUT, ISC_LOG_INFO, \ + "bad zone transfer request: '%s/%s': %s (%s)", \ + _buf1, _buf2, msg, isc_result_totext(code)); \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) + +#define CHECK(op) \ + do { result = (op); \ + if (result != ISC_R_SUCCESS) goto failure; \ + } while (0) + +/**************************************************************************/ +/* + * A db_rr_iterator_t is an iterator that iterates over an entire database, + * returning one RR at a time, in some arbitrary order. + */ + +typedef struct db_rr_iterator db_rr_iterator_t; + +struct db_rr_iterator { + isc_result_t result; + dns_db_t *db; + dns_dbiterator_t *dbit; + dns_dbversion_t *ver; + isc_stdtime_t now; + dns_dbnode_t *node; + dns_fixedname_t fixedname; + dns_rdatasetiter_t *rdatasetit; + dns_rdataset_t rdataset; + dns_rdata_t rdata; +}; + +static isc_result_t +db_rr_iterator_init(db_rr_iterator_t *it, dns_db_t *db, dns_dbversion_t *ver, + isc_stdtime_t now); + +static isc_result_t +db_rr_iterator_first(db_rr_iterator_t *it); + +static isc_result_t +db_rr_iterator_next(db_rr_iterator_t *it); + +static void +db_rr_iterator_current(db_rr_iterator_t *it, dns_name_t **name, + isc_uint32_t *ttl, dns_rdata_t **rdata); + +static void +db_rr_iterator_destroy(db_rr_iterator_t *it); + +static isc_result_t +db_rr_iterator_init(db_rr_iterator_t *it, dns_db_t *db, dns_dbversion_t *ver, + isc_stdtime_t now) +{ + isc_result_t result; + it->db = db; + it->dbit = NULL; + it->ver = ver; + it->now = now; + it->node = NULL; + result = dns_db_createiterator(it->db, ISC_FALSE, &it->dbit); + if (result != ISC_R_SUCCESS) + return (result); + it->rdatasetit = NULL; + dns_rdata_init(&it->rdata); + dns_rdataset_init(&it->rdataset); + dns_fixedname_init(&it->fixedname); + INSIST(! dns_rdataset_isassociated(&it->rdataset)); + it->result = ISC_R_SUCCESS; + return (it->result); +} + +static isc_result_t +db_rr_iterator_first(db_rr_iterator_t *it) { + it->result = dns_dbiterator_first(it->dbit); + /* + * The top node may be empty when out of zone glue exists. + * Walk the tree to find the first node with data. + */ + while (it->result == ISC_R_SUCCESS) { + it->result = dns_dbiterator_current(it->dbit, &it->node, + dns_fixedname_name(&it->fixedname)); + if (it->result != ISC_R_SUCCESS) + return (it->result); + + it->result = dns_db_allrdatasets(it->db, it->node, + it->ver, it->now, + &it->rdatasetit); + if (it->result != ISC_R_SUCCESS) + return (it->result); + + it->result = dns_rdatasetiter_first(it->rdatasetit); + if (it->result != ISC_R_SUCCESS) { + /* + * This node is empty. Try next node. + */ + dns_rdatasetiter_destroy(&it->rdatasetit); + dns_db_detachnode(it->db, &it->node); + it->result = dns_dbiterator_next(it->dbit); + continue; + } + dns_rdatasetiter_current(it->rdatasetit, &it->rdataset); + + it->result = dns_rdataset_first(&it->rdataset); + return (it->result); + } + return (it->result); +} + + +static isc_result_t +db_rr_iterator_next(db_rr_iterator_t *it) { + if (it->result != ISC_R_SUCCESS) + return (it->result); + + INSIST(it->dbit != NULL); + INSIST(it->node != NULL); + INSIST(it->rdatasetit != NULL); + + it->result = dns_rdataset_next(&it->rdataset); + if (it->result == ISC_R_NOMORE) { + dns_rdataset_disassociate(&it->rdataset); + it->result = dns_rdatasetiter_next(it->rdatasetit); + /* + * The while loop body is executed more than once + * only when an empty dbnode needs to be skipped. + */ + while (it->result == ISC_R_NOMORE) { + dns_rdatasetiter_destroy(&it->rdatasetit); + dns_db_detachnode(it->db, &it->node); + it->result = dns_dbiterator_next(it->dbit); + if (it->result == ISC_R_NOMORE) { + /* We are at the end of the entire database. */ + return (it->result); + } + if (it->result != ISC_R_SUCCESS) + return (it->result); + it->result = dns_dbiterator_current(it->dbit, + &it->node, + dns_fixedname_name(&it->fixedname)); + if (it->result != ISC_R_SUCCESS) + return (it->result); + it->result = dns_db_allrdatasets(it->db, it->node, + it->ver, it->now, + &it->rdatasetit); + if (it->result != ISC_R_SUCCESS) + return (it->result); + it->result = dns_rdatasetiter_first(it->rdatasetit); + } + if (it->result != ISC_R_SUCCESS) + return (it->result); + dns_rdatasetiter_current(it->rdatasetit, &it->rdataset); + it->result = dns_rdataset_first(&it->rdataset); + if (it->result != ISC_R_SUCCESS) + return (it->result); + } + return (it->result); +} + +static void +db_rr_iterator_pause(db_rr_iterator_t *it) { + RUNTIME_CHECK(dns_dbiterator_pause(it->dbit) == ISC_R_SUCCESS); +} + +static void +db_rr_iterator_destroy(db_rr_iterator_t *it) { + if (dns_rdataset_isassociated(&it->rdataset)) + dns_rdataset_disassociate(&it->rdataset); + if (it->rdatasetit != NULL) + dns_rdatasetiter_destroy(&it->rdatasetit); + if (it->node != NULL) + dns_db_detachnode(it->db, &it->node); + dns_dbiterator_destroy(&it->dbit); +} + +static void +db_rr_iterator_current(db_rr_iterator_t *it, dns_name_t **name, + isc_uint32_t *ttl, dns_rdata_t **rdata) +{ + REQUIRE(name != NULL && *name == NULL); + REQUIRE(it->result == ISC_R_SUCCESS); + *name = dns_fixedname_name(&it->fixedname); + *ttl = it->rdataset.ttl; + dns_rdata_reset(&it->rdata); + dns_rdataset_current(&it->rdataset, &it->rdata); + *rdata = &it->rdata; +} + +/**************************************************************************/ + +/* Log an RR (for debugging) */ + +static void +log_rr(dns_name_t *name, dns_rdata_t *rdata, isc_uint32_t ttl) { + isc_result_t result; + isc_buffer_t buf; + char mem[2000]; + dns_rdatalist_t rdl; + dns_rdataset_t rds; + dns_rdata_t rd = DNS_RDATA_INIT; + + rdl.type = rdata->type; + rdl.rdclass = rdata->rdclass; + rdl.ttl = ttl; + ISC_LIST_INIT(rdl.rdata); + ISC_LINK_INIT(&rdl, link); + dns_rdataset_init(&rds); + dns_rdata_init(&rd); + dns_rdata_clone(rdata, &rd); + ISC_LIST_APPEND(rdl.rdata, &rd, link); + RUNTIME_CHECK(dns_rdatalist_tordataset(&rdl, &rds) == ISC_R_SUCCESS); + + isc_buffer_init(&buf, mem, sizeof(mem)); + result = dns_rdataset_totext(&rds, name, + ISC_FALSE, ISC_FALSE, &buf); + + /* + * We could use xfrout_log(), but that would produce + * very long lines with a repetitive prefix. + */ + if (result == ISC_R_SUCCESS) { + /* + * Get rid of final newline. + */ + INSIST(buf.used >= 1 && + ((char *) buf.base)[buf.used - 1] == '\n'); + buf.used--; + + isc_log_write(XFROUT_RR_LOGARGS, "%.*s", + (int)isc_buffer_usedlength(&buf), + (char *)isc_buffer_base(&buf)); + } else { + isc_log_write(XFROUT_RR_LOGARGS, ""); + } +} + +/**************************************************************************/ +/* + * An 'rrstream_t' is a polymorphic iterator that returns + * a stream of resource records. There are multiple implementations, + * e.g. for generating AXFR and IXFR records streams. + */ + +typedef struct rrstream_methods rrstream_methods_t; + +typedef struct rrstream { + isc_mem_t *mctx; + rrstream_methods_t *methods; +} rrstream_t; + +struct rrstream_methods { + isc_result_t (*first)(rrstream_t *); + isc_result_t (*next)(rrstream_t *); + void (*current)(rrstream_t *, + dns_name_t **, + isc_uint32_t *, + dns_rdata_t **); + void (*pause)(rrstream_t *); + void (*destroy)(rrstream_t **); +}; + +static void +rrstream_noop_pause(rrstream_t *rs) { + UNUSED(rs); +} + +/**************************************************************************/ +/* + * An 'ixfr_rrstream_t' is an 'rrstream_t' that returns + * an IXFR-like RR stream from a journal file. + * + * The SOA at the beginning of each sequence of additions + * or deletions are included in the stream, but the extra + * SOAs at the beginning and end of the entire transfer are + * not included. + */ + +typedef struct ixfr_rrstream { + rrstream_t common; + dns_journal_t *journal; +} ixfr_rrstream_t; + +/* Forward declarations. */ +static void +ixfr_rrstream_destroy(rrstream_t **sp); + +static rrstream_methods_t ixfr_rrstream_methods; + +/* + * Returns: anything dns_journal_open() or dns_journal_iter_init() + * may return. + */ + +static isc_result_t +ixfr_rrstream_create(isc_mem_t *mctx, + const char *journal_filename, + isc_uint32_t begin_serial, + isc_uint32_t end_serial, + rrstream_t **sp) +{ + ixfr_rrstream_t *s; + isc_result_t result; + + INSIST(sp != NULL && *sp == NULL); + + s = isc_mem_get(mctx, sizeof(*s)); + if (s == NULL) + return (ISC_R_NOMEMORY); + s->common.mctx = mctx; + s->common.methods = &ixfr_rrstream_methods; + s->journal = NULL; + + CHECK(dns_journal_open(mctx, journal_filename, + ISC_FALSE, &s->journal)); + CHECK(dns_journal_iter_init(s->journal, begin_serial, end_serial)); + + *sp = (rrstream_t *) s; + return (ISC_R_SUCCESS); + + failure: + ixfr_rrstream_destroy((rrstream_t **) (void *)&s); + return (result); +} + +static isc_result_t +ixfr_rrstream_first(rrstream_t *rs) { + ixfr_rrstream_t *s = (ixfr_rrstream_t *) rs; + return (dns_journal_first_rr(s->journal)); +} + +static isc_result_t +ixfr_rrstream_next(rrstream_t *rs) { + ixfr_rrstream_t *s = (ixfr_rrstream_t *) rs; + return (dns_journal_next_rr(s->journal)); +} + +static void +ixfr_rrstream_current(rrstream_t *rs, + dns_name_t **name, isc_uint32_t *ttl, + dns_rdata_t **rdata) +{ + ixfr_rrstream_t *s = (ixfr_rrstream_t *) rs; + dns_journal_current_rr(s->journal, name, ttl, rdata); +} + +static void +ixfr_rrstream_destroy(rrstream_t **rsp) { + ixfr_rrstream_t *s = (ixfr_rrstream_t *) *rsp; + if (s->journal != 0) + dns_journal_destroy(&s->journal); + isc_mem_put(s->common.mctx, s, sizeof(*s)); +} + +static rrstream_methods_t ixfr_rrstream_methods = { + ixfr_rrstream_first, + ixfr_rrstream_next, + ixfr_rrstream_current, + rrstream_noop_pause, + ixfr_rrstream_destroy +}; + +/**************************************************************************/ +/* + * An 'axfr_rrstream_t' is an 'rrstream_t' that returns + * an AXFR-like RR stream from a database. + * + * The SOAs at the beginning and end of the transfer are + * not included in the stream. + */ + +typedef struct axfr_rrstream { + rrstream_t common; + db_rr_iterator_t it; + isc_boolean_t it_valid; +} axfr_rrstream_t; + +/* + * Forward declarations. + */ +static void +axfr_rrstream_destroy(rrstream_t **rsp); + +static rrstream_methods_t axfr_rrstream_methods; + +static isc_result_t +axfr_rrstream_create(isc_mem_t *mctx, dns_db_t *db, dns_dbversion_t *ver, + rrstream_t **sp) +{ + axfr_rrstream_t *s; + isc_result_t result; + + INSIST(sp != NULL && *sp == NULL); + + s = isc_mem_get(mctx, sizeof(*s)); + if (s == NULL) + return (ISC_R_NOMEMORY); + s->common.mctx = mctx; + s->common.methods = &axfr_rrstream_methods; + s->it_valid = ISC_FALSE; + + CHECK(db_rr_iterator_init(&s->it, db, ver, 0)); + s->it_valid = ISC_TRUE; + + *sp = (rrstream_t *) s; + return (ISC_R_SUCCESS); + + failure: + axfr_rrstream_destroy((rrstream_t **) (void *)&s); + return (result); +} + +static isc_result_t +axfr_rrstream_first(rrstream_t *rs) { + axfr_rrstream_t *s = (axfr_rrstream_t *) rs; + isc_result_t result; + result = db_rr_iterator_first(&s->it); + if (result != ISC_R_SUCCESS) + return (result); + /* Skip SOA records. */ + for (;;) { + dns_name_t *name_dummy = NULL; + isc_uint32_t ttl_dummy; + dns_rdata_t *rdata = NULL; + db_rr_iterator_current(&s->it, &name_dummy, + &ttl_dummy, &rdata); + if (rdata->type != dns_rdatatype_soa) + break; + result = db_rr_iterator_next(&s->it); + if (result != ISC_R_SUCCESS) + break; + } + return (result); +} + +static isc_result_t +axfr_rrstream_next(rrstream_t *rs) { + axfr_rrstream_t *s = (axfr_rrstream_t *) rs; + isc_result_t result; + + /* Skip SOA records. */ + for (;;) { + dns_name_t *name_dummy = NULL; + isc_uint32_t ttl_dummy; + dns_rdata_t *rdata = NULL; + result = db_rr_iterator_next(&s->it); + if (result != ISC_R_SUCCESS) + break; + db_rr_iterator_current(&s->it, &name_dummy, + &ttl_dummy, &rdata); + if (rdata->type != dns_rdatatype_soa) + break; + } + return (result); +} + +static void +axfr_rrstream_current(rrstream_t *rs, dns_name_t **name, isc_uint32_t *ttl, + dns_rdata_t **rdata) +{ + axfr_rrstream_t *s = (axfr_rrstream_t *) rs; + db_rr_iterator_current(&s->it, name, ttl, rdata); +} + +static void +axfr_rrstream_pause(rrstream_t *rs) { + axfr_rrstream_t *s = (axfr_rrstream_t *) rs; + db_rr_iterator_pause(&s->it); +} + +static void +axfr_rrstream_destroy(rrstream_t **rsp) { + axfr_rrstream_t *s = (axfr_rrstream_t *) *rsp; + if (s->it_valid) + db_rr_iterator_destroy(&s->it); + isc_mem_put(s->common.mctx, s, sizeof(*s)); +} + +static rrstream_methods_t axfr_rrstream_methods = { + axfr_rrstream_first, + axfr_rrstream_next, + axfr_rrstream_current, + axfr_rrstream_pause, + axfr_rrstream_destroy +}; + +/**************************************************************************/ +/* + * An 'soa_rrstream_t' is a degenerate 'rrstream_t' that returns + * a single SOA record. + */ + +typedef struct soa_rrstream { + rrstream_t common; + dns_difftuple_t *soa_tuple; +} soa_rrstream_t; + +/* + * Forward declarations. + */ +static void +soa_rrstream_destroy(rrstream_t **rsp); + +static rrstream_methods_t soa_rrstream_methods; + +static isc_result_t +soa_rrstream_create(isc_mem_t *mctx, dns_db_t *db, dns_dbversion_t *ver, + rrstream_t **sp) +{ + soa_rrstream_t *s; + isc_result_t result; + + INSIST(sp != NULL && *sp == NULL); + + s = isc_mem_get(mctx, sizeof(*s)); + if (s == NULL) + return (ISC_R_NOMEMORY); + s->common.mctx = mctx; + s->common.methods = &soa_rrstream_methods; + s->soa_tuple = NULL; + + CHECK(dns_db_createsoatuple(db, ver, mctx, DNS_DIFFOP_EXISTS, + &s->soa_tuple)); + + *sp = (rrstream_t *) s; + return (ISC_R_SUCCESS); + + failure: + soa_rrstream_destroy((rrstream_t **) (void *)&s); + return (result); +} + +static isc_result_t +soa_rrstream_first(rrstream_t *rs) { + UNUSED(rs); + return (ISC_R_SUCCESS); +} + +static isc_result_t +soa_rrstream_next(rrstream_t *rs) { + UNUSED(rs); + return (ISC_R_NOMORE); +} + +static void +soa_rrstream_current(rrstream_t *rs, dns_name_t **name, isc_uint32_t *ttl, + dns_rdata_t **rdata) +{ + soa_rrstream_t *s = (soa_rrstream_t *) rs; + *name = &s->soa_tuple->name; + *ttl = s->soa_tuple->ttl; + *rdata = &s->soa_tuple->rdata; +} + +static void +soa_rrstream_destroy(rrstream_t **rsp) { + soa_rrstream_t *s = (soa_rrstream_t *) *rsp; + if (s->soa_tuple != NULL) + dns_difftuple_free(&s->soa_tuple); + isc_mem_put(s->common.mctx, s, sizeof(*s)); +} + +static rrstream_methods_t soa_rrstream_methods = { + soa_rrstream_first, + soa_rrstream_next, + soa_rrstream_current, + rrstream_noop_pause, + soa_rrstream_destroy +}; + +/**************************************************************************/ +/* + * A 'compound_rrstream_t' objects owns a soa_rrstream + * and another rrstream, the "data stream". It returns + * a concatenated stream consisting of the soa_rrstream, then + * the data stream, then the soa_rrstream again. + * + * The component streams are owned by the compound_rrstream_t + * and are destroyed with it. + */ + +typedef struct compound_rrstream { + rrstream_t common; + rrstream_t *components[3]; + int state; + isc_result_t result; +} compound_rrstream_t; + +/* + * Forward declarations. + */ +static void +compound_rrstream_destroy(rrstream_t **rsp); + +static isc_result_t +compound_rrstream_next(rrstream_t *rs); + +static rrstream_methods_t compound_rrstream_methods; + +/* + * Requires: + * soa_stream != NULL && *soa_stream != NULL + * data_stream != NULL && *data_stream != NULL + * sp != NULL && *sp == NULL + * + * Ensures: + * *soa_stream == NULL + * *data_stream == NULL + * *sp points to a valid compound_rrstream_t + * The soa and data streams will be destroyed + * when the compound_rrstream_t is destroyed. + */ +static isc_result_t +compound_rrstream_create(isc_mem_t *mctx, rrstream_t **soa_stream, + rrstream_t **data_stream, rrstream_t **sp) +{ + compound_rrstream_t *s; + + INSIST(sp != NULL && *sp == NULL); + + s = isc_mem_get(mctx, sizeof(*s)); + if (s == NULL) + return (ISC_R_NOMEMORY); + s->common.mctx = mctx; + s->common.methods = &compound_rrstream_methods; + s->components[0] = *soa_stream; + s->components[1] = *data_stream; + s->components[2] = *soa_stream; + s->state = -1; + s->result = ISC_R_FAILURE; + + *soa_stream = NULL; + *data_stream = NULL; + *sp = (rrstream_t *) s; + return (ISC_R_SUCCESS); +} + +static isc_result_t +compound_rrstream_first(rrstream_t *rs) { + compound_rrstream_t *s = (compound_rrstream_t *) rs; + s->state = 0; + do { + rrstream_t *curstream = s->components[s->state]; + s->result = curstream->methods->first(curstream); + } while (s->result == ISC_R_NOMORE && s->state < 2); + return (s->result); +} + +static isc_result_t +compound_rrstream_next(rrstream_t *rs) { + compound_rrstream_t *s = (compound_rrstream_t *) rs; + rrstream_t *curstream = s->components[s->state]; + s->result = curstream->methods->next(curstream); + while (s->result == ISC_R_NOMORE) { + /* + * Make sure locks held by the current stream + * are released before we switch streams. + */ + curstream->methods->pause(curstream); + if (s->state == 2) + return (ISC_R_NOMORE); + s->state++; + curstream = s->components[s->state]; + s->result = curstream->methods->first(curstream); + } + return (s->result); +} + +static void +compound_rrstream_current(rrstream_t *rs, dns_name_t **name, isc_uint32_t *ttl, + dns_rdata_t **rdata) +{ + compound_rrstream_t *s = (compound_rrstream_t *) rs; + rrstream_t *curstream; + INSIST(0 <= s->state && s->state < 3); + INSIST(s->result == ISC_R_SUCCESS); + curstream = s->components[s->state]; + curstream->methods->current(curstream, name, ttl, rdata); +} + +static void +compound_rrstream_pause(rrstream_t *rs) +{ + compound_rrstream_t *s = (compound_rrstream_t *) rs; + rrstream_t *curstream; + INSIST(0 <= s->state && s->state < 3); + curstream = s->components[s->state]; + curstream->methods->pause(curstream); +} + +static void +compound_rrstream_destroy(rrstream_t **rsp) { + compound_rrstream_t *s = (compound_rrstream_t *) *rsp; + s->components[0]->methods->destroy(&s->components[0]); + s->components[1]->methods->destroy(&s->components[1]); + s->components[2] = NULL; /* Copy of components[0]. */ + isc_mem_put(s->common.mctx, s, sizeof(*s)); +} + +static rrstream_methods_t compound_rrstream_methods = { + compound_rrstream_first, + compound_rrstream_next, + compound_rrstream_current, + compound_rrstream_pause, + compound_rrstream_destroy +}; + +/**************************************************************************/ +/* + * An 'xfrout_ctx_t' contains the state of an outgoing AXFR or IXFR + * in progress. + */ + +typedef struct { + isc_mem_t *mctx; + ns_client_t *client; + unsigned int id; /* ID of request */ + dns_name_t *qname; /* Question name of request */ + dns_rdatatype_t qtype; /* dns_rdatatype_{a,i}xfr */ + dns_rdataclass_t qclass; + dns_db_t *db; + dns_dbversion_t *ver; + isc_quota_t *quota; + rrstream_t *stream; /* The XFR RR stream */ + isc_boolean_t end_of_stream; /* EOS has been reached */ + isc_buffer_t buf; /* Buffer for message owner + names and rdatas */ + isc_buffer_t txlenbuf; /* Transmit length buffer */ + isc_buffer_t txbuf; /* Transmit message buffer */ + void *txmem; + unsigned int txmemlen; + unsigned int nmsg; /* Number of messages sent */ + dns_tsigkey_t *tsigkey; /* Key used to create TSIG */ + isc_buffer_t *lasttsig; /* the last TSIG */ + isc_boolean_t many_answers; + int sends; /* Send in progress */ + isc_boolean_t shuttingdown; + const char *mnemonic; /* Style of transfer */ +} xfrout_ctx_t; + +static isc_result_t +xfrout_ctx_create(isc_mem_t *mctx, ns_client_t *client, + unsigned int id, dns_name_t *qname, dns_rdatatype_t qtype, + dns_rdataclass_t qclass, + dns_db_t *db, dns_dbversion_t *ver, isc_quota_t *quota, + rrstream_t *stream, dns_tsigkey_t *tsigkey, + isc_buffer_t *lasttsig, + unsigned int maxtime, + unsigned int idletime, + isc_boolean_t many_answers, + xfrout_ctx_t **xfrp); + +static void +sendstream(xfrout_ctx_t *xfr); + +static void +xfrout_senddone(isc_task_t *task, isc_event_t *event); + +static void +xfrout_fail(xfrout_ctx_t *xfr, isc_result_t result, const char *msg); + +static void +xfrout_maybe_destroy(xfrout_ctx_t *xfr); + +static void +xfrout_ctx_destroy(xfrout_ctx_t **xfrp); + +static void +xfrout_client_shutdown(void *arg, isc_result_t result); + +static void +xfrout_log1(ns_client_t *client, dns_name_t *zonename, + dns_rdataclass_t rdclass, int level, + const char *fmt, ...) ISC_FORMAT_PRINTF(5, 6); + +static void +xfrout_log(xfrout_ctx_t *xfr, unsigned int level, const char *fmt, ...) + ISC_FORMAT_PRINTF(3, 4); + +/**************************************************************************/ + +void +ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) { + isc_result_t result; + dns_name_t *question_name; + dns_rdataset_t *question_rdataset; + dns_zone_t *zone = NULL; + dns_db_t *db = NULL; + dns_dbversion_t *ver = NULL; + dns_rdataclass_t question_class; + rrstream_t *soa_stream = NULL; + rrstream_t *data_stream = NULL; + rrstream_t *stream = NULL; + dns_difftuple_t *current_soa_tuple = NULL; + dns_name_t *soa_name; + dns_rdataset_t *soa_rdataset; + dns_rdata_t soa_rdata = DNS_RDATA_INIT; + isc_boolean_t have_soa = ISC_FALSE; + const char *mnemonic = NULL; + isc_mem_t *mctx = client->mctx; + dns_message_t *request = client->message; + xfrout_ctx_t *xfr = NULL; + isc_quota_t *quota = NULL; + dns_transfer_format_t format = client->view->transfer_format; + isc_netaddr_t na; + dns_peer_t *peer = NULL; + isc_buffer_t *tsigbuf = NULL; + char *journalfile; + char msg[NS_CLIENT_ACLMSGSIZE("zone transfer")]; + char keyname[DNS_NAME_FORMATSIZE]; + isc_boolean_t is_poll = ISC_FALSE; + + switch (reqtype) { + case dns_rdatatype_axfr: + mnemonic = "AXFR"; + break; + case dns_rdatatype_ixfr: + mnemonic = "IXFR"; + break; + default: + INSIST(0); + break; + } + + ns_client_log(client, + DNS_LOGCATEGORY_XFER_OUT, NS_LOGMODULE_XFER_OUT, + ISC_LOG_DEBUG(6), "%s request", mnemonic); + /* + * Apply quota. + */ + result = isc_quota_attach(&ns_g_server->xfroutquota, "a); + if (result != ISC_R_SUCCESS) { + isc_log_write(XFROUT_COMMON_LOGARGS, ISC_LOG_WARNING, + "%s request denied: %s", mnemonic, + isc_result_totext(result)); + goto failure; + } + + /* + * Interpret the question section. + */ + result = dns_message_firstname(request, DNS_SECTION_QUESTION); + INSIST(result == ISC_R_SUCCESS); + + /* + * The question section must contain exactly one question, and + * it must be for AXFR/IXFR as appropriate. + */ + question_name = NULL; + dns_message_currentname(request, DNS_SECTION_QUESTION, &question_name); + question_rdataset = ISC_LIST_HEAD(question_name->list); + question_class = question_rdataset->rdclass; + INSIST(question_rdataset->type == reqtype); + if (ISC_LIST_NEXT(question_rdataset, link) != NULL) + FAILC(DNS_R_FORMERR, "multiple questions"); + result = dns_message_nextname(request, DNS_SECTION_QUESTION); + if (result != ISC_R_NOMORE) + FAILC(DNS_R_FORMERR, "multiple questions"); + + result = dns_zt_find(client->view->zonetable, question_name, 0, NULL, + &zone); + if (result != ISC_R_SUCCESS) + FAILQ(DNS_R_NOTAUTH, "non-authoritative zone", + question_name, question_class); + switch(dns_zone_gettype(zone)) { + case dns_zone_master: + case dns_zone_slave: + break; /* Master and slave zones are OK for transfer. */ + default: + FAILQ(DNS_R_NOTAUTH, "non-authoritative zone", + question_name, question_class); + } + CHECK(dns_zone_getdb(zone, &db)); + dns_db_currentversion(db, &ver); + + xfrout_log1(client, question_name, question_class, ISC_LOG_DEBUG(6), + "%s question section OK", mnemonic); + + /* + * Check the authority section. Look for a SOA record with + * the same name and class as the question. + */ + for (result = dns_message_firstname(request, DNS_SECTION_AUTHORITY); + result == ISC_R_SUCCESS; + result = dns_message_nextname(request, DNS_SECTION_AUTHORITY)) + { + soa_name = NULL; + dns_message_currentname(request, DNS_SECTION_AUTHORITY, + &soa_name); + + /* + * Ignore data whose owner name is not the zone apex. + */ + if (! dns_name_equal(soa_name, question_name)) + continue; + + for (soa_rdataset = ISC_LIST_HEAD(soa_name->list); + soa_rdataset != NULL; + soa_rdataset = ISC_LIST_NEXT(soa_rdataset, link)) + { + /* + * Ignore non-SOA data. + */ + if (soa_rdataset->type != dns_rdatatype_soa) + continue; + if (soa_rdataset->rdclass != question_class) + continue; + + CHECK(dns_rdataset_first(soa_rdataset)); + dns_rdataset_current(soa_rdataset, &soa_rdata); + result = dns_rdataset_next(soa_rdataset); + if (result == ISC_R_SUCCESS) + FAILC(DNS_R_FORMERR, + "IXFR authority section " + "has multiple SOAs"); + have_soa = ISC_TRUE; + goto got_soa; + } + } + got_soa: + if (result != ISC_R_NOMORE) + CHECK(result); + + xfrout_log1(client, question_name, question_class, ISC_LOG_DEBUG(6), + "%s authority section OK", mnemonic); + + /* + * Decide whether to allow this transfer. + */ + ns_client_aclmsg("zone transfer", question_name, reqtype, + client->view->rdclass, msg, sizeof(msg)); + CHECK(ns_client_checkacl(client, msg, + dns_zone_getxfracl(zone), ISC_TRUE, + ISC_LOG_ERROR)); + + /* + * AXFR over UDP is not possible. + */ + if (reqtype == dns_rdatatype_axfr && + (client->attributes & NS_CLIENTATTR_TCP) == 0) + FAILC(DNS_R_FORMERR, "attempted AXFR over UDP"); + + /* + * Look up the requesting server in the peer table. + */ + isc_netaddr_fromsockaddr(&na, &client->peeraddr); + (void)dns_peerlist_peerbyaddr(client->view->peers, &na, &peer); + + /* + * Decide on the transfer format (one-answer or many-answers). + */ + if (peer != NULL) + (void)dns_peer_gettransferformat(peer, &format); + + /* + * Get a dynamically allocated copy of the current SOA. + */ + CHECK(dns_db_createsoatuple(db, ver, mctx, DNS_DIFFOP_EXISTS, + ¤t_soa_tuple)); + + if (reqtype == dns_rdatatype_ixfr) { + isc_uint32_t begin_serial, current_serial; + isc_boolean_t provide_ixfr; + + /* + * Outgoing IXFR may have been disabled for this peer + * or globally. + */ + provide_ixfr = client->view->provideixfr; + if (peer != NULL) + (void) dns_peer_getprovideixfr(peer, &provide_ixfr); + if (provide_ixfr == ISC_FALSE) + goto axfr_fallback; + + if (! have_soa) + FAILC(DNS_R_FORMERR, + "IXFR request missing SOA"); + + begin_serial = dns_soa_getserial(&soa_rdata); + current_serial = dns_soa_getserial(¤t_soa_tuple->rdata); + + /* + * RFC1995 says "If an IXFR query with the same or + * newer version number than that of the server + * is received, it is replied to with a single SOA + * record of the server's current version, just as + * in AXFR". The claim about AXFR is incorrect, + * but other than that, we do as the RFC says. + * + * Sending a single SOA record is also how we refuse + * IXFR over UDP (currently, we always do). + */ + if (DNS_SERIAL_GE(begin_serial, current_serial) || + (client->attributes & NS_CLIENTATTR_TCP) == 0) + { + CHECK(soa_rrstream_create(mctx, db, ver, &stream)); + is_poll = ISC_TRUE; + goto have_stream; + } + journalfile = dns_zone_getjournal(zone); + if (journalfile != NULL) + result = ixfr_rrstream_create(mctx, + journalfile, + begin_serial, + current_serial, + &data_stream); + else + result = ISC_R_NOTFOUND; + if (result == ISC_R_NOTFOUND || + result == ISC_R_RANGE) { + xfrout_log1(client, question_name, question_class, + ISC_LOG_DEBUG(4), + "IXFR version not in journal, " + "falling back to AXFR"); + mnemonic = "AXFR-style IXFR"; + goto axfr_fallback; + } + CHECK(result); + } else { + axfr_fallback: + CHECK(axfr_rrstream_create(mctx, db, ver, + &data_stream)); + } + + /* + * Bracket the the data stream with SOAs. + */ + CHECK(soa_rrstream_create(mctx, db, ver, &soa_stream)); + CHECK(compound_rrstream_create(mctx, &soa_stream, &data_stream, + &stream)); + soa_stream = NULL; + data_stream = NULL; + + have_stream: + CHECK(dns_message_getquerytsig(request, mctx, &tsigbuf)); + /* + * Create the xfrout context object. This transfers the ownership + * of "stream", "db", "ver", and "quota" to the xfrout context object. + */ + CHECK(xfrout_ctx_create(mctx, client, request->id, question_name, + reqtype, question_class, db, ver, quota, + stream, dns_message_gettsigkey(request), + tsigbuf, + dns_zone_getmaxxfrout(zone), + dns_zone_getidleout(zone), + (format == dns_many_answers) ? + ISC_TRUE : ISC_FALSE, + &xfr)); + xfr->mnemonic = mnemonic; + stream = NULL; + quota = NULL; + + CHECK(xfr->stream->methods->first(xfr->stream)); + + if (xfr->tsigkey != NULL) { + dns_name_format(&xfr->tsigkey->name, keyname, sizeof(keyname)); + } else + keyname[0] = '\0'; + if (is_poll) + xfrout_log1(client, question_name, question_class, + ISC_LOG_DEBUG(1), "IXFR poll up to date%s%s", + (xfr->tsigkey != NULL) ? ": TSIG " : "", keyname); + else + xfrout_log1(client, question_name, question_class, + ISC_LOG_INFO, "%s started%s%s", mnemonic, + (xfr->tsigkey != NULL) ? ": TSIG " : "", keyname); + + /* + * Hand the context over to sendstream(). Set xfr to NULL; + * sendstream() is responsible for either passing the + * context on to a later event handler or destroying it. + */ + sendstream(xfr); + xfr = NULL; + + result = ISC_R_SUCCESS; + + failure: + if (quota != NULL) + isc_quota_detach("a); + if (current_soa_tuple != NULL) + dns_difftuple_free(¤t_soa_tuple); + if (stream != NULL) + stream->methods->destroy(&stream); + if (soa_stream != NULL) + soa_stream->methods->destroy(&soa_stream); + if (data_stream != NULL) + data_stream->methods->destroy(&data_stream); + if (ver != NULL) + dns_db_closeversion(db, &ver, ISC_FALSE); + if (db != NULL) + dns_db_detach(&db); + if (zone != NULL) + dns_zone_detach(&zone); + /* XXX kludge */ + if (xfr != NULL) { + xfrout_fail(xfr, result, "setting up zone transfer"); + } else if (result != ISC_R_SUCCESS) { + ns_client_log(client, DNS_LOGCATEGORY_XFER_OUT, + NS_LOGMODULE_XFER_OUT, + ISC_LOG_DEBUG(3), "zone transfer setup failed"); + ns_client_error(client, result); + } +} + +static isc_result_t +xfrout_ctx_create(isc_mem_t *mctx, ns_client_t *client, unsigned int id, + dns_name_t *qname, dns_rdatatype_t qtype, + dns_rdataclass_t qclass, + dns_db_t *db, dns_dbversion_t *ver, isc_quota_t *quota, + rrstream_t *stream, dns_tsigkey_t *tsigkey, + isc_buffer_t *lasttsig, unsigned int maxtime, + unsigned int idletime, isc_boolean_t many_answers, + xfrout_ctx_t **xfrp) +{ + xfrout_ctx_t *xfr; + isc_result_t result; + unsigned int len; + void *mem; + + INSIST(xfrp != NULL && *xfrp == NULL); + xfr = isc_mem_get(mctx, sizeof(*xfr)); + if (xfr == NULL) + return (ISC_R_NOMEMORY); + xfr->mctx = mctx; + xfr->client = NULL; + ns_client_attach(client, &xfr->client); + xfr->id = id; + xfr->qname = qname; + xfr->qtype = qtype; + xfr->qclass = qclass; + xfr->db = NULL; + xfr->ver = NULL; + dns_db_attach(db, &xfr->db); + dns_db_attachversion(db, ver, &xfr->ver); + xfr->end_of_stream = ISC_FALSE; + xfr->tsigkey = tsigkey; + xfr->lasttsig = lasttsig; + xfr->txmem = NULL; + xfr->txmemlen = 0; + xfr->nmsg = 0; + xfr->many_answers = many_answers, + xfr->sends = 0; + xfr->shuttingdown = ISC_FALSE; + xfr->mnemonic = NULL; + xfr->buf.base = NULL; + xfr->buf.length = 0; + xfr->txmem = NULL; + xfr->txmemlen = 0; + xfr->stream = NULL; + xfr->quota = NULL; + + /* + * Allocate a temporary buffer for the uncompressed response + * message data. The size should be no more than 65535 bytes + * so that the compressed data will fit in a TCP message, + * and no less than 65535 bytes so that an almost maximum-sized + * RR will fit. Note that although 65535-byte RRs are allowed + * in principle, they cannot be zone-transferred (at least not + * if uncompressible), because the message and RR headers would + * push the size of the TCP message over the 65536 byte limit. + */ + len = 65535; + mem = isc_mem_get(mctx, len); + if (mem == NULL) { + result = ISC_R_NOMEMORY; + goto failure; + } + isc_buffer_init(&xfr->buf, mem, len); + + /* + * Allocate another temporary buffer for the compressed + * response message and its TCP length prefix. + */ + len = 2 + 65535; + mem = isc_mem_get(mctx, len); + if (mem == NULL) { + result = ISC_R_NOMEMORY; + goto failure; + } + isc_buffer_init(&xfr->txlenbuf, mem, 2); + isc_buffer_init(&xfr->txbuf, (char *) mem + 2, len - 2); + xfr->txmem = mem; + xfr->txmemlen = len; + + CHECK(dns_timer_setidle(xfr->client->timer, + maxtime, idletime, ISC_FALSE)); + + /* + * Register a shutdown callback with the client, so that we + * can stop the transfer immediately when the client task + * gets a shutdown event. + */ + xfr->client->shutdown = xfrout_client_shutdown; + xfr->client->shutdown_arg = xfr; + /* + * These MUST be after the last "goto failure;" / CHECK to + * prevent a double free by the caller. + */ + xfr->quota = quota; + xfr->stream = stream; + + *xfrp = xfr; + return (ISC_R_SUCCESS); + +failure: + xfrout_ctx_destroy(&xfr); + return (result); +} + + +/* + * Arrange to send as much as we can of "stream" without blocking. + * + * Requires: + * The stream iterator is initialized and points at an RR, + * or possiby at the end of the stream (that is, the + * _first method of the iterator has been called). + */ +static void +sendstream(xfrout_ctx_t *xfr) { + dns_message_t *tcpmsg = NULL; + dns_message_t *msg = NULL; /* Client message if UDP, tcpmsg if TCP */ + isc_result_t result; + isc_region_t used; + isc_region_t region; + dns_rdataset_t *qrdataset; + dns_name_t *msgname = NULL; + dns_rdata_t *msgrdata = NULL; + dns_rdatalist_t *msgrdl = NULL; + dns_rdataset_t *msgrds = NULL; + dns_compress_t cctx; + isc_boolean_t cleanup_cctx = ISC_FALSE; + + int n_rrs; + + isc_buffer_clear(&xfr->buf); + isc_buffer_clear(&xfr->txlenbuf); + isc_buffer_clear(&xfr->txbuf); + + if ((xfr->client->attributes & NS_CLIENTATTR_TCP) == 0) { + /* + * In the UDP case, we put the response data directly into + * the client message. + */ + msg = xfr->client->message; + CHECK(dns_message_reply(msg, ISC_TRUE)); + } else { + /* + * TCP. Build a response dns_message_t, temporarily storing + * the raw, uncompressed owner names and RR data contiguously + * in xfr->buf. We know that if the uncompressed data fits + * in xfr->buf, the compressed data will surely fit in a TCP + * message. + */ + + CHECK(dns_message_create(xfr->mctx, + DNS_MESSAGE_INTENTRENDER, &tcpmsg)); + msg = tcpmsg; + + msg->id = xfr->id; + msg->rcode = dns_rcode_noerror; + msg->flags = DNS_MESSAGEFLAG_QR | DNS_MESSAGEFLAG_AA; + if ((xfr->client->attributes & NS_CLIENTATTR_RA) != 0) + msg->flags |= DNS_MESSAGEFLAG_RA; + CHECK(dns_message_settsigkey(msg, xfr->tsigkey)); + CHECK(dns_message_setquerytsig(msg, xfr->lasttsig)); + if (xfr->lasttsig != NULL) + isc_buffer_free(&xfr->lasttsig); + + /* + * Include a question section in the first message only. + * BIND 8.2.1 will not recognize an IXFR if it does not + * have a question section. + */ + if (xfr->nmsg == 0) { + dns_name_t *qname = NULL; + isc_region_t r; + + /* + * Reserve space for the 12-byte message header + * and 4 bytes of question. + */ + isc_buffer_add(&xfr->buf, 12 + 4); + + qrdataset = NULL; + result = dns_message_gettemprdataset(msg, &qrdataset); + if (result != ISC_R_SUCCESS) + goto failure; + dns_rdataset_init(qrdataset); + dns_rdataset_makequestion(qrdataset, + xfr->client->message->rdclass, + xfr->qtype); + + result = dns_message_gettempname(msg, &qname); + if (result != ISC_R_SUCCESS) + goto failure; + dns_name_init(qname, NULL); + isc_buffer_availableregion(&xfr->buf, &r); + INSIST(r.length >= xfr->qname->length); + r.length = xfr->qname->length; + isc_buffer_putmem(&xfr->buf, xfr->qname->ndata, + xfr->qname->length); + dns_name_fromregion(qname, &r); + ISC_LIST_INIT(qname->list); + ISC_LIST_APPEND(qname->list, qrdataset, link); + + dns_message_addname(msg, qname, DNS_SECTION_QUESTION); + } + else + msg->tcp_continuation = 1; + } + + /* + * Try to fit in as many RRs as possible, unless "one-answer" + * format has been requested. + */ + for (n_rrs = 0; ; n_rrs++) { + dns_name_t *name = NULL; + isc_uint32_t ttl; + dns_rdata_t *rdata = NULL; + + unsigned int size; + isc_region_t r; + + msgname = NULL; + msgrdata = NULL; + msgrdl = NULL; + msgrds = NULL; + + xfr->stream->methods->current(xfr->stream, + &name, &ttl, &rdata); + size = name->length + 10 + rdata->length; + isc_buffer_availableregion(&xfr->buf, &r); + if (size >= r.length) { + /* + * RR would not fit. If there are other RRs in the + * buffer, send them now and leave this RR to the + * next message. If this RR overflows the buffer + * all by itself, fail. + * + * In theory some RRs might fit in a TCP message + * when compressed even if they do not fit when + * uncompressed, but surely we don't want + * to send such monstrosities to an unsuspecting + * slave. + */ + if (n_rrs == 0) { + xfrout_log(xfr, ISC_LOG_WARNING, + "RR too large for zone transfer " + "(%d bytes)", size); + /* XXX DNS_R_RRTOOLARGE? */ + result = ISC_R_NOSPACE; + goto failure; + } + break; + } + + if (isc_log_wouldlog(ns_g_lctx, XFROUT_RR_LOGLEVEL)) + log_rr(name, rdata, ttl); /* XXX */ + + result = dns_message_gettempname(msg, &msgname); + if (result != ISC_R_SUCCESS) + goto failure; + dns_name_init(msgname, NULL); + isc_buffer_availableregion(&xfr->buf, &r); + INSIST(r.length >= name->length); + r.length = name->length; + isc_buffer_putmem(&xfr->buf, name->ndata, name->length); + dns_name_fromregion(msgname, &r); + + /* Reserve space for RR header. */ + isc_buffer_add(&xfr->buf, 10); + + result = dns_message_gettemprdata(msg, &msgrdata); + if (result != ISC_R_SUCCESS) + goto failure; + isc_buffer_availableregion(&xfr->buf, &r); + r.length = rdata->length; + isc_buffer_putmem(&xfr->buf, rdata->data, rdata->length); + dns_rdata_init(msgrdata); + dns_rdata_fromregion(msgrdata, + rdata->rdclass, rdata->type, &r); + + result = dns_message_gettemprdatalist(msg, &msgrdl); + if (result != ISC_R_SUCCESS) + goto failure; + msgrdl->type = rdata->type; + msgrdl->rdclass = rdata->rdclass; + msgrdl->ttl = ttl; + ISC_LINK_INIT(msgrdl, link); + ISC_LIST_INIT(msgrdl->rdata); + ISC_LIST_APPEND(msgrdl->rdata, msgrdata, link); + + result = dns_message_gettemprdataset(msg, &msgrds); + if (result != ISC_R_SUCCESS) + goto failure; + dns_rdataset_init(msgrds); + result = dns_rdatalist_tordataset(msgrdl, msgrds); + INSIST(result == ISC_R_SUCCESS); + + ISC_LIST_APPEND(msgname->list, msgrds, link); + + dns_message_addname(msg, msgname, DNS_SECTION_ANSWER); + msgname = NULL; + + result = xfr->stream->methods->next(xfr->stream); + if (result == ISC_R_NOMORE) { + xfr->end_of_stream = ISC_TRUE; + break; + } + CHECK(result); + + if (! xfr->many_answers) + break; + } + + if ((xfr->client->attributes & NS_CLIENTATTR_TCP) != 0) { + CHECK(dns_compress_init(&cctx, -1, xfr->mctx)); + cleanup_cctx = ISC_TRUE; + CHECK(dns_message_renderbegin(msg, &cctx, &xfr->txbuf)); + CHECK(dns_message_rendersection(msg, DNS_SECTION_QUESTION, 0)); + CHECK(dns_message_rendersection(msg, DNS_SECTION_ANSWER, 0)); + CHECK(dns_message_renderend(msg)); + dns_compress_invalidate(&cctx); + cleanup_cctx = ISC_FALSE; + + isc_buffer_usedregion(&xfr->txbuf, &used); + isc_buffer_putuint16(&xfr->txlenbuf, + (isc_uint16_t)used.length); + region.base = xfr->txlenbuf.base; + region.length = 2 + used.length; + xfrout_log(xfr, ISC_LOG_DEBUG(8), + "sending TCP message of %d bytes", + used.length); + CHECK(isc_socket_send(xfr->client->tcpsocket, /* XXX */ + ®ion, xfr->client->task, + xfrout_senddone, + xfr)); + xfr->sends++; + } else { + xfrout_log(xfr, ISC_LOG_DEBUG(8), "sending IXFR UDP response"); + ns_client_send(xfr->client); + xfr->stream->methods->pause(xfr->stream); + xfrout_ctx_destroy(&xfr); + return; + } + + /* Advance lasttsig to be the last TSIG generated */ + CHECK(dns_message_getquerytsig(msg, xfr->mctx, &xfr->lasttsig)); + + xfr->nmsg++; + + failure: + if (msgname != NULL) { + if (msgrds != NULL) { + if (dns_rdataset_isassociated(msgrds)) + dns_rdataset_disassociate(msgrds); + dns_message_puttemprdataset(msg, &msgrds); + } + if (msgrdl != NULL) { + ISC_LIST_UNLINK(msgrdl->rdata, msgrdata, link); + dns_message_puttemprdatalist(msg, &msgrdl); + } + if (msgrdata != NULL) + dns_message_puttemprdata(msg, &msgrdata); + dns_message_puttempname(msg, &msgname); + } + + if (tcpmsg != NULL) + dns_message_destroy(&tcpmsg); + + if (cleanup_cctx) + dns_compress_invalidate(&cctx); + /* + * Make sure to release any locks held by database + * iterators before returning from the event handler. + */ + xfr->stream->methods->pause(xfr->stream); + + if (result == ISC_R_SUCCESS) + return; + + xfrout_fail(xfr, result, "sending zone data"); +} + +static void +xfrout_ctx_destroy(xfrout_ctx_t **xfrp) { + xfrout_ctx_t *xfr = *xfrp; + + INSIST(xfr->sends == 0); + + xfr->client->shutdown = NULL; + xfr->client->shutdown_arg = NULL; + + if (xfr->stream != NULL) + xfr->stream->methods->destroy(&xfr->stream); + if (xfr->buf.base != NULL) + isc_mem_put(xfr->mctx, xfr->buf.base, xfr->buf.length); + if (xfr->txmem != NULL) + isc_mem_put(xfr->mctx, xfr->txmem, xfr->txmemlen); + if (xfr->lasttsig != NULL) + isc_buffer_free(&xfr->lasttsig); + if (xfr->quota != NULL) + isc_quota_detach(&xfr->quota); + if (xfr->ver != NULL) + dns_db_closeversion(xfr->db, &xfr->ver, ISC_FALSE); + if (xfr->db != NULL) + dns_db_detach(&xfr->db); + + ns_client_detach(&xfr->client); + + isc_mem_put(xfr->mctx, xfr, sizeof(*xfr)); + + *xfrp = NULL; +} + +static void +xfrout_senddone(isc_task_t *task, isc_event_t *event) { + isc_socketevent_t *sev = (isc_socketevent_t *)event; + xfrout_ctx_t *xfr = (xfrout_ctx_t *)event->ev_arg; + isc_result_t evresult = sev->result; + + UNUSED(task); + + INSIST(event->ev_type == ISC_SOCKEVENT_SENDDONE); + + isc_event_free(&event); + xfr->sends--; + INSIST(xfr->sends == 0); + + (void)isc_timer_touch(xfr->client->timer); + if (xfr->shuttingdown == ISC_TRUE) { + xfrout_maybe_destroy(xfr); + } else if (evresult != ISC_R_SUCCESS) { + xfrout_fail(xfr, evresult, "send"); + } else if (xfr->end_of_stream == ISC_FALSE) { + sendstream(xfr); + } else { + /* End of zone transfer stream. */ + xfrout_log(xfr, ISC_LOG_INFO, "%s ended", xfr->mnemonic); + ns_client_next(xfr->client, ISC_R_SUCCESS); + xfrout_ctx_destroy(&xfr); + } +} + +static void +xfrout_fail(xfrout_ctx_t *xfr, isc_result_t result, const char *msg) { + xfr->shuttingdown = ISC_TRUE; + xfrout_log(xfr, ISC_LOG_ERROR, "%s: %s", + msg, isc_result_totext(result)); + xfrout_maybe_destroy(xfr); +} + +static void +xfrout_maybe_destroy(xfrout_ctx_t *xfr) { + INSIST(xfr->shuttingdown == ISC_TRUE); + if (xfr->sends > 0) { + /* + * If we are currently sending, cancel it and wait for + * cancel event before destroying the context. + */ + isc_socket_cancel(xfr->client->tcpsocket, xfr->client->task, + ISC_SOCKCANCEL_SEND); + } else { + ns_client_next(xfr->client, ISC_R_CANCELED); + xfrout_ctx_destroy(&xfr); + } +} + +static void +xfrout_client_shutdown(void *arg, isc_result_t result) { + xfrout_ctx_t *xfr = (xfrout_ctx_t *) arg; + xfrout_fail(xfr, result, "aborted"); +} + +/* + * Log outgoing zone transfer messages in a format like + * : transfer of : + */ + +static void +xfrout_logv(ns_client_t *client, dns_name_t *zonename, + dns_rdataclass_t rdclass, int level, const char *fmt, va_list ap) + ISC_FORMAT_PRINTF(5, 0); + +static void +xfrout_logv(ns_client_t *client, dns_name_t *zonename, + dns_rdataclass_t rdclass, int level, const char *fmt, va_list ap) +{ + char msgbuf[2048]; + char namebuf[DNS_NAME_FORMATSIZE]; + char classbuf[DNS_RDATACLASS_FORMATSIZE]; + + dns_name_format(zonename, namebuf, sizeof(namebuf)); + dns_rdataclass_format(rdclass, classbuf, sizeof(classbuf)); + vsnprintf(msgbuf, sizeof(msgbuf), fmt, ap); + ns_client_log(client, DNS_LOGCATEGORY_XFER_OUT, + NS_LOGMODULE_XFER_OUT, level, + "transfer of '%s/%s': %s", namebuf, classbuf, msgbuf); +} + +/* + * Logging function for use when a xfrout_ctx_t has not yet been created. + */ +static void +xfrout_log1(ns_client_t *client, dns_name_t *zonename, + dns_rdataclass_t rdclass, int level, const char *fmt, ...) { + va_list ap; + va_start(ap, fmt); + xfrout_logv(client, zonename, rdclass, level, fmt, ap); + va_end(ap); +} + +/* + * Logging function for use when there is a xfrout_ctx_t. + */ +static void +xfrout_log(xfrout_ctx_t *xfr, unsigned int level, const char *fmt, ...) { + va_list ap; + va_start(ap, fmt); + xfrout_logv(xfr->client, xfr->qname, xfr->qclass, level, fmt, ap); + va_end(ap); +} diff --git a/contrib/bind9/bin/named/zoneconf.c b/contrib/bind9/bin/named/zoneconf.c new file mode 100644 index 000000000000..afafa534d2b6 --- /dev/null +++ b/contrib/bind9/bin/named/zoneconf.c @@ -0,0 +1,729 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: zoneconf.c,v 1.87.2.4.10.13 2004/04/20 14:12:09 marka Exp $ */ + +#include + +#include +#include +#include +#include +#include /* Required for HP/UX (and others?) */ +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* + * These are BIND9 server defaults, not necessarily identical to the + * library defaults defined in zone.c. + */ +#define RETERR(x) do { \ + isc_result_t _r = (x); \ + if (_r != ISC_R_SUCCESS) \ + return (_r); \ + } while (0) + +/* + * Convenience function for configuring a single zone ACL. + */ +static isc_result_t +configure_zone_acl(cfg_obj_t *zconfig, cfg_obj_t *vconfig, cfg_obj_t *config, + const char *aclname, ns_aclconfctx_t *actx, + dns_zone_t *zone, + void (*setzacl)(dns_zone_t *, dns_acl_t *), + void (*clearzacl)(dns_zone_t *)) +{ + isc_result_t result; + cfg_obj_t *maps[4]; + cfg_obj_t *aclobj = NULL; + int i = 0; + dns_acl_t *dacl = NULL; + + if (zconfig != NULL) + maps[i++] = cfg_tuple_get(zconfig, "options"); + if (vconfig != NULL) + maps[i++] = cfg_tuple_get(vconfig, "options"); + if (config != NULL) { + cfg_obj_t *options = NULL; + (void)cfg_map_get(config, "options", &options); + if (options != NULL) + maps[i++] = options; + } + maps[i] = NULL; + + result = ns_config_get(maps, aclname, &aclobj); + if (aclobj == NULL) { + (*clearzacl)(zone); + return (ISC_R_SUCCESS); + } + + result = ns_acl_fromconfig(aclobj, config, actx, + dns_zone_getmctx(zone), &dacl); + if (result != ISC_R_SUCCESS) + return (result); + (*setzacl)(zone, dacl); + dns_acl_detach(&dacl); + return (ISC_R_SUCCESS); +} + +/* + * Parse the zone update-policy statement. + */ +static isc_result_t +configure_zone_ssutable(cfg_obj_t *zconfig, dns_zone_t *zone) { + cfg_obj_t *updatepolicy = NULL; + cfg_listelt_t *element, *element2; + dns_ssutable_t *table = NULL; + isc_mem_t *mctx = dns_zone_getmctx(zone); + isc_result_t result; + + (void)cfg_map_get(zconfig, "update-policy", &updatepolicy); + if (updatepolicy == NULL) + return (ISC_R_SUCCESS); + + result = dns_ssutable_create(mctx, &table); + if (result != ISC_R_SUCCESS) + return (result); + + for (element = cfg_list_first(updatepolicy); + element != NULL; + element = cfg_list_next(element)) + { + cfg_obj_t *stmt = cfg_listelt_value(element); + cfg_obj_t *mode = cfg_tuple_get(stmt, "mode"); + cfg_obj_t *identity = cfg_tuple_get(stmt, "identity"); + cfg_obj_t *matchtype = cfg_tuple_get(stmt, "matchtype"); + cfg_obj_t *dname = cfg_tuple_get(stmt, "name"); + cfg_obj_t *typelist = cfg_tuple_get(stmt, "types"); + char *str; + isc_boolean_t grant = ISC_FALSE; + unsigned int mtype = DNS_SSUMATCHTYPE_NAME; + dns_fixedname_t fname, fident; + isc_buffer_t b; + dns_rdatatype_t *types; + unsigned int i, n; + + str = cfg_obj_asstring(mode); + if (strcasecmp(str, "grant") == 0) + grant = ISC_TRUE; + else if (strcasecmp(str, "deny") == 0) + grant = ISC_FALSE; + else + INSIST(0); + + str = cfg_obj_asstring(matchtype); + if (strcasecmp(str, "name") == 0) + mtype = DNS_SSUMATCHTYPE_NAME; + else if (strcasecmp(str, "subdomain") == 0) + mtype = DNS_SSUMATCHTYPE_SUBDOMAIN; + else if (strcasecmp(str, "wildcard") == 0) + mtype = DNS_SSUMATCHTYPE_WILDCARD; + else if (strcasecmp(str, "self") == 0) + mtype = DNS_SSUMATCHTYPE_SELF; + else + INSIST(0); + + dns_fixedname_init(&fident); + str = cfg_obj_asstring(identity); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + result = dns_name_fromtext(dns_fixedname_name(&fident), &b, + dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) { + cfg_obj_log(identity, ns_g_lctx, ISC_LOG_ERROR, + "'%s' is not a valid name", str); + goto cleanup; + } + + dns_fixedname_init(&fname); + str = cfg_obj_asstring(dname); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + result = dns_name_fromtext(dns_fixedname_name(&fname), &b, + dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) { + cfg_obj_log(identity, ns_g_lctx, ISC_LOG_ERROR, + "'%s' is not a valid name", str); + goto cleanup; + } + + n = ns_config_listcount(typelist); + if (n == 0) + types = NULL; + else { + types = isc_mem_get(mctx, n * sizeof(dns_rdatatype_t)); + if (types == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup; + } + } + + i = 0; + for (element2 = cfg_list_first(typelist); + element2 != NULL; + element2 = cfg_list_next(element2)) + { + cfg_obj_t *typeobj; + isc_textregion_t r; + + INSIST(i < n); + + typeobj = cfg_listelt_value(element2); + str = cfg_obj_asstring(typeobj); + r.base = str; + r.length = strlen(str); + + result = dns_rdatatype_fromtext(&types[i++], &r); + if (result != ISC_R_SUCCESS) { + cfg_obj_log(identity, ns_g_lctx, ISC_LOG_ERROR, + "'%s' is not a valid type", str); + isc_mem_put(mctx, types, + n * sizeof(dns_rdatatype_t)); + goto cleanup; + } + } + INSIST(i == n); + + result = dns_ssutable_addrule(table, grant, + dns_fixedname_name(&fident), + mtype, + dns_fixedname_name(&fname), + n, types); + if (types != NULL) + isc_mem_put(mctx, types, n * sizeof(dns_rdatatype_t)); + if (result != ISC_R_SUCCESS) { + goto cleanup; + } + + } + + result = ISC_R_SUCCESS; + dns_zone_setssutable(zone, table); + + cleanup: + dns_ssutable_detach(&table); + return (result); +} + +/* + * Convert a config file zone type into a server zone type. + */ +static inline dns_zonetype_t +zonetype_fromconfig(cfg_obj_t *map) { + cfg_obj_t *obj = NULL; + isc_result_t result; + + result = cfg_map_get(map, "type", &obj); + INSIST(result == ISC_R_SUCCESS); + return (ns_config_getzonetype(obj)); +} + +/* + * Helper function for strtoargv(). Pardon the gratuitous recursion. + */ +static isc_result_t +strtoargvsub(isc_mem_t *mctx, char *s, unsigned int *argcp, + char ***argvp, unsigned int n) +{ + isc_result_t result; + + /* Discard leading whitespace. */ + while (*s == ' ' || *s == '\t') + s++; + + if (*s == '\0') { + /* We have reached the end of the string. */ + *argcp = n; + *argvp = isc_mem_get(mctx, n * sizeof(char *)); + if (*argvp == NULL) + return (ISC_R_NOMEMORY); + } else { + char *p = s; + while (*p != ' ' && *p != '\t' && *p != '\0') + p++; + if (*p != '\0') + *p++ = '\0'; + + result = strtoargvsub(mctx, p, argcp, argvp, n + 1); + if (result != ISC_R_SUCCESS) + return (result); + (*argvp)[n] = s; + } + return (ISC_R_SUCCESS); +} + +/* + * Tokenize the string "s" into whitespace-separated words, + * return the number of words in '*argcp' and an array + * of pointers to the words in '*argvp'. The caller + * must free the array using isc_mem_put(). The string + * is modified in-place. + */ +static isc_result_t +strtoargv(isc_mem_t *mctx, char *s, unsigned int *argcp, char ***argvp) { + return (strtoargvsub(mctx, s, argcp, argvp, 0)); +} + +static void +checknames(dns_zonetype_t ztype, cfg_obj_t **maps, cfg_obj_t **objp) { + const char *zone = NULL; + isc_result_t result; + + switch (ztype) { + case dns_zone_slave: zone = "slave"; break; + case dns_zone_master: zone = "master"; break; + default: + INSIST(0); + } + result = ns_checknames_get(maps, zone, objp); + INSIST(result == ISC_R_SUCCESS); +} + +isc_result_t +ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig, + ns_aclconfctx_t *ac, dns_zone_t *zone) +{ + isc_result_t result; + char *zname; + dns_rdataclass_t zclass; + dns_rdataclass_t vclass; + cfg_obj_t *maps[5]; + cfg_obj_t *zoptions = NULL; + cfg_obj_t *options = NULL; + cfg_obj_t *obj; + const char *filename = NULL; + dns_notifytype_t notifytype = dns_notifytype_yes; + isc_sockaddr_t *addrs; + dns_name_t **keynames; + isc_uint32_t count; + char *cpval; + unsigned int dbargc; + char **dbargv; + static char default_dbtype[] = "rbt"; + isc_mem_t *mctx = dns_zone_getmctx(zone); + dns_dialuptype_t dialup = dns_dialuptype_no; + dns_zonetype_t ztype; + int i; + isc_int32_t journal_size; + isc_boolean_t multi; + isc_boolean_t alt; + dns_view_t *view; + isc_boolean_t check = ISC_FALSE, fail = ISC_FALSE; + + i = 0; + if (zconfig != NULL) { + zoptions = cfg_tuple_get(zconfig, "options"); + maps[i++] = zoptions; + } + if (vconfig != NULL) + maps[i++] = cfg_tuple_get(vconfig, "options"); + if (config != NULL) { + (void)cfg_map_get(config, "options", &options); + if (options != NULL) + maps[i++] = options; + } + maps[i++] = ns_g_defaults; + maps[i++] = NULL; + + if (vconfig != NULL) + RETERR(ns_config_getclass(cfg_tuple_get(vconfig, "class"), + dns_rdataclass_in, &vclass)); + else + vclass = dns_rdataclass_in; + + /* + * Configure values common to all zone types. + */ + + zname = cfg_obj_asstring(cfg_tuple_get(zconfig, "name")); + + RETERR(ns_config_getclass(cfg_tuple_get(zconfig, "class"), + vclass, &zclass)); + dns_zone_setclass(zone, zclass); + + ztype = zonetype_fromconfig(zoptions); + dns_zone_settype(zone, ztype); + + obj = NULL; + result = cfg_map_get(zoptions, "database", &obj); + if (result == ISC_R_SUCCESS) + cpval = cfg_obj_asstring(obj); + else + cpval = default_dbtype; + RETERR(strtoargv(mctx, cpval, &dbargc, &dbargv)); + /* + * ANSI C is strange here. There is no logical reason why (char **) + * cannot be promoted automatically to (const char * const *) by the + * compiler w/o generating a warning. + */ + RETERR(dns_zone_setdbtype(zone, dbargc, (const char * const *)dbargv)); + isc_mem_put(mctx, dbargv, dbargc * sizeof(*dbargv)); + + obj = NULL; + result = cfg_map_get(zoptions, "file", &obj); + if (result == ISC_R_SUCCESS) + filename = cfg_obj_asstring(obj); + RETERR(dns_zone_setfile(zone, filename)); + + if (ztype == dns_zone_slave) + RETERR(configure_zone_acl(zconfig, vconfig, config, + "allow-notify", ac, zone, + dns_zone_setnotifyacl, + dns_zone_clearnotifyacl)); + /* + * XXXAG This probably does not make sense for stubs. + */ + RETERR(configure_zone_acl(zconfig, vconfig, config, + "allow-query", ac, zone, + dns_zone_setqueryacl, + dns_zone_clearqueryacl)); + + obj = NULL; + result = ns_config_get(maps, "dialup", &obj); + INSIST(result == ISC_R_SUCCESS); + if (cfg_obj_isboolean(obj)) { + if (cfg_obj_asboolean(obj)) + dialup = dns_dialuptype_yes; + else + dialup = dns_dialuptype_no; + } else { + char *dialupstr = cfg_obj_asstring(obj); + if (strcasecmp(dialupstr, "notify") == 0) + dialup = dns_dialuptype_notify; + else if (strcasecmp(dialupstr, "notify-passive") == 0) + dialup = dns_dialuptype_notifypassive; + else if (strcasecmp(dialupstr, "refresh") == 0) + dialup = dns_dialuptype_refresh; + else if (strcasecmp(dialupstr, "passive") == 0) + dialup = dns_dialuptype_passive; + else + INSIST(0); + } + dns_zone_setdialup(zone, dialup); + + obj = NULL; + result = ns_config_get(maps, "zone-statistics", &obj); + INSIST(result == ISC_R_SUCCESS); + RETERR(dns_zone_setstatistics(zone, cfg_obj_asboolean(obj))); + + /* + * Configure master functionality. This applies + * to primary masters (type "master") and slaves + * acting as masters (type "slave"), but not to stubs. + */ + if (ztype != dns_zone_stub) { + obj = NULL; + result = ns_config_get(maps, "notify", &obj); + INSIST(result == ISC_R_SUCCESS); + if (cfg_obj_isboolean(obj)) { + if (cfg_obj_asboolean(obj)) + notifytype = dns_notifytype_yes; + else + notifytype = dns_notifytype_no; + } else { + char *notifystr = cfg_obj_asstring(obj); + if (strcasecmp(notifystr, "explicit") == 0) + notifytype = dns_notifytype_explicit; + else + INSIST(0); + } + dns_zone_setnotifytype(zone, notifytype); + + obj = NULL; + result = ns_config_get(maps, "also-notify", &obj); + if (result == ISC_R_SUCCESS) { + isc_sockaddr_t *addrs = NULL; + isc_uint32_t addrcount; + result = ns_config_getiplist(config, obj, 0, mctx, + &addrs, &addrcount); + if (result != ISC_R_SUCCESS) + return (result); + result = dns_zone_setalsonotify(zone, addrs, + addrcount); + ns_config_putiplist(mctx, &addrs, addrcount); + if (result != ISC_R_SUCCESS) + return (result); + } else + RETERR(dns_zone_setalsonotify(zone, NULL, 0)); + + obj = NULL; + result = ns_config_get(maps, "notify-source", &obj); + INSIST(result == ISC_R_SUCCESS); + RETERR(dns_zone_setnotifysrc4(zone, cfg_obj_assockaddr(obj))); + ns_add_reserved_dispatch(ns_g_server, cfg_obj_assockaddr(obj)); + + obj = NULL; + result = ns_config_get(maps, "notify-source-v6", &obj); + INSIST(result == ISC_R_SUCCESS); + RETERR(dns_zone_setnotifysrc6(zone, cfg_obj_assockaddr(obj))); + ns_add_reserved_dispatch(ns_g_server, cfg_obj_assockaddr(obj)); + + RETERR(configure_zone_acl(zconfig, vconfig, config, + "allow-transfer", ac, zone, + dns_zone_setxfracl, + dns_zone_clearxfracl)); + + obj = NULL; + result = ns_config_get(maps, "max-transfer-time-out", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setmaxxfrout(zone, cfg_obj_asuint32(obj) * 60); + + obj = NULL; + result = ns_config_get(maps, "max-transfer-idle-out", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setidleout(zone, cfg_obj_asuint32(obj) * 60); + + obj = NULL; + result = ns_config_get(maps, "max-journal-size", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setjournalsize(zone, -1); + if (cfg_obj_isstring(obj)) { + const char *str = cfg_obj_asstring(obj); + INSIST(strcasecmp(str, "unlimited") == 0); + journal_size = ISC_UINT32_MAX / 2; + } else { + isc_resourcevalue_t value; + value = cfg_obj_asuint64(obj); + if (value > ISC_UINT32_MAX / 2) { + cfg_obj_log(obj, ns_g_lctx, + ISC_LOG_ERROR, + "'max-journal-size " + "%" ISC_PRINT_QUADFORMAT "d' " + "is too large", + value); + RETERR(ISC_R_RANGE); + } + journal_size = (isc_uint32_t)value; + } + dns_zone_setjournalsize(zone, journal_size); + + obj = NULL; + result = ns_config_get(maps, "ixfr-from-differences", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setoption(zone, DNS_ZONEOPT_IXFRFROMDIFFS, + cfg_obj_asboolean(obj)); + + checknames(ztype, maps, &obj); + INSIST(obj != NULL); + if (strcasecmp(cfg_obj_asstring(obj), "warn") == 0) { + fail = ISC_FALSE; + check = ISC_TRUE; + } else if (strcasecmp(cfg_obj_asstring(obj), "fail") == 0) { + fail = check = ISC_TRUE; + } else if (strcasecmp(cfg_obj_asstring(obj), "ignore") == 0) { + fail = check = ISC_FALSE; + } else + INSIST(0); + dns_zone_setoption(zone, DNS_ZONEOPT_CHECKNAMES, check); + dns_zone_setoption(zone, DNS_ZONEOPT_CHECKNAMESFAIL, fail); + } + + /* + * Configure update-related options. These apply to + * primary masters only. + */ + if (ztype == dns_zone_master) { + dns_acl_t *updateacl; + RETERR(configure_zone_acl(zconfig, vconfig, config, + "allow-update", ac, zone, + dns_zone_setupdateacl, + dns_zone_clearupdateacl)); + + updateacl = dns_zone_getupdateacl(zone); + if (updateacl != NULL && dns_acl_isinsecure(updateacl)) + isc_log_write(ns_g_lctx, DNS_LOGCATEGORY_SECURITY, + NS_LOGMODULE_SERVER, ISC_LOG_WARNING, + "zone '%s' allows updates by IP " + "address, which is insecure", + zname); + + RETERR(configure_zone_ssutable(zoptions, zone)); + + obj = NULL; + result = ns_config_get(maps, "sig-validity-interval", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setsigvalidityinterval(zone, + cfg_obj_asuint32(obj) * 86400); + + obj = NULL; + result = ns_config_get(maps, "key-directory", &obj); + if (result == ISC_R_SUCCESS) { + filename = cfg_obj_asstring(obj); + if (!isc_file_isabsolute(filename)) { + cfg_obj_log(obj, ns_g_lctx, ISC_LOG_ERROR, + "key-directory '%s' " + "is not absolute", filename); + return (ISC_R_FAILURE); + } + RETERR(dns_zone_setkeydirectory(zone, filename)); + } + + } else if (ztype == dns_zone_slave) { + RETERR(configure_zone_acl(zconfig, vconfig, config, + "allow-update-forwarding", ac, zone, + dns_zone_setforwardacl, + dns_zone_clearforwardacl)); + } + + /* + * Configure slave functionality. + */ + switch (ztype) { + case dns_zone_slave: + case dns_zone_stub: + obj = NULL; + result = cfg_map_get(zoptions, "masters", &obj); + if (obj != NULL) { + addrs = NULL; + keynames = NULL; + RETERR(ns_config_getipandkeylist(config, obj, mctx, + &addrs, &keynames, + &count)); + result = dns_zone_setmasterswithkeys(zone, addrs, + keynames, count); + ns_config_putipandkeylist(mctx, &addrs, &keynames, + count); + } else + result = dns_zone_setmasters(zone, NULL, 0); + RETERR(result); + + multi = ISC_FALSE; + if (count > 1) { + obj = NULL; + result = ns_config_get(maps, "multi-master", &obj); + INSIST(result == ISC_R_SUCCESS); + multi = cfg_obj_asboolean(obj); + } + dns_zone_setoption(zone, DNS_ZONEOPT_MULTIMASTER, multi); + + obj = NULL; + result = ns_config_get(maps, "max-transfer-time-in", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setmaxxfrin(zone, cfg_obj_asuint32(obj) * 60); + + obj = NULL; + result = ns_config_get(maps, "max-transfer-idle-in", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setidlein(zone, cfg_obj_asuint32(obj) * 60); + + obj = NULL; + result = ns_config_get(maps, "max-refresh-time", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setmaxrefreshtime(zone, cfg_obj_asuint32(obj)); + + obj = NULL; + result = ns_config_get(maps, "min-refresh-time", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setminrefreshtime(zone, cfg_obj_asuint32(obj)); + + obj = NULL; + result = ns_config_get(maps, "max-retry-time", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setmaxretrytime(zone, cfg_obj_asuint32(obj)); + + obj = NULL; + result = ns_config_get(maps, "min-retry-time", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setminretrytime(zone, cfg_obj_asuint32(obj)); + + obj = NULL; + result = ns_config_get(maps, "transfer-source", &obj); + INSIST(result == ISC_R_SUCCESS); + RETERR(dns_zone_setxfrsource4(zone, cfg_obj_assockaddr(obj))); + ns_add_reserved_dispatch(ns_g_server, cfg_obj_assockaddr(obj)); + + obj = NULL; + result = ns_config_get(maps, "transfer-source-v6", &obj); + INSIST(result == ISC_R_SUCCESS); + RETERR(dns_zone_setxfrsource6(zone, cfg_obj_assockaddr(obj))); + ns_add_reserved_dispatch(ns_g_server, cfg_obj_assockaddr(obj)); + + obj = NULL; + result = ns_config_get(maps, "alt-transfer-source", &obj); + INSIST(result == ISC_R_SUCCESS); + RETERR(dns_zone_setaltxfrsource4(zone, cfg_obj_assockaddr(obj))); + + obj = NULL; + result = ns_config_get(maps, "alt-transfer-source-v6", &obj); + INSIST(result == ISC_R_SUCCESS); + RETERR(dns_zone_setaltxfrsource6(zone, cfg_obj_assockaddr(obj))); + + obj = NULL; + (void)ns_config_get(maps, "use-alt-transfer-source", &obj); + if (obj == NULL) { + /* + * Default off when views are in use otherwise + * on for BIND 8 compatibility. + */ + view = dns_zone_getview(zone); + if (view != NULL && strcmp(view->name, "_default") == 0) + alt = ISC_TRUE; + else + alt = ISC_FALSE; + } else + alt = cfg_obj_asboolean(obj); + dns_zone_setoption(zone, DNS_ZONEOPT_USEALTXFRSRC, alt); + + break; + + default: + break; + } + + return (ISC_R_SUCCESS); +} + +isc_boolean_t +ns_zone_reusable(dns_zone_t *zone, cfg_obj_t *zconfig) { + cfg_obj_t *zoptions = NULL; + cfg_obj_t *obj = NULL; + const char *cfilename; + const char *zfilename; + + zoptions = cfg_tuple_get(zconfig, "options"); + + if (zonetype_fromconfig(zoptions) != dns_zone_gettype(zone)) + return (ISC_FALSE); + + obj = NULL; + (void)cfg_map_get(zoptions, "file", &obj); + if (obj != NULL) + cfilename = cfg_obj_asstring(obj); + else + cfilename = NULL; + zfilename = dns_zone_getfile(zone); + if (!((cfilename == NULL && zfilename == NULL) || + (cfilename != NULL && zfilename != NULL && + strcmp(cfilename, zfilename) == 0))) + return (ISC_FALSE); + + return (ISC_TRUE); +} diff --git a/contrib/bind9/bin/nsupdate/Makefile.in b/contrib/bind9/bin/nsupdate/Makefile.in new file mode 100644 index 000000000000..2652628768da --- /dev/null +++ b/contrib/bind9/bin/nsupdate/Makefile.in @@ -0,0 +1,83 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000-2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.15.12.10 2004/07/20 07:01:49 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_VERSION@ + +@BIND9_MAKE_INCLUDES@ + +CINCLUDES = ${LWRES_INCLUDES} ${DNS_INCLUDES} ${BIND9_INCLUDES} \ + ${ISC_INCLUDES} + +CDEFINES = +CWARNINGS = + +LWRESLIBS = ../../lib/lwres/liblwres.@A@ +DNSLIBS = ../../lib/dns/libdns.@A@ @DNS_CRYPTO_LIBS@ +BIND9LIBS = ../../lib/bind9/libbind9.@A@ +ISCLIBS = ../../lib/isc/libisc.@A@ +ISCCFGLIBS = ../../lib/isccfg/libisccfg.@A@ + +LWRESDEPLIBS = ../../lib/lwres/liblwres.@A@ +DNSDEPLIBS = ../../lib/dns/libdns.@A@ +BIND9DEPLIBS = ../../lib/bind9/libbind9.@A@ +ISCDEPLIBS = ../../lib/isc/libisc.@A@ +ISCCFGDEPLIBS = ../../lib/isccfg/libisccfg.@A@ + +DEPLIBS = ${DNSDEPLIBS} ${BIND9DEPLIBS} ${ISCDEPLIBS} ${ISCCFGDEPLIBS} + +LIBS = ${LWRESLIBS} ${DNSLIBS} ${BIND9LIBS} ${ISCLIBS} ${ISCCFGLIBS} @LIBS@ + +SUBDIRS = + +TARGETS = nsupdate@EXEEXT@ + +OBJS = nsupdate.@O@ + +UOBJS = + +SRCS = nsupdate.c + +MANPAGES = nsupdate.8 + +HTMLPAGES = nsupdate.html + +MANOBJS = ${MANPAGES} ${HTMLPAGES} + +@BIND9_MAKE_RULES@ + +nsupdate@EXEEXT@: nsupdate.@O@ ${UOBJS} ${DEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ nsupdate.@O@ ${UOBJS} ${LIBS} + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f ${MANOBJS} + +clean distclean:: + rm -f ${TARGETS} + +installdirs: + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${bindir} + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man8 + +install:: nsupdate@EXEEXT@ installdirs + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} nsupdate@EXEEXT@ ${DESTDIR}${bindir} + ${INSTALL_DATA} ${srcdir}/nsupdate.8 ${DESTDIR}${mandir}/man8 diff --git a/contrib/bind9/bin/nsupdate/nsupdate.8 b/contrib/bind9/bin/nsupdate/nsupdate.8 new file mode 100644 index 000000000000..7828db23a8b9 --- /dev/null +++ b/contrib/bind9/bin/nsupdate/nsupdate.8 @@ -0,0 +1,369 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2003 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: nsupdate.8,v 1.24.2.2.2.5 2004/03/08 09:04:15 marka Exp $ +.\" +.TH "NSUPDATE" "8" "Jun 30, 2000" "BIND9" "" +.SH NAME +nsupdate \- Dynamic DNS update utility +.SH SYNOPSIS +.sp +\fBnsupdate\fR [ \fB-d\fR ] [ \fB [ -y \fIkeyname:secret\fB ] [ -k \fIkeyfile\fB ] \fR ] [ \fB-t \fItimeout\fB\fR ] [ \fB-u \fIudptimeout\fB\fR ] [ \fB-r \fIudpretries\fB\fR ] [ \fB-v\fR ] [ \fBfilename\fR ] +.SH "DESCRIPTION" +.PP +\fBnsupdate\fR +is used to submit Dynamic DNS Update requests as defined in RFC2136 +to a name server. +This allows resource records to be added or removed from a zone +without manually editing the zone file. +A single update request can contain requests to add or remove more than one +resource record. +.PP +Zones that are under dynamic control via +\fBnsupdate\fR +or a DHCP server should not be edited by hand. +Manual edits could +conflict with dynamic updates and cause data to be lost. +.PP +The resource records that are dynamically added or removed with +\fBnsupdate\fR +have to be in the same zone. +Requests are sent to the zone's master server. +This is identified by the MNAME field of the zone's SOA record. +.PP +The +\fB-d\fR +option makes +\fBnsupdate\fR +operate in debug mode. +This provides tracing information about the update requests that are +made and the replies received from the name server. +.PP +Transaction signatures can be used to authenticate the Dynamic DNS +updates. +These use the TSIG resource record type described in RFC2845 or the +SIG(0) record described in RFC3535 and RFC2931. +TSIG relies on a shared secret that should only be known to +\fBnsupdate\fR and the name server. +Currently, the only supported encryption algorithm for TSIG is +HMAC-MD5, which is defined in RFC 2104. +Once other algorithms are defined for TSIG, applications will need to +ensure they select the appropriate algorithm as well as the key when +authenticating each other. +For instance suitable +\fBkey\fR +and +\fBserver\fR +statements would be added to +\fI/etc/named.conf\fR +so that the name server can associate the appropriate secret key +and algorithm with the IP address of the +client application that will be using TSIG authentication. +SIG(0) uses public key cryptography. To use a SIG(0) key, the public +key must be stored in a KEY record in a zone served by the name server. +\fBnsupdate\fR +does not read +\fI/etc/named.conf\fR. +.PP +\fBnsupdate\fR +uses the +\fB-y\fR +or +\fB-k\fR +option (with an HMAC-MD5 key) to provide the shared secret needed to generate +a TSIG record for authenticating Dynamic DNS update requests. +These options are mutually exclusive. +With the +\fB-k\fR +option, +\fBnsupdate\fR +reads the shared secret from the file +\fIkeyfile\fR, +whose name is of the form +\fIK{name}.+157.+{random}.private\fR. +For historical +reasons, the file +\fIK{name}.+157.+{random}.key\fR +must also be present. When the +\fB-y\fR +option is used, a signature is generated from +\fIkeyname:secret.\fR +\fIkeyname\fR +is the name of the key, +and +\fIsecret\fR +is the base64 encoded shared secret. +Use of the +\fB-y\fR +option is discouraged because the shared secret is supplied as a command +line argument in clear text. +This may be visible in the output from +\fBps\fR(1) +or in a history file maintained by the user's shell. +.PP +The \fB-k\fR may also be used to specify a SIG(0) key used +to authenticate Dynamic DNS update requests. In this case, the key +specified is not an HMAC-MD5 key. +.PP +By default +\fBnsupdate\fR +uses UDP to send update requests to the name server unless they are too +large to fit in a UDP request in which case TCP will be used. +The +\fB-v\fR +option makes +\fBnsupdate\fR +use a TCP connection. +This may be preferable when a batch of update requests is made. +.PP +The \fB-t\fR option sets the maximum time a update request can +take before it is aborted. The default is 300 seconds. Zero can be used +to disable the timeout. +.PP +The \fB-u\fR option sets the UDP retry interval. The default is +3 seconds. If zero the interval will be computed from the timeout interval +and number of UDP retries. +.PP +The \fB-r\fR option sets the number of UDP retries. The default is +3. If zero only one update request will be made. +.SH "INPUT FORMAT" +.PP +\fBnsupdate\fR +reads input from +\fIfilename\fR +or standard input. +Each command is supplied on exactly one line of input. +Some commands are for administrative purposes. +The others are either update instructions or prerequisite checks on the +contents of the zone. +These checks set conditions that some name or set of +resource records (RRset) either exists or is absent from the zone. +These conditions must be met if the entire update request is to succeed. +Updates will be rejected if the tests for the prerequisite conditions fail. +.PP +Every update request consists of zero or more prerequisites +and zero or more updates. +This allows a suitably authenticated update request to proceed if some +specified resource records are present or missing from the zone. +A blank input line (or the \fBsend\fR command) causes the +accumulated commands to be sent as one Dynamic DNS update request to the +name server. +.PP +The command formats and their meaning are as follows: +.TP +\fBserver servername [ port ]\fR +Sends all dynamic update requests to the name server +\fIservername\fR. +When no server statement is provided, +\fBnsupdate\fR +will send updates to the master server of the correct zone. +The MNAME field of that zone's SOA record will identify the master +server for that zone. +\fIport\fR +is the port number on +\fIservername\fR +where the dynamic update requests get sent. +If no port number is specified, the default DNS port number of 53 is +used. +.TP +\fBlocal address [ port ]\fR +Sends all dynamic update requests using the local +\fIaddress\fR. +When no local statement is provided, +\fBnsupdate\fR +will send updates using an address and port chosen by the system. +\fIport\fR +can additionally be used to make requests come from a specific port. +If no port number is specified, the system will assign one. +.TP +\fBzone zonename\fR +Specifies that all updates are to be made to the zone +\fIzonename\fR. +If no +\fIzone\fR +statement is provided, +\fBnsupdate\fR +will attempt determine the correct zone to update based on the rest of the input. +.TP +\fBclass classname\fR +Specify the default class. +If no \fIclass\fR is specified the default class is +\fIIN\fR. +.TP +\fBkey name secret\fR +Specifies that all updates are to be TSIG signed using the +\fIkeyname\fR \fIkeysecret\fR pair. +The \fBkey\fR command +overrides any key specified on the command line via +\fB-y\fR or \fB-k\fR. +.TP +\fBprereq nxdomain domain-name\fR +Requires that no resource record of any type exists with name +\fIdomain-name\fR. +.TP +\fBprereq yxdomain domain-name\fR +Requires that +\fIdomain-name\fR +exists (has as at least one resource record, of any type). +.TP +\fBprereq nxrrset domain-name [ class ] type\fR +Requires that no resource record exists of the specified +\fItype\fR, +\fIclass\fR +and +\fIdomain-name\fR. +If +\fIclass\fR +is omitted, IN (internet) is assumed. +.TP +\fBprereq yxrrset domain-name [ class ] type\fR +This requires that a resource record of the specified +\fItype\fR, +\fIclass\fR +and +\fIdomain-name\fR +must exist. +If +\fIclass\fR +is omitted, IN (internet) is assumed. +.TP +\fBprereq yxrrset domain-name [ class ] type data\fI...\fB\fR +The +\fIdata\fR +from each set of prerequisites of this form +sharing a common +\fItype\fR, +\fIclass\fR, +and +\fIdomain-name\fR +are combined to form a set of RRs. This set of RRs must +exactly match the set of RRs existing in the zone at the +given +\fItype\fR, +\fIclass\fR, +and +\fIdomain-name\fR. +The +\fIdata\fR +are written in the standard text representation of the resource record's +RDATA. +.TP +\fBupdate delete domain-name [ ttl ] [ class ] [ type [ data\fI...\fB ] ]\fR +Deletes any resource records named +\fIdomain-name\fR. +If +\fItype\fR +and +\fIdata\fR +is provided, only matching resource records will be removed. +The internet class is assumed if +\fIclass\fR +is not supplied. The +\fIttl\fR +is ignored, and is only allowed for compatibility. +.TP +\fBupdate add domain-name ttl [ class ] type data\fI...\fB\fR +Adds a new resource record with the specified +\fIttl\fR, +\fIclass\fR +and +\fIdata\fR. +.TP +\fBshow\fR +Displays the current message, containing all of the prerequisites and +updates specified since the last send. +.TP +\fBsend\fR +Sends the current message. This is equivalent to entering a blank line. +.TP +\fBanswer\fR +Displays the answer. +.PP +Lines beginning with a semicolon are comments and are ignored. +.SH "EXAMPLES" +.PP +The examples below show how +\fBnsupdate\fR +could be used to insert and delete resource records from the +\fBexample.com\fR +zone. +Notice that the input in each example contains a trailing blank line so that +a group of commands are sent as one dynamic update request to the +master name server for +\fBexample.com\fR. +.sp +.nf +# nsupdate +> update delete oldhost.example.com A +> update add newhost.example.com 86400 A 172.16.1.1 +> send +.sp +.fi +.PP +Any A records for +\fBoldhost.example.com\fR +are deleted. +and an A record for +\fBnewhost.example.com\fR +it IP address 172.16.1.1 is added. +The newly-added record has a 1 day TTL (86400 seconds) +.sp +.nf +# nsupdate +> prereq nxdomain nickname.example.com +> update add nickname.example.com 86400 CNAME somehost.example.com +> send +.sp +.fi +.PP +The prerequisite condition gets the name server to check that there +are no resource records of any type for +\fBnickname.example.com\fR. +If there are, the update request fails. +If this name does not exist, a CNAME for it is added. +This ensures that when the CNAME is added, it cannot conflict with the +long-standing rule in RFC1034 that a name must not exist as any other +record type if it exists as a CNAME. +(The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have +RRSIG, DNSKEY and NSEC records.) +.SH "FILES" +.TP +\fB/etc/resolv.conf\fR +used to identify default name server +.TP +\fBK{name}.+157.+{random}.key\fR +base-64 encoding of HMAC-MD5 key created by +\fBdnssec-keygen\fR(8). +.TP +\fBK{name}.+157.+{random}.private\fR +base-64 encoding of HMAC-MD5 key created by +\fBdnssec-keygen\fR(8). +.SH "SEE ALSO" +.PP +\fBRFC2136\fR, +\fBRFC3007\fR, +\fBRFC2104\fR, +\fBRFC2845\fR, +\fBRFC1034\fR, +\fBRFC2535\fR, +\fBRFC2931\fR, +\fBnamed\fR(8), +\fBdnssec-keygen\fR(8). +.SH "BUGS" +.PP +The TSIG key is redundantly stored in two separate files. +This is a consequence of nsupdate using the DST library +for its cryptographic operations, and may change in future +releases. diff --git a/contrib/bind9/bin/nsupdate/nsupdate.c b/contrib/bind9/bin/nsupdate/nsupdate.c new file mode 100644 index 000000000000..cb30a5f334ee --- /dev/null +++ b/contrib/bind9/bin/nsupdate/nsupdate.c @@ -0,0 +1,1983 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: nsupdate.c,v 1.103.2.15.2.16 2004/06/17 01:00:38 sra Exp $ */ + +#include + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include + +#include + +#ifdef HAVE_ADDRINFO +#ifdef HAVE_GETADDRINFO +#ifdef HAVE_GAISTRERROR +#define USE_GETADDRINFO +#endif +#endif +#endif + +#ifndef USE_GETADDRINFO +#ifndef ISC_PLATFORM_NONSTDHERRNO +extern int h_errno; +#endif +#endif + +#define MAXCMD (4 * 1024) +#define MAXWIRE (64 * 1024) +#define PACKETSIZE ((64 * 1024) - 1) +#define INITTEXT (2 * 1024) +#define MAXTEXT (128 * 1024) +#define FIND_TIMEOUT 5 +#define TTL_MAX 2147483647U /* Maximum signed 32 bit integer. */ + +#define DNSDEFAULTPORT 53 + +#ifndef RESOLV_CONF +#define RESOLV_CONF "/etc/resolv.conf" +#endif + +static isc_boolean_t debugging = ISC_FALSE, ddebugging = ISC_FALSE; +static isc_boolean_t memdebugging = ISC_FALSE; +static isc_boolean_t have_ipv4 = ISC_FALSE; +static isc_boolean_t have_ipv6 = ISC_FALSE; +static isc_boolean_t is_dst_up = ISC_FALSE; +static isc_boolean_t usevc = ISC_FALSE; +static isc_taskmgr_t *taskmgr = NULL; +static isc_task_t *global_task = NULL; +static isc_event_t *global_event = NULL; +static isc_mem_t *mctx = NULL; +static dns_dispatchmgr_t *dispatchmgr = NULL; +static dns_requestmgr_t *requestmgr = NULL; +static isc_socketmgr_t *socketmgr = NULL; +static isc_timermgr_t *timermgr = NULL; +static dns_dispatch_t *dispatchv4 = NULL; +static dns_dispatch_t *dispatchv6 = NULL; +static dns_message_t *updatemsg = NULL; +static dns_fixedname_t fuserzone; +static dns_name_t *userzone = NULL; +static dns_tsigkey_t *tsigkey = NULL; +static dst_key_t *sig0key; +static lwres_context_t *lwctx = NULL; +static lwres_conf_t *lwconf; +static isc_sockaddr_t *servers; +static int ns_inuse = 0; +static int ns_total = 0; +static isc_sockaddr_t *userserver = NULL; +static isc_sockaddr_t *localaddr = NULL; +static char *keystr = NULL, *keyfile = NULL; +static isc_entropy_t *entp = NULL; +static isc_boolean_t shuttingdown = ISC_FALSE; +static FILE *input; +static isc_boolean_t interactive = ISC_TRUE; +static isc_boolean_t seenerror = ISC_FALSE; +static const dns_master_style_t *style; +static int requests = 0; +static unsigned int timeout = 300; +static unsigned int udp_timeout = 3; +static unsigned int udp_retries = 3; +static dns_rdataclass_t defaultclass = dns_rdataclass_in; +static dns_rdataclass_t zoneclass = dns_rdataclass_none; +static dns_message_t *answer = NULL; + +typedef struct nsu_requestinfo { + dns_message_t *msg; + isc_sockaddr_t *addr; +} nsu_requestinfo_t; + +static void +sendrequest(isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr, + dns_message_t *msg, dns_request_t **request); +static void +fatal(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +static void +debug(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +static void +ddebug(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +#define STATUS_MORE (isc_uint16_t)0 +#define STATUS_SEND (isc_uint16_t)1 +#define STATUS_QUIT (isc_uint16_t)2 +#define STATUS_SYNTAX (isc_uint16_t)3 + +static dns_rdataclass_t +getzoneclass(void) { + if (zoneclass == dns_rdataclass_none) + zoneclass = defaultclass; + return (zoneclass); +} + +static isc_boolean_t +setzoneclass(dns_rdataclass_t rdclass) { + if (zoneclass == dns_rdataclass_none || + rdclass == dns_rdataclass_none) + zoneclass = rdclass; + if (zoneclass != rdclass) + return (ISC_FALSE); + return (ISC_TRUE); +} + +static void +fatal(const char *format, ...) { + va_list args; + + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + fprintf(stderr, "\n"); + exit(1); +} + +static void +debug(const char *format, ...) { + va_list args; + + if (debugging) { + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + fprintf(stderr, "\n"); + } +} + +static void +ddebug(const char *format, ...) { + va_list args; + + if (ddebugging) { + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + fprintf(stderr, "\n"); + } +} + +static inline void +check_result(isc_result_t result, const char *msg) { + if (result != ISC_R_SUCCESS) + fatal("%s: %s", msg, isc_result_totext(result)); +} + +static void * +mem_alloc(void *arg, size_t size) { + return (isc_mem_get(arg, size)); +} + +static void +mem_free(void *arg, void *mem, size_t size) { + isc_mem_put(arg, mem, size); +} + +static char * +nsu_strsep(char **stringp, const char *delim) { + char *string = *stringp; + char *s; + const char *d; + char sc, dc; + + if (string == NULL) + return (NULL); + + for (; *string != '\0'; string++) { + sc = *string; + for (d = delim; (dc = *d) != '\0'; d++) { + if (sc == dc) + break; + } + if (dc == 0) + break; + } + + for (s = string; *s != '\0'; s++) { + sc = *s; + for (d = delim; (dc = *d) != '\0'; d++) { + if (sc == dc) { + *s++ = '\0'; + *stringp = s; + return (string); + } + } + } + *stringp = NULL; + return (string); +} + +static void +reset_system(void) { + isc_result_t result; + + ddebug("reset_system()"); + /* If the update message is still around, destroy it */ + if (updatemsg != NULL) + dns_message_reset(updatemsg, DNS_MESSAGE_INTENTRENDER); + else { + result = dns_message_create(mctx, DNS_MESSAGE_INTENTRENDER, + &updatemsg); + check_result(result, "dns_message_create"); + } + updatemsg->opcode = dns_opcode_update; +} + +static void +setup_keystr(void) { + unsigned char *secret = NULL; + int secretlen; + isc_buffer_t secretbuf; + isc_result_t result; + isc_buffer_t keynamesrc; + char *secretstr; + char *s; + dns_fixedname_t fkeyname; + dns_name_t *keyname; + + dns_fixedname_init(&fkeyname); + keyname = dns_fixedname_name(&fkeyname); + + debug("Creating key..."); + + s = strchr(keystr, ':'); + if (s == NULL || s == keystr || *s == 0) + fatal("key option must specify keyname:secret"); + secretstr = s + 1; + + isc_buffer_init(&keynamesrc, keystr, s - keystr); + isc_buffer_add(&keynamesrc, s - keystr); + + debug("namefromtext"); + result = dns_name_fromtext(keyname, &keynamesrc, dns_rootname, + ISC_FALSE, NULL); + check_result(result, "dns_name_fromtext"); + + secretlen = strlen(secretstr) * 3 / 4; + secret = isc_mem_allocate(mctx, secretlen); + if (secret == NULL) + fatal("out of memory"); + + isc_buffer_init(&secretbuf, secret, secretlen); + result = isc_base64_decodestring(secretstr, &secretbuf); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not create key from %s: %s\n", + keystr, isc_result_totext(result)); + goto failure; + } + + secretlen = isc_buffer_usedlength(&secretbuf); + + debug("keycreate"); + result = dns_tsigkey_create(keyname, dns_tsig_hmacmd5_name, + secret, secretlen, ISC_TRUE, NULL, + 0, 0, mctx, NULL, &tsigkey); + if (result != ISC_R_SUCCESS) + fprintf(stderr, "could not create key from %s: %s\n", + keystr, dns_result_totext(result)); + failure: + if (secret != NULL) + isc_mem_free(mctx, secret); +} + +static void +setup_keyfile(void) { + dst_key_t *dstkey = NULL; + isc_result_t result; + + debug("Creating key..."); + + result = dst_key_fromnamedfile(keyfile, + DST_TYPE_PRIVATE | DST_TYPE_KEY, mctx, + &dstkey); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not read key from %s: %s\n", + keyfile, isc_result_totext(result)); + return; + } + if (dst_key_alg(dstkey) == DST_ALG_HMACMD5) { + result = dns_tsigkey_createfromkey(dst_key_name(dstkey), + dns_tsig_hmacmd5_name, + dstkey, ISC_FALSE, NULL, + 0, 0, mctx, NULL, &tsigkey); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not create key from %s: %s\n", + keyfile, isc_result_totext(result)); + dst_key_free(&dstkey); + return; + } + } else + sig0key = dstkey; +} + +static void +doshutdown(void) { + isc_task_detach(&global_task); + + if (userserver != NULL) + isc_mem_put(mctx, userserver, sizeof(isc_sockaddr_t)); + + if (localaddr != NULL) + isc_mem_put(mctx, localaddr, sizeof(isc_sockaddr_t)); + + if (tsigkey != NULL) { + ddebug("Freeing TSIG key"); + dns_tsigkey_detach(&tsigkey); + } + + if (sig0key != NULL) { + ddebug("Freeing SIG(0) key"); + dst_key_free(&sig0key); + } + + if (updatemsg != NULL) + dns_message_destroy(&updatemsg); + + if (is_dst_up) { + ddebug("Destroy DST lib"); + dst_lib_destroy(); + is_dst_up = ISC_FALSE; + } + + if (entp != NULL) { + ddebug("Detach from entropy"); + isc_entropy_detach(&entp); + } + + lwres_conf_clear(lwctx); + lwres_context_destroy(&lwctx); + + isc_mem_put(mctx, servers, ns_total * sizeof(isc_sockaddr_t)); + + ddebug("Destroying request manager"); + dns_requestmgr_detach(&requestmgr); + + ddebug("Freeing the dispatchers"); + if (have_ipv4) + dns_dispatch_detach(&dispatchv4); + if (have_ipv6) + dns_dispatch_detach(&dispatchv6); + + ddebug("Shutting down dispatch manager"); + dns_dispatchmgr_destroy(&dispatchmgr); + +} + +static void +maybeshutdown(void) { + ddebug("Shutting down request manager"); + dns_requestmgr_shutdown(requestmgr); + + if (requests != 0) + return; + + doshutdown(); +} + +static void +shutdown_program(isc_task_t *task, isc_event_t *event) { + REQUIRE(task == global_task); + UNUSED(task); + + ddebug("shutdown_program()"); + isc_event_free(&event); + + shuttingdown = ISC_TRUE; + maybeshutdown(); +} + +static void +setup_system(void) { + isc_result_t result; + isc_sockaddr_t bind_any, bind_any6; + lwres_result_t lwresult; + unsigned int attrs, attrmask; + int i; + + ddebug("setup_system()"); + + dns_result_register(); + + result = isc_net_probeipv4(); + if (result == ISC_R_SUCCESS) + have_ipv4 = ISC_TRUE; + + result = isc_net_probeipv6(); + if (result == ISC_R_SUCCESS) + have_ipv6 = ISC_TRUE; + + if (!have_ipv4 && !have_ipv6) + fatal("could not find either IPv4 or IPv6"); + + result = isc_mem_create(0, 0, &mctx); + check_result(result, "isc_mem_create"); + + lwresult = lwres_context_create(&lwctx, mctx, mem_alloc, mem_free, 1); + if (lwresult != LWRES_R_SUCCESS) + fatal("lwres_context_create failed"); + + (void)lwres_conf_parse(lwctx, RESOLV_CONF); + lwconf = lwres_conf_get(lwctx); + + ns_total = lwconf->nsnext; + if (ns_total <= 0) { + /* No name servers in resolv.conf; default to loopback. */ + struct in_addr localhost; + ns_total = 1; + servers = isc_mem_get(mctx, ns_total * sizeof(isc_sockaddr_t)); + if (servers == NULL) + fatal("out of memory"); + localhost.s_addr = htonl(INADDR_LOOPBACK); + isc_sockaddr_fromin(&servers[0], &localhost, DNSDEFAULTPORT); + } else { + servers = isc_mem_get(mctx, ns_total * sizeof(isc_sockaddr_t)); + if (servers == NULL) + fatal("out of memory"); + for (i = 0; i < ns_total; i++) { + if (lwconf->nameservers[i].family == LWRES_ADDRTYPE_V4) { + struct in_addr in4; + memcpy(&in4, lwconf->nameservers[i].address, 4); + isc_sockaddr_fromin(&servers[i], &in4, DNSDEFAULTPORT); + } else { + struct in6_addr in6; + memcpy(&in6, lwconf->nameservers[i].address, 16); + isc_sockaddr_fromin6(&servers[i], &in6, + DNSDEFAULTPORT); + } + } + } + + result = isc_entropy_create(mctx, &entp); + check_result(result, "isc_entropy_create"); + + result = isc_hash_create(mctx, entp, DNS_NAME_MAXWIRE); + check_result(result, "isc_hash_create"); + isc_hash_init(); + + result = dns_dispatchmgr_create(mctx, entp, &dispatchmgr); + check_result(result, "dns_dispatchmgr_create"); + + result = isc_socketmgr_create(mctx, &socketmgr); + check_result(result, "dns_socketmgr_create"); + + result = isc_timermgr_create(mctx, &timermgr); + check_result(result, "dns_timermgr_create"); + + result = isc_taskmgr_create(mctx, 1, 0, &taskmgr); + check_result(result, "isc_taskmgr_create"); + + result = isc_task_create(taskmgr, 0, &global_task); + check_result(result, "isc_task_create"); + + result = isc_task_onshutdown(global_task, shutdown_program, NULL); + check_result(result, "isc_task_onshutdown"); + + result = dst_lib_init(mctx, entp, 0); + check_result(result, "dst_lib_init"); + is_dst_up = ISC_TRUE; + + attrmask = DNS_DISPATCHATTR_UDP | DNS_DISPATCHATTR_TCP; + attrmask |= DNS_DISPATCHATTR_IPV4 | DNS_DISPATCHATTR_IPV6; + + if (have_ipv6) { + attrs = DNS_DISPATCHATTR_UDP; + attrs |= DNS_DISPATCHATTR_MAKEQUERY; + attrs |= DNS_DISPATCHATTR_IPV6; + isc_sockaddr_any6(&bind_any6); + result = dns_dispatch_getudp(dispatchmgr, socketmgr, taskmgr, + &bind_any6, PACKETSIZE, + 4, 2, 3, 5, + attrs, attrmask, &dispatchv6); + check_result(result, "dns_dispatch_getudp (v6)"); + } + + if (have_ipv4) { + attrs = DNS_DISPATCHATTR_UDP; + attrs |= DNS_DISPATCHATTR_MAKEQUERY; + attrs |= DNS_DISPATCHATTR_IPV4; + isc_sockaddr_any(&bind_any); + result = dns_dispatch_getudp(dispatchmgr, socketmgr, taskmgr, + &bind_any, PACKETSIZE, + 4, 2, 3, 5, + attrs, attrmask, &dispatchv4); + check_result(result, "dns_dispatch_getudp (v4)"); + } + + result = dns_requestmgr_create(mctx, timermgr, + socketmgr, taskmgr, dispatchmgr, + dispatchv4, dispatchv6, &requestmgr); + check_result(result, "dns_requestmgr_create"); + + if (keystr != NULL) + setup_keystr(); + else if (keyfile != NULL) + setup_keyfile(); +} + +static void +get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr) { + int count; + isc_result_t result; + + isc_app_block(); + result = bind9_getaddresses(host, port, sockaddr, 1, &count); + isc_app_unblock(); + if (result != ISC_R_SUCCESS) + fatal("couldn't get address for '%s': %s", + host, isc_result_totext(result)); + INSIST(count == 1); +} + +static void +parse_args(int argc, char **argv) { + int ch; + isc_result_t result; + + debug("parse_args"); + while ((ch = isc_commandline_parse(argc, argv, "dDMy:vk:r:t:u:")) != -1) + { + switch (ch) { + case 'd': + debugging = ISC_TRUE; + break; + case 'D': /* was -dd */ + debugging = ISC_TRUE; + ddebugging = ISC_TRUE; + break; + case 'M': /* was -dm */ + debugging = ISC_TRUE; + ddebugging = ISC_TRUE; + memdebugging = ISC_TRUE; + isc_mem_debugging = ISC_MEM_DEBUGTRACE | + ISC_MEM_DEBUGRECORD; + break; + case 'y': + keystr = isc_commandline_argument; + break; + case 'v': + usevc = ISC_TRUE; + break; + case 'k': + keyfile = isc_commandline_argument; + break; + case 't': + result = isc_parse_uint32(&timeout, + isc_commandline_argument, 10); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "bad timeout '%s'\n", isc_commandline_argument); + exit(1); + } + if (timeout == 0) + timeout = ULONG_MAX; + break; + case 'u': + result = isc_parse_uint32(&udp_timeout, + isc_commandline_argument, 10); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "bad udp timeout '%s'\n", isc_commandline_argument); + exit(1); + } + if (udp_timeout == 0) + udp_timeout = ULONG_MAX; + break; + case 'r': + result = isc_parse_uint32(&udp_retries, + isc_commandline_argument, 10); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "bad udp retries '%s'\n", isc_commandline_argument); + exit(1); + } + break; + default: + fprintf(stderr, "%s: invalid argument -%c\n", + argv[0], ch); + fprintf(stderr, "usage: nsupdate [-d] " + "[-y keyname:secret | -k keyfile] [-v] " + "[filename]\n"); + exit(1); + } + } + if (keyfile != NULL && keystr != NULL) { + fprintf(stderr, "%s: cannot specify both -k and -y\n", + argv[0]); + exit(1); + } + + if (argv[isc_commandline_index] != NULL) { + if (strcmp(argv[isc_commandline_index], "-") == 0) { + input = stdin; + } else { + result = isc_stdio_open(argv[isc_commandline_index], + "r", &input); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not open '%s': %s\n", + argv[isc_commandline_index], + isc_result_totext(result)); + exit(1); + } + } + interactive = ISC_FALSE; + } +} + +static isc_uint16_t +parse_name(char **cmdlinep, dns_message_t *msg, dns_name_t **namep) { + isc_result_t result; + char *word; + isc_buffer_t *namebuf = NULL; + isc_buffer_t source; + + word = nsu_strsep(cmdlinep, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read owner name\n"); + return (STATUS_SYNTAX); + } + + result = dns_message_gettempname(msg, namep); + check_result(result, "dns_message_gettempname"); + result = isc_buffer_allocate(mctx, &namebuf, DNS_NAME_MAXWIRE); + check_result(result, "isc_buffer_allocate"); + dns_name_init(*namep, NULL); + dns_name_setbuffer(*namep, namebuf); + dns_message_takebuffer(msg, &namebuf); + isc_buffer_init(&source, word, strlen(word)); + isc_buffer_add(&source, strlen(word)); + result = dns_name_fromtext(*namep, &source, dns_rootname, + ISC_FALSE, NULL); + check_result(result, "dns_name_fromtext"); + isc_buffer_invalidate(&source); + return (STATUS_MORE); +} + +static isc_uint16_t +parse_rdata(char **cmdlinep, dns_rdataclass_t rdataclass, + dns_rdatatype_t rdatatype, dns_message_t *msg, + dns_rdata_t *rdata) +{ + char *cmdline = *cmdlinep; + isc_buffer_t source, *buf = NULL, *newbuf = NULL; + isc_region_t r; + isc_lex_t *lex = NULL; + dns_rdatacallbacks_t callbacks; + isc_result_t result; + + while (*cmdline != 0 && isspace((unsigned char)*cmdline)) + cmdline++; + + if (*cmdline != 0) { + dns_rdatacallbacks_init(&callbacks); + result = isc_lex_create(mctx, strlen(cmdline), &lex); + check_result(result, "isc_lex_create"); + isc_buffer_init(&source, cmdline, strlen(cmdline)); + isc_buffer_add(&source, strlen(cmdline)); + result = isc_lex_openbuffer(lex, &source); + check_result(result, "isc_lex_openbuffer"); + result = isc_buffer_allocate(mctx, &buf, MAXWIRE); + check_result(result, "isc_buffer_allocate"); + result = dns_rdata_fromtext(rdata, rdataclass, rdatatype, lex, + dns_rootname, 0, mctx, buf, + &callbacks); + isc_lex_destroy(&lex); + if (result == ISC_R_SUCCESS) { + isc_buffer_usedregion(buf, &r); + result = isc_buffer_allocate(mctx, &newbuf, r.length); + check_result(result, "isc_buffer_allocate"); + isc_buffer_putmem(newbuf, r.base, r.length); + isc_buffer_usedregion(newbuf, &r); + dns_rdata_fromregion(rdata, rdataclass, rdatatype, &r); + isc_buffer_free(&buf); + dns_message_takebuffer(msg, &newbuf); + } else { + fprintf(stderr, "invalid rdata format: %s\n", + isc_result_totext(result)); + isc_buffer_free(&buf); + return (STATUS_SYNTAX); + } + } else { + rdata->flags = DNS_RDATA_UPDATE; + } + *cmdlinep = cmdline; + return (STATUS_MORE); +} + +static isc_uint16_t +make_prereq(char *cmdline, isc_boolean_t ispositive, isc_boolean_t isrrset) { + isc_result_t result; + char *word; + dns_name_t *name = NULL; + isc_textregion_t region; + dns_rdataset_t *rdataset = NULL; + dns_rdatalist_t *rdatalist = NULL; + dns_rdataclass_t rdataclass; + dns_rdatatype_t rdatatype; + dns_rdata_t *rdata = NULL; + isc_uint16_t retval; + + ddebug("make_prereq()"); + + /* + * Read the owner name + */ + retval = parse_name(&cmdline, updatemsg, &name); + if (retval != STATUS_MORE) + return (retval); + + /* + * If this is an rrset prereq, read the class or type. + */ + if (isrrset) { + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read class or type\n"); + goto failure; + } + region.base = word; + region.length = strlen(word); + result = dns_rdataclass_fromtext(&rdataclass, ®ion); + if (result == ISC_R_SUCCESS) { + if (!setzoneclass(rdataclass)) { + fprintf(stderr, "class mismatch: %s\n", word); + goto failure; + } + /* + * Now read the type. + */ + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read type\n"); + goto failure; + } + region.base = word; + region.length = strlen(word); + result = dns_rdatatype_fromtext(&rdatatype, ®ion); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "invalid type: %s\n", word); + goto failure; + } + } else { + rdataclass = getzoneclass(); + result = dns_rdatatype_fromtext(&rdatatype, ®ion); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "invalid type: %s\n", word); + goto failure; + } + } + } else + rdatatype = dns_rdatatype_any; + + result = dns_message_gettemprdata(updatemsg, &rdata); + check_result(result, "dns_message_gettemprdata"); + + rdata->data = NULL; + rdata->length = 0; + + if (isrrset && ispositive) { + retval = parse_rdata(&cmdline, rdataclass, rdatatype, + updatemsg, rdata); + if (retval != STATUS_MORE) + goto failure; + } else + rdata->flags = DNS_RDATA_UPDATE; + + result = dns_message_gettemprdatalist(updatemsg, &rdatalist); + check_result(result, "dns_message_gettemprdatalist"); + result = dns_message_gettemprdataset(updatemsg, &rdataset); + check_result(result, "dns_message_gettemprdataset"); + dns_rdatalist_init(rdatalist); + rdatalist->type = rdatatype; + if (ispositive) { + if (isrrset && rdata->data != NULL) + rdatalist->rdclass = rdataclass; + else + rdatalist->rdclass = dns_rdataclass_any; + } else + rdatalist->rdclass = dns_rdataclass_none; + rdatalist->covers = 0; + rdatalist->ttl = 0; + rdata->rdclass = rdatalist->rdclass; + rdata->type = rdatatype; + ISC_LIST_INIT(rdatalist->rdata); + ISC_LIST_APPEND(rdatalist->rdata, rdata, link); + dns_rdataset_init(rdataset); + dns_rdatalist_tordataset(rdatalist, rdataset); + ISC_LIST_INIT(name->list); + ISC_LIST_APPEND(name->list, rdataset, link); + dns_message_addname(updatemsg, name, DNS_SECTION_PREREQUISITE); + return (STATUS_MORE); + + failure: + if (name != NULL) + dns_message_puttempname(updatemsg, &name); + return (STATUS_SYNTAX); +} + +static isc_uint16_t +evaluate_prereq(char *cmdline) { + char *word; + isc_boolean_t ispositive, isrrset; + + ddebug("evaluate_prereq()"); + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read operation code\n"); + return (STATUS_SYNTAX); + } + if (strcasecmp(word, "nxdomain") == 0) { + ispositive = ISC_FALSE; + isrrset = ISC_FALSE; + } else if (strcasecmp(word, "yxdomain") == 0) { + ispositive = ISC_TRUE; + isrrset = ISC_FALSE; + } else if (strcasecmp(word, "nxrrset") == 0) { + ispositive = ISC_FALSE; + isrrset = ISC_TRUE; + } else if (strcasecmp(word, "yxrrset") == 0) { + ispositive = ISC_TRUE; + isrrset = ISC_TRUE; + } else { + fprintf(stderr, "incorrect operation code: %s\n", word); + return (STATUS_SYNTAX); + } + return (make_prereq(cmdline, ispositive, isrrset)); +} + +static isc_uint16_t +evaluate_server(char *cmdline) { + char *word, *server; + long port; + + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read server name\n"); + return (STATUS_SYNTAX); + } + server = word; + + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) + port = DNSDEFAULTPORT; + else { + char *endp; + port = strtol(word, &endp, 10); + if (*endp != 0) { + fprintf(stderr, "port '%s' is not numeric\n", word); + return (STATUS_SYNTAX); + } else if (port < 1 || port > 65535) { + fprintf(stderr, "port '%s' is out of range " + "(1 to 65535)\n", word); + return (STATUS_SYNTAX); + } + } + + if (userserver == NULL) { + userserver = isc_mem_get(mctx, sizeof(isc_sockaddr_t)); + if (userserver == NULL) + fatal("out of memory"); + } + + get_address(server, (in_port_t)port, userserver); + + return (STATUS_MORE); +} + +static isc_uint16_t +evaluate_local(char *cmdline) { + char *word, *local; + long port; + struct in_addr in4; + struct in6_addr in6; + + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read server name\n"); + return (STATUS_SYNTAX); + } + local = word; + + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) + port = 0; + else { + char *endp; + port = strtol(word, &endp, 10); + if (*endp != 0) { + fprintf(stderr, "port '%s' is not numeric\n", word); + return (STATUS_SYNTAX); + } else if (port < 1 || port > 65535) { + fprintf(stderr, "port '%s' is out of range " + "(1 to 65535)\n", word); + return (STATUS_SYNTAX); + } + } + + if (localaddr == NULL) { + localaddr = isc_mem_get(mctx, sizeof(isc_sockaddr_t)); + if (localaddr == NULL) + fatal("out of memory"); + } + + if (have_ipv6 && inet_pton(AF_INET6, local, &in6) == 1) + isc_sockaddr_fromin6(localaddr, &in6, (in_port_t)port); + else if (have_ipv4 && inet_pton(AF_INET, local, &in4) == 1) + isc_sockaddr_fromin(localaddr, &in4, (in_port_t)port); + else { + fprintf(stderr, "invalid address %s", local); + return (STATUS_SYNTAX); + } + + return (STATUS_MORE); +} + +static isc_uint16_t +evaluate_key(char *cmdline) { + char *namestr; + char *secretstr; + isc_buffer_t b; + isc_result_t result; + dns_fixedname_t fkeyname; + dns_name_t *keyname; + int secretlen; + unsigned char *secret = NULL; + isc_buffer_t secretbuf; + + namestr = nsu_strsep(&cmdline, " \t\r\n"); + if (*namestr == 0) { + fprintf(stderr, "could not read key name\n"); + return (STATUS_SYNTAX); + } + + dns_fixedname_init(&fkeyname); + keyname = dns_fixedname_name(&fkeyname); + + isc_buffer_init(&b, namestr, strlen(namestr)); + isc_buffer_add(&b, strlen(namestr)); + result = dns_name_fromtext(keyname, &b, dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not parse key name\n"); + return (STATUS_SYNTAX); + } + + secretstr = nsu_strsep(&cmdline, "\r\n"); + if (*secretstr == 0) { + fprintf(stderr, "could not read key secret\n"); + return (STATUS_SYNTAX); + } + secretlen = strlen(secretstr) * 3 / 4; + secret = isc_mem_allocate(mctx, secretlen); + if (secret == NULL) + fatal("out of memory"); + + isc_buffer_init(&secretbuf, secret, secretlen); + result = isc_base64_decodestring(secretstr, &secretbuf); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not create key from %s: %s\n", + secretstr, isc_result_totext(result)); + isc_mem_free(mctx, secret); + return (STATUS_SYNTAX); + } + secretlen = isc_buffer_usedlength(&secretbuf); + + if (tsigkey != NULL) + dns_tsigkey_detach(&tsigkey); + result = dns_tsigkey_create(keyname, dns_tsig_hmacmd5_name, + secret, secretlen, ISC_TRUE, NULL, 0, 0, + mctx, NULL, &tsigkey); + isc_mem_free(mctx, secret); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not create key from %s %s: %s\n", + namestr, secretstr, dns_result_totext(result)); + return (STATUS_SYNTAX); + } + return (STATUS_MORE); +} + +static isc_uint16_t +evaluate_zone(char *cmdline) { + char *word; + isc_buffer_t b; + isc_result_t result; + + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read zone name\n"); + return (STATUS_SYNTAX); + } + + dns_fixedname_init(&fuserzone); + userzone = dns_fixedname_name(&fuserzone); + isc_buffer_init(&b, word, strlen(word)); + isc_buffer_add(&b, strlen(word)); + result = dns_name_fromtext(userzone, &b, dns_rootname, ISC_FALSE, + NULL); + if (result != ISC_R_SUCCESS) { + userzone = NULL; /* Lest it point to an invalid name */ + fprintf(stderr, "could not parse zone name\n"); + return (STATUS_SYNTAX); + } + + return (STATUS_MORE); +} + +static isc_uint16_t +evaluate_class(char *cmdline) { + char *word; + isc_textregion_t r; + isc_result_t result; + dns_rdataclass_t rdclass; + + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read class name\n"); + return (STATUS_SYNTAX); + } + + r.base = word; + r.length = strlen(word); + result = dns_rdataclass_fromtext(&rdclass, &r); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not parse class name: %s\n", word); + return (STATUS_SYNTAX); + } + switch (rdclass) { + case dns_rdataclass_none: + case dns_rdataclass_any: + case dns_rdataclass_reserved0: + fprintf(stderr, "bad default class: %s\n", word); + return (STATUS_SYNTAX); + default: + defaultclass = rdclass; + } + + return (STATUS_MORE); +} + +static isc_uint16_t +update_addordelete(char *cmdline, isc_boolean_t isdelete) { + isc_result_t result; + dns_name_t *name = NULL; + isc_uint32_t ttl; + char *word; + dns_rdataclass_t rdataclass; + dns_rdatatype_t rdatatype; + dns_rdata_t *rdata = NULL; + dns_rdatalist_t *rdatalist = NULL; + dns_rdataset_t *rdataset = NULL; + isc_textregion_t region; + isc_uint16_t retval; + + ddebug("update_addordelete()"); + + /* + * Read the owner name. + */ + retval = parse_name(&cmdline, updatemsg, &name); + if (retval != STATUS_MORE) + return (retval); + + result = dns_message_gettemprdata(updatemsg, &rdata); + check_result(result, "dns_message_gettemprdata"); + + rdata->rdclass = 0; + rdata->type = 0; + rdata->data = NULL; + rdata->length = 0; + + /* + * If this is an add, read the TTL and verify that it's in range. + * If it's a delete, ignore a TTL if present (for compatibility). + */ + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + if (!isdelete) { + fprintf(stderr, "could not read owner ttl\n"); + goto failure; + } + else { + ttl = 0; + rdataclass = dns_rdataclass_any; + rdatatype = dns_rdatatype_any; + rdata->flags = DNS_RDATA_UPDATE; + goto doneparsing; + } + } + result = isc_parse_uint32(&ttl, word, 10); + if (result != ISC_R_SUCCESS) { + if (isdelete) { + ttl = 0; + goto parseclass; + } else { + fprintf(stderr, "ttl '%s': %s\n", word, + isc_result_totext(result)); + goto failure; + } + } + + if (isdelete) + ttl = 0; + else if (ttl > TTL_MAX) { + fprintf(stderr, "ttl '%s' is out of range (0 to %u)\n", + word, TTL_MAX); + goto failure; + } + + /* + * Read the class or type. + */ + word = nsu_strsep(&cmdline, " \t\r\n"); + parseclass: + if (*word == 0) { + if (isdelete) { + rdataclass = dns_rdataclass_any; + rdatatype = dns_rdatatype_any; + rdata->flags = DNS_RDATA_UPDATE; + goto doneparsing; + } else { + fprintf(stderr, "could not read class or type\n"); + goto failure; + } + } + region.base = word; + region.length = strlen(word); + result = dns_rdataclass_fromtext(&rdataclass, ®ion); + if (result == ISC_R_SUCCESS) { + if (!setzoneclass(rdataclass)) { + fprintf(stderr, "class mismatch: %s\n", word); + goto failure; + } + /* + * Now read the type. + */ + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + if (isdelete) { + rdataclass = dns_rdataclass_any; + rdatatype = dns_rdatatype_any; + rdata->flags = DNS_RDATA_UPDATE; + goto doneparsing; + } else { + fprintf(stderr, "could not read type\n"); + goto failure; + } + } + region.base = word; + region.length = strlen(word); + result = dns_rdatatype_fromtext(&rdatatype, ®ion); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "'%s' is not a valid type: %s\n", + word, isc_result_totext(result)); + goto failure; + } + } else { + rdataclass = getzoneclass(); + result = dns_rdatatype_fromtext(&rdatatype, ®ion); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "'%s' is not a valid class or type: " + "%s\n", word, isc_result_totext(result)); + goto failure; + } + } + + retval = parse_rdata(&cmdline, rdataclass, rdatatype, updatemsg, + rdata); + if (retval != STATUS_MORE) + goto failure; + + if (isdelete) { + if ((rdata->flags & DNS_RDATA_UPDATE) != 0) + rdataclass = dns_rdataclass_any; + else + rdataclass = dns_rdataclass_none; + } else { + if ((rdata->flags & DNS_RDATA_UPDATE) != 0) { + fprintf(stderr, "could not read rdata\n"); + goto failure; + } + } + + doneparsing: + + result = dns_message_gettemprdatalist(updatemsg, &rdatalist); + check_result(result, "dns_message_gettemprdatalist"); + result = dns_message_gettemprdataset(updatemsg, &rdataset); + check_result(result, "dns_message_gettemprdataset"); + dns_rdatalist_init(rdatalist); + rdatalist->type = rdatatype; + rdatalist->rdclass = rdataclass; + rdatalist->covers = rdatatype; + rdatalist->ttl = (dns_ttl_t)ttl; + ISC_LIST_INIT(rdatalist->rdata); + ISC_LIST_APPEND(rdatalist->rdata, rdata, link); + dns_rdataset_init(rdataset); + dns_rdatalist_tordataset(rdatalist, rdataset); + ISC_LIST_INIT(name->list); + ISC_LIST_APPEND(name->list, rdataset, link); + dns_message_addname(updatemsg, name, DNS_SECTION_UPDATE); + return (STATUS_MORE); + + failure: + if (name != NULL) + dns_message_puttempname(updatemsg, &name); + if (rdata != NULL) + dns_message_puttemprdata(updatemsg, &rdata); + return (STATUS_SYNTAX); +} + +static isc_uint16_t +evaluate_update(char *cmdline) { + char *word; + isc_boolean_t isdelete; + + ddebug("evaluate_update()"); + word = nsu_strsep(&cmdline, " \t\r\n"); + if (*word == 0) { + fprintf(stderr, "could not read operation code\n"); + return (STATUS_SYNTAX); + } + if (strcasecmp(word, "delete") == 0) + isdelete = ISC_TRUE; + else if (strcasecmp(word, "add") == 0) + isdelete = ISC_FALSE; + else { + fprintf(stderr, "incorrect operation code: %s\n", word); + return (STATUS_SYNTAX); + } + return (update_addordelete(cmdline, isdelete)); +} + +static void +show_message(dns_message_t *msg) { + isc_result_t result; + isc_buffer_t *buf = NULL; + int bufsz; + + ddebug("show_message()"); + bufsz = INITTEXT; + do { + if (bufsz > MAXTEXT) { + fprintf(stderr, "could not allocate large enough " + "buffer to display message\n"); + exit(1); + } + if (buf != NULL) + isc_buffer_free(&buf); + result = isc_buffer_allocate(mctx, &buf, bufsz); + check_result(result, "isc_buffer_allocate"); + result = dns_message_totext(msg, style, 0, buf); + bufsz *= 2; + } while (result == ISC_R_NOSPACE); + if (result != ISC_R_SUCCESS) { + fprintf(stderr, "could not convert message to text format.\n"); + isc_buffer_free(&buf); + return; + } + printf("Outgoing update query:\n%.*s", + (int)isc_buffer_usedlength(buf), + (char*)isc_buffer_base(buf)); + isc_buffer_free(&buf); +} + + +static isc_uint16_t +get_next_command(void) { + char cmdlinebuf[MAXCMD]; + char *cmdline; + char *word; + + ddebug("get_next_command()"); + if (interactive) + fprintf(stdout, "> "); + isc_app_block(); + cmdline = fgets(cmdlinebuf, MAXCMD, input); + isc_app_unblock(); + if (cmdline == NULL) + return (STATUS_QUIT); + word = nsu_strsep(&cmdline, " \t\r\n"); + + if (feof(input)) + return (STATUS_QUIT); + if (*word == 0) + return (STATUS_SEND); + if (word[0] == ';') + return (STATUS_MORE); + if (strcasecmp(word, "quit") == 0) + return (STATUS_QUIT); + if (strcasecmp(word, "prereq") == 0) + return (evaluate_prereq(cmdline)); + if (strcasecmp(word, "update") == 0) + return (evaluate_update(cmdline)); + if (strcasecmp(word, "server") == 0) + return (evaluate_server(cmdline)); + if (strcasecmp(word, "local") == 0) + return (evaluate_local(cmdline)); + if (strcasecmp(word, "zone") == 0) + return (evaluate_zone(cmdline)); + if (strcasecmp(word, "class") == 0) + return (evaluate_class(cmdline)); + if (strcasecmp(word, "send") == 0) + return (STATUS_SEND); + if (strcasecmp(word, "show") == 0) { + show_message(updatemsg); + return (STATUS_MORE); + } + if (strcasecmp(word, "answer") == 0) { + if (answer != NULL) + show_message(answer); + return (STATUS_MORE); + } + if (strcasecmp(word, "key") == 0) + return (evaluate_key(cmdline)); + fprintf(stderr, "incorrect section name: %s\n", word); + return (STATUS_SYNTAX); +} + +static isc_boolean_t +user_interaction(void) { + isc_uint16_t result = STATUS_MORE; + + ddebug("user_interaction()"); + while ((result == STATUS_MORE) || (result == STATUS_SYNTAX)) + result = get_next_command(); + if (result == STATUS_SEND) + return (ISC_TRUE); + return (ISC_FALSE); + +} + +static void +done_update(void) { + isc_event_t *event = global_event; + ddebug("done_update()"); + isc_task_send(global_task, &event); +} + +static void +check_tsig_error(dns_rdataset_t *rdataset, isc_buffer_t *b) { + isc_result_t result; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdata_any_tsig_t tsig; + + result = dns_rdataset_first(rdataset); + check_result(result, "dns_rdataset_first"); + dns_rdataset_current(rdataset, &rdata); + result = dns_rdata_tostruct(&rdata, &tsig, NULL); + check_result(result, "dns_rdata_tostruct"); + if (tsig.error != 0) { + if (isc_buffer_remaininglength(b) < 1) + check_result(ISC_R_NOSPACE, "isc_buffer_remaininglength"); + isc__buffer_putstr(b, "(" /*)*/); + result = dns_tsigrcode_totext(tsig.error, b); + check_result(result, "dns_tsigrcode_totext"); + if (isc_buffer_remaininglength(b) < 1) + check_result(ISC_R_NOSPACE, "isc_buffer_remaininglength"); + isc__buffer_putstr(b, /*(*/ ")"); + } +} + +static void +update_completed(isc_task_t *task, isc_event_t *event) { + dns_requestevent_t *reqev = NULL; + isc_result_t result; + dns_request_t *request; + + UNUSED(task); + + ddebug("update_completed()"); + + requests--; + + REQUIRE(event->ev_type == DNS_EVENT_REQUESTDONE); + reqev = (dns_requestevent_t *)event; + request = reqev->request; + + if (shuttingdown) { + dns_request_destroy(&request); + isc_event_free(&event); + maybeshutdown(); + return; + } + + if (reqev->result != ISC_R_SUCCESS) { + fprintf(stderr, "; Communication with server failed: %s\n", + isc_result_totext(reqev->result)); + seenerror = ISC_TRUE; + goto done; + } + + result = dns_message_create(mctx, DNS_MESSAGE_INTENTPARSE, &answer); + check_result(result, "dns_message_create"); + result = dns_request_getresponse(request, answer, + DNS_MESSAGEPARSE_PRESERVEORDER); + switch (result) { + case ISC_R_SUCCESS: + break; + case DNS_R_CLOCKSKEW: + case DNS_R_EXPECTEDTSIG: + case DNS_R_TSIGERRORSET: + case DNS_R_TSIGVERIFYFAILURE: + case DNS_R_UNEXPECTEDTSIG: + fprintf(stderr, "; TSIG error with server: %s\n", + isc_result_totext(result)); + seenerror = ISC_TRUE; + break; + default: + check_result(result, "dns_request_getresponse"); + } + + if (answer->rcode != dns_rcode_noerror) { + seenerror = ISC_TRUE; + if (!debugging) { + char buf[64]; + isc_buffer_t b; + dns_rdataset_t *rds; + + isc_buffer_init(&b, buf, sizeof(buf) - 1); + result = dns_rcode_totext(answer->rcode, &b); + check_result(result, "dns_rcode_totext"); + rds = dns_message_gettsig(answer, NULL); + if (rds != NULL) + check_tsig_error(rds, &b); + fprintf(stderr, "update failed: %.*s\n", + (int)isc_buffer_usedlength(&b), buf); + } + } + if (debugging) { + isc_buffer_t *buf = NULL; + int bufsz; + + bufsz = INITTEXT; + do { + if (bufsz > MAXTEXT) { + fprintf(stderr, "could not allocate large " + "enough buffer to display message\n"); + exit(1); + } + if (buf != NULL) + isc_buffer_free(&buf); + result = isc_buffer_allocate(mctx, &buf, bufsz); + check_result(result, "isc_buffer_allocate"); + result = dns_message_totext(answer, style, 0, buf); + bufsz *= 2; + } while (result == ISC_R_NOSPACE); + check_result(result, "dns_message_totext"); + fprintf(stderr, "\nReply from update query:\n%.*s\n", + (int)isc_buffer_usedlength(buf), + (char*)isc_buffer_base(buf)); + isc_buffer_free(&buf); + } + done: + dns_request_destroy(&request); + isc_event_free(&event); + done_update(); +} + +static void +send_update(dns_name_t *zonename, isc_sockaddr_t *master, + isc_sockaddr_t *srcaddr) +{ + isc_result_t result; + dns_request_t *request = NULL; + dns_name_t *name = NULL; + dns_rdataset_t *rdataset = NULL; + unsigned int options = 0; + + ddebug("send_update()"); + + result = dns_message_gettempname(updatemsg, &name); + check_result(result, "dns_message_gettempname"); + dns_name_init(name, NULL); + dns_name_clone(zonename, name); + result = dns_message_gettemprdataset(updatemsg, &rdataset); + check_result(result, "dns_message_gettemprdataset"); + dns_rdataset_makequestion(rdataset, getzoneclass(), dns_rdatatype_soa); + ISC_LIST_INIT(name->list); + ISC_LIST_APPEND(name->list, rdataset, link); + dns_message_addname(updatemsg, name, DNS_SECTION_ZONE); + + if (usevc) + options |= DNS_REQUESTOPT_TCP; + if (tsigkey == NULL && sig0key != NULL) { + result = dns_message_setsig0key(updatemsg, sig0key); + check_result(result, "dns_message_setsig0key"); + } + if (debugging) { + char addrbuf[ISC_SOCKADDR_FORMATSIZE]; + + isc_sockaddr_format(master, addrbuf, sizeof(addrbuf)); + fprintf(stderr, "Sending update to %s\n", addrbuf); + } + result = dns_request_createvia3(requestmgr, updatemsg, srcaddr, + master, options, tsigkey, timeout, + udp_timeout, udp_retries, global_task, + update_completed, NULL, &request); + check_result(result, "dns_request_createvia3"); + + if (debugging) + show_message(updatemsg); + + requests++; +} + +static void +recvsoa(isc_task_t *task, isc_event_t *event) { + dns_requestevent_t *reqev = NULL; + dns_request_t *request = NULL; + isc_result_t result, eresult; + dns_message_t *rcvmsg = NULL; + dns_section_t section; + dns_name_t *name = NULL; + dns_rdataset_t *soaset = NULL; + dns_rdata_soa_t soa; + dns_rdata_t soarr = DNS_RDATA_INIT; + int pass = 0; + dns_name_t master; + isc_sockaddr_t *serveraddr, tempaddr; + dns_name_t *zonename; + nsu_requestinfo_t *reqinfo; + dns_message_t *soaquery = NULL; + isc_sockaddr_t *addr; + isc_boolean_t seencname = ISC_FALSE; + + UNUSED(task); + + ddebug("recvsoa()"); + + requests--; + + REQUIRE(event->ev_type == DNS_EVENT_REQUESTDONE); + reqev = (dns_requestevent_t *)event; + request = reqev->request; + eresult = reqev->result; + reqinfo = reqev->ev_arg; + soaquery = reqinfo->msg; + addr = reqinfo->addr; + + if (shuttingdown) { + dns_request_destroy(&request); + dns_message_destroy(&soaquery); + isc_mem_put(mctx, reqinfo, sizeof(nsu_requestinfo_t)); + isc_event_free(&event); + maybeshutdown(); + return; + } + + if (eresult != ISC_R_SUCCESS) { + char addrbuf[ISC_SOCKADDR_FORMATSIZE]; + + isc_sockaddr_format(addr, addrbuf, sizeof(addrbuf)); + fprintf(stderr, "; Communication with %s failed: %s\n", + addrbuf, isc_result_totext(eresult)); + if (userserver != NULL) + fatal("could not talk to specified name server"); + else if (++ns_inuse >= lwconf->nsnext) + fatal("could not talk to any default name server"); + ddebug("Destroying request [%p]", request); + dns_request_destroy(&request); + dns_message_renderreset(soaquery); + sendrequest(localaddr, &servers[ns_inuse], soaquery, &request); + isc_mem_put(mctx, reqinfo, sizeof(nsu_requestinfo_t)); + isc_event_free(&event); + setzoneclass(dns_rdataclass_none); + return; + } + isc_mem_put(mctx, reqinfo, sizeof(nsu_requestinfo_t)); + + isc_event_free(&event); + reqev = NULL; + + ddebug("About to create rcvmsg"); + result = dns_message_create(mctx, DNS_MESSAGE_INTENTPARSE, &rcvmsg); + check_result(result, "dns_message_create"); + result = dns_request_getresponse(request, rcvmsg, + DNS_MESSAGEPARSE_PRESERVEORDER); + if (result == DNS_R_TSIGERRORSET && userserver != NULL) { + dns_message_destroy(&rcvmsg); + ddebug("Destroying request [%p]", request); + dns_request_destroy(&request); + reqinfo = isc_mem_get(mctx, sizeof(nsu_requestinfo_t)); + if (reqinfo == NULL) + fatal("out of memory"); + reqinfo->msg = soaquery; + reqinfo->addr = addr; + dns_message_renderreset(soaquery); + ddebug("retrying soa request without TSIG"); + result = dns_request_createvia3(requestmgr, soaquery, + localaddr, addr, 0, NULL, + FIND_TIMEOUT * 20, + FIND_TIMEOUT * 20, 3, + global_task, recvsoa, reqinfo, + &request); + check_result(result, "dns_request_createvia"); + requests++; + return; + } + check_result(result, "dns_request_getresponse"); + section = DNS_SECTION_ANSWER; + if (debugging) { + isc_buffer_t *buf = NULL; + int bufsz; + bufsz = INITTEXT; + do { + if (buf != NULL) + isc_buffer_free(&buf); + if (bufsz > MAXTEXT) { + fprintf(stderr, "could not allocate enough " + "space for debugging message\n"); + exit(1); + } + result = isc_buffer_allocate(mctx, &buf, bufsz); + check_result(result, "isc_buffer_allocate"); + result = dns_message_totext(rcvmsg, style, 0, buf); + } while (result == ISC_R_NOSPACE); + check_result(result, "dns_message_totext"); + fprintf(stderr, "Reply from SOA query:\n%.*s\n", + (int)isc_buffer_usedlength(buf), + (char*)isc_buffer_base(buf)); + isc_buffer_free(&buf); + } + + if (rcvmsg->rcode != dns_rcode_noerror && + rcvmsg->rcode != dns_rcode_nxdomain) + fatal("response to SOA query was unsuccessful"); + + lookforsoa: + if (pass == 0) + section = DNS_SECTION_ANSWER; + else if (pass == 1) + section = DNS_SECTION_AUTHORITY; + else + fatal("response to SOA query didn't contain an SOA"); + + + result = dns_message_firstname(rcvmsg, section); + if (result != ISC_R_SUCCESS) { + pass++; + goto lookforsoa; + } + while (result == ISC_R_SUCCESS) { + name = NULL; + dns_message_currentname(rcvmsg, section, &name); + soaset = NULL; + result = dns_message_findtype(name, dns_rdatatype_soa, 0, + &soaset); + if (result == ISC_R_SUCCESS) + break; + if (section == DNS_SECTION_ANSWER) { + dns_rdataset_t *tset = NULL; + if (dns_message_findtype(name, dns_rdatatype_cname, 0, + &tset) == ISC_R_SUCCESS + || + dns_message_findtype(name, dns_rdatatype_dname, 0, + &tset) == ISC_R_SUCCESS + ) + { + seencname = ISC_TRUE; + break; + } + } + + result = dns_message_nextname(rcvmsg, section); + } + + if (soaset == NULL && !seencname) { + pass++; + goto lookforsoa; + } + + if (seencname) { + dns_name_t tname; + unsigned int nlabels; + + result = dns_message_firstname(soaquery, DNS_SECTION_QUESTION); + INSIST(result == ISC_R_SUCCESS); + name = NULL; + dns_message_currentname(soaquery, DNS_SECTION_QUESTION, &name); + nlabels = dns_name_countlabels(name); + if (nlabels == 1) + fatal("could not find enclosing zone"); + dns_name_init(&tname, NULL); + dns_name_getlabelsequence(name, 1, nlabels - 1, &tname); + dns_name_clone(&tname, name); + dns_request_destroy(&request); + dns_message_renderreset(soaquery); + if (userserver != NULL) + sendrequest(localaddr, userserver, soaquery, &request); + else + sendrequest(localaddr, &servers[ns_inuse], soaquery, + &request); + goto out; + } + + if (debugging) { + char namestr[DNS_NAME_FORMATSIZE]; + dns_name_format(name, namestr, sizeof(namestr)); + fprintf(stderr, "Found zone name: %s\n", namestr); + } + + result = dns_rdataset_first(soaset); + check_result(result, "dns_rdataset_first"); + + dns_rdata_init(&soarr); + dns_rdataset_current(soaset, &soarr); + result = dns_rdata_tostruct(&soarr, &soa, NULL); + check_result(result, "dns_rdata_tostruct"); + + dns_name_init(&master, NULL); + dns_name_clone(&soa.origin, &master); + + if (userzone != NULL) + zonename = userzone; + else + zonename = name; + + if (debugging) { + char namestr[DNS_NAME_FORMATSIZE]; + dns_name_format(&master, namestr, sizeof(namestr)); + fprintf(stderr, "The master is: %s\n", namestr); + } + + if (userserver != NULL) + serveraddr = userserver; + else { + char serverstr[DNS_NAME_MAXTEXT+1]; + isc_buffer_t buf; + + isc_buffer_init(&buf, serverstr, sizeof(serverstr)); + result = dns_name_totext(&master, ISC_TRUE, &buf); + check_result(result, "dns_name_totext"); + serverstr[isc_buffer_usedlength(&buf)] = 0; + get_address(serverstr, DNSDEFAULTPORT, &tempaddr); + serveraddr = &tempaddr; + } + + send_update(zonename, serveraddr, localaddr); + + dns_message_destroy(&soaquery); + dns_request_destroy(&request); + + out: + setzoneclass(dns_rdataclass_none); + dns_rdata_freestruct(&soa); + dns_message_destroy(&rcvmsg); + ddebug("Out of recvsoa"); +} + +static void +sendrequest(isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr, + dns_message_t *msg, dns_request_t **request) +{ + isc_result_t result; + nsu_requestinfo_t *reqinfo; + + reqinfo = isc_mem_get(mctx, sizeof(nsu_requestinfo_t)); + if (reqinfo == NULL) + fatal("out of memory"); + reqinfo->msg = msg; + reqinfo->addr = destaddr; + result = dns_request_createvia3(requestmgr, msg, srcaddr, destaddr, 0, + (userserver != NULL) ? tsigkey : NULL, + FIND_TIMEOUT * 20, FIND_TIMEOUT, 3, + global_task, recvsoa, reqinfo, request); + check_result(result, "dns_request_createvia"); + requests++; +} + +static void +start_update(void) { + isc_result_t result; + dns_rdataset_t *rdataset = NULL; + dns_name_t *name = NULL; + dns_request_t *request = NULL; + dns_message_t *soaquery = NULL; + dns_name_t *firstname; + dns_section_t section = DNS_SECTION_UPDATE; + + ddebug("start_update()"); + + if (answer != NULL) + dns_message_destroy(&answer); + result = dns_message_firstname(updatemsg, section); + if (result == ISC_R_NOMORE) { + section = DNS_SECTION_PREREQUISITE; + result = dns_message_firstname(updatemsg, section); + } + if (result != ISC_R_SUCCESS) { + done_update(); + return; + } + + if (userzone != NULL && userserver != NULL) { + send_update(userzone, userserver, localaddr); + setzoneclass(dns_rdataclass_none); + return; + } + + result = dns_message_create(mctx, DNS_MESSAGE_INTENTRENDER, + &soaquery); + check_result(result, "dns_message_create"); + + soaquery->flags |= DNS_MESSAGEFLAG_RD; + + result = dns_message_gettempname(soaquery, &name); + check_result(result, "dns_message_gettempname"); + + result = dns_message_gettemprdataset(soaquery, &rdataset); + check_result(result, "dns_message_gettemprdataset"); + + dns_rdataset_makequestion(rdataset, getzoneclass(), dns_rdatatype_soa); + + firstname = NULL; + dns_message_currentname(updatemsg, section, &firstname); + dns_name_init(name, NULL); + dns_name_clone(firstname, name); + + ISC_LIST_INIT(name->list); + ISC_LIST_APPEND(name->list, rdataset, link); + dns_message_addname(soaquery, name, DNS_SECTION_QUESTION); + + if (userserver != NULL) + sendrequest(localaddr, userserver, soaquery, &request); + else { + ns_inuse = 0; + sendrequest(localaddr, &servers[ns_inuse], soaquery, &request); + } +} + +static void +cleanup(void) { + ddebug("cleanup()"); + + if (answer != NULL) + dns_message_destroy(&answer); + ddebug("Shutting down task manager"); + isc_taskmgr_destroy(&taskmgr); + + ddebug("Destroying event"); + isc_event_free(&global_event); + + ddebug("Shutting down socket manager"); + isc_socketmgr_destroy(&socketmgr); + + ddebug("Shutting down timer manager"); + isc_timermgr_destroy(&timermgr); + + ddebug("Destroying hash context"); + isc_hash_destroy(); + + ddebug("Destroying memory context"); + if (memdebugging) + isc_mem_stats(mctx, stderr); + isc_mem_destroy(&mctx); +} + +static void +getinput(isc_task_t *task, isc_event_t *event) { + isc_boolean_t more; + + UNUSED(task); + + if (shuttingdown) { + maybeshutdown(); + return; + } + + if (global_event == NULL) + global_event = event; + + reset_system(); + more = user_interaction(); + if (!more) { + isc_app_shutdown(); + return; + } + start_update(); + return; +} + +int +main(int argc, char **argv) { + isc_result_t result; + style = &dns_master_style_debug; + + input = stdin; + + interactive = ISC_TF(isatty(0)); + + isc_app_start(); + + parse_args(argc, argv); + + setup_system(); + + result = isc_app_onrun(mctx, global_task, getinput, NULL); + check_result(result, "isc_app_onrun"); + + (void)isc_app_run(); + + cleanup(); + + isc_app_finish(); + + if (seenerror) + return (2); + else + return (0); +} diff --git a/contrib/bind9/bin/nsupdate/nsupdate.docbook b/contrib/bind9/bin/nsupdate/nsupdate.docbook new file mode 100644 index 000000000000..7d23333c864c --- /dev/null +++ b/contrib/bind9/bin/nsupdate/nsupdate.docbook @@ -0,0 +1,629 @@ + + + + + + + +Jun 30, 2000 + + +nsupdate +8 +BIND9 + + +nsupdate +Dynamic DNS update utility + + + +nsupdate + + + + + + + + + +filename + + + + +DESCRIPTION + +nsupdate +is used to submit Dynamic DNS Update requests as defined in RFC2136 +to a name server. +This allows resource records to be added or removed from a zone +without manually editing the zone file. +A single update request can contain requests to add or remove more than one +resource record. + + +Zones that are under dynamic control via +nsupdate +or a DHCP server should not be edited by hand. +Manual edits could +conflict with dynamic updates and cause data to be lost. + + +The resource records that are dynamically added or removed with +nsupdate +have to be in the same zone. +Requests are sent to the zone's master server. +This is identified by the MNAME field of the zone's SOA record. + + +The + +option makes +nsupdate +operate in debug mode. +This provides tracing information about the update requests that are +made and the replies received from the name server. + + +Transaction signatures can be used to authenticate the Dynamic DNS +updates. +These use the TSIG resource record type described in RFC2845 or the +SIG(0) record described in RFC3535 and RFC2931. +TSIG relies on a shared secret that should only be known to +nsupdate and the name server. +Currently, the only supported encryption algorithm for TSIG is +HMAC-MD5, which is defined in RFC 2104. +Once other algorithms are defined for TSIG, applications will need to +ensure they select the appropriate algorithm as well as the key when +authenticating each other. +For instance suitable +key +and +server +statements would be added to +/etc/named.conf +so that the name server can associate the appropriate secret key +and algorithm with the IP address of the +client application that will be using TSIG authentication. +SIG(0) uses public key cryptography. To use a SIG(0) key, the public +key must be stored in a KEY record in a zone served by the name server. +nsupdate +does not read +/etc/named.conf. + + +nsupdate +uses the + +or + +option (with an HMAC-MD5 key) to provide the shared secret needed to generate +a TSIG record for authenticating Dynamic DNS update requests. +These options are mutually exclusive. +With the + +option, +nsupdate +reads the shared secret from the file +keyfile, +whose name is of the form +K{name}.+157.+{random}.private. +For historical +reasons, the file +K{name}.+157.+{random}.key +must also be present. When the + +option is used, a signature is generated from +keyname:secret. +keyname +is the name of the key, +and +secret +is the base64 encoded shared secret. +Use of the + +option is discouraged because the shared secret is supplied as a command +line argument in clear text. +This may be visible in the output from + +ps1 + + +or in a history file maintained by the user's shell. + + +The may also be used to specify a SIG(0) key used +to authenticate Dynamic DNS update requests. In this case, the key +specified is not an HMAC-MD5 key. + + +By default +nsupdate +uses UDP to send update requests to the name server unless they are too +large to fit in a UDP request in which case TCP will be used. +The + +option makes +nsupdate +use a TCP connection. +This may be preferable when a batch of update requests is made. + +The option sets the maximum time a update request can +take before it is aborted. The default is 300 seconds. Zero can be used +to disable the timeout. + +The option sets the UDP retry interval. The default is +3 seconds. If zero the interval will be computed from the timeout interval +and number of UDP retries. + +The option sets the number of UDP retries. The default is +3. If zero only one update request will be made. + + + + +INPUT FORMAT + +nsupdate +reads input from +filename +or standard input. +Each command is supplied on exactly one line of input. +Some commands are for administrative purposes. +The others are either update instructions or prerequisite checks on the +contents of the zone. +These checks set conditions that some name or set of +resource records (RRset) either exists or is absent from the zone. +These conditions must be met if the entire update request is to succeed. +Updates will be rejected if the tests for the prerequisite conditions fail. + + +Every update request consists of zero or more prerequisites +and zero or more updates. +This allows a suitably authenticated update request to proceed if some +specified resource records are present or missing from the zone. +A blank input line (or the send command) causes the +accumulated commands to be sent as one Dynamic DNS update request to the +name server. + + +The command formats and their meaning are as follows: + + + +server +servername +port + + + + +Sends all dynamic update requests to the name server +servername. +When no server statement is provided, +nsupdate +will send updates to the master server of the correct zone. +The MNAME field of that zone's SOA record will identify the master +server for that zone. +port +is the port number on +servername +where the dynamic update requests get sent. +If no port number is specified, the default DNS port number of 53 is +used. + + + + +local +address +port + + + + +Sends all dynamic update requests using the local +address. + +When no local statement is provided, +nsupdate +will send updates using an address and port chosen by the system. +port +can additionally be used to make requests come from a specific port. +If no port number is specified, the system will assign one. + + + +zone +zonename + + + + +Specifies that all updates are to be made to the zone +zonename. +If no +zone +statement is provided, +nsupdate +will attempt determine the correct zone to update based on the rest of the input. + + + + + + +class +classname + + + + +Specify the default class. +If no class is specified the default class is +IN. + + + + + + +key +name +secret + + + + +Specifies that all updates are to be TSIG signed using the +keyname keysecret pair. +The key command +overrides any key specified on the command line via + or . + + + + + + +prereq nxdomain +domain-name + + + + +Requires that no resource record of any type exists with name +domain-name. + + + + + + + +prereq yxdomain +domain-name + + + + +Requires that +domain-name +exists (has as at least one resource record, of any type). + + + + + + +prereq nxrrset +domain-name +class +type + + + + +Requires that no resource record exists of the specified +type, +class +and +domain-name. +If +class +is omitted, IN (internet) is assumed. + + + + + + + +prereq yxrrset +domain-name +class +type + + + + +This requires that a resource record of the specified +type, +class +and +domain-name +must exist. +If +class +is omitted, IN (internet) is assumed. + + + + + + +prereq yxrrset +domain-name +class +type +data + + + + +The +data +from each set of prerequisites of this form +sharing a common +type, +class, +and +domain-name +are combined to form a set of RRs. This set of RRs must +exactly match the set of RRs existing in the zone at the +given +type, +class, +and +domain-name. +The +data +are written in the standard text representation of the resource record's +RDATA. + + + + + + +update delete +domain-name +ttl +class +type data + + + + +Deletes any resource records named +domain-name. +If +type +and +data +is provided, only matching resource records will be removed. +The internet class is assumed if +class +is not supplied. The +ttl +is ignored, and is only allowed for compatibility. + + + + + + +update add +domain-name +ttl +class +type +data + + + + +Adds a new resource record with the specified +ttl, +class +and +data. + + + + + + +show + + + + +Displays the current message, containing all of the prerequisites and +updates specified since the last send. + + + + + + +send + + + + +Sends the current message. This is equivalent to entering a blank line. + + + + + +answer + + + + +Displays the answer. + + + + + + +Lines beginning with a semicolon are comments and are ignored. + + + + + +EXAMPLES + +The examples below show how +nsupdate +could be used to insert and delete resource records from the +example.com +zone. +Notice that the input in each example contains a trailing blank line so that +a group of commands are sent as one dynamic update request to the +master name server for +example.com. + + +# nsupdate +> update delete oldhost.example.com A +> update add newhost.example.com 86400 A 172.16.1.1 +> send + + + +Any A records for +oldhost.example.com +are deleted. +and an A record for +newhost.example.com +it IP address 172.16.1.1 is added. +The newly-added record has a 1 day TTL (86400 seconds) + +# nsupdate +> prereq nxdomain nickname.example.com +> update add nickname.example.com 86400 CNAME somehost.example.com +> send + + + +The prerequisite condition gets the name server to check that there +are no resource records of any type for +nickname.example.com. + +If there are, the update request fails. +If this name does not exist, a CNAME for it is added. +This ensures that when the CNAME is added, it cannot conflict with the +long-standing rule in RFC1034 that a name must not exist as any other +record type if it exists as a CNAME. +(The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have +RRSIG, DNSKEY and NSEC records.) + + + + +FILES + + +/etc/resolv.conf + + +used to identify default name server + + + +K{name}.+157.+{random}.key + + +base-64 encoding of HMAC-MD5 key created by + +dnssec-keygen8 +. + + + +K{name}.+157.+{random}.private + + +base-64 encoding of HMAC-MD5 key created by + +dnssec-keygen8 +. + + + + + + +SEE ALSO + + +RFC2136 +, + +RFC3007 +, + +RFC2104 +, + +RFC2845 +, + +RFC1034 +, + +RFC2535 +, + +RFC2931 +, + +named8 +, + +dnssec-keygen8 +. + + + +BUGS + +The TSIG key is redundantly stored in two separate files. +This is a consequence of nsupdate using the DST library +for its cryptographic operations, and may change in future +releases. + + + diff --git a/contrib/bind9/bin/nsupdate/nsupdate.html b/contrib/bind9/bin/nsupdate/nsupdate.html new file mode 100644 index 000000000000..f9cb98cc35f0 --- /dev/null +++ b/contrib/bind9/bin/nsupdate/nsupdate.html @@ -0,0 +1,962 @@ + + + + + +nsupdate

nsupdate

Name

nsupdate -- Dynamic DNS update utility

Synopsis

nsupdate [-d] [-y keyname:secret | -k keyfile] [-t timeout] [-u udptimeout] [-r udpretries] [-v] [filename]

DESCRIPTION

nsupdate +is used to submit Dynamic DNS Update requests as defined in RFC2136 +to a name server. +This allows resource records to be added or removed from a zone +without manually editing the zone file. +A single update request can contain requests to add or remove more than one +resource record.

Zones that are under dynamic control via +nsupdate +or a DHCP server should not be edited by hand. +Manual edits could +conflict with dynamic updates and cause data to be lost.

The resource records that are dynamically added or removed with +nsupdate +have to be in the same zone. +Requests are sent to the zone's master server. +This is identified by the MNAME field of the zone's SOA record.

The +-d +option makes +nsupdate +operate in debug mode. +This provides tracing information about the update requests that are +made and the replies received from the name server.

Transaction signatures can be used to authenticate the Dynamic DNS +updates. +These use the TSIG resource record type described in RFC2845 or the +SIG(0) record described in RFC3535 and RFC2931. +TSIG relies on a shared secret that should only be known to +nsupdate and the name server. +Currently, the only supported encryption algorithm for TSIG is +HMAC-MD5, which is defined in RFC 2104. +Once other algorithms are defined for TSIG, applications will need to +ensure they select the appropriate algorithm as well as the key when +authenticating each other. +For instance suitable +key +and +server +statements would be added to +/etc/named.conf +so that the name server can associate the appropriate secret key +and algorithm with the IP address of the +client application that will be using TSIG authentication. +SIG(0) uses public key cryptography. To use a SIG(0) key, the public +key must be stored in a KEY record in a zone served by the name server. +nsupdate +does not read +/etc/named.conf.

nsupdate +uses the +-y +or +-k +option (with an HMAC-MD5 key) to provide the shared secret needed to generate +a TSIG record for authenticating Dynamic DNS update requests. +These options are mutually exclusive. +With the +-k +option, +nsupdate +reads the shared secret from the file +keyfile, +whose name is of the form +K{name}.+157.+{random}.private. +For historical +reasons, the file +K{name}.+157.+{random}.key +must also be present. When the +-y +option is used, a signature is generated from +keyname:secret. +keyname +is the name of the key, +and +secret +is the base64 encoded shared secret. +Use of the +-y +option is discouraged because the shared secret is supplied as a command +line argument in clear text. +This may be visible in the output from +ps(1) +or in a history file maintained by the user's shell.

The -k may also be used to specify a SIG(0) key used +to authenticate Dynamic DNS update requests. In this case, the key +specified is not an HMAC-MD5 key.

By default +nsupdate +uses UDP to send update requests to the name server unless they are too +large to fit in a UDP request in which case TCP will be used. +The +-v +option makes +nsupdate +use a TCP connection. +This may be preferable when a batch of update requests is made.

The -t option sets the maximum time a update request can +take before it is aborted. The default is 300 seconds. Zero can be used +to disable the timeout.

The -u option sets the UDP retry interval. The default is +3 seconds. If zero the interval will be computed from the timeout interval +and number of UDP retries.

The -r option sets the number of UDP retries. The default is +3. If zero only one update request will be made.

INPUT FORMAT

nsupdate +reads input from +filename +or standard input. +Each command is supplied on exactly one line of input. +Some commands are for administrative purposes. +The others are either update instructions or prerequisite checks on the +contents of the zone. +These checks set conditions that some name or set of +resource records (RRset) either exists or is absent from the zone. +These conditions must be met if the entire update request is to succeed. +Updates will be rejected if the tests for the prerequisite conditions fail.

Every update request consists of zero or more prerequisites +and zero or more updates. +This allows a suitably authenticated update request to proceed if some +specified resource records are present or missing from the zone. +A blank input line (or the send command) causes the +accumulated commands to be sent as one Dynamic DNS update request to the +name server.

The command formats and their meaning are as follows: +

server {servername} [port]

Sends all dynamic update requests to the name server +servername. +When no server statement is provided, +nsupdate +will send updates to the master server of the correct zone. +The MNAME field of that zone's SOA record will identify the master +server for that zone. +port +is the port number on +servername +where the dynamic update requests get sent. +If no port number is specified, the default DNS port number of 53 is +used.

local {address} [port]

Sends all dynamic update requests using the local +address. + +When no local statement is provided, +nsupdate +will send updates using an address and port chosen by the system. +port +can additionally be used to make requests come from a specific port. +If no port number is specified, the system will assign one.

zone {zonename}

Specifies that all updates are to be made to the zone +zonename. +If no +zone +statement is provided, +nsupdate +will attempt determine the correct zone to update based on the rest of the input.

class {classname}

Specify the default class. +If no class is specified the default class is +IN.

key {name} {secret}

Specifies that all updates are to be TSIG signed using the +keyname keysecret pair. +The key command +overrides any key specified on the command line via +-y or -k.

prereq nxdomain {domain-name}

Requires that no resource record of any type exists with name +domain-name.

prereq yxdomain {domain-name}

Requires that +domain-name +exists (has as at least one resource record, of any type).

prereq nxrrset {domain-name} [class] {type}

Requires that no resource record exists of the specified +type, +class +and +domain-name. +If +class +is omitted, IN (internet) is assumed.

prereq yxrrset {domain-name} [class] {type}

This requires that a resource record of the specified +type, +class +and +domain-name +must exist. +If +class +is omitted, IN (internet) is assumed.

prereq yxrrset {domain-name} [class] {type} {data...}

The +data +from each set of prerequisites of this form +sharing a common +type, +class, +and +domain-name +are combined to form a set of RRs. This set of RRs must +exactly match the set of RRs existing in the zone at the +given +type, +class, +and +domain-name. +The +data +are written in the standard text representation of the resource record's +RDATA.

update delete {domain-name} [ttl] [class] [type [data...]]

Deletes any resource records named +domain-name. +If +type +and +data +is provided, only matching resource records will be removed. +The internet class is assumed if +class +is not supplied. The +ttl +is ignored, and is only allowed for compatibility.

update add {domain-name} {ttl} [class] {type} {data...}

Adds a new resource record with the specified +ttl, +class +and +data.

show

Displays the current message, containing all of the prerequisites and +updates specified since the last send.

send

Sends the current message. This is equivalent to entering a blank line.

answer

Displays the answer.

Lines beginning with a semicolon are comments and are ignored.

EXAMPLES

The examples below show how +nsupdate +could be used to insert and delete resource records from the +example.com +zone. +Notice that the input in each example contains a trailing blank line so that +a group of commands are sent as one dynamic update request to the +master name server for +example.com. + +

# nsupdate
+> update delete oldhost.example.com A
+> update add newhost.example.com 86400 A 172.16.1.1
+> send

Any A records for +oldhost.example.com +are deleted. +and an A record for +newhost.example.com +it IP address 172.16.1.1 is added. +The newly-added record has a 1 day TTL (86400 seconds) +

# nsupdate
+> prereq nxdomain nickname.example.com
+> update add nickname.example.com 86400 CNAME somehost.example.com
+> send

The prerequisite condition gets the name server to check that there +are no resource records of any type for +nickname.example.com. + +If there are, the update request fails. +If this name does not exist, a CNAME for it is added. +This ensures that when the CNAME is added, it cannot conflict with the +long-standing rule in RFC1034 that a name must not exist as any other +record type if it exists as a CNAME. +(The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have +RRSIG, DNSKEY and NSEC records.)

FILES

/etc/resolv.conf

used to identify default name server

K{name}.+157.+{random}.key

base-64 encoding of HMAC-MD5 key created by +dnssec-keygen(8).

K{name}.+157.+{random}.private

base-64 encoding of HMAC-MD5 key created by +dnssec-keygen(8).

SEE ALSO

RFC2136, +RFC3007, +RFC2104, +RFC2845, +RFC1034, +RFC2535, +RFC2931, +named(8), +dnssec-keygen(8).

BUGS

The TSIG key is redundantly stored in two separate files. +This is a consequence of nsupdate using the DST library +for its cryptographic operations, and may change in future +releases.

diff --git a/contrib/bind9/bin/rndc/Makefile.in b/contrib/bind9/bin/rndc/Makefile.in new file mode 100644 index 000000000000..e6773151126b --- /dev/null +++ b/contrib/bind9/bin/rndc/Makefile.in @@ -0,0 +1,102 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000-2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.32.2.3.8.8 2004/07/20 07:01:50 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_VERSION@ + +@BIND9_MAKE_INCLUDES@ + +CINCLUDES = -I${srcdir}/include ${ISC_INCLUDES} ${ISCCC_INCLUDES} \ + ${ISCCFG_INCLUDES} ${DNS_INCLUDES} ${BIND9_INCLUDES} + +CDEFINES = +CWARNINGS = + +ISCCFGLIBS = ../../lib/isccfg/libisccfg.@A@ +ISCCCLIBS = ../../lib/isccc/libisccc.@A@ +ISCLIBS = ../../lib/isc/libisc.@A@ +DNSLIBS = ../../lib/dns/libdns.@A@ @DNS_CRYPTO_LIBS@ +BIND9LIBS = ../../lib/bind9/libbind9.@A@ + +ISCCFGDEPLIBS = ../../lib/isccfg/libisccfg.@A@ +ISCCCDEPLIBS = ../../lib/isccc/libisccc.@A@ +ISCDEPLIBS = ../../lib/isc/libisc.@A@ +DNSDEPLIBS = ../../lib/dns/libdns.@A@ +BIND9DEPLIBS = ../../lib/bind9/libbind9.@A@ + +RNDCLIBS = ${ISCCFGLIBS} ${ISCCCLIBS} ${BIND9LIBS} ${DNSLIBS} ${ISCLIBS} @LIBS@ +RNDCDEPLIBS = ${ISCCFGDEPLIBS} ${ISCCCDEPLIBS} ${BIND9DEPLIBS} ${DNSDEPLIBS} ${ISCDEPLIBS} + +CONFLIBS = ${DNSLIBS} ${ISCLIBS} @LIBS@ +CONFDEPLIBS = ${DNSDEPLIBS} ${ISCDEPLIBS} + +SUBDIRS = unix + +TARGETS = rndc@EXEEXT@ rndc-confgen@EXEEXT@ + +MANPAGES = rndc.8 rndc-confgen.8 rndc.conf.5 + +HTMLPAGES = rndc.html rndc-confgen.html rndc.conf.html + +MANOBJS = ${MANPAGES} ${HTMLPAGES} + +UOBJS = unix/os.@O@ + +@BIND9_MAKE_RULES@ + +rndc.@O@: rndc.c + ${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} \ + -DVERSION=\"${VERSION}\" \ + -DRNDC_CONFFILE=\"${sysconfdir}/rndc.conf\" \ + -DRNDC_KEYFILE=\"${sysconfdir}/rndc.key\" \ + -c ${srcdir}/rndc.c + +rndc-confgen.@O@: rndc-confgen.c + ${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} \ + -DRNDC_KEYFILE=\"${sysconfdir}/rndc.key\" \ + -c ${srcdir}/rndc-confgen.c + +rndc@EXEEXT@: rndc.@O@ util.@O@ ${RNDCDEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rndc.@O@ util.@O@ \ + ${RNDCLIBS} + +rndc-confgen@EXEEXT@: rndc-confgen.@O@ util.@O@ ${UOBJS} ${CONFDEPLIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rndc-confgen.@O@ util.@O@ \ + ${UOBJS} ${CONFLIBS} + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f ${MANOBJS} + +installdirs: + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${sbindir} + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man8 + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man5 + +install:: rndc@EXEEXT@ rndc-confgen@EXEEXT@ installdirs + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} rndc@EXEEXT@ ${DESTDIR}${sbindir} + ${LIBTOOL_MODE_INSTALL} ${INSTALL_PROGRAM} rndc-confgen@EXEEXT@ ${DESTDIR}${sbindir} + ${INSTALL_DATA} ${srcdir}/rndc.8 ${DESTDIR}${mandir}/man8 + ${INSTALL_DATA} ${srcdir}/rndc-confgen.8 ${DESTDIR}${mandir}/man8 + ${INSTALL_DATA} ${srcdir}/rndc.conf.5 ${DESTDIR}${mandir}/man5 + +clean distclean maintainer-clean:: + rm -f ${TARGETS} diff --git a/contrib/bind9/bin/rndc/include/rndc/os.h b/contrib/bind9/bin/rndc/include/rndc/os.h new file mode 100644 index 000000000000..b5ade476b9f1 --- /dev/null +++ b/contrib/bind9/bin/rndc/include/rndc/os.h @@ -0,0 +1,44 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: os.h,v 1.4.206.1 2004/03/06 10:21:33 marka Exp $ */ + +#ifndef RNDC_OS_H +#define RNDC_OS_H 1 + +#include +#include + +ISC_LANG_BEGINDECLS + +FILE *safe_create(const char *filename); +/* + * Open 'filename' for writing, truncate if necessary. If the file was + * created ensure that only the owner can read/write it. + */ + +int set_user(FILE *fd, const char *user); +/* + * Set the owner of the file refernced by 'fd' to 'user'. + * Returns: + * 0 success + * -1 insufficient permissions, or 'user' does not exist. + */ + +ISC_LANG_ENDDECLS + +#endif diff --git a/contrib/bind9/bin/rndc/rndc-confgen.8 b/contrib/bind9/bin/rndc/rndc-confgen.8 new file mode 100644 index 000000000000..b12e90cc569e --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc-confgen.8 @@ -0,0 +1,140 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2001-2003 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: rndc-confgen.8,v 1.3.2.5.2.3 2004/06/03 05:35:48 marka Exp $ +.\" +.TH "RNDC-CONFGEN" "8" "Aug 27, 2001" "BIND9" "" +.SH NAME +rndc-confgen \- rndc key generation tool +.SH SYNOPSIS +.sp +\fBrndc-confgen\fR [ \fB-a\fR ] [ \fB-b \fIkeysize\fB\fR ] [ \fB-c \fIkeyfile\fB\fR ] [ \fB-h\fR ] [ \fB-k \fIkeyname\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-r \fIrandomfile\fB\fR ] [ \fB-s \fIaddress\fB\fR ] [ \fB-t \fIchrootdir\fB\fR ] [ \fB-u \fIuser\fB\fR ] +.SH "DESCRIPTION" +.PP +\fBrndc-confgen\fR generates configuration files +for \fBrndc\fR. It can be used as a +convenient alternative to writing the +\fIrndc.conf\fR file +and the corresponding \fBcontrols\fR +and \fBkey\fR +statements in \fInamed.conf\fR by hand. +Alternatively, it can be run with the \fB-a\fR +option to set up a \fIrndc.key\fR file and +avoid the need for a \fIrndc.conf\fR file +and a \fBcontrols\fR statement altogether. +.SH "OPTIONS" +.TP +\fB-a\fR +Do automatic \fBrndc\fR configuration. +This creates a file \fIrndc.key\fR +in \fI/etc\fR (or whatever +sysconfdir +was specified as when BIND was built) +that is read by both \fBrndc\fR +and \fBnamed\fR on startup. The +\fIrndc.key\fR file defines a default +command channel and authentication key allowing +\fBrndc\fR to communicate with +\fBnamed\fR on the local host +with no further configuration. + +Running \fBrndc-confgen -a\fR allows +BIND 9 and \fBrndc\fR to be used as drop-in +replacements for BIND 8 and \fBndc\fR, +with no changes to the existing BIND 8 +\fInamed.conf\fR file. + +If a more elaborate configuration than that +generated by \fBrndc-confgen -a\fR +is required, for example if rndc is to be used remotely, +you should run \fBrndc-confgen\fR without the +\fB-a\fR option and set up a +\fIrndc.conf\fR and +\fInamed.conf\fR +as directed. +.TP +\fB-b \fIkeysize\fB\fR +Specifies the size of the authentication key in bits. +Must be between 1 and 512 bits; the default is 128. +.TP +\fB-c \fIkeyfile\fB\fR +Used with the \fB-a\fR option to specify +an alternate location for \fIrndc.key\fR. +.TP +\fB-h\fR +Prints a short summary of the options and arguments to +\fBrndc-confgen\fR. +.TP +\fB-k \fIkeyname\fB\fR +Specifies the key name of the rndc authentication key. +This must be a valid domain name. +The default is rndc-key. +.TP +\fB-p \fIport\fB\fR +Specifies the command channel port where \fBnamed\fR +listens for connections from \fBrndc\fR. +The default is 953. +.TP +\fB-r \fIrandomfile\fB\fR +Specifies a source of random data for generating the +authorization. If the operating +system does not provide a \fI/dev/random\fR +or equivalent device, the default source of randomness +is keyboard input. \fIrandomdev\fR specifies +the name of a character device or file containing random +data to be used instead of the default. The special value +\fIkeyboard\fR indicates that keyboard +input should be used. +.TP +\fB-s \fIaddress\fB\fR +Specifies the IP address where \fBnamed\fR +listens for command channel connections from +\fBrndc\fR. The default is the loopback +address 127.0.0.1. +.TP +\fB-t \fIchrootdir\fB\fR +Used with the \fB-a\fR option to specify +a directory where \fBnamed\fR will run +chrooted. An additional copy of the \fIrndc.key\fR +will be written relative to this directory so that +it will be found by the chrooted \fBnamed\fR. +.TP +\fB-u \fIuser\fB\fR +Used with the \fB-a\fR option to set the owner +of the \fIrndc.key\fR file generated. If +\fB-t\fR is also specified only the file in +the chroot area has its owner changed. +.SH "EXAMPLES" +.PP +To allow \fBrndc\fR to be used with +no manual configuration, run +.PP +\fBrndc-confgen -a\fR +.PP +To print a sample \fIrndc.conf\fR file and +corresponding \fBcontrols\fR and \fBkey\fR +statements to be manually inserted into \fInamed.conf\fR, +run +.PP +\fBrndc-confgen\fR +.SH "SEE ALSO" +.PP +\fBrndc\fR(8), +\fBrndc.conf\fR(5), +\fBnamed\fR(8), +\fIBIND 9 Administrator Reference Manual\fR. +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/rndc/rndc-confgen.c b/contrib/bind9/bin/rndc/rndc-confgen.c new file mode 100644 index 000000000000..ef0d4973186c --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc-confgen.c @@ -0,0 +1,323 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001, 2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: rndc-confgen.c,v 1.9.2.6.2.4 2004/03/06 10:21:31 marka Exp $ */ + +#include + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + +#include "util.h" + +#define DEFAULT_KEYLENGTH 128 /* Bits. */ +#define DEFAULT_KEYNAME "rndc-key" +#define DEFAULT_SERVER "127.0.0.1" +#define DEFAULT_PORT 953 + +static char program[256]; +char *progname; + +isc_boolean_t verbose = ISC_FALSE; + +const char *keyfile, *keydef; + +static void +usage(int status) { + + fprintf(stderr, "\ +Usage:\n\ + %s [-a] [-b bits] [-c keyfile] [-k keyname] [-p port] [-r randomfile] \ +[-s addr] [-t chrootdir] [-u user]\n\ + -a: generate just the key clause and write it to keyfile (%s)\n\ + -b bits: from 1 through 512, default %d; total length of the secret\n\ + -c keyfile: specify an alternate key file (requires -a)\n\ + -k keyname: the name as it will be used in named.conf and rndc.conf\n\ + -p port: the port named will listen on and rndc will connect to\n\ + -r randomfile: a file containing random data\n\ + -s addr: the address to which rndc should connect\n\ + -t chrootdir: write a keyfile in chrootdir as well (requires -a)\n\ + -u user: set the keyfile owner to \"user\" (requires -a)\n", + progname, keydef, DEFAULT_KEYLENGTH); + + exit (status); +} + +/* + * Write an rndc.key file to 'keyfile'. If 'user' is non-NULL, + * make that user the owner of the file. The key will have + * the name 'keyname' and the secret in the buffer 'secret'. + */ +static void +write_key_file(const char *keyfile, const char *user, + const char *keyname, isc_buffer_t *secret ) +{ + FILE *fd; + + fd = safe_create(keyfile); + if (fd == NULL) + fatal( "unable to create \"%s\"\n", keyfile); + if (user != NULL) { + if (set_user(fd, user) == -1) + fatal("unable to set file owner\n"); + } + fprintf(fd, "key \"%s\" {\n\talgorithm hmac-md5;\n" + "\tsecret \"%.*s\";\n};\n", keyname, + (int)isc_buffer_usedlength(secret), + (char *)isc_buffer_base(secret)); + fflush(fd); + if (ferror(fd)) + fatal("write to %s failed\n", keyfile); + if (fclose(fd)) + fatal("fclose(%s) failed\n", keyfile); + fprintf(stderr, "wrote key file \"%s\"\n", keyfile); +} + +int +main(int argc, char **argv) { + isc_boolean_t show_final_mem = ISC_FALSE; + isc_buffer_t key_rawbuffer; + isc_buffer_t key_txtbuffer; + isc_region_t key_rawregion; + isc_mem_t *mctx = NULL; + isc_entropy_t *ectx = NULL; + isc_entropysource_t *entropy_source = NULL; + isc_result_t result = ISC_R_SUCCESS; + dst_key_t *key = NULL; + const char *keyname = NULL; + const char *randomfile = NULL; + const char *serveraddr = NULL; + char key_rawsecret[64]; + char key_txtsecret[256]; + char *p; + int ch; + int port; + int keysize; + int entropy_flags = 0; + int open_keyboard = ISC_ENTROPY_KEYBOARDMAYBE; + struct in_addr addr4_dummy; + struct in6_addr addr6_dummy; + char *chrootdir = NULL; + char *user = NULL; + isc_boolean_t keyonly = ISC_FALSE; + int len; + + keydef = keyfile = RNDC_KEYFILE; + + result = isc_file_progname(*argv, program, sizeof(program)); + if (result != ISC_R_SUCCESS) + memcpy(program, "rndc-confgen", 13); + progname = program; + + keyname = DEFAULT_KEYNAME; + keysize = DEFAULT_KEYLENGTH; + serveraddr = DEFAULT_SERVER; + port = DEFAULT_PORT; + + while ((ch = isc_commandline_parse(argc, argv, + "ab:c:hk:Mmp:r:s:t:u:Vy")) != -1) { + switch (ch) { + case 'a': + keyonly = ISC_TRUE; + break; + case 'b': + keysize = strtol(isc_commandline_argument, &p, 10); + if (*p != '\0' || keysize < 0) + fatal("-b requires a non-negative number"); + if (keysize < 1 || keysize > 512) + fatal("-b must be in the range 1 through 512"); + break; + case 'c': + keyfile = isc_commandline_argument; + break; + case 'h': + usage(0); + case 'k': + case 'y': /* Compatible with rndc -y. */ + keyname = isc_commandline_argument; + break; + case 'M': + isc_mem_debugging = ISC_MEM_DEBUGTRACE; + break; + + case 'm': + show_final_mem = ISC_TRUE; + break; + case 'p': + port = strtol(isc_commandline_argument, &p, 10); + if (*p != '\0' || port < 0 || port > 65535) + fatal("port '%s' out of range", + isc_commandline_argument); + break; + case 'r': + randomfile = isc_commandline_argument; + break; + case 's': + serveraddr = isc_commandline_argument; + if (inet_pton(AF_INET, serveraddr, &addr4_dummy) != 1 && + inet_pton(AF_INET6, serveraddr, &addr6_dummy) != 1) + fatal("-s should be an IPv4 or IPv6 address"); + break; + case 't': + chrootdir = isc_commandline_argument; + break; + case 'u': + user = isc_commandline_argument; + break; + case 'V': + verbose = ISC_TRUE; + break; + case '?': + usage(1); + break; + default: + fatal("unexpected error parsing command arguments: " + "got %c\n", ch); + break; + } + } + + argc -= isc_commandline_index; + argv += isc_commandline_index; + + if (argc > 0) + usage(1); + + DO("create memory context", isc_mem_create(0, 0, &mctx)); + + DO("create entropy context", isc_entropy_create(mctx, &ectx)); + + if (randomfile != NULL && strcmp(randomfile, "keyboard") == 0) { + randomfile = NULL; + open_keyboard = ISC_ENTROPY_KEYBOARDYES; + } + DO("start entropy source", isc_entropy_usebestsource(ectx, + &entropy_source, + randomfile, + open_keyboard)); + + entropy_flags = ISC_ENTROPY_BLOCKING | ISC_ENTROPY_GOODONLY; + + DO("initialize dst library", dst_lib_init(mctx, ectx, entropy_flags)); + + DO("generate key", dst_key_generate(dns_rootname, DST_ALG_HMACMD5, + keysize, 0, 0, + DNS_KEYPROTO_ANY, + dns_rdataclass_in, mctx, &key)); + + isc_buffer_init(&key_rawbuffer, &key_rawsecret, sizeof(key_rawsecret)); + + DO("dump key to buffer", dst_key_tobuffer(key, &key_rawbuffer)); + + isc_buffer_init(&key_txtbuffer, &key_txtsecret, sizeof(key_txtsecret)); + isc_buffer_usedregion(&key_rawbuffer, &key_rawregion); + + DO("bsse64 encode secret", isc_base64_totext(&key_rawregion, -1, "", + &key_txtbuffer)); + + /* + * Shut down the entropy source now so the "stop typing" message + * does not muck with the output. + */ + if (entropy_source != NULL) + isc_entropy_destroysource(&entropy_source); + + if (key != NULL) + dst_key_free(&key); + + isc_entropy_detach(&ectx); + dst_lib_destroy(); + + if (keyonly) { + write_key_file(keyfile, chrootdir == NULL ? user : NULL, + keyname, &key_txtbuffer); + + if (chrootdir != NULL) { + char *buf; + len = strlen(chrootdir) + strlen(keyfile) + 2; + buf = isc_mem_get(mctx, len); + if (buf == NULL) + fatal("isc_mem_get(%d) failed\n", len); + snprintf(buf, len, "%s/%s", chrootdir, keyfile); + + write_key_file(buf, user, keyname, &key_txtbuffer); + isc_mem_put(mctx, buf, len); + } + } else { + printf("\ +# Start of rndc.conf\n\ +key \"%s\" {\n\ + algorithm hmac-md5;\n\ + secret \"%.*s\";\n\ +};\n\ +\n\ +options {\n\ + default-key \"%s\";\n\ + default-server %s;\n\ + default-port %d;\n\ +};\n\ +# End of rndc.conf\n\ +\n\ +# Use with the following in named.conf, adjusting the allow list as needed:\n\ +# key \"%s\" {\n\ +# algorithm hmac-md5;\n\ +# secret \"%.*s\";\n\ +# };\n\ +# \n\ +# controls {\n\ +# inet %s port %d\n\ +# allow { %s; } keys { \"%s\"; };\n\ +# };\n\ +# End of named.conf\n", + keyname, + (int)isc_buffer_usedlength(&key_txtbuffer), + (char *)isc_buffer_base(&key_txtbuffer), + keyname, serveraddr, port, + keyname, + (int)isc_buffer_usedlength(&key_txtbuffer), + (char *)isc_buffer_base(&key_txtbuffer), + serveraddr, port, serveraddr, keyname); + } + + if (show_final_mem) + isc_mem_stats(mctx, stderr); + + isc_mem_destroy(&mctx); + + return (0); +} diff --git a/contrib/bind9/bin/rndc/rndc-confgen.docbook b/contrib/bind9/bin/rndc/rndc-confgen.docbook new file mode 100644 index 000000000000..272de459c19a --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc-confgen.docbook @@ -0,0 +1,273 @@ + + + + + + + + Aug 27, 2001 + + + + rndc-confgen + 8 + BIND9 + + + + rndc-confgen + rndc key generation tool + + + + + rndc-confgen + + + + + + + + + + + + + + + DESCRIPTION + + rndc-confgen generates configuration files + for rndc. It can be used as a + convenient alternative to writing the + rndc.conf file + and the corresponding controls + and key + statements in named.conf by hand. + Alternatively, it can be run with the -a + option to set up a rndc.key file and + avoid the need for a rndc.conf file + and a controls statement altogether. + + + + + + OPTIONS + + + + -a + + + Do automatic rndc configuration. + This creates a file rndc.key + in /etc (or whatever + sysconfdir + was specified as when BIND was built) + that is read by both rndc + and named on startup. The + rndc.key file defines a default + command channel and authentication key allowing + rndc to communicate with + named on the local host + with no further configuration. + + + Running rndc-confgen -a allows + BIND 9 and rndc to be used as drop-in + replacements for BIND 8 and ndc, + with no changes to the existing BIND 8 + named.conf file. + + + If a more elaborate configuration than that + generated by rndc-confgen -a + is required, for example if rndc is to be used remotely, + you should run rndc-confgen without the + -a option and set up a + rndc.conf and + named.conf + as directed. + + + + + + -b keysize + + + Specifies the size of the authentication key in bits. + Must be between 1 and 512 bits; the default is 128. + + + + + + -c keyfile + + + Used with the -a option to specify + an alternate location for rndc.key. + + + + + + -h + + + Prints a short summary of the options and arguments to + rndc-confgen. + + + + + + -k keyname + + + Specifies the key name of the rndc authentication key. + This must be a valid domain name. + The default is rndc-key. + + + + + + -p port + + + Specifies the command channel port where named + listens for connections from rndc. + The default is 953. + + + + + + -r randomfile + + + Specifies a source of random data for generating the + authorization. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. + + + + + + -s address + + + Specifies the IP address where named + listens for command channel connections from + rndc. The default is the loopback + address 127.0.0.1. + + + + + + -t chrootdir + + + Used with the -a option to specify + a directory where named will run + chrooted. An additional copy of the rndc.key + will be written relative to this directory so that + it will be found by the chrooted named. + + + + + + -u user + + + Used with the -a option to set the owner + of the rndc.key file generated. If + -t is also specified only the file in + the chroot area has its owner changed. + + + + + + + + + EXAMPLES + + To allow rndc to be used with + no manual configuration, run + + + rndc-confgen -a + + + To print a sample rndc.conf file and + corresponding controls and key + statements to be manually inserted into named.conf, + run + + + rndc-confgen + + + + + SEE ALSO + + + rndc + 8 + , + + rndc.conf + 5 + , + + named + 8 + , + BIND 9 Administrator Reference Manual. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + diff --git a/contrib/bind9/bin/rndc/rndc-confgen.html b/contrib/bind9/bin/rndc/rndc-confgen.html new file mode 100644 index 000000000000..7292be2f99dc --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc-confgen.html @@ -0,0 +1,538 @@ + + + + + +rndc-confgen

rndc-confgen

Name

rndc-confgen -- rndc key generation tool

Synopsis

rndc-confgen [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address] [-t chrootdir] [-u user]

DESCRIPTION

rndc-confgen generates configuration files + for rndc. It can be used as a + convenient alternative to writing the + rndc.conf file + and the corresponding controls + and key + statements in named.conf by hand. + Alternatively, it can be run with the -a + option to set up a rndc.key file and + avoid the need for a rndc.conf file + and a controls statement altogether. +

OPTIONS

-a

Do automatic rndc configuration. + This creates a file rndc.key + in /etc (or whatever + sysconfdir + was specified as when BIND was built) + that is read by both rndc + and named on startup. The + rndc.key file defines a default + command channel and authentication key allowing + rndc to communicate with + named on the local host + with no further configuration. +

Running rndc-confgen -a allows + BIND 9 and rndc to be used as drop-in + replacements for BIND 8 and ndc, + with no changes to the existing BIND 8 + named.conf file. +

If a more elaborate configuration than that + generated by rndc-confgen -a + is required, for example if rndc is to be used remotely, + you should run rndc-confgen without the + -a option and set up a + rndc.conf and + named.conf + as directed. +

-b keysize

Specifies the size of the authentication key in bits. + Must be between 1 and 512 bits; the default is 128. +

-c keyfile

Used with the -a option to specify + an alternate location for rndc.key. +

-h

Prints a short summary of the options and arguments to + rndc-confgen. +

-k keyname

Specifies the key name of the rndc authentication key. + This must be a valid domain name. + The default is rndc-key. +

-p port

Specifies the command channel port where named + listens for connections from rndc. + The default is 953. +

-r randomfile

Specifies a source of random data for generating the + authorization. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. +

-s address

Specifies the IP address where named + listens for command channel connections from + rndc. The default is the loopback + address 127.0.0.1. +

-t chrootdir

Used with the -a option to specify + a directory where named will run + chrooted. An additional copy of the rndc.key + will be written relative to this directory so that + it will be found by the chrooted named. +

-u user

Used with the -a option to set the owner + of the rndc.key file generated. If + -t is also specified only the file in + the chroot area has its owner changed. +

EXAMPLES

To allow rndc to be used with + no manual configuration, run +

rndc-confgen -a +

To print a sample rndc.conf file and + corresponding controls and key + statements to be manually inserted into named.conf, + run +

rndc-confgen +

SEE ALSO

rndc(8), + rndc.conf(5), + named(8), + BIND 9 Administrator Reference Manual. +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/rndc/rndc.8 b/contrib/bind9/bin/rndc/rndc.8 new file mode 100644 index 000000000000..356883bc4147 --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc.8 @@ -0,0 +1,118 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: rndc.8,v 1.24.206.2 2004/06/03 05:35:49 marka Exp $ +.\" +.TH "RNDC" "8" "June 30, 2000" "BIND9" "" +.SH NAME +rndc \- name server control utility +.SH SYNOPSIS +.sp +\fBrndc\fR [ \fB-c \fIconfig-file\fB\fR ] [ \fB-k \fIkey-file\fB\fR ] [ \fB-s \fIserver\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-V\fR ] [ \fB-y \fIkey_id\fB\fR ] \fBcommand\fR +.SH "DESCRIPTION" +.PP +\fBrndc\fR controls the operation of a name +server. It supersedes the \fBndc\fR utility +that was provided in old BIND releases. If +\fBrndc\fR is invoked with no command line +options or arguments, it prints a short summary of the +supported commands and the available options and their +arguments. +.PP +\fBrndc\fR communicates with the name server +over a TCP connection, sending commands authenticated with +digital signatures. In the current versions of +\fBrndc\fR and \fBnamed\fR named +the only supported authentication algorithm is HMAC-MD5, +which uses a shared secret on each end of the connection. +This provides TSIG-style authentication for the command +request and the name server's response. All commands sent +over the channel must be signed by a key_id known to the +server. +.PP +\fBrndc\fR reads a configuration file to +determine how to contact the name server and decide what +algorithm and key it should use. +.SH "OPTIONS" +.TP +\fB-c \fIconfig-file\fB\fR +Use \fIconfig-file\fR +as the configuration file instead of the default, +\fI/etc/rndc.conf\fR. +.TP +\fB-k \fIkey-file\fB\fR +Use \fIkey-file\fR +as the key file instead of the default, +\fI/etc/rndc.key\fR. The key in +\fI/etc/rndc.key\fR will be used to authenticate +commands sent to the server if the \fIconfig-file\fR +does not exist. +.TP +\fB-s \fIserver\fB\fR +\fIserver\fR is +the name or address of the server which matches a +server statement in the configuration file for +\fBrndc\fR. If no server is supplied on the +command line, the host named by the default-server clause +in the option statement of the configuration file will be +used. +.TP +\fB-p \fIport\fB\fR +Send commands to TCP port +\fIport\fR instead +of BIND 9's default control channel port, 953. +.TP +\fB-V\fR +Enable verbose logging. +.TP +\fB-y \fIkeyid\fB\fR +Use the key \fIkeyid\fR +from the configuration file. +\fIkeyid\fR must be +known by named with the same algorithm and secret string +in order for control message validation to succeed. +If no \fIkeyid\fR +is specified, \fBrndc\fR will first look +for a key clause in the server statement of the server +being used, or if no server statement is present for that +host, then the default-key clause of the options statement. +Note that the configuration file contains shared secrets +which are used to send authenticated control commands +to name servers. It should therefore not have general read +or write access. +.PP +For the complete set of commands supported by \fBrndc\fR, +see the BIND 9 Administrator Reference Manual or run +\fBrndc\fR without arguments to see its help message. +.PP +.SH "LIMITATIONS" +.PP +\fBrndc\fR does not yet support all the commands of +the BIND 8 \fBndc\fR utility. +.PP +There is currently no way to provide the shared secret for a +\fBkey_id\fR without using the configuration file. +.PP +Several error messages could be clearer. +.SH "SEE ALSO" +.PP +\fBrndc.conf\fR(5), +\fBnamed\fR(8), +\fBnamed.conf\fR(5) +\fBndc\fR(8), +\fIBIND 9 Administrator Reference Manual\fR. +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/rndc/rndc.c b/contrib/bind9/bin/rndc/rndc.c new file mode 100644 index 000000000000..9ea07ac00eb3 --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc.c @@ -0,0 +1,687 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000-2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: rndc.c,v 1.77.2.5.2.12 2004/03/08 04:04:23 marka Exp $ */ + +/* + * Principal Author: DCL + */ + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "util.h" + +#define SERVERADDRS 10 + +char *progname; +isc_boolean_t verbose; + +static const char *admin_conffile; +static const char *admin_keyfile; +static const char *version = VERSION; +static const char *servername = NULL; +static isc_sockaddr_t serveraddrs[SERVERADDRS]; +static int nserveraddrs; +static int currentaddr = 0; +static unsigned int remoteport = 0; +static isc_socketmgr_t *socketmgr = NULL; +static unsigned char databuf[2048]; +static isccc_ccmsg_t ccmsg; +static isccc_region_t secret; +static isc_boolean_t failed = ISC_FALSE; +static isc_mem_t *mctx; +static int sends, recvs, connects; +static char *command; +static char *args; +static char program[256]; +static isc_socket_t *sock = NULL; +static isc_uint32_t serial; + +static void rndc_startconnect(isc_sockaddr_t *addr, isc_task_t *task); + +static void +usage(int status) { + fprintf(stderr, "\ +Usage: %s [-c config] [-s server] [-p port]\n\ + [-k key-file ] [-y key] [-V] command\n\ +\n\ +command is one of the following:\n\ +\n\ + reload Reload configuration file and zones.\n\ + reload zone [class [view]]\n\ + Reload a single zone.\n\ + refresh zone [class [view]]\n\ + Schedule immediate maintenance for a zone.\n\ + retransfer zone [class [view]]\n\ + Retransfer a single zone without checking serial number.\n\ + freeze zone [class [view]]\n\ + Suspend updates to a dynamic zone.\n\ + unfreeze zone [class [view]]\n\ + Enable updates to a frozen dynamic zone and reload it.\n\ + reconfig Reload configuration file and new zones only.\n\ + stats Write server statistics to the statistics file.\n\ + querylog Toggle query logging.\n\ + dumpdb Dump cache(s) to the dump file (named_dump.db).\n\ + stop Save pending updates to master files and stop the server.\n\ + stop -p Save pending updates to master files and stop the server\n\ + reporting process id.\n\ + halt Stop the server without saving pending updates.\n\ + halt -p Stop the server without saving pending updates reporting\n\ + process id.\n\ + trace Increment debugging level by one.\n\ + trace level Change the debugging level.\n\ + notrace Set debugging level to 0.\n\ + flush Flushes all of the server's caches.\n\ + flush [view] Flushes the server's cache for a view.\n\ + flushname name [view]\n\ + Flush the given name from the server's cache(s)\n\ + status Display status of the server.\n\ + recursing Dump the queries that are currently recursing (named.recursing)\n\ + *restart Restart the server.\n\ +\n\ +* == not yet implemented\n\ +Version: %s\n", + progname, version); + + exit(status); +} + +static void +get_addresses(const char *host, in_port_t port) { + isc_result_t result; + + isc_app_block(); + result = bind9_getaddresses(servername, port, + serveraddrs, SERVERADDRS, &nserveraddrs); + isc_app_unblock(); + if (result != ISC_R_SUCCESS) + fatal("couldn't get address for '%s': %s", + host, isc_result_totext(result)); + INSIST(nserveraddrs > 0); +} + +static void +rndc_senddone(isc_task_t *task, isc_event_t *event) { + isc_socketevent_t *sevent = (isc_socketevent_t *)event; + + UNUSED(task); + + sends--; + if (sevent->result != ISC_R_SUCCESS) + fatal("send failed: %s", isc_result_totext(sevent->result)); + isc_event_free(&event); +} + +static void +rndc_recvdone(isc_task_t *task, isc_event_t *event) { + isccc_sexpr_t *response = NULL; + isccc_sexpr_t *data; + isccc_region_t source; + char *errormsg = NULL; + char *textmsg = NULL; + isc_result_t result; + + recvs--; + + if (ccmsg.result == ISC_R_EOF) + fatal("connection to remote host closed\n" + "This may indicate that the remote server is using " + "an older version of \n" + "the command protocol, this host is not authorized " + "to connect,\nor the key is invalid."); + + if (ccmsg.result != ISC_R_SUCCESS) + fatal("recv failed: %s", isc_result_totext(ccmsg.result)); + + source.rstart = isc_buffer_base(&ccmsg.buffer); + source.rend = isc_buffer_used(&ccmsg.buffer); + + DO("parse message", isccc_cc_fromwire(&source, &response, &secret)); + + data = isccc_alist_lookup(response, "_data"); + if (data == NULL) + fatal("no data section in response"); + result = isccc_cc_lookupstring(data, "err", &errormsg); + if (result == ISC_R_SUCCESS) { + failed = ISC_TRUE; + fprintf(stderr, "%s: '%s' failed: %s\n", + progname, command, errormsg); + } + else if (result != ISC_R_NOTFOUND) + fprintf(stderr, "%s: parsing response failed: %s\n", + progname, isc_result_totext(result)); + + result = isccc_cc_lookupstring(data, "text", &textmsg); + if (result == ISC_R_SUCCESS) + printf("%s\n", textmsg); + else if (result != ISC_R_NOTFOUND) + fprintf(stderr, "%s: parsing response failed: %s\n", + progname, isc_result_totext(result)); + + isc_event_free(&event); + isccc_sexpr_free(&response); + isc_socket_detach(&sock); + isc_task_shutdown(task); + RUNTIME_CHECK(isc_app_shutdown() == ISC_R_SUCCESS); +} + +static void +rndc_recvnonce(isc_task_t *task, isc_event_t *event) { + isccc_sexpr_t *response = NULL; + isccc_sexpr_t *_ctrl; + isccc_region_t source; + isc_result_t result; + isc_uint32_t nonce; + isccc_sexpr_t *request = NULL; + isccc_time_t now; + isc_region_t r; + isccc_sexpr_t *data; + isccc_region_t message; + isc_uint32_t len; + isc_buffer_t b; + + recvs--; + + if (ccmsg.result == ISC_R_EOF) + fatal("connection to remote host closed\n" + "This may indicate that the remote server is using " + "an older version of \n" + "the command protocol, this host is not authorized " + "to connect,\nor the key is invalid."); + + if (ccmsg.result != ISC_R_SUCCESS) + fatal("recv failed: %s", isc_result_totext(ccmsg.result)); + + source.rstart = isc_buffer_base(&ccmsg.buffer); + source.rend = isc_buffer_used(&ccmsg.buffer); + + DO("parse message", isccc_cc_fromwire(&source, &response, &secret)); + + _ctrl = isccc_alist_lookup(response, "_ctrl"); + if (_ctrl == NULL) + fatal("_ctrl section missing"); + nonce = 0; + if (isccc_cc_lookupuint32(_ctrl, "_nonce", &nonce) != ISC_R_SUCCESS) + nonce = 0; + + isc_stdtime_get(&now); + + DO("create message", isccc_cc_createmessage(1, NULL, NULL, ++serial, + now, now + 60, &request)); + data = isccc_alist_lookup(request, "_data"); + if (data == NULL) + fatal("_data section missing"); + if (isccc_cc_definestring(data, "type", args) == NULL) + fatal("out of memory"); + if (nonce != 0) { + _ctrl = isccc_alist_lookup(request, "_ctrl"); + if (_ctrl == NULL) + fatal("_ctrl section missing"); + if (isccc_cc_defineuint32(_ctrl, "_nonce", nonce) == NULL) + fatal("out of memory"); + } + message.rstart = databuf + 4; + message.rend = databuf + sizeof(databuf); + DO("render message", isccc_cc_towire(request, &message, &secret)); + len = sizeof(databuf) - REGION_SIZE(message); + isc_buffer_init(&b, databuf, 4); + isc_buffer_putuint32(&b, len - 4); + r.length = len; + r.base = databuf; + + isccc_ccmsg_cancelread(&ccmsg); + DO("schedule recv", isccc_ccmsg_readmessage(&ccmsg, task, + rndc_recvdone, NULL)); + recvs++; + DO("send message", isc_socket_send(sock, &r, task, rndc_senddone, + NULL)); + sends++; + + isc_event_free(&event); + isccc_sexpr_free(&response); + return; +} + +static void +rndc_connected(isc_task_t *task, isc_event_t *event) { + isc_socketevent_t *sevent = (isc_socketevent_t *)event; + isccc_sexpr_t *request = NULL; + isccc_sexpr_t *data; + isccc_time_t now; + isccc_region_t message; + isc_region_t r; + isc_uint32_t len; + isc_buffer_t b; + isc_result_t result; + + connects--; + + if (sevent->result != ISC_R_SUCCESS) { + if (sevent->result != ISC_R_CANCELED && + currentaddr < nserveraddrs) + { + notify("connection failed: %s", + isc_result_totext(sevent->result)); + isc_socket_detach(&sock); + isc_event_free(&event); + rndc_startconnect(&serveraddrs[currentaddr++], task); + return; + } else + fatal("connect failed: %s", + isc_result_totext(sevent->result)); + } + + isc_stdtime_get(&now); + DO("create message", isccc_cc_createmessage(1, NULL, NULL, ++serial, + now, now + 60, &request)); + data = isccc_alist_lookup(request, "_data"); + if (data == NULL) + fatal("_data section missing"); + if (isccc_cc_definestring(data, "type", "null") == NULL) + fatal("out of memory"); + message.rstart = databuf + 4; + message.rend = databuf + sizeof(databuf); + DO("render message", isccc_cc_towire(request, &message, &secret)); + len = sizeof(databuf) - REGION_SIZE(message); + isc_buffer_init(&b, databuf, 4); + isc_buffer_putuint32(&b, len - 4); + r.length = len; + r.base = databuf; + + isccc_ccmsg_init(mctx, sock, &ccmsg); + isccc_ccmsg_setmaxsize(&ccmsg, 1024); + + DO("schedule recv", isccc_ccmsg_readmessage(&ccmsg, task, + rndc_recvnonce, NULL)); + recvs++; + DO("send message", isc_socket_send(sock, &r, task, rndc_senddone, + NULL)); + sends++; + isc_event_free(&event); +} + +static void +rndc_startconnect(isc_sockaddr_t *addr, isc_task_t *task) { + isc_result_t result; + + char socktext[ISC_SOCKADDR_FORMATSIZE]; + + isc_sockaddr_format(addr, socktext, sizeof(socktext)); + + notify("using server %s (%s)", servername, socktext); + + DO("create socket", isc_socket_create(socketmgr, + isc_sockaddr_pf(addr), + isc_sockettype_tcp, &sock)); + DO("connect", isc_socket_connect(sock, addr, task, rndc_connected, + NULL)); + connects++; +} + +static void +rndc_start(isc_task_t *task, isc_event_t *event) { + isc_event_free(&event); + + get_addresses(servername, (in_port_t) remoteport); + + currentaddr = 0; + rndc_startconnect(&serveraddrs[currentaddr++], task); +} + +static void +parse_config(isc_mem_t *mctx, isc_log_t *log, const char *keyname, + cfg_parser_t **pctxp, cfg_obj_t **configp) +{ + isc_result_t result; + const char *conffile = admin_conffile; + cfg_obj_t *defkey = NULL; + cfg_obj_t *options = NULL; + cfg_obj_t *servers = NULL; + cfg_obj_t *server = NULL; + cfg_obj_t *keys = NULL; + cfg_obj_t *key = NULL; + cfg_obj_t *defport = NULL; + cfg_obj_t *secretobj = NULL; + cfg_obj_t *algorithmobj = NULL; + cfg_obj_t *config = NULL; + cfg_listelt_t *elt; + const char *secretstr; + const char *algorithm; + static char secretarray[1024]; + const cfg_type_t *conftype = &cfg_type_rndcconf; + isc_boolean_t key_only = ISC_FALSE; + + if (! isc_file_exists(conffile)) { + conffile = admin_keyfile; + conftype = &cfg_type_rndckey; + + if (! isc_file_exists(conffile)) + fatal("neither %s nor %s was found", + admin_conffile, admin_keyfile); + key_only = ISC_TRUE; + } + + DO("create parser", cfg_parser_create(mctx, log, pctxp)); + + /* + * The parser will output its own errors, so DO() is not used. + */ + result = cfg_parse_file(*pctxp, conffile, conftype, &config); + if (result != ISC_R_SUCCESS) + fatal("could not load rndc configuration"); + + if (!key_only) + (void)cfg_map_get(config, "options", &options); + + if (key_only && servername == NULL) + servername = "127.0.0.1"; + else if (servername == NULL && options != NULL) { + cfg_obj_t *defserverobj = NULL; + (void)cfg_map_get(options, "default-server", &defserverobj); + if (defserverobj != NULL) + servername = cfg_obj_asstring(defserverobj); + } + + if (servername == NULL) + fatal("no server specified and no default"); + + if (!key_only) { + (void)cfg_map_get(config, "server", &servers); + if (servers != NULL) { + for (elt = cfg_list_first(servers); + elt != NULL; + elt = cfg_list_next(elt)) + { + const char *name; + server = cfg_listelt_value(elt); + name = cfg_obj_asstring(cfg_map_getname(server)); + if (strcasecmp(name, servername) == 0) + break; + server = NULL; + } + } + } + + /* + * Look for the name of the key to use. + */ + if (keyname != NULL) + ; /* Was set on command line, do nothing. */ + else if (server != NULL) { + DO("get key for server", cfg_map_get(server, "key", &defkey)); + keyname = cfg_obj_asstring(defkey); + } else if (options != NULL) { + DO("get default key", cfg_map_get(options, "default-key", + &defkey)); + keyname = cfg_obj_asstring(defkey); + } else if (!key_only) + fatal("no key for server and no default"); + + /* + * Get the key's definition. + */ + if (key_only) + DO("get key", cfg_map_get(config, "key", &key)); + else { + DO("get config key list", cfg_map_get(config, "key", &keys)); + for (elt = cfg_list_first(keys); + elt != NULL; + elt = cfg_list_next(elt)) + { + key = cfg_listelt_value(elt); + if (strcasecmp(cfg_obj_asstring(cfg_map_getname(key)), + keyname) == 0) + break; + } + if (elt == NULL) + fatal("no key definition for name %s", keyname); + } + (void)cfg_map_get(key, "secret", &secretobj); + (void)cfg_map_get(key, "algorithm", &algorithmobj); + if (secretobj == NULL || algorithmobj == NULL) + fatal("key must have algorithm and secret"); + + secretstr = cfg_obj_asstring(secretobj); + algorithm = cfg_obj_asstring(algorithmobj); + + if (strcasecmp(algorithm, "hmac-md5") != 0) + fatal("unsupported algorithm: %s", algorithm); + + secret.rstart = (unsigned char *)secretarray; + secret.rend = (unsigned char *)secretarray + sizeof(secretarray); + DO("decode base64 secret", isccc_base64_decode(secretstr, &secret)); + secret.rend = secret.rstart; + secret.rstart = (unsigned char *)secretarray; + + /* + * Find the port to connect to. + */ + if (remoteport != 0) + ; /* Was set on command line, do nothing. */ + else { + if (server != NULL) + (void)cfg_map_get(server, "port", &defport); + if (defport == NULL && options != NULL) + (void)cfg_map_get(options, "default-port", &defport); + } + if (defport != NULL) { + remoteport = cfg_obj_asuint32(defport); + if (remoteport > 65535 || remoteport == 0) + fatal("port %d out of range", remoteport); + } else if (remoteport == 0) + remoteport = NS_CONTROL_PORT; + + *configp = config; +} + +int +main(int argc, char **argv) { + isc_boolean_t show_final_mem = ISC_FALSE; + isc_result_t result = ISC_R_SUCCESS; + isc_taskmgr_t *taskmgr = NULL; + isc_task_t *task = NULL; + isc_log_t *log = NULL; + isc_logconfig_t *logconfig = NULL; + isc_logdestination_t logdest; + cfg_parser_t *pctx = NULL; + cfg_obj_t *config = NULL; + const char *keyname = NULL; + char *p; + size_t argslen; + int ch; + int i; + + result = isc_file_progname(*argv, program, sizeof(program)); + if (result != ISC_R_SUCCESS) + memcpy(program, "rndc", 5); + progname = program; + + admin_conffile = RNDC_CONFFILE; + admin_keyfile = RNDC_KEYFILE; + + result = isc_app_start(); + if (result != ISC_R_SUCCESS) + fatal("isc_app_start() failed: %s", isc_result_totext(result)); + + while ((ch = isc_commandline_parse(argc, argv, "c:k:Mmp:s:Vy:")) + != -1) { + switch (ch) { + case 'c': + admin_conffile = isc_commandline_argument; + break; + + case 'k': + admin_keyfile = isc_commandline_argument; + break; + + case 'M': + isc_mem_debugging = ISC_MEM_DEBUGTRACE; + break; + + case 'm': + show_final_mem = ISC_TRUE; + break; + + case 'p': + remoteport = atoi(isc_commandline_argument); + if (remoteport > 65535 || remoteport == 0) + fatal("port '%s' out of range", + isc_commandline_argument); + break; + + case 's': + servername = isc_commandline_argument; + break; + case 'V': + verbose = ISC_TRUE; + break; + case 'y': + keyname = isc_commandline_argument; + break; + case '?': + usage(0); + break; + default: + fatal("unexpected error parsing command arguments: " + "got %c\n", ch); + break; + } + } + + argc -= isc_commandline_index; + argv += isc_commandline_index; + + if (argc < 1) + usage(1); + + isc_random_get(&serial); + + DO("create memory context", isc_mem_create(0, 0, &mctx)); + DO("create socket manager", isc_socketmgr_create(mctx, &socketmgr)); + DO("create task manager", isc_taskmgr_create(mctx, 1, 0, &taskmgr)); + DO("create task", isc_task_create(taskmgr, 0, &task)); + + DO("create logging context", isc_log_create(mctx, &log, &logconfig)); + isc_log_setcontext(log); + DO("setting log tag", isc_log_settag(logconfig, progname)); + logdest.file.stream = stderr; + logdest.file.name = NULL; + logdest.file.versions = ISC_LOG_ROLLNEVER; + logdest.file.maximum_size = 0; + DO("creating log channel", + isc_log_createchannel(logconfig, "stderr", + ISC_LOG_TOFILEDESC, ISC_LOG_INFO, &logdest, + ISC_LOG_PRINTTAG|ISC_LOG_PRINTLEVEL)); + DO("enabling log channel", isc_log_usechannel(logconfig, "stderr", + NULL, NULL)); + + parse_config(mctx, log, keyname, &pctx, &config); + + isccc_result_register(); + + command = *argv; + + /* + * Convert argc/argv into a space-delimited command string + * similar to what the user might enter in interactive mode + * (if that were implemented). + */ + argslen = 0; + for (i = 0; i < argc; i++) + argslen += strlen(argv[i]) + 1; + + args = isc_mem_get(mctx, argslen); + if (args == NULL) + DO("isc_mem_get", ISC_R_NOMEMORY); + + p = args; + for (i = 0; i < argc; i++) { + size_t len = strlen(argv[i]); + memcpy(p, argv[i], len); + p += len; + *p++ = ' '; + } + + p--; + *p++ = '\0'; + INSIST(p == args + argslen); + + notify("%s", command); + + if (strcmp(command, "restart") == 0) + fatal("'%s' is not implemented", command); + + DO("post event", isc_app_onrun(mctx, task, rndc_start, NULL)); + + result = isc_app_run(); + if (result != ISC_R_SUCCESS) + fatal("isc_app_run() failed: %s", isc_result_totext(result)); + + if (connects > 0 || sends > 0 || recvs > 0) + isc_socket_cancel(sock, task, ISC_SOCKCANCEL_ALL); + + isc_task_detach(&task); + isc_taskmgr_destroy(&taskmgr); + isc_socketmgr_destroy(&socketmgr); + isc_log_destroy(&log); + isc_log_setcontext(NULL); + + cfg_obj_destroy(pctx, &config); + cfg_parser_destroy(&pctx); + + isc_mem_put(mctx, args, argslen); + isccc_ccmsg_invalidate(&ccmsg); + + if (show_final_mem) + isc_mem_stats(mctx, stderr); + + isc_mem_destroy(&mctx); + + if (failed) + return (1); + + return (0); +} diff --git a/contrib/bind9/bin/rndc/rndc.conf b/contrib/bind9/bin/rndc/rndc.conf new file mode 100644 index 000000000000..1dc56074d715 --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc.conf @@ -0,0 +1,36 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: rndc.conf,v 1.7.206.1 2004/03/06 10:21:32 marka Exp $ */ + +/* + * Sample rndc configuration file. + */ + +options { + default-server localhost; + default-key "key"; +}; + +server localhost { + key "key"; +}; + +key "key" { + algorithm hmac-md5; + secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; +}; diff --git a/contrib/bind9/bin/rndc/rndc.conf.5 b/contrib/bind9/bin/rndc/rndc.conf.5 new file mode 100644 index 000000000000..5b61cfb00c1e --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc.conf.5 @@ -0,0 +1,142 @@ +.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 Internet Software Consortium. +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +.\" PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $Id: rndc.conf.5,v 1.21.206.2 2004/06/03 05:35:50 marka Exp $ +.\" +.TH "RNDC.CONF" "5" "June 30, 2000" "BIND9" "" +.SH NAME +rndc.conf \- rndc configuration file +.SH SYNOPSIS +.sp +\fBrndc.conf\fR +.SH "DESCRIPTION" +.PP +\fIrndc.conf\fR is the configuration file +for \fBrndc\fR, the BIND 9 name server control +utility. This file has a similar structure and syntax to +\fInamed.conf\fR. Statements are enclosed +in braces and terminated with a semi-colon. Clauses in +the statements are also semi-colon terminated. The usual +comment styles are supported: +.PP +C style: /* */ +.PP +C++ style: // to end of line +.PP +Unix style: # to end of line +.PP +\fIrndc.conf\fR is much simpler than +\fInamed.conf\fR. The file uses three +statements: an options statement, a server statement +and a key statement. +.PP +The \fBoptions\fR statement contains three clauses. +The \fBdefault-server\fR clause is followed by the +name or address of a name server. This host will be used when +no name server is given as an argument to +\fBrndc\fR. The \fBdefault-key\fR +clause is followed by the name of a key which is identified by +a \fBkey\fR statement. If no +\fBkeyid\fR is provided on the rndc command line, +and no \fBkey\fR clause is found in a matching +\fBserver\fR statement, this default key will be +used to authenticate the server's commands and responses. The +\fBdefault-port\fR clause is followed by the port +to connect to on the remote name server. If no +\fBport\fR option is provided on the rndc command +line, and no \fBport\fR clause is found in a +matching \fBserver\fR statement, this default port +will be used to connect. +.PP +After the \fBserver\fR keyword, the server statement +includes a string which is the hostname or address for a name +server. The statement has two possible clauses: +\fBkey\fR and \fBport\fR. The key name must +match the name of a key statement in the file. The port number +specifies the port to connect to. +.PP +The \fBkey\fR statement begins with an identifying +string, the name of the key. The statement has two clauses. +\fBalgorithm\fR identifies the encryption algorithm +for \fBrndc\fR to use; currently only HMAC-MD5 is +supported. This is followed by a secret clause which contains +the base-64 encoding of the algorithm's encryption key. The +base-64 string is enclosed in double quotes. +.PP +There are two common ways to generate the base-64 string for the +secret. The BIND 9 program \fBrndc-confgen\fR can +be used to generate a random key, or the +\fBmmencode\fR program, also known as +\fBmimencode\fR, can be used to generate a base-64 +string from known input. \fBmmencode\fR does not +ship with BIND 9 but is available on many systems. See the +EXAMPLE section for sample command lines for each. +.SH "EXAMPLE" +.sp +.nf + options { + default-server localhost; + default-key samplekey; + }; + + server localhost { + key samplekey; + }; + + key samplekey { + algorithm hmac-md5; + secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; + }; + +.sp +.fi +.PP +In the above example, \fBrndc\fR will by default use +the server at localhost (127.0.0.1) and the key called samplekey. +Commands to the localhost server will use the samplekey key, which +must also be defined in the server's configuration file with the +same name and secret. The key statement indicates that samplekey +uses the HMAC-MD5 algorithm and its secret clause contains the +base-64 encoding of the HMAC-MD5 secret enclosed in double quotes. +.PP +To generate a random secret with \fBrndc-confgen\fR: +.PP +\fBrndc-confgen\fR +.PP +A complete \fIrndc.conf\fR file, including the +randomly generated key, will be written to the standard +output. Commented out \fBkey\fR and +\fBcontrols\fR statements for +\fInamed.conf\fR are also printed. +.PP +To generate a base-64 secret with \fBmmencode\fR: +.PP +\fBecho "known plaintext for a secret" | mmencode\fR +.SH "NAME SERVER CONFIGURATION" +.PP +The name server must be configured to accept rndc connections and +to recognize the key specified in the \fIrndc.conf\fR +file, using the controls statement in \fInamed.conf\fR. +See the sections on the \fBcontrols\fR statement in the +BIND 9 Administrator Reference Manual for details. +.SH "SEE ALSO" +.PP +\fBrndc\fR(8), +\fBrndc-confgen\fR(8), +\fBmmencode\fR(1), +\fIBIND 9 Administrator Reference Manual\fR. +.SH "AUTHOR" +.PP +Internet Systems Consortium diff --git a/contrib/bind9/bin/rndc/rndc.conf.docbook b/contrib/bind9/bin/rndc/rndc.conf.docbook new file mode 100644 index 000000000000..95f158b7602a --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc.conf.docbook @@ -0,0 +1,210 @@ + + + + + + + + June 30, 2000 + + + + rndc.conf + 5 + BIND9 + + + + rndc.conf + rndc configuration file + + + + + rndc.conf + + + + + DESCRIPTION + + rndc.conf is the configuration file + for rndc, the BIND 9 name server control + utility. This file has a similar structure and syntax to + named.conf. Statements are enclosed + in braces and terminated with a semi-colon. Clauses in + the statements are also semi-colon terminated. The usual + comment styles are supported: + + + C style: /* */ + + + C++ style: // to end of line + + + Unix style: # to end of line + + + rndc.conf is much simpler than + named.conf. The file uses three + statements: an options statement, a server statement + and a key statement. + + + The statement contains three clauses. + The clause is followed by the + name or address of a name server. This host will be used when + no name server is given as an argument to + rndc. The + clause is followed by the name of a key which is identified by + a statement. If no + is provided on the rndc command line, + and no clause is found in a matching + statement, this default key will be + used to authenticate the server's commands and responses. The + clause is followed by the port + to connect to on the remote name server. If no + option is provided on the rndc command + line, and no clause is found in a + matching statement, this default port + will be used to connect. + + + After the keyword, the server statement + includes a string which is the hostname or address for a name + server. The statement has two possible clauses: + and . The key name must + match the name of a key statement in the file. The port number + specifies the port to connect to. + + + The statement begins with an identifying + string, the name of the key. The statement has two clauses. + identifies the encryption algorithm + for rndc to use; currently only HMAC-MD5 is + supported. This is followed by a secret clause which contains + the base-64 encoding of the algorithm's encryption key. The + base-64 string is enclosed in double quotes. + + + There are two common ways to generate the base-64 string for the + secret. The BIND 9 program rndc-confgen can + be used to generate a random key, or the + mmencode program, also known as + mimencode, can be used to generate a base-64 + string from known input. mmencode does not + ship with BIND 9 but is available on many systems. See the + EXAMPLE section for sample command lines for each. + + + + + EXAMPLE + + + options { + default-server localhost; + default-key samplekey; + }; + + server localhost { + key samplekey; + }; + + key samplekey { + algorithm hmac-md5; + secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; + }; + + + + In the above example, rndc will by default use + the server at localhost (127.0.0.1) and the key called samplekey. + Commands to the localhost server will use the samplekey key, which + must also be defined in the server's configuration file with the + same name and secret. The key statement indicates that samplekey + uses the HMAC-MD5 algorithm and its secret clause contains the + base-64 encoding of the HMAC-MD5 secret enclosed in double quotes. + + + To generate a random secret with rndc-confgen: + + + rndc-confgen + + + A complete rndc.conf file, including the + randomly generated key, will be written to the standard + output. Commented out and + statements for + named.conf are also printed. + + + To generate a base-64 secret with mmencode: + + + echo "known plaintext for a secret" | mmencode + + + + + NAME SERVER CONFIGURATION + + The name server must be configured to accept rndc connections and + to recognize the key specified in the rndc.conf + file, using the controls statement in named.conf. + See the sections on the statement in the + BIND 9 Administrator Reference Manual for details. + + + + + SEE ALSO + + + rndc + 8 + , + + rndc-confgen + 8 + , + + mmencode + 1 + , + BIND 9 Administrator Reference Manual. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + + diff --git a/contrib/bind9/bin/rndc/rndc.conf.html b/contrib/bind9/bin/rndc/rndc.conf.html new file mode 100644 index 000000000000..ea087c8be60e --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc.conf.html @@ -0,0 +1,377 @@ + + + + + +rndc.conf

rndc.conf

Name

rndc.conf -- rndc configuration file

Synopsis

rndc.conf

DESCRIPTION

rndc.conf is the configuration file + for rndc, the BIND 9 name server control + utility. This file has a similar structure and syntax to + named.conf. Statements are enclosed + in braces and terminated with a semi-colon. Clauses in + the statements are also semi-colon terminated. The usual + comment styles are supported: +

C style: /* */ +

C++ style: // to end of line +

Unix style: # to end of line +

rndc.conf is much simpler than + named.conf. The file uses three + statements: an options statement, a server statement + and a key statement. +

The options statement contains three clauses. + The default-server clause is followed by the + name or address of a name server. This host will be used when + no name server is given as an argument to + rndc. The default-key + clause is followed by the name of a key which is identified by + a key statement. If no + keyid is provided on the rndc command line, + and no key clause is found in a matching + server statement, this default key will be + used to authenticate the server's commands and responses. The + default-port clause is followed by the port + to connect to on the remote name server. If no + port option is provided on the rndc command + line, and no port clause is found in a + matching server statement, this default port + will be used to connect. +

After the server keyword, the server statement + includes a string which is the hostname or address for a name + server. The statement has two possible clauses: + key and port. The key name must + match the name of a key statement in the file. The port number + specifies the port to connect to. +

The key statement begins with an identifying + string, the name of the key. The statement has two clauses. + algorithm identifies the encryption algorithm + for rndc to use; currently only HMAC-MD5 is + supported. This is followed by a secret clause which contains + the base-64 encoding of the algorithm's encryption key. The + base-64 string is enclosed in double quotes. +

There are two common ways to generate the base-64 string for the + secret. The BIND 9 program rndc-confgen can + be used to generate a random key, or the + mmencode program, also known as + mimencode, can be used to generate a base-64 + string from known input. mmencode does not + ship with BIND 9 but is available on many systems. See the + EXAMPLE section for sample command lines for each. +

EXAMPLE

    options {
+        default-server  localhost;
+        default-key     samplekey;
+      };
+
+      server localhost {
+        key             samplekey;
+      };
+
+      key samplekey {
+        algorithm       hmac-md5;
+        secret          "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
+      };
+

In the above example, rndc will by default use + the server at localhost (127.0.0.1) and the key called samplekey. + Commands to the localhost server will use the samplekey key, which + must also be defined in the server's configuration file with the + same name and secret. The key statement indicates that samplekey + uses the HMAC-MD5 algorithm and its secret clause contains the + base-64 encoding of the HMAC-MD5 secret enclosed in double quotes. +

To generate a random secret with rndc-confgen: +

rndc-confgen +

A complete rndc.conf file, including the + randomly generated key, will be written to the standard + output. Commented out key and + controls statements for + named.conf are also printed. +

To generate a base-64 secret with mmencode: +

echo "known plaintext for a secret" | mmencode +

NAME SERVER CONFIGURATION

The name server must be configured to accept rndc connections and + to recognize the key specified in the rndc.conf + file, using the controls statement in named.conf. + See the sections on the controls statement in the + BIND 9 Administrator Reference Manual for details. +

SEE ALSO

rndc(8), + rndc-confgen(8), + mmencode(1), + BIND 9 Administrator Reference Manual. +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/rndc/rndc.docbook b/contrib/bind9/bin/rndc/rndc.docbook new file mode 100644 index 000000000000..d4529ccfa6e2 --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc.docbook @@ -0,0 +1,228 @@ + + + + + + + + June 30, 2000 + + + + rndc + 8 + BIND9 + + + + rndc + name server control utility + + + + + rndc + + + + + + + command + + + + + DESCRIPTION + + rndc controls the operation of a name + server. It supersedes the ndc utility + that was provided in old BIND releases. If + rndc is invoked with no command line + options or arguments, it prints a short summary of the + supported commands and the available options and their + arguments. + + + rndc communicates with the name server + over a TCP connection, sending commands authenticated with + digital signatures. In the current versions of + rndc and named named + the only supported authentication algorithm is HMAC-MD5, + which uses a shared secret on each end of the connection. + This provides TSIG-style authentication for the command + request and the name server's response. All commands sent + over the channel must be signed by a key_id known to the + server. + + + rndc reads a configuration file to + determine how to contact the name server and decide what + algorithm and key it should use. + + + + + OPTIONS + + + + -c config-file + + + Use config-file + as the configuration file instead of the default, + /etc/rndc.conf. + + + + + + -k key-file + + + Use key-file + as the key file instead of the default, + /etc/rndc.key. The key in + /etc/rndc.key will be used to authenticate + commands sent to the server if the config-file + does not exist. + + + + + + -s server + + + server is + the name or address of the server which matches a + server statement in the configuration file for + rndc. If no server is supplied on the + command line, the host named by the default-server clause + in the option statement of the configuration file will be + used. + + + + + + -p port + + + Send commands to TCP port + port instead + of BIND 9's default control channel port, 953. + + + + + + -V + + + Enable verbose logging. + + + + + + -y keyid + + + Use the key keyid + from the configuration file. + keyid must be + known by named with the same algorithm and secret string + in order for control message validation to succeed. + If no keyid + is specified, rndc will first look + for a key clause in the server statement of the server + being used, or if no server statement is present for that + host, then the default-key clause of the options statement. + Note that the configuration file contains shared secrets + which are used to send authenticated control commands + to name servers. It should therefore not have general read + or write access. + + + + + + + + For the complete set of commands supported by rndc, + see the BIND 9 Administrator Reference Manual or run + rndc without arguments to see its help message. + + + + + + LIMITATIONS + + rndc does not yet support all the commands of + the BIND 8 ndc utility. + + + There is currently no way to provide the shared secret for a + without using the configuration file. + + + Several error messages could be clearer. + + + + + SEE ALSO + + + rndc.conf + 5 + , + + named + 8 + , + + named.conf + 5 + + + ndc + 8 + , + BIND 9 Administrator Reference Manual. + + + + + AUTHOR + + Internet Systems Consortium + + + + + + + diff --git a/contrib/bind9/bin/rndc/rndc.html b/contrib/bind9/bin/rndc/rndc.html new file mode 100644 index 000000000000..56f1aa1dba15 --- /dev/null +++ b/contrib/bind9/bin/rndc/rndc.html @@ -0,0 +1,388 @@ + + + + + +rndc

rndc

Name

rndc -- name server control utility

Synopsis

rndc [-c config-file] [-k key-file] [-s server] [-p port] [-V] [-y key_id] {command}

DESCRIPTION

rndc controls the operation of a name + server. It supersedes the ndc utility + that was provided in old BIND releases. If + rndc is invoked with no command line + options or arguments, it prints a short summary of the + supported commands and the available options and their + arguments. +

rndc communicates with the name server + over a TCP connection, sending commands authenticated with + digital signatures. In the current versions of + rndc and named named + the only supported authentication algorithm is HMAC-MD5, + which uses a shared secret on each end of the connection. + This provides TSIG-style authentication for the command + request and the name server's response. All commands sent + over the channel must be signed by a key_id known to the + server. +

rndc reads a configuration file to + determine how to contact the name server and decide what + algorithm and key it should use. +

OPTIONS

-c config-file

Use config-file + as the configuration file instead of the default, + /etc/rndc.conf. +

-k key-file

Use key-file + as the key file instead of the default, + /etc/rndc.key. The key in + /etc/rndc.key will be used to authenticate + commands sent to the server if the config-file + does not exist. +

-s server

server is + the name or address of the server which matches a + server statement in the configuration file for + rndc. If no server is supplied on the + command line, the host named by the default-server clause + in the option statement of the configuration file will be + used. +

-p port

Send commands to TCP port + port instead + of BIND 9's default control channel port, 953. +

-V

Enable verbose logging. +

-y keyid

Use the key keyid + from the configuration file. + keyid must be + known by named with the same algorithm and secret string + in order for control message validation to succeed. + If no keyid + is specified, rndc will first look + for a key clause in the server statement of the server + being used, or if no server statement is present for that + host, then the default-key clause of the options statement. + Note that the configuration file contains shared secrets + which are used to send authenticated control commands + to name servers. It should therefore not have general read + or write access. +

For the complete set of commands supported by rndc, + see the BIND 9 Administrator Reference Manual or run + rndc without arguments to see its help message. +

LIMITATIONS

rndc does not yet support all the commands of + the BIND 8 ndc utility. +

There is currently no way to provide the shared secret for a + key_id without using the configuration file. +

Several error messages could be clearer. +

SEE ALSO

rndc.conf(5), + named(8), + named.conf(5) + ndc(8), + BIND 9 Administrator Reference Manual. +

AUTHOR

Internet Systems Consortium +

diff --git a/contrib/bind9/bin/rndc/unix/Makefile.in b/contrib/bind9/bin/rndc/unix/Makefile.in new file mode 100644 index 000000000000..0409a188838f --- /dev/null +++ b/contrib/bind9/bin/rndc/unix/Makefile.in @@ -0,0 +1,36 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.1.12.3 2004/03/08 04:04:24 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_MAKE_INCLUDES@ + +CINCLUDES = -I${srcdir}/include -I${srcdir}/../include \ + ${DNS_INCLUDES} ${ISC_INCLUDES} + +CDEFINES = +CWARNINGS = + +OBJS = os.@O@ + +SRCS = os.c + +TARGETS = ${OBJS} + +@BIND9_MAKE_RULES@ diff --git a/contrib/bind9/bin/rndc/unix/os.c b/contrib/bind9/bin/rndc/unix/os.c new file mode 100644 index 000000000000..1adfdee9f15e --- /dev/null +++ b/contrib/bind9/bin/rndc/unix/os.c @@ -0,0 +1,68 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: os.c,v 1.5.206.1 2004/03/06 10:21:33 marka Exp $ */ + +#include + +#include + +#include +#include +#include +#include +#include +#include +#include + +int +set_user(FILE *fd, const char *user) { + struct passwd *pw; + + pw = getpwnam(user); + if (pw == NULL) { + errno = EINVAL; + return (-1); + } + return (fchown(fileno(fd), pw->pw_uid, -1)); +} + +FILE * +safe_create(const char *filename) { + int fd; + FILE *f; + struct stat sb; + int flags = O_WRONLY; + + if (stat(filename, &sb) == -1) { + if (errno != ENOENT) + return (NULL); + flags = O_WRONLY | O_CREAT | O_EXCL; + } else if ((sb.st_mode & S_IFREG) == 0) { + errno = EOPNOTSUPP; + return (NULL); + } else + flags = O_WRONLY | O_TRUNC; + + fd = open(filename, flags, S_IRUSR | S_IWUSR); + if (fd == -1) + return (NULL); + f = fdopen(fd, "w"); + if (f == NULL) + close(fd); + return (f); +} diff --git a/contrib/bind9/bin/rndc/util.c b/contrib/bind9/bin/rndc/util.c new file mode 100644 index 000000000000..249cbe2ab1c1 --- /dev/null +++ b/contrib/bind9/bin/rndc/util.c @@ -0,0 +1,55 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: util.c,v 1.2.206.1 2004/03/06 10:21:32 marka Exp $ */ + +#include + +#include +#include +#include + +#include + +#include "util.h" + +extern isc_boolean_t verbose; +extern const char *progname; + +void +notify(const char *fmt, ...) { + va_list ap; + + if (verbose) { + va_start(ap, fmt); + vfprintf(stderr, fmt, ap); + va_end(ap); + fputs("\n", stderr); + } +} + +void +fatal(const char *format, ...) { + va_list args; + + fprintf(stderr, "%s: ", progname); + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + fprintf(stderr, "\n"); + exit(1); +} diff --git a/contrib/bind9/bin/rndc/util.h b/contrib/bind9/bin/rndc/util.h new file mode 100644 index 000000000000..3c19cd447575 --- /dev/null +++ b/contrib/bind9/bin/rndc/util.h @@ -0,0 +1,49 @@ +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2000, 2001 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: util.h,v 1.5.206.1 2004/03/06 10:21:32 marka Exp $ */ + +#ifndef RNDC_UTIL_H +#define RNDC_UTIL_H 1 + +#include + +#include + +#define NS_CONTROL_PORT 953 + +#undef DO +#define DO(name, function) \ + do { \ + result = function; \ + if (result != ISC_R_SUCCESS) \ + fatal("%s: %s", name, isc_result_totext(result)); \ + else \ + notify("%s", name); \ + } while (0) + +ISC_LANG_BEGINDECLS + +void +notify(const char *fmt, ...) ISC_FORMAT_PRINTF(1, 2); + +void +fatal(const char *format, ...) ISC_FORMAT_PRINTF(1, 2); + +ISC_LANG_ENDDECLS + +#endif /* RNDC_UTIL_H */ diff --git a/contrib/bind9/config.guess b/contrib/bind9/config.guess new file mode 100644 index 000000000000..6e510829546b --- /dev/null +++ b/contrib/bind9/config.guess @@ -0,0 +1,1435 @@ +#! /bin/sh +# Attempt to guess a canonical system name. +# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, +# 2000, 2001, 2002, 2003 Free Software Foundation, Inc. + +timestamp='2004-01-24' + +# This file is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +# +# As a special exception to the GNU General Public License, if you +# distribute this file as part of a program that contains a +# configuration script generated by Autoconf, you may include it under +# the same distribution terms that you use for the rest of that program. + +# Originally written by Per Bothner . +# Please send patches to . Submit a context +# diff and a properly formatted ChangeLog entry. +# +# This script attempts to guess a canonical system name similar to +# config.sub. If it succeeds, it prints the system name on stdout, and +# exits with 0. Otherwise, it exits with 1. +# +# The plan is that this can be called by configure scripts if you +# don't specify an explicit build system type. + +me=`echo "$0" | sed -e 's,.*/,,'` + +usage="\ +Usage: $0 [OPTION] + +Output the configuration name of the system \`$me' is run on. + +Operation modes: + -h, --help print this help, then exit + -t, --time-stamp print date of last modification, then exit + -v, --version print version number, then exit + +Report bugs and patches to ." + +version="\ +GNU config.guess ($timestamp) + +Originally written by Per Bothner. +Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 +Free Software Foundation, Inc. + +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." + +help=" +Try \`$me --help' for more information." + +# Parse command line +while test $# -gt 0 ; do + case $1 in + --time-stamp | --time* | -t ) + echo "$timestamp" ; exit 0 ;; + --version | -v ) + echo "$version" ; exit 0 ;; + --help | --h* | -h ) + echo "$usage"; exit 0 ;; + -- ) # Stop option processing + shift; break ;; + - ) # Use stdin as input. + break ;; + -* ) + echo "$me: invalid option $1$help" >&2 + exit 1 ;; + * ) + break ;; + esac +done + +if test $# != 0; then + echo "$me: too many arguments$help" >&2 + exit 1 +fi + +trap 'exit 1' 1 2 15 + +# CC_FOR_BUILD -- compiler used by this script. Note that the use of a +# compiler to aid in system detection is discouraged as it requires +# temporary files to be created and, as you can see below, it is a +# headache to deal with in a portable fashion. + +# Historically, `CC_FOR_BUILD' used to be named `HOST_CC'. We still +# use `HOST_CC' if defined, but it is deprecated. + +# Portable tmp directory creation inspired by the Autoconf team. + +set_cc_for_build=' +trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) && exit \$exitcode" 0 ; +trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 15 ; +: ${TMPDIR=/tmp} ; + { tmp=`(umask 077 && mktemp -d -q "$TMPDIR/cgXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } || + { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) ; } || + { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: creating insecure temp directory" >&2 ; } || + { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; } ; +dummy=$tmp/dummy ; +tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ; +case $CC_FOR_BUILD,$HOST_CC,$CC in + ,,) echo "int x;" > $dummy.c ; + for c in cc gcc c89 c99 ; do + if ($c -c -o $dummy.o $dummy.c) >/dev/null 2>&1 ; then + CC_FOR_BUILD="$c"; break ; + fi ; + done ; + if test x"$CC_FOR_BUILD" = x ; then + CC_FOR_BUILD=no_compiler_found ; + fi + ;; + ,,*) CC_FOR_BUILD=$CC ;; + ,*,*) CC_FOR_BUILD=$HOST_CC ;; +esac ;' + +# This is needed to find uname on a Pyramid OSx when run in the BSD universe. +# (ghazi@noc.rutgers.edu 1994-08-24) +if (test -f /.attbin/uname) >/dev/null 2>&1 ; then + PATH=$PATH:/.attbin ; export PATH +fi + +UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown +UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown +UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown +UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown + +# Note: order is significant - the case branches are not exclusive. + +case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in + *:NetBSD:*:*) + # NetBSD (nbsd) targets should (where applicable) match one or + # more of the tupples: *-*-netbsdelf*, *-*-netbsdaout*, + # *-*-netbsdecoff* and *-*-netbsd*. For targets that recently + # switched to ELF, *-*-netbsd* would select the old + # object file format. This provides both forward + # compatibility and a consistent mechanism for selecting the + # object file format. + # + # Note: NetBSD doesn't particularly care about the vendor + # portion of the name. We always set it to "unknown". + sysctl="sysctl -n hw.machine_arch" + UNAME_MACHINE_ARCH=`(/sbin/$sysctl 2>/dev/null || \ + /usr/sbin/$sysctl 2>/dev/null || echo unknown)` + case "${UNAME_MACHINE_ARCH}" in + armeb) machine=armeb-unknown ;; + arm*) machine=arm-unknown ;; + sh3el) machine=shl-unknown ;; + sh3eb) machine=sh-unknown ;; + *) machine=${UNAME_MACHINE_ARCH}-unknown ;; + esac + # The Operating System including object format, if it has switched + # to ELF recently, or will in the future. + case "${UNAME_MACHINE_ARCH}" in + arm*|i386|m68k|ns32k|sh3*|sparc|vax) + eval $set_cc_for_build + if echo __ELF__ | $CC_FOR_BUILD -E - 2>/dev/null \ + | grep __ELF__ >/dev/null + then + # Once all utilities can be ECOFF (netbsdecoff) or a.out (netbsdaout). + # Return netbsd for either. FIX? + os=netbsd + else + os=netbsdelf + fi + ;; + *) + os=netbsd + ;; + esac + # The OS release + # Debian GNU/NetBSD machines have a different userland, and + # thus, need a distinct triplet. However, they do not need + # kernel version information, so it can be replaced with a + # suitable tag, in the style of linux-gnu. + case "${UNAME_VERSION}" in + Debian*) + release='-gnu' + ;; + *) + release=`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'` + ;; + esac + # Since CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM: + # contains redundant information, the shorter form: + # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used. + echo "${machine}-${os}${release}" + exit 0 ;; + amiga:OpenBSD:*:*) + echo m68k-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + arc:OpenBSD:*:*) + echo mipsel-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + hp300:OpenBSD:*:*) + echo m68k-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + mac68k:OpenBSD:*:*) + echo m68k-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + macppc:OpenBSD:*:*) + echo powerpc-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + mvme68k:OpenBSD:*:*) + echo m68k-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + mvme88k:OpenBSD:*:*) + echo m88k-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + mvmeppc:OpenBSD:*:*) + echo powerpc-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + pegasos:OpenBSD:*:*) + echo powerpc-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + pmax:OpenBSD:*:*) + echo mipsel-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + sgi:OpenBSD:*:*) + echo mipseb-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + sun3:OpenBSD:*:*) + echo m68k-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + wgrisc:OpenBSD:*:*) + echo mipsel-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + *:OpenBSD:*:*) + echo ${UNAME_MACHINE}-unknown-openbsd${UNAME_RELEASE} + exit 0 ;; + alpha:OSF1:*:*) + if test $UNAME_RELEASE = "V4.0"; then + UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'` + fi + # According to Compaq, /usr/sbin/psrinfo has been available on + # OSF/1 and Tru64 systems produced since 1995. I hope that + # covers most systems running today. This code pipes the CPU + # types through head -n 1, so we only detect the type of CPU 0. + ALPHA_CPU_TYPE=`/usr/sbin/psrinfo -v | sed -n -e 's/^ The alpha \(.*\) processor.*$/\1/p' | head -n 1` + case "$ALPHA_CPU_TYPE" in + "EV4 (21064)") + UNAME_MACHINE="alpha" ;; + "EV4.5 (21064)") + UNAME_MACHINE="alpha" ;; + "LCA4 (21066/21068)") + UNAME_MACHINE="alpha" ;; + "EV5 (21164)") + UNAME_MACHINE="alphaev5" ;; + "EV5.6 (21164A)") + UNAME_MACHINE="alphaev56" ;; + "EV5.6 (21164PC)") + UNAME_MACHINE="alphapca56" ;; + "EV5.7 (21164PC)") + UNAME_MACHINE="alphapca57" ;; + "EV6 (21264)") + UNAME_MACHINE="alphaev6" ;; + "EV6.7 (21264A)") + UNAME_MACHINE="alphaev67" ;; + "EV6.8CB (21264C)") + UNAME_MACHINE="alphaev68" ;; + "EV6.8AL (21264B)") + UNAME_MACHINE="alphaev68" ;; + "EV6.8CX (21264D)") + UNAME_MACHINE="alphaev68" ;; + "EV6.9A (21264/EV69A)") + UNAME_MACHINE="alphaev69" ;; + "EV7 (21364)") + UNAME_MACHINE="alphaev7" ;; + "EV7.9 (21364A)") + UNAME_MACHINE="alphaev79" ;; + esac + # A Vn.n version is a released version. + # A Tn.n version is a released field test version. + # A Xn.n version is an unreleased experimental baselevel. + # 1.2 uses "1.2" for uname -r. + echo ${UNAME_MACHINE}-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[VTX]//' | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'` + exit 0 ;; + Alpha*:OpenVMS:*:*) + echo alpha-hp-vms + exit 0 ;; + Alpha\ *:Windows_NT*:*) + # How do we know it's Interix rather than the generic POSIX subsystem? + # Should we change UNAME_MACHINE based on the output of uname instead + # of the specific Alpha model? + echo alpha-pc-interix + exit 0 ;; + 21064:Windows_NT:50:3) + echo alpha-dec-winnt3.5 + exit 0 ;; + Amiga*:UNIX_System_V:4.0:*) + echo m68k-unknown-sysv4 + exit 0;; + *:[Aa]miga[Oo][Ss]:*:*) + echo ${UNAME_MACHINE}-unknown-amigaos + exit 0 ;; + *:[Mm]orph[Oo][Ss]:*:*) + echo ${UNAME_MACHINE}-unknown-morphos + exit 0 ;; + *:OS/390:*:*) + echo i370-ibm-openedition + exit 0 ;; + *:OS400:*:*) + echo powerpc-ibm-os400 + exit 0 ;; + arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*) + echo arm-acorn-riscix${UNAME_RELEASE} + exit 0;; + SR2?01:HI-UX/MPP:*:* | SR8000:HI-UX/MPP:*:*) + echo hppa1.1-hitachi-hiuxmpp + exit 0;; + Pyramid*:OSx*:*:* | MIS*:OSx*:*:* | MIS*:SMP_DC-OSx*:*:*) + # akee@wpdis03.wpafb.af.mil (Earle F. Ake) contributed MIS and NILE. + if test "`(/bin/universe) 2>/dev/null`" = att ; then + echo pyramid-pyramid-sysv3 + else + echo pyramid-pyramid-bsd + fi + exit 0 ;; + NILE*:*:*:dcosx) + echo pyramid-pyramid-svr4 + exit 0 ;; + DRS?6000:unix:4.0:6*) + echo sparc-icl-nx6 + exit 0 ;; + DRS?6000:UNIX_SV:4.2*:7*) + case `/usr/bin/uname -p` in + sparc) echo sparc-icl-nx7 && exit 0 ;; + esac ;; + sun4H:SunOS:5.*:*) + echo sparc-hal-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` + exit 0 ;; + sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*) + echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` + exit 0 ;; + i86pc:SunOS:5.*:*) + echo i386-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` + exit 0 ;; + sun4*:SunOS:6*:*) + # According to config.sub, this is the proper way to canonicalize + # SunOS6. Hard to guess exactly what SunOS6 will be like, but + # it's likely to be more like Solaris than SunOS4. + echo sparc-sun-solaris3`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` + exit 0 ;; + sun4*:SunOS:*:*) + case "`/usr/bin/arch -k`" in + Series*|S4*) + UNAME_RELEASE=`uname -v` + ;; + esac + # Japanese Language versions have a version number like `4.1.3-JL'. + echo sparc-sun-sunos`echo ${UNAME_RELEASE}|sed -e 's/-/_/'` + exit 0 ;; + sun3*:SunOS:*:*) + echo m68k-sun-sunos${UNAME_RELEASE} + exit 0 ;; + sun*:*:4.2BSD:*) + UNAME_RELEASE=`(sed 1q /etc/motd | awk '{print substr($5,1,3)}') 2>/dev/null` + test "x${UNAME_RELEASE}" = "x" && UNAME_RELEASE=3 + case "`/bin/arch`" in + sun3) + echo m68k-sun-sunos${UNAME_RELEASE} + ;; + sun4) + echo sparc-sun-sunos${UNAME_RELEASE} + ;; + esac + exit 0 ;; + aushp:SunOS:*:*) + echo sparc-auspex-sunos${UNAME_RELEASE} + exit 0 ;; + # The situation for MiNT is a little confusing. The machine name + # can be virtually everything (everything which is not + # "atarist" or "atariste" at least should have a processor + # > m68000). The system name ranges from "MiNT" over "FreeMiNT" + # to the lowercase version "mint" (or "freemint"). Finally + # the system name "TOS" denotes a system which is actually not + # MiNT. But MiNT is downward compatible to TOS, so this should + # be no problem. + atarist[e]:*MiNT:*:* | atarist[e]:*mint:*:* | atarist[e]:*TOS:*:*) + echo m68k-atari-mint${UNAME_RELEASE} + exit 0 ;; + atari*:*MiNT:*:* | atari*:*mint:*:* | atarist[e]:*TOS:*:*) + echo m68k-atari-mint${UNAME_RELEASE} + exit 0 ;; + *falcon*:*MiNT:*:* | *falcon*:*mint:*:* | *falcon*:*TOS:*:*) + echo m68k-atari-mint${UNAME_RELEASE} + exit 0 ;; + milan*:*MiNT:*:* | milan*:*mint:*:* | *milan*:*TOS:*:*) + echo m68k-milan-mint${UNAME_RELEASE} + exit 0 ;; + hades*:*MiNT:*:* | hades*:*mint:*:* | *hades*:*TOS:*:*) + echo m68k-hades-mint${UNAME_RELEASE} + exit 0 ;; + *:*MiNT:*:* | *:*mint:*:* | *:*TOS:*:*) + echo m68k-unknown-mint${UNAME_RELEASE} + exit 0 ;; + m68k:machten:*:*) + echo m68k-apple-machten${UNAME_RELEASE} + exit 0 ;; + powerpc:machten:*:*) + echo powerpc-apple-machten${UNAME_RELEASE} + exit 0 ;; + RISC*:Mach:*:*) + echo mips-dec-mach_bsd4.3 + exit 0 ;; + RISC*:ULTRIX:*:*) + echo mips-dec-ultrix${UNAME_RELEASE} + exit 0 ;; + VAX*:ULTRIX*:*:*) + echo vax-dec-ultrix${UNAME_RELEASE} + exit 0 ;; + 2020:CLIX:*:* | 2430:CLIX:*:*) + echo clipper-intergraph-clix${UNAME_RELEASE} + exit 0 ;; + mips:*:*:UMIPS | mips:*:*:RISCos) + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c +#ifdef __cplusplus +#include /* for printf() prototype */ + int main (int argc, char *argv[]) { +#else + int main (argc, argv) int argc; char *argv[]; { +#endif + #if defined (host_mips) && defined (MIPSEB) + #if defined (SYSTYPE_SYSV) + printf ("mips-mips-riscos%ssysv\n", argv[1]); exit (0); + #endif + #if defined (SYSTYPE_SVR4) + printf ("mips-mips-riscos%ssvr4\n", argv[1]); exit (0); + #endif + #if defined (SYSTYPE_BSD43) || defined(SYSTYPE_BSD) + printf ("mips-mips-riscos%sbsd\n", argv[1]); exit (0); + #endif + #endif + exit (-1); + } +EOF + $CC_FOR_BUILD -o $dummy $dummy.c \ + && $dummy `echo "${UNAME_RELEASE}" | sed -n 's/\([0-9]*\).*/\1/p'` \ + && exit 0 + echo mips-mips-riscos${UNAME_RELEASE} + exit 0 ;; + Motorola:PowerMAX_OS:*:*) + echo powerpc-motorola-powermax + exit 0 ;; + Motorola:*:4.3:PL8-*) + echo powerpc-harris-powermax + exit 0 ;; + Night_Hawk:*:*:PowerMAX_OS | Synergy:PowerMAX_OS:*:*) + echo powerpc-harris-powermax + exit 0 ;; + Night_Hawk:Power_UNIX:*:*) + echo powerpc-harris-powerunix + exit 0 ;; + m88k:CX/UX:7*:*) + echo m88k-harris-cxux7 + exit 0 ;; + m88k:*:4*:R4*) + echo m88k-motorola-sysv4 + exit 0 ;; + m88k:*:3*:R3*) + echo m88k-motorola-sysv3 + exit 0 ;; + AViiON:dgux:*:*) + # DG/UX returns AViiON for all architectures + UNAME_PROCESSOR=`/usr/bin/uname -p` + if [ $UNAME_PROCESSOR = mc88100 ] || [ $UNAME_PROCESSOR = mc88110 ] + then + if [ ${TARGET_BINARY_INTERFACE}x = m88kdguxelfx ] || \ + [ ${TARGET_BINARY_INTERFACE}x = x ] + then + echo m88k-dg-dgux${UNAME_RELEASE} + else + echo m88k-dg-dguxbcs${UNAME_RELEASE} + fi + else + echo i586-dg-dgux${UNAME_RELEASE} + fi + exit 0 ;; + M88*:DolphinOS:*:*) # DolphinOS (SVR3) + echo m88k-dolphin-sysv3 + exit 0 ;; + M88*:*:R3*:*) + # Delta 88k system running SVR3 + echo m88k-motorola-sysv3 + exit 0 ;; + XD88*:*:*:*) # Tektronix XD88 system running UTekV (SVR3) + echo m88k-tektronix-sysv3 + exit 0 ;; + Tek43[0-9][0-9]:UTek:*:*) # Tektronix 4300 system running UTek (BSD) + echo m68k-tektronix-bsd + exit 0 ;; + *:IRIX*:*:*) + echo mips-sgi-irix`echo ${UNAME_RELEASE}|sed -e 's/-/_/g'` + exit 0 ;; + ????????:AIX?:[12].1:2) # AIX 2.2.1 or AIX 2.1.1 is RT/PC AIX. + echo romp-ibm-aix # uname -m gives an 8 hex-code CPU id + exit 0 ;; # Note that: echo "'`uname -s`'" gives 'AIX ' + i*86:AIX:*:*) + echo i386-ibm-aix + exit 0 ;; + ia64:AIX:*:*) + if [ -x /usr/bin/oslevel ] ; then + IBM_REV=`/usr/bin/oslevel` + else + IBM_REV=${UNAME_VERSION}.${UNAME_RELEASE} + fi + echo ${UNAME_MACHINE}-ibm-aix${IBM_REV} + exit 0 ;; + *:AIX:2:3) + if grep bos325 /usr/include/stdio.h >/dev/null 2>&1; then + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + #include + + main() + { + if (!__power_pc()) + exit(1); + puts("powerpc-ibm-aix3.2.5"); + exit(0); + } +EOF + $CC_FOR_BUILD -o $dummy $dummy.c && $dummy && exit 0 + echo rs6000-ibm-aix3.2.5 + elif grep bos324 /usr/include/stdio.h >/dev/null 2>&1; then + echo rs6000-ibm-aix3.2.4 + else + echo rs6000-ibm-aix3.2 + fi + exit 0 ;; + *:AIX:*:[45]) + IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | sed 1q | awk '{ print $1 }'` + if /usr/sbin/lsattr -El ${IBM_CPU_ID} | grep ' POWER' >/dev/null 2>&1; then + IBM_ARCH=rs6000 + else + IBM_ARCH=powerpc + fi + if [ -x /usr/bin/oslevel ] ; then + IBM_REV=`/usr/bin/oslevel` + else + IBM_REV=${UNAME_VERSION}.${UNAME_RELEASE} + fi + echo ${IBM_ARCH}-ibm-aix${IBM_REV} + exit 0 ;; + *:AIX:*:*) + echo rs6000-ibm-aix + exit 0 ;; + ibmrt:4.4BSD:*|romp-ibm:BSD:*) + echo romp-ibm-bsd4.4 + exit 0 ;; + ibmrt:*BSD:*|romp-ibm:BSD:*) # covers RT/PC BSD and + echo romp-ibm-bsd${UNAME_RELEASE} # 4.3 with uname added to + exit 0 ;; # report: romp-ibm BSD 4.3 + *:BOSX:*:*) + echo rs6000-bull-bosx + exit 0 ;; + DPX/2?00:B.O.S.:*:*) + echo m68k-bull-sysv3 + exit 0 ;; + 9000/[34]??:4.3bsd:1.*:*) + echo m68k-hp-bsd + exit 0 ;; + hp300:4.4BSD:*:* | 9000/[34]??:4.3bsd:2.*:*) + echo m68k-hp-bsd4.4 + exit 0 ;; + 9000/[34678]??:HP-UX:*:*) + HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'` + case "${UNAME_MACHINE}" in + 9000/31? ) HP_ARCH=m68000 ;; + 9000/[34]?? ) HP_ARCH=m68k ;; + 9000/[678][0-9][0-9]) + if [ -x /usr/bin/getconf ]; then + sc_cpu_version=`/usr/bin/getconf SC_CPU_VERSION 2>/dev/null` + sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null` + case "${sc_cpu_version}" in + 523) HP_ARCH="hppa1.0" ;; # CPU_PA_RISC1_0 + 528) HP_ARCH="hppa1.1" ;; # CPU_PA_RISC1_1 + 532) # CPU_PA_RISC2_0 + case "${sc_kernel_bits}" in + 32) HP_ARCH="hppa2.0n" ;; + 64) HP_ARCH="hppa2.0w" ;; + '') HP_ARCH="hppa2.0" ;; # HP-UX 10.20 + esac ;; + esac + fi + if [ "${HP_ARCH}" = "" ]; then + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + + #define _HPUX_SOURCE + #include + #include + + int main () + { + #if defined(_SC_KERNEL_BITS) + long bits = sysconf(_SC_KERNEL_BITS); + #endif + long cpu = sysconf (_SC_CPU_VERSION); + + switch (cpu) + { + case CPU_PA_RISC1_0: puts ("hppa1.0"); break; + case CPU_PA_RISC1_1: puts ("hppa1.1"); break; + case CPU_PA_RISC2_0: + #if defined(_SC_KERNEL_BITS) + switch (bits) + { + case 64: puts ("hppa2.0w"); break; + case 32: puts ("hppa2.0n"); break; + default: puts ("hppa2.0"); break; + } break; + #else /* !defined(_SC_KERNEL_BITS) */ + puts ("hppa2.0"); break; + #endif + default: puts ("hppa1.0"); break; + } + exit (0); + } +EOF + (CCOPTS= $CC_FOR_BUILD -o $dummy $dummy.c 2>/dev/null) && HP_ARCH=`$dummy` + test -z "$HP_ARCH" && HP_ARCH=hppa + fi ;; + esac + if [ ${HP_ARCH} = "hppa2.0w" ] + then + # avoid double evaluation of $set_cc_for_build + test -n "$CC_FOR_BUILD" || eval $set_cc_for_build + if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E -) | grep __LP64__ >/dev/null + then + HP_ARCH="hppa2.0w" + else + HP_ARCH="hppa64" + fi + fi + echo ${HP_ARCH}-hp-hpux${HPUX_REV} + exit 0 ;; + ia64:HP-UX:*:*) + HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'` + echo ia64-hp-hpux${HPUX_REV} + exit 0 ;; + 3050*:HI-UX:*:*) + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + #include + int + main () + { + long cpu = sysconf (_SC_CPU_VERSION); + /* The order matters, because CPU_IS_HP_MC68K erroneously returns + true for CPU_PA_RISC1_0. CPU_IS_PA_RISC returns correct + results, however. */ + if (CPU_IS_PA_RISC (cpu)) + { + switch (cpu) + { + case CPU_PA_RISC1_0: puts ("hppa1.0-hitachi-hiuxwe2"); break; + case CPU_PA_RISC1_1: puts ("hppa1.1-hitachi-hiuxwe2"); break; + case CPU_PA_RISC2_0: puts ("hppa2.0-hitachi-hiuxwe2"); break; + default: puts ("hppa-hitachi-hiuxwe2"); break; + } + } + else if (CPU_IS_HP_MC68K (cpu)) + puts ("m68k-hitachi-hiuxwe2"); + else puts ("unknown-hitachi-hiuxwe2"); + exit (0); + } +EOF + $CC_FOR_BUILD -o $dummy $dummy.c && $dummy && exit 0 + echo unknown-hitachi-hiuxwe2 + exit 0 ;; + 9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:* ) + echo hppa1.1-hp-bsd + exit 0 ;; + 9000/8??:4.3bsd:*:*) + echo hppa1.0-hp-bsd + exit 0 ;; + *9??*:MPE/iX:*:* | *3000*:MPE/iX:*:*) + echo hppa1.0-hp-mpeix + exit 0 ;; + hp7??:OSF1:*:* | hp8?[79]:OSF1:*:* ) + echo hppa1.1-hp-osf + exit 0 ;; + hp8??:OSF1:*:*) + echo hppa1.0-hp-osf + exit 0 ;; + i*86:OSF1:*:*) + if [ -x /usr/sbin/sysversion ] ; then + echo ${UNAME_MACHINE}-unknown-osf1mk + else + echo ${UNAME_MACHINE}-unknown-osf1 + fi + exit 0 ;; + parisc*:Lites*:*:*) + echo hppa1.1-hp-lites + exit 0 ;; + C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*) + echo c1-convex-bsd + exit 0 ;; + C2*:ConvexOS:*:* | convex:ConvexOS:C2*:*) + if getsysinfo -f scalar_acc + then echo c32-convex-bsd + else echo c2-convex-bsd + fi + exit 0 ;; + C34*:ConvexOS:*:* | convex:ConvexOS:C34*:*) + echo c34-convex-bsd + exit 0 ;; + C38*:ConvexOS:*:* | convex:ConvexOS:C38*:*) + echo c38-convex-bsd + exit 0 ;; + C4*:ConvexOS:*:* | convex:ConvexOS:C4*:*) + echo c4-convex-bsd + exit 0 ;; + CRAY*Y-MP:*:*:*) + echo ymp-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/' + exit 0 ;; + CRAY*[A-Z]90:*:*:*) + echo ${UNAME_MACHINE}-cray-unicos${UNAME_RELEASE} \ + | sed -e 's/CRAY.*\([A-Z]90\)/\1/' \ + -e y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/ \ + -e 's/\.[^.]*$/.X/' + exit 0 ;; + CRAY*TS:*:*:*) + echo t90-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/' + exit 0 ;; + CRAY*T3E:*:*:*) + echo alphaev5-cray-unicosmk${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/' + exit 0 ;; + CRAY*SV1:*:*:*) + echo sv1-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/' + exit 0 ;; + *:UNICOS/mp:*:*) + echo nv1-cray-unicosmp${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/' + exit 0 ;; + F30[01]:UNIX_System_V:*:* | F700:UNIX_System_V:*:*) + FUJITSU_PROC=`uname -m | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'` + FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'` + FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'` + echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}" + exit 0 ;; + 5000:UNIX_System_V:4.*:*) + FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'` + FUJITSU_REL=`echo ${UNAME_RELEASE} | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/ /_/'` + echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}" + exit 0 ;; + i*86:BSD/386:*:* | i*86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*) + echo ${UNAME_MACHINE}-pc-bsdi${UNAME_RELEASE} + exit 0 ;; + sparc*:BSD/OS:*:*) + echo sparc-unknown-bsdi${UNAME_RELEASE} + exit 0 ;; + *:BSD/OS:*:*) + echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE} + exit 0 ;; + *:FreeBSD:*:*) + # Determine whether the default compiler uses glibc. + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + #include + #if __GLIBC__ >= 2 + LIBC=gnu + #else + LIBC= + #endif +EOF + eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=` + # GNU/KFreeBSD systems have a "k" prefix to indicate we are using + # FreeBSD's kernel, but not the complete OS. + case ${LIBC} in gnu) kernel_only='k' ;; esac + echo ${UNAME_MACHINE}-unknown-${kernel_only}freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`${LIBC:+-$LIBC} + exit 0 ;; + i*:CYGWIN*:*) + echo ${UNAME_MACHINE}-pc-cygwin + exit 0 ;; + i*:MINGW*:*) + echo ${UNAME_MACHINE}-pc-mingw32 + exit 0 ;; + i*:PW*:*) + echo ${UNAME_MACHINE}-pc-pw32 + exit 0 ;; + x86:Interix*:[34]*) + echo i586-pc-interix${UNAME_RELEASE}|sed -e 's/\..*//' + exit 0 ;; + [345]86:Windows_95:* | [345]86:Windows_98:* | [345]86:Windows_NT:*) + echo i${UNAME_MACHINE}-pc-mks + exit 0 ;; + i*:Windows_NT*:* | Pentium*:Windows_NT*:*) + # How do we know it's Interix rather than the generic POSIX subsystem? + # It also conflicts with pre-2.0 versions of AT&T UWIN. Should we + # UNAME_MACHINE based on the output of uname instead of i386? + echo i586-pc-interix + exit 0 ;; + i*:UWIN*:*) + echo ${UNAME_MACHINE}-pc-uwin + exit 0 ;; + p*:CYGWIN*:*) + echo powerpcle-unknown-cygwin + exit 0 ;; + prep*:SunOS:5.*:*) + echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` + exit 0 ;; + *:GNU:*:*) + # the GNU system + echo `echo ${UNAME_MACHINE}|sed -e 's,[-/].*$,,'`-unknown-gnu`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'` + exit 0 ;; + *:GNU/*:*:*) + # other systems with GNU libc and userland + echo ${UNAME_MACHINE}-unknown-`echo ${UNAME_SYSTEM} | sed 's,^[^/]*/,,' | tr '[A-Z]' '[a-z]'``echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`-gnu + exit 0 ;; + i*86:Minix:*:*) + echo ${UNAME_MACHINE}-pc-minix + exit 0 ;; + arm*:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-gnu + exit 0 ;; + cris:Linux:*:*) + echo cris-axis-linux-gnu + exit 0 ;; + ia64:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-gnu + exit 0 ;; + m68*:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-gnu + exit 0 ;; + mips:Linux:*:*) + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + #undef CPU + #undef mips + #undef mipsel + #if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL) + CPU=mipsel + #else + #if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB) + CPU=mips + #else + CPU= + #endif + #endif +EOF + eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^CPU=` + test x"${CPU}" != x && echo "${CPU}-unknown-linux-gnu" && exit 0 + ;; + mips64:Linux:*:*) + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + #undef CPU + #undef mips64 + #undef mips64el + #if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL) + CPU=mips64el + #else + #if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB) + CPU=mips64 + #else + CPU= + #endif + #endif +EOF + eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^CPU=` + test x"${CPU}" != x && echo "${CPU}-unknown-linux-gnu" && exit 0 + ;; + ppc:Linux:*:*) + echo powerpc-unknown-linux-gnu + exit 0 ;; + ppc64:Linux:*:*) + echo powerpc64-unknown-linux-gnu + exit 0 ;; + alpha:Linux:*:*) + case `sed -n '/^cpu model/s/^.*: \(.*\)/\1/p' < /proc/cpuinfo` in + EV5) UNAME_MACHINE=alphaev5 ;; + EV56) UNAME_MACHINE=alphaev56 ;; + PCA56) UNAME_MACHINE=alphapca56 ;; + PCA57) UNAME_MACHINE=alphapca56 ;; + EV6) UNAME_MACHINE=alphaev6 ;; + EV67) UNAME_MACHINE=alphaev67 ;; + EV68*) UNAME_MACHINE=alphaev68 ;; + esac + objdump --private-headers /bin/sh | grep ld.so.1 >/dev/null + if test "$?" = 0 ; then LIBC="libc1" ; else LIBC="" ; fi + echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC} + exit 0 ;; + parisc:Linux:*:* | hppa:Linux:*:*) + # Look for CPU level + case `grep '^cpu[^a-z]*:' /proc/cpuinfo 2>/dev/null | cut -d' ' -f2` in + PA7*) echo hppa1.1-unknown-linux-gnu ;; + PA8*) echo hppa2.0-unknown-linux-gnu ;; + *) echo hppa-unknown-linux-gnu ;; + esac + exit 0 ;; + parisc64:Linux:*:* | hppa64:Linux:*:*) + echo hppa64-unknown-linux-gnu + exit 0 ;; + s390:Linux:*:* | s390x:Linux:*:*) + echo ${UNAME_MACHINE}-ibm-linux + exit 0 ;; + sh64*:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-gnu + exit 0 ;; + sh*:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-gnu + exit 0 ;; + sparc:Linux:*:* | sparc64:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-gnu + exit 0 ;; + x86_64:Linux:*:*) + echo x86_64-unknown-linux-gnu + exit 0 ;; + i*86:Linux:*:*) + # The BFD linker knows what the default object file format is, so + # first see if it will tell us. cd to the root directory to prevent + # problems with other programs or directories called `ld' in the path. + # Set LC_ALL=C to ensure ld outputs messages in English. + ld_supported_targets=`cd /; LC_ALL=C ld --help 2>&1 \ + | sed -ne '/supported targets:/!d + s/[ ][ ]*/ /g + s/.*supported targets: *// + s/ .*// + p'` + case "$ld_supported_targets" in + elf32-i386) + TENTATIVE="${UNAME_MACHINE}-pc-linux-gnu" + ;; + a.out-i386-linux) + echo "${UNAME_MACHINE}-pc-linux-gnuaout" + exit 0 ;; + coff-i386) + echo "${UNAME_MACHINE}-pc-linux-gnucoff" + exit 0 ;; + "") + # Either a pre-BFD a.out linker (linux-gnuoldld) or + # one that does not give us useful --help. + echo "${UNAME_MACHINE}-pc-linux-gnuoldld" + exit 0 ;; + esac + # Determine whether the default compiler is a.out or elf + eval $set_cc_for_build + sed 's/^ //' << EOF >$dummy.c + #include + #ifdef __ELF__ + # ifdef __GLIBC__ + # if __GLIBC__ >= 2 + LIBC=gnu + # else + LIBC=gnulibc1 + # endif + # else + LIBC=gnulibc1 + # endif + #else + #ifdef __INTEL_COMPILER + LIBC=gnu + #else + LIBC=gnuaout + #endif + #endif + #ifdef __dietlibc__ + LIBC=dietlibc + #endif +EOF + eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=` + test x"${LIBC}" != x && echo "${UNAME_MACHINE}-pc-linux-${LIBC}" && exit 0 + test x"${TENTATIVE}" != x && echo "${TENTATIVE}" && exit 0 + ;; + i*86:DYNIX/ptx:4*:*) + # ptx 4.0 does uname -s correctly, with DYNIX/ptx in there. + # earlier versions are messed up and put the nodename in both + # sysname and nodename. + echo i386-sequent-sysv4 + exit 0 ;; + i*86:UNIX_SV:4.2MP:2.*) + # Unixware is an offshoot of SVR4, but it has its own version + # number series starting with 2... + # I am not positive that other SVR4 systems won't match this, + # I just have to hope. -- rms. + # Use sysv4.2uw... so that sysv4* matches it. + echo ${UNAME_MACHINE}-pc-sysv4.2uw${UNAME_VERSION} + exit 0 ;; + i*86:OS/2:*:*) + # If we were able to find `uname', then EMX Unix compatibility + # is probably installed. + echo ${UNAME_MACHINE}-pc-os2-emx + exit 0 ;; + i*86:XTS-300:*:STOP) + echo ${UNAME_MACHINE}-unknown-stop + exit 0 ;; + i*86:atheos:*:*) + echo ${UNAME_MACHINE}-unknown-atheos + exit 0 ;; + i*86:syllable:*:*) + echo ${UNAME_MACHINE}-pc-syllable + exit 0 ;; + i*86:LynxOS:2.*:* | i*86:LynxOS:3.[01]*:* | i*86:LynxOS:4.0*:*) + echo i386-unknown-lynxos${UNAME_RELEASE} + exit 0 ;; + i*86:*DOS:*:*) + echo ${UNAME_MACHINE}-pc-msdosdjgpp + exit 0 ;; + i*86:*:4.*:* | i*86:SYSTEM_V:4.*:*) + UNAME_REL=`echo ${UNAME_RELEASE} | sed 's/\/MP$//'` + if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then + echo ${UNAME_MACHINE}-univel-sysv${UNAME_REL} + else + echo ${UNAME_MACHINE}-pc-sysv${UNAME_REL} + fi + exit 0 ;; + i*86:*:5:[78]*) + case `/bin/uname -X | grep "^Machine"` in + *486*) UNAME_MACHINE=i486 ;; + *Pentium) UNAME_MACHINE=i586 ;; + *Pent*|*Celeron) UNAME_MACHINE=i686 ;; + esac + echo ${UNAME_MACHINE}-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}${UNAME_VERSION} + exit 0 ;; + i*86:*:3.2:*) + if test -f /usr/options/cb.name; then + UNAME_REL=`sed -n 's/.*Version //p' /dev/null >/dev/null ; then + UNAME_REL=`(/bin/uname -X|grep Release|sed -e 's/.*= //')` + (/bin/uname -X|grep i80486 >/dev/null) && UNAME_MACHINE=i486 + (/bin/uname -X|grep '^Machine.*Pentium' >/dev/null) \ + && UNAME_MACHINE=i586 + (/bin/uname -X|grep '^Machine.*Pent *II' >/dev/null) \ + && UNAME_MACHINE=i686 + (/bin/uname -X|grep '^Machine.*Pentium Pro' >/dev/null) \ + && UNAME_MACHINE=i686 + echo ${UNAME_MACHINE}-pc-sco$UNAME_REL + else + echo ${UNAME_MACHINE}-pc-sysv32 + fi + exit 0 ;; + pc:*:*:*) + # Left here for compatibility: + # uname -m prints for DJGPP always 'pc', but it prints nothing about + # the processor, so we play safe by assuming i386. + echo i386-pc-msdosdjgpp + exit 0 ;; + Intel:Mach:3*:*) + echo i386-pc-mach3 + exit 0 ;; + paragon:*:*:*) + echo i860-intel-osf1 + exit 0 ;; + i860:*:4.*:*) # i860-SVR4 + if grep Stardent /usr/include/sys/uadmin.h >/dev/null 2>&1 ; then + echo i860-stardent-sysv${UNAME_RELEASE} # Stardent Vistra i860-SVR4 + else # Add other i860-SVR4 vendors below as they are discovered. + echo i860-unknown-sysv${UNAME_RELEASE} # Unknown i860-SVR4 + fi + exit 0 ;; + mini*:CTIX:SYS*5:*) + # "miniframe" + echo m68010-convergent-sysv + exit 0 ;; + mc68k:UNIX:SYSTEM5:3.51m) + echo m68k-convergent-sysv + exit 0 ;; + M680?0:D-NIX:5.3:*) + echo m68k-diab-dnix + exit 0 ;; + M68*:*:R3V[567]*:*) + test -r /sysV68 && echo 'm68k-motorola-sysv' && exit 0 ;; + 3[345]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0 | SDS2:*:4.0:3.0 | SHG2:*:4.0:3.0) + OS_REL='' + test -r /etc/.relid \ + && OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid` + /bin/uname -p 2>/dev/null | grep 86 >/dev/null \ + && echo i486-ncr-sysv4.3${OS_REL} && exit 0 + /bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \ + && echo i586-ncr-sysv4.3${OS_REL} && exit 0 ;; + 3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*) + /bin/uname -p 2>/dev/null | grep 86 >/dev/null \ + && echo i486-ncr-sysv4 && exit 0 ;; + m68*:LynxOS:2.*:* | m68*:LynxOS:3.0*:*) + echo m68k-unknown-lynxos${UNAME_RELEASE} + exit 0 ;; + mc68030:UNIX_System_V:4.*:*) + echo m68k-atari-sysv4 + exit 0 ;; + TSUNAMI:LynxOS:2.*:*) + echo sparc-unknown-lynxos${UNAME_RELEASE} + exit 0 ;; + rs6000:LynxOS:2.*:*) + echo rs6000-unknown-lynxos${UNAME_RELEASE} + exit 0 ;; + PowerPC:LynxOS:2.*:* | PowerPC:LynxOS:3.[01]*:* | PowerPC:LynxOS:4.0*:*) + echo powerpc-unknown-lynxos${UNAME_RELEASE} + exit 0 ;; + SM[BE]S:UNIX_SV:*:*) + echo mips-dde-sysv${UNAME_RELEASE} + exit 0 ;; + RM*:ReliantUNIX-*:*:*) + echo mips-sni-sysv4 + exit 0 ;; + RM*:SINIX-*:*:*) + echo mips-sni-sysv4 + exit 0 ;; + *:SINIX-*:*:*) + if uname -p 2>/dev/null >/dev/null ; then + UNAME_MACHINE=`(uname -p) 2>/dev/null` + echo ${UNAME_MACHINE}-sni-sysv4 + else + echo ns32k-sni-sysv + fi + exit 0 ;; + PENTIUM:*:4.0*:*) # Unisys `ClearPath HMP IX 4000' SVR4/MP effort + # says + echo i586-unisys-sysv4 + exit 0 ;; + *:UNIX_System_V:4*:FTX*) + # From Gerald Hewes . + # How about differentiating between stratus architectures? -djm + echo hppa1.1-stratus-sysv4 + exit 0 ;; + *:*:*:FTX*) + # From seanf@swdc.stratus.com. + echo i860-stratus-sysv4 + exit 0 ;; + *:VOS:*:*) + # From Paul.Green@stratus.com. + echo hppa1.1-stratus-vos + exit 0 ;; + mc68*:A/UX:*:*) + echo m68k-apple-aux${UNAME_RELEASE} + exit 0 ;; + news*:NEWS-OS:6*:*) + echo mips-sony-newsos6 + exit 0 ;; + R[34]000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R*000:UNIX_SV:*:*) + if [ -d /usr/nec ]; then + echo mips-nec-sysv${UNAME_RELEASE} + else + echo mips-unknown-sysv${UNAME_RELEASE} + fi + exit 0 ;; + BeBox:BeOS:*:*) # BeOS running on hardware made by Be, PPC only. + echo powerpc-be-beos + exit 0 ;; + BeMac:BeOS:*:*) # BeOS running on Mac or Mac clone, PPC only. + echo powerpc-apple-beos + exit 0 ;; + BePC:BeOS:*:*) # BeOS running on Intel PC compatible. + echo i586-pc-beos + exit 0 ;; + SX-4:SUPER-UX:*:*) + echo sx4-nec-superux${UNAME_RELEASE} + exit 0 ;; + SX-5:SUPER-UX:*:*) + echo sx5-nec-superux${UNAME_RELEASE} + exit 0 ;; + SX-6:SUPER-UX:*:*) + echo sx6-nec-superux${UNAME_RELEASE} + exit 0 ;; + Power*:Rhapsody:*:*) + echo powerpc-apple-rhapsody${UNAME_RELEASE} + exit 0 ;; + *:Rhapsody:*:*) + echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE} + exit 0 ;; + *:Darwin:*:*) + case `uname -p` in + *86) UNAME_PROCESSOR=i686 ;; + powerpc) UNAME_PROCESSOR=powerpc ;; + esac + echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE} + exit 0 ;; + *:procnto*:*:* | *:QNX:[0123456789]*:*) + UNAME_PROCESSOR=`uname -p` + if test "$UNAME_PROCESSOR" = "x86"; then + UNAME_PROCESSOR=i386 + UNAME_MACHINE=pc + fi + echo ${UNAME_PROCESSOR}-${UNAME_MACHINE}-nto-qnx${UNAME_RELEASE} + exit 0 ;; + *:QNX:*:4*) + echo i386-pc-qnx + exit 0 ;; + NSR-?:NONSTOP_KERNEL:*:*) + echo nsr-tandem-nsk${UNAME_RELEASE} + exit 0 ;; + *:NonStop-UX:*:*) + echo mips-compaq-nonstopux + exit 0 ;; + BS2000:POSIX*:*:*) + echo bs2000-siemens-sysv + exit 0 ;; + DS/*:UNIX_System_V:*:*) + echo ${UNAME_MACHINE}-${UNAME_SYSTEM}-${UNAME_RELEASE} + exit 0 ;; + *:Plan9:*:*) + # "uname -m" is not consistent, so use $cputype instead. 386 + # is converted to i386 for consistency with other x86 + # operating systems. + if test "$cputype" = "386"; then + UNAME_MACHINE=i386 + else + UNAME_MACHINE="$cputype" + fi + echo ${UNAME_MACHINE}-unknown-plan9 + exit 0 ;; + *:TOPS-10:*:*) + echo pdp10-unknown-tops10 + exit 0 ;; + *:TENEX:*:*) + echo pdp10-unknown-tenex + exit 0 ;; + KS10:TOPS-20:*:* | KL10:TOPS-20:*:* | TYPE4:TOPS-20:*:*) + echo pdp10-dec-tops20 + exit 0 ;; + XKL-1:TOPS-20:*:* | TYPE5:TOPS-20:*:*) + echo pdp10-xkl-tops20 + exit 0 ;; + *:TOPS-20:*:*) + echo pdp10-unknown-tops20 + exit 0 ;; + *:ITS:*:*) + echo pdp10-unknown-its + exit 0 ;; + SEI:*:*:SEIUX) + echo mips-sei-seiux${UNAME_RELEASE} + exit 0 ;; + *:DragonFly:*:*) + echo ${UNAME_MACHINE}-unknown-dragonfly`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` + exit 0 ;; +esac + +#echo '(No uname command or uname output not recognized.)' 1>&2 +#echo "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" 1>&2 + +eval $set_cc_for_build +cat >$dummy.c < +# include +#endif +main () +{ +#if defined (sony) +#if defined (MIPSEB) + /* BFD wants "bsd" instead of "newsos". Perhaps BFD should be changed, + I don't know.... */ + printf ("mips-sony-bsd\n"); exit (0); +#else +#include + printf ("m68k-sony-newsos%s\n", +#ifdef NEWSOS4 + "4" +#else + "" +#endif + ); exit (0); +#endif +#endif + +#if defined (__arm) && defined (__acorn) && defined (__unix) + printf ("arm-acorn-riscix"); exit (0); +#endif + +#if defined (hp300) && !defined (hpux) + printf ("m68k-hp-bsd\n"); exit (0); +#endif + +#if defined (NeXT) +#if !defined (__ARCHITECTURE__) +#define __ARCHITECTURE__ "m68k" +#endif + int version; + version=`(hostinfo | sed -n 's/.*NeXT Mach \([0-9]*\).*/\1/p') 2>/dev/null`; + if (version < 4) + printf ("%s-next-nextstep%d\n", __ARCHITECTURE__, version); + else + printf ("%s-next-openstep%d\n", __ARCHITECTURE__, version); + exit (0); +#endif + +#if defined (MULTIMAX) || defined (n16) +#if defined (UMAXV) + printf ("ns32k-encore-sysv\n"); exit (0); +#else +#if defined (CMU) + printf ("ns32k-encore-mach\n"); exit (0); +#else + printf ("ns32k-encore-bsd\n"); exit (0); +#endif +#endif +#endif + +#if defined (__386BSD__) + printf ("i386-pc-bsd\n"); exit (0); +#endif + +#if defined (sequent) +#if defined (i386) + printf ("i386-sequent-dynix\n"); exit (0); +#endif +#if defined (ns32000) + printf ("ns32k-sequent-dynix\n"); exit (0); +#endif +#endif + +#if defined (_SEQUENT_) + struct utsname un; + + uname(&un); + + if (strncmp(un.version, "V2", 2) == 0) { + printf ("i386-sequent-ptx2\n"); exit (0); + } + if (strncmp(un.version, "V1", 2) == 0) { /* XXX is V1 correct? */ + printf ("i386-sequent-ptx1\n"); exit (0); + } + printf ("i386-sequent-ptx\n"); exit (0); + +#endif + +#if defined (vax) +# if !defined (ultrix) +# include +# if defined (BSD) +# if BSD == 43 + printf ("vax-dec-bsd4.3\n"); exit (0); +# else +# if BSD == 199006 + printf ("vax-dec-bsd4.3reno\n"); exit (0); +# else + printf ("vax-dec-bsd\n"); exit (0); +# endif +# endif +# else + printf ("vax-dec-bsd\n"); exit (0); +# endif +# else + printf ("vax-dec-ultrix\n"); exit (0); +# endif +#endif + +#if defined (alliant) && defined (i860) + printf ("i860-alliant-bsd\n"); exit (0); +#endif + + exit (1); +} +EOF + +$CC_FOR_BUILD -o $dummy $dummy.c 2>/dev/null && $dummy && exit 0 + +# Apollos put the system type in the environment. + +test -d /usr/apollo && { echo ${ISP}-apollo-${SYSTYPE}; exit 0; } + +# Convex versions that predate uname can use getsysinfo(1) + +if [ -x /usr/convex/getsysinfo ] +then + case `getsysinfo -f cpu_type` in + c1*) + echo c1-convex-bsd + exit 0 ;; + c2*) + if getsysinfo -f scalar_acc + then echo c32-convex-bsd + else echo c2-convex-bsd + fi + exit 0 ;; + c34*) + echo c34-convex-bsd + exit 0 ;; + c38*) + echo c38-convex-bsd + exit 0 ;; + c4*) + echo c4-convex-bsd + exit 0 ;; + esac +fi + +cat >&2 < in order to provide the needed +information to handle your system. + +config.guess timestamp = $timestamp + +uname -m = `(uname -m) 2>/dev/null || echo unknown` +uname -r = `(uname -r) 2>/dev/null || echo unknown` +uname -s = `(uname -s) 2>/dev/null || echo unknown` +uname -v = `(uname -v) 2>/dev/null || echo unknown` + +/usr/bin/uname -p = `(/usr/bin/uname -p) 2>/dev/null` +/bin/uname -X = `(/bin/uname -X) 2>/dev/null` + +hostinfo = `(hostinfo) 2>/dev/null` +/bin/universe = `(/bin/universe) 2>/dev/null` +/usr/bin/arch -k = `(/usr/bin/arch -k) 2>/dev/null` +/bin/arch = `(/bin/arch) 2>/dev/null` +/usr/bin/oslevel = `(/usr/bin/oslevel) 2>/dev/null` +/usr/convex/getsysinfo = `(/usr/convex/getsysinfo) 2>/dev/null` + +UNAME_MACHINE = ${UNAME_MACHINE} +UNAME_RELEASE = ${UNAME_RELEASE} +UNAME_SYSTEM = ${UNAME_SYSTEM} +UNAME_VERSION = ${UNAME_VERSION} +EOF + +exit 1 + +# Local variables: +# eval: (add-hook 'write-file-hooks 'time-stamp) +# time-stamp-start: "timestamp='" +# time-stamp-format: "%:y-%02m-%02d" +# time-stamp-end: "'" +# End: diff --git a/contrib/bind9/config.sub b/contrib/bind9/config.sub new file mode 100644 index 000000000000..463186dbfd6b --- /dev/null +++ b/contrib/bind9/config.sub @@ -0,0 +1,1537 @@ +#! /bin/sh +# Configuration validation subroutine script. +# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, +# 2000, 2001, 2002, 2003 Free Software Foundation, Inc. + +timestamp='2004-01-05' + +# This file is (in principle) common to ALL GNU software. +# The presence of a machine in this file suggests that SOME GNU software +# can handle that machine. It does not imply ALL GNU software can. +# +# This file is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, +# Boston, MA 02111-1307, USA. + +# As a special exception to the GNU General Public License, if you +# distribute this file as part of a program that contains a +# configuration script generated by Autoconf, you may include it under +# the same distribution terms that you use for the rest of that program. + +# Please send patches to . Submit a context +# diff and a properly formatted ChangeLog entry. +# +# Configuration subroutine to validate and canonicalize a configuration type. +# Supply the specified configuration type as an argument. +# If it is invalid, we print an error message on stderr and exit with code 1. +# Otherwise, we print the canonical config type on stdout and succeed. + +# This file is supposed to be the same for all GNU packages +# and recognize all the CPU types, system types and aliases +# that are meaningful with *any* GNU software. +# Each package is responsible for reporting which valid configurations +# it does not support. The user should be able to distinguish +# a failure to support a valid configuration from a meaningless +# configuration. + +# The goal of this file is to map all the various variations of a given +# machine specification into a single specification in the form: +# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM +# or in some cases, the newer four-part form: +# CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM +# It is wrong to echo any other type of specification. + +me=`echo "$0" | sed -e 's,.*/,,'` + +usage="\ +Usage: $0 [OPTION] CPU-MFR-OPSYS + $0 [OPTION] ALIAS + +Canonicalize a configuration name. + +Operation modes: + -h, --help print this help, then exit + -t, --time-stamp print date of last modification, then exit + -v, --version print version number, then exit + +Report bugs and patches to ." + +version="\ +GNU config.sub ($timestamp) + +Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 +Free Software Foundation, Inc. + +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." + +help=" +Try \`$me --help' for more information." + +# Parse command line +while test $# -gt 0 ; do + case $1 in + --time-stamp | --time* | -t ) + echo "$timestamp" ; exit 0 ;; + --version | -v ) + echo "$version" ; exit 0 ;; + --help | --h* | -h ) + echo "$usage"; exit 0 ;; + -- ) # Stop option processing + shift; break ;; + - ) # Use stdin as input. + break ;; + -* ) + echo "$me: invalid option $1$help" + exit 1 ;; + + *local*) + # First pass through any local machine types. + echo $1 + exit 0;; + + * ) + break ;; + esac +done + +case $# in + 0) echo "$me: missing argument$help" >&2 + exit 1;; + 1) ;; + *) echo "$me: too many arguments$help" >&2 + exit 1;; +esac + +# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any). +# Here we must recognize all the valid KERNEL-OS combinations. +maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'` +case $maybe_os in + nto-qnx* | linux-gnu* | linux-dietlibc | linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | \ + kfreebsd*-gnu* | knetbsd*-gnu* | netbsd*-gnu* | storm-chaos* | os2-emx* | rtmk-nova*) + os=-$maybe_os + basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'` + ;; + *) + basic_machine=`echo $1 | sed 's/-[^-]*$//'` + if [ $basic_machine != $1 ] + then os=`echo $1 | sed 's/.*-/-/'` + else os=; fi + ;; +esac + +### Let's recognize common machines as not being operating systems so +### that things like config.sub decstation-3100 work. We also +### recognize some manufacturers as not being operating systems, so we +### can provide default operating systems below. +case $os in + -sun*os*) + # Prevent following clause from handling this invalid input. + ;; + -dec* | -mips* | -sequent* | -encore* | -pc532* | -sgi* | -sony* | \ + -att* | -7300* | -3300* | -delta* | -motorola* | -sun[234]* | \ + -unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \ + -convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\ + -c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \ + -harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \ + -apple | -axis) + os= + basic_machine=$1 + ;; + -sim | -cisco | -oki | -wec | -winbond) + os= + basic_machine=$1 + ;; + -scout) + ;; + -wrs) + os=-vxworks + basic_machine=$1 + ;; + -chorusos*) + os=-chorusos + basic_machine=$1 + ;; + -chorusrdb) + os=-chorusrdb + basic_machine=$1 + ;; + -hiux*) + os=-hiuxwe2 + ;; + -sco5) + os=-sco3.2v5 + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -sco4) + os=-sco3.2v4 + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -sco3.2.[4-9]*) + os=`echo $os | sed -e 's/sco3.2./sco3.2v/'` + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -sco3.2v[4-9]*) + # Don't forget version if it is 3.2v4 or newer. + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -sco*) + os=-sco3.2v2 + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -udk*) + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -isc) + os=-isc2.2 + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -clix*) + basic_machine=clipper-intergraph + ;; + -isc*) + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -lynx*) + os=-lynxos + ;; + -ptx*) + basic_machine=`echo $1 | sed -e 's/86-.*/86-sequent/'` + ;; + -windowsnt*) + os=`echo $os | sed -e 's/windowsnt/winnt/'` + ;; + -psos*) + os=-psos + ;; + -mint | -mint[0-9]*) + basic_machine=m68k-atari + os=-mint + ;; +esac + +# Decode aliases for certain CPU-COMPANY combinations. +case $basic_machine in + # Recognize the basic CPU types without company name. + # Some are omitted here because they have special meanings below. + 1750a | 580 \ + | a29k \ + | alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \ + | alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | alpha64pca5[67] \ + | am33_2.0 \ + | arc | arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb] | avr \ + | c4x | clipper \ + | d10v | d30v | dlx | dsp16xx \ + | fr30 | frv \ + | h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \ + | i370 | i860 | i960 | ia64 \ + | ip2k | iq2000 \ + | m32r | m68000 | m68k | m88k | mcore \ + | mips | mipsbe | mipseb | mipsel | mipsle \ + | mips16 \ + | mips64 | mips64el \ + | mips64vr | mips64vrel \ + | mips64orion | mips64orionel \ + | mips64vr4100 | mips64vr4100el \ + | mips64vr4300 | mips64vr4300el \ + | mips64vr5000 | mips64vr5000el \ + | mipsisa32 | mipsisa32el \ + | mipsisa32r2 | mipsisa32r2el \ + | mipsisa64 | mipsisa64el \ + | mipsisa64r2 | mipsisa64r2el \ + | mipsisa64sb1 | mipsisa64sb1el \ + | mipsisa64sr71k | mipsisa64sr71kel \ + | mipstx39 | mipstx39el \ + | mn10200 | mn10300 \ + | msp430 \ + | ns16k | ns32k \ + | openrisc | or32 \ + | pdp10 | pdp11 | pj | pjl \ + | powerpc | powerpc64 | powerpc64le | powerpcle | ppcbe \ + | pyramid \ + | sh | sh[1234] | sh[23]e | sh[34]eb | shbe | shle | sh[1234]le | sh3ele \ + | sh64 | sh64le \ + | sparc | sparc64 | sparc86x | sparclet | sparclite | sparcv9 | sparcv9b \ + | strongarm \ + | tahoe | thumb | tic4x | tic80 | tron \ + | v850 | v850e \ + | we32k \ + | x86 | xscale | xstormy16 | xtensa \ + | z8k) + basic_machine=$basic_machine-unknown + ;; + m6811 | m68hc11 | m6812 | m68hc12) + # Motorola 68HC11/12. + basic_machine=$basic_machine-unknown + os=-none + ;; + m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70 | w65 | z8k) + ;; + + # We use `pc' rather than `unknown' + # because (1) that's what they normally are, and + # (2) the word "unknown" tends to confuse beginning users. + i*86 | x86_64) + basic_machine=$basic_machine-pc + ;; + # Object if more than one company name word. + *-*-*) + echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2 + exit 1 + ;; + # Recognize the basic CPU types with company name. + 580-* \ + | a29k-* \ + | alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \ + | alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \ + | alphapca5[67]-* | alpha64pca5[67]-* | arc-* \ + | arm-* | armbe-* | armle-* | armeb-* | armv*-* \ + | avr-* \ + | bs2000-* \ + | c[123]* | c30-* | [cjt]90-* | c4x-* | c54x-* | c55x-* | c6x-* \ + | clipper-* | cydra-* \ + | d10v-* | d30v-* | dlx-* \ + | elxsi-* \ + | f30[01]-* | f700-* | fr30-* | frv-* | fx80-* \ + | h8300-* | h8500-* \ + | hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \ + | i*86-* | i860-* | i960-* | ia64-* \ + | ip2k-* | iq2000-* \ + | m32r-* \ + | m68000-* | m680[012346]0-* | m68360-* | m683?2-* | m68k-* \ + | m88110-* | m88k-* | mcore-* \ + | mips-* | mipsbe-* | mipseb-* | mipsel-* | mipsle-* \ + | mips16-* \ + | mips64-* | mips64el-* \ + | mips64vr-* | mips64vrel-* \ + | mips64orion-* | mips64orionel-* \ + | mips64vr4100-* | mips64vr4100el-* \ + | mips64vr4300-* | mips64vr4300el-* \ + | mips64vr5000-* | mips64vr5000el-* \ + | mipsisa32-* | mipsisa32el-* \ + | mipsisa32r2-* | mipsisa32r2el-* \ + | mipsisa64-* | mipsisa64el-* \ + | mipsisa64r2-* | mipsisa64r2el-* \ + | mipsisa64sb1-* | mipsisa64sb1el-* \ + | mipsisa64sr71k-* | mipsisa64sr71kel-* \ + | mipstx39-* | mipstx39el-* \ + | msp430-* \ + | none-* | np1-* | nv1-* | ns16k-* | ns32k-* \ + | orion-* \ + | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \ + | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \ + | pyramid-* \ + | romp-* | rs6000-* \ + | sh-* | sh[1234]-* | sh[23]e-* | sh[34]eb-* | shbe-* \ + | shle-* | sh[1234]le-* | sh3ele-* | sh64-* | sh64le-* \ + | sparc-* | sparc64-* | sparc86x-* | sparclet-* | sparclite-* \ + | sparcv9-* | sparcv9b-* | strongarm-* | sv1-* | sx?-* \ + | tahoe-* | thumb-* \ + | tic30-* | tic4x-* | tic54x-* | tic55x-* | tic6x-* | tic80-* \ + | tron-* \ + | v850-* | v850e-* | vax-* \ + | we32k-* \ + | x86-* | x86_64-* | xps100-* | xscale-* | xstormy16-* \ + | xtensa-* \ + | ymp-* \ + | z8k-*) + ;; + # Recognize the various machine names and aliases which stand + # for a CPU type and a company and sometimes even an OS. + 386bsd) + basic_machine=i386-unknown + os=-bsd + ;; + 3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc) + basic_machine=m68000-att + ;; + 3b*) + basic_machine=we32k-att + ;; + a29khif) + basic_machine=a29k-amd + os=-udi + ;; + adobe68k) + basic_machine=m68010-adobe + os=-scout + ;; + alliant | fx80) + basic_machine=fx80-alliant + ;; + altos | altos3068) + basic_machine=m68k-altos + ;; + am29k) + basic_machine=a29k-none + os=-bsd + ;; + amd64) + basic_machine=x86_64-pc + ;; + amd64-*) + basic_machine=x86_64-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + amdahl) + basic_machine=580-amdahl + os=-sysv + ;; + amiga | amiga-*) + basic_machine=m68k-unknown + ;; + amigaos | amigados) + basic_machine=m68k-unknown + os=-amigaos + ;; + amigaunix | amix) + basic_machine=m68k-unknown + os=-sysv4 + ;; + apollo68) + basic_machine=m68k-apollo + os=-sysv + ;; + apollo68bsd) + basic_machine=m68k-apollo + os=-bsd + ;; + aux) + basic_machine=m68k-apple + os=-aux + ;; + balance) + basic_machine=ns32k-sequent + os=-dynix + ;; + c90) + basic_machine=c90-cray + os=-unicos + ;; + convex-c1) + basic_machine=c1-convex + os=-bsd + ;; + convex-c2) + basic_machine=c2-convex + os=-bsd + ;; + convex-c32) + basic_machine=c32-convex + os=-bsd + ;; + convex-c34) + basic_machine=c34-convex + os=-bsd + ;; + convex-c38) + basic_machine=c38-convex + os=-bsd + ;; + cray | j90) + basic_machine=j90-cray + os=-unicos + ;; + crds | unos) + basic_machine=m68k-crds + ;; + cris | cris-* | etrax*) + basic_machine=cris-axis + ;; + da30 | da30-*) + basic_machine=m68k-da30 + ;; + decstation | decstation-3100 | pmax | pmax-* | pmin | dec3100 | decstatn) + basic_machine=mips-dec + ;; + decsystem10* | dec10*) + basic_machine=pdp10-dec + os=-tops10 + ;; + decsystem20* | dec20*) + basic_machine=pdp10-dec + os=-tops20 + ;; + delta | 3300 | motorola-3300 | motorola-delta \ + | 3300-motorola | delta-motorola) + basic_machine=m68k-motorola + ;; + delta88) + basic_machine=m88k-motorola + os=-sysv3 + ;; + dpx20 | dpx20-*) + basic_machine=rs6000-bull + os=-bosx + ;; + dpx2* | dpx2*-bull) + basic_machine=m68k-bull + os=-sysv3 + ;; + ebmon29k) + basic_machine=a29k-amd + os=-ebmon + ;; + elxsi) + basic_machine=elxsi-elxsi + os=-bsd + ;; + encore | umax | mmax) + basic_machine=ns32k-encore + ;; + es1800 | OSE68k | ose68k | ose | OSE) + basic_machine=m68k-ericsson + os=-ose + ;; + fx2800) + basic_machine=i860-alliant + ;; + genix) + basic_machine=ns32k-ns + ;; + gmicro) + basic_machine=tron-gmicro + os=-sysv + ;; + go32) + basic_machine=i386-pc + os=-go32 + ;; + h3050r* | hiux*) + basic_machine=hppa1.1-hitachi + os=-hiuxwe2 + ;; + h8300hms) + basic_machine=h8300-hitachi + os=-hms + ;; + h8300xray) + basic_machine=h8300-hitachi + os=-xray + ;; + h8500hms) + basic_machine=h8500-hitachi + os=-hms + ;; + harris) + basic_machine=m88k-harris + os=-sysv3 + ;; + hp300-*) + basic_machine=m68k-hp + ;; + hp300bsd) + basic_machine=m68k-hp + os=-bsd + ;; + hp300hpux) + basic_machine=m68k-hp + os=-hpux + ;; + hp3k9[0-9][0-9] | hp9[0-9][0-9]) + basic_machine=hppa1.0-hp + ;; + hp9k2[0-9][0-9] | hp9k31[0-9]) + basic_machine=m68000-hp + ;; + hp9k3[2-9][0-9]) + basic_machine=m68k-hp + ;; + hp9k6[0-9][0-9] | hp6[0-9][0-9]) + basic_machine=hppa1.0-hp + ;; + hp9k7[0-79][0-9] | hp7[0-79][0-9]) + basic_machine=hppa1.1-hp + ;; + hp9k78[0-9] | hp78[0-9]) + # FIXME: really hppa2.0-hp + basic_machine=hppa1.1-hp + ;; + hp9k8[67]1 | hp8[67]1 | hp9k80[24] | hp80[24] | hp9k8[78]9 | hp8[78]9 | hp9k893 | hp893) + # FIXME: really hppa2.0-hp + basic_machine=hppa1.1-hp + ;; + hp9k8[0-9][13679] | hp8[0-9][13679]) + basic_machine=hppa1.1-hp + ;; + hp9k8[0-9][0-9] | hp8[0-9][0-9]) + basic_machine=hppa1.0-hp + ;; + hppa-next) + os=-nextstep3 + ;; + hppaosf) + basic_machine=hppa1.1-hp + os=-osf + ;; + hppro) + basic_machine=hppa1.1-hp + os=-proelf + ;; + i370-ibm* | ibm*) + basic_machine=i370-ibm + ;; +# I'm not sure what "Sysv32" means. Should this be sysv3.2? + i*86v32) + basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` + os=-sysv32 + ;; + i*86v4*) + basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` + os=-sysv4 + ;; + i*86v) + basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` + os=-sysv + ;; + i*86sol2) + basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` + os=-solaris2 + ;; + i386mach) + basic_machine=i386-mach + os=-mach + ;; + i386-vsta | vsta) + basic_machine=i386-unknown + os=-vsta + ;; + iris | iris4d) + basic_machine=mips-sgi + case $os in + -irix*) + ;; + *) + os=-irix4 + ;; + esac + ;; + isi68 | isi) + basic_machine=m68k-isi + os=-sysv + ;; + m88k-omron*) + basic_machine=m88k-omron + ;; + magnum | m3230) + basic_machine=mips-mips + os=-sysv + ;; + merlin) + basic_machine=ns32k-utek + os=-sysv + ;; + mingw32) + basic_machine=i386-pc + os=-mingw32 + ;; + miniframe) + basic_machine=m68000-convergent + ;; + *mint | -mint[0-9]* | *MiNT | *MiNT[0-9]*) + basic_machine=m68k-atari + os=-mint + ;; + mips3*-*) + basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'` + ;; + mips3*) + basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown + ;; + mmix*) + basic_machine=mmix-knuth + os=-mmixware + ;; + monitor) + basic_machine=m68k-rom68k + os=-coff + ;; + morphos) + basic_machine=powerpc-unknown + os=-morphos + ;; + msdos) + basic_machine=i386-pc + os=-msdos + ;; + mvs) + basic_machine=i370-ibm + os=-mvs + ;; + ncr3000) + basic_machine=i486-ncr + os=-sysv4 + ;; + netbsd386) + basic_machine=i386-unknown + os=-netbsd + ;; + netwinder) + basic_machine=armv4l-rebel + os=-linux + ;; + news | news700 | news800 | news900) + basic_machine=m68k-sony + os=-newsos + ;; + news1000) + basic_machine=m68030-sony + os=-newsos + ;; + news-3600 | risc-news) + basic_machine=mips-sony + os=-newsos + ;; + necv70) + basic_machine=v70-nec + os=-sysv + ;; + next | m*-next ) + basic_machine=m68k-next + case $os in + -nextstep* ) + ;; + -ns2*) + os=-nextstep2 + ;; + *) + os=-nextstep3 + ;; + esac + ;; + nh3000) + basic_machine=m68k-harris + os=-cxux + ;; + nh[45]000) + basic_machine=m88k-harris + os=-cxux + ;; + nindy960) + basic_machine=i960-intel + os=-nindy + ;; + mon960) + basic_machine=i960-intel + os=-mon960 + ;; + nonstopux) + basic_machine=mips-compaq + os=-nonstopux + ;; + np1) + basic_machine=np1-gould + ;; + nv1) + basic_machine=nv1-cray + os=-unicosmp + ;; + nsr-tandem) + basic_machine=nsr-tandem + ;; + op50n-* | op60c-*) + basic_machine=hppa1.1-oki + os=-proelf + ;; + or32 | or32-*) + basic_machine=or32-unknown + os=-coff + ;; + os400) + basic_machine=powerpc-ibm + os=-os400 + ;; + OSE68000 | ose68000) + basic_machine=m68000-ericsson + os=-ose + ;; + os68k) + basic_machine=m68k-none + os=-os68k + ;; + pa-hitachi) + basic_machine=hppa1.1-hitachi + os=-hiuxwe2 + ;; + paragon) + basic_machine=i860-intel + os=-osf + ;; + pbd) + basic_machine=sparc-tti + ;; + pbb) + basic_machine=m68k-tti + ;; + pc532 | pc532-*) + basic_machine=ns32k-pc532 + ;; + pentium | p5 | k5 | k6 | nexgen | viac3) + basic_machine=i586-pc + ;; + pentiumpro | p6 | 6x86 | athlon | athlon_*) + basic_machine=i686-pc + ;; + pentiumii | pentium2 | pentiumiii | pentium3) + basic_machine=i686-pc + ;; + pentium4) + basic_machine=i786-pc + ;; + pentium-* | p5-* | k5-* | k6-* | nexgen-* | viac3-*) + basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + pentiumpro-* | p6-* | 6x86-* | athlon-*) + basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + pentiumii-* | pentium2-* | pentiumiii-* | pentium3-*) + basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + pentium4-*) + basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + pn) + basic_machine=pn-gould + ;; + power) basic_machine=power-ibm + ;; + ppc) basic_machine=powerpc-unknown + ;; + ppc-*) basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + ppcle | powerpclittle | ppc-le | powerpc-little) + basic_machine=powerpcle-unknown + ;; + ppcle-* | powerpclittle-*) + basic_machine=powerpcle-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + ppc64) basic_machine=powerpc64-unknown + ;; + ppc64-*) basic_machine=powerpc64-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + ppc64le | powerpc64little | ppc64-le | powerpc64-little) + basic_machine=powerpc64le-unknown + ;; + ppc64le-* | powerpc64little-*) + basic_machine=powerpc64le-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + ps2) + basic_machine=i386-ibm + ;; + pw32) + basic_machine=i586-unknown + os=-pw32 + ;; + rom68k) + basic_machine=m68k-rom68k + os=-coff + ;; + rm[46]00) + basic_machine=mips-siemens + ;; + rtpc | rtpc-*) + basic_machine=romp-ibm + ;; + s390 | s390-*) + basic_machine=s390-ibm + ;; + s390x | s390x-*) + basic_machine=s390x-ibm + ;; + sa29200) + basic_machine=a29k-amd + os=-udi + ;; + sb1) + basic_machine=mipsisa64sb1-unknown + ;; + sb1el) + basic_machine=mipsisa64sb1el-unknown + ;; + sei) + basic_machine=mips-sei + os=-seiux + ;; + sequent) + basic_machine=i386-sequent + ;; + sh) + basic_machine=sh-hitachi + os=-hms + ;; + sh64) + basic_machine=sh64-unknown + ;; + sparclite-wrs | simso-wrs) + basic_machine=sparclite-wrs + os=-vxworks + ;; + sps7) + basic_machine=m68k-bull + os=-sysv2 + ;; + spur) + basic_machine=spur-unknown + ;; + st2000) + basic_machine=m68k-tandem + ;; + stratus) + basic_machine=i860-stratus + os=-sysv4 + ;; + sun2) + basic_machine=m68000-sun + ;; + sun2os3) + basic_machine=m68000-sun + os=-sunos3 + ;; + sun2os4) + basic_machine=m68000-sun + os=-sunos4 + ;; + sun3os3) + basic_machine=m68k-sun + os=-sunos3 + ;; + sun3os4) + basic_machine=m68k-sun + os=-sunos4 + ;; + sun4os3) + basic_machine=sparc-sun + os=-sunos3 + ;; + sun4os4) + basic_machine=sparc-sun + os=-sunos4 + ;; + sun4sol2) + basic_machine=sparc-sun + os=-solaris2 + ;; + sun3 | sun3-*) + basic_machine=m68k-sun + ;; + sun4) + basic_machine=sparc-sun + ;; + sun386 | sun386i | roadrunner) + basic_machine=i386-sun + ;; + sv1) + basic_machine=sv1-cray + os=-unicos + ;; + symmetry) + basic_machine=i386-sequent + os=-dynix + ;; + t3e) + basic_machine=alphaev5-cray + os=-unicos + ;; + t90) + basic_machine=t90-cray + os=-unicos + ;; + tic54x | c54x*) + basic_machine=tic54x-unknown + os=-coff + ;; + tic55x | c55x*) + basic_machine=tic55x-unknown + os=-coff + ;; + tic6x | c6x*) + basic_machine=tic6x-unknown + os=-coff + ;; + tx39) + basic_machine=mipstx39-unknown + ;; + tx39el) + basic_machine=mipstx39el-unknown + ;; + toad1) + basic_machine=pdp10-xkl + os=-tops20 + ;; + tower | tower-32) + basic_machine=m68k-ncr + ;; + tpf) + basic_machine=s390x-ibm + os=-tpf + ;; + udi29k) + basic_machine=a29k-amd + os=-udi + ;; + ultra3) + basic_machine=a29k-nyu + os=-sym1 + ;; + v810 | necv810) + basic_machine=v810-nec + os=-none + ;; + vaxv) + basic_machine=vax-dec + os=-sysv + ;; + vms) + basic_machine=vax-dec + os=-vms + ;; + vpp*|vx|vx-*) + basic_machine=f301-fujitsu + ;; + vxworks960) + basic_machine=i960-wrs + os=-vxworks + ;; + vxworks68) + basic_machine=m68k-wrs + os=-vxworks + ;; + vxworks29k) + basic_machine=a29k-wrs + os=-vxworks + ;; + w65*) + basic_machine=w65-wdc + os=-none + ;; + w89k-*) + basic_machine=hppa1.1-winbond + os=-proelf + ;; + xps | xps100) + basic_machine=xps100-honeywell + ;; + ymp) + basic_machine=ymp-cray + os=-unicos + ;; + z8k-*-coff) + basic_machine=z8k-unknown + os=-sim + ;; + none) + basic_machine=none-none + os=-none + ;; + +# Here we handle the default manufacturer of certain CPU types. It is in +# some cases the only manufacturer, in others, it is the most popular. + w89k) + basic_machine=hppa1.1-winbond + ;; + op50n) + basic_machine=hppa1.1-oki + ;; + op60c) + basic_machine=hppa1.1-oki + ;; + romp) + basic_machine=romp-ibm + ;; + rs6000) + basic_machine=rs6000-ibm + ;; + vax) + basic_machine=vax-dec + ;; + pdp10) + # there are many clones, so DEC is not a safe bet + basic_machine=pdp10-unknown + ;; + pdp11) + basic_machine=pdp11-dec + ;; + we32k) + basic_machine=we32k-att + ;; + sh3 | sh4 | sh[34]eb | sh[1234]le | sh[23]ele) + basic_machine=sh-unknown + ;; + sh64) + basic_machine=sh64-unknown + ;; + sparc | sparcv9 | sparcv9b) + basic_machine=sparc-sun + ;; + cydra) + basic_machine=cydra-cydrome + ;; + orion) + basic_machine=orion-highlevel + ;; + orion105) + basic_machine=clipper-highlevel + ;; + mac | mpw | mac-mpw) + basic_machine=m68k-apple + ;; + pmac | pmac-mpw) + basic_machine=powerpc-apple + ;; + *-unknown) + # Make sure to match an already-canonicalized machine name. + ;; + *) + echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2 + exit 1 + ;; +esac + +# Here we canonicalize certain aliases for manufacturers. +case $basic_machine in + *-digital*) + basic_machine=`echo $basic_machine | sed 's/digital.*/dec/'` + ;; + *-commodore*) + basic_machine=`echo $basic_machine | sed 's/commodore.*/cbm/'` + ;; + *) + ;; +esac + +# Decode manufacturer-specific aliases for certain operating systems. + +if [ x"$os" != x"" ] +then +case $os in + # First match some system type aliases + # that might get confused with valid system types. + # -solaris* is a basic system type, with this one exception. + -solaris1 | -solaris1.*) + os=`echo $os | sed -e 's|solaris1|sunos4|'` + ;; + -solaris) + os=-solaris2 + ;; + -svr4*) + os=-sysv4 + ;; + -unixware*) + os=-sysv4.2uw + ;; + -gnu/linux*) + os=`echo $os | sed -e 's|gnu/linux|linux-gnu|'` + ;; + # First accept the basic system types. + # The portable systems comes first. + # Each alternative MUST END IN A *, to match a version number. + # -sysv* is not here because it comes later, after sysvr4. + -gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \ + | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[34]*\ + | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \ + | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \ + | -aos* \ + | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \ + | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \ + | -hiux* | -386bsd* | -knetbsd* | -netbsd* | -openbsd* | -kfreebsd* | -freebsd* | -riscix* \ + | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \ + | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \ + | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \ + | -chorusos* | -chorusrdb* \ + | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ + | -mingw32* | -linux-gnu* | -linux-uclibc* | -uxpv* | -beos* | -mpeix* | -udk* \ + | -interix* | -uwin* | -mks* | -rhapsody* | -darwin* | -opened* \ + | -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \ + | -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* \ + | -os2* | -vos* | -palmos* | -uclinux* | -nucleus* \ + | -morphos* | -superux* | -rtmk* | -rtmk-nova* | -windiss* \ + | -powermax* | -dnix* | -nx6 | -nx7 | -sei* | -dragonfly*) + # Remember, each alternative MUST END IN *, to match a version number. + ;; + -qnx*) + case $basic_machine in + x86-* | i*86-*) + ;; + *) + os=-nto$os + ;; + esac + ;; + -nto-qnx*) + ;; + -nto*) + os=`echo $os | sed -e 's|nto|nto-qnx|'` + ;; + -sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \ + | -windows* | -osx | -abug | -netware* | -os9* | -beos* \ + | -macos* | -mpw* | -magic* | -mmixware* | -mon960* | -lnews*) + ;; + -mac*) + os=`echo $os | sed -e 's|mac|macos|'` + ;; + -linux-dietlibc) + os=-linux-dietlibc + ;; + -linux*) + os=`echo $os | sed -e 's|linux|linux-gnu|'` + ;; + -sunos5*) + os=`echo $os | sed -e 's|sunos5|solaris2|'` + ;; + -sunos6*) + os=`echo $os | sed -e 's|sunos6|solaris3|'` + ;; + -opened*) + os=-openedition + ;; + -os400*) + os=-os400 + ;; + -wince*) + os=-wince + ;; + -osfrose*) + os=-osfrose + ;; + -osf*) + os=-osf + ;; + -utek*) + os=-bsd + ;; + -dynix*) + os=-bsd + ;; + -acis*) + os=-aos + ;; + -atheos*) + os=-atheos + ;; + -syllable*) + os=-syllable + ;; + -386bsd) + os=-bsd + ;; + -ctix* | -uts*) + os=-sysv + ;; + -nova*) + os=-rtmk-nova + ;; + -ns2 ) + os=-nextstep2 + ;; + -nsk*) + os=-nsk + ;; + # Preserve the version number of sinix5. + -sinix5.*) + os=`echo $os | sed -e 's|sinix|sysv|'` + ;; + -sinix*) + os=-sysv4 + ;; + -tpf*) + os=-tpf + ;; + -triton*) + os=-sysv3 + ;; + -oss*) + os=-sysv3 + ;; + -svr4) + os=-sysv4 + ;; + -svr3) + os=-sysv3 + ;; + -sysvr4) + os=-sysv4 + ;; + # This must come after -sysvr4. + -sysv*) + ;; + -ose*) + os=-ose + ;; + -es1800*) + os=-ose + ;; + -xenix) + os=-xenix + ;; + -*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*) + os=-mint + ;; + -aros*) + os=-aros + ;; + -kaos*) + os=-kaos + ;; + -none) + ;; + *) + # Get rid of the `-' at the beginning of $os. + os=`echo $os | sed 's/[^-]*-//'` + echo Invalid configuration \`$1\': system \`$os\' not recognized 1>&2 + exit 1 + ;; +esac +else + +# Here we handle the default operating systems that come with various machines. +# The value should be what the vendor currently ships out the door with their +# machine or put another way, the most popular os provided with the machine. + +# Note that if you're going to try to match "-MANUFACTURER" here (say, +# "-sun"), then you have to tell the case statement up towards the top +# that MANUFACTURER isn't an operating system. Otherwise, code above +# will signal an error saying that MANUFACTURER isn't an operating +# system, and we'll never get to this point. + +case $basic_machine in + *-acorn) + os=-riscix1.2 + ;; + arm*-rebel) + os=-linux + ;; + arm*-semi) + os=-aout + ;; + c4x-* | tic4x-*) + os=-coff + ;; + # This must come before the *-dec entry. + pdp10-*) + os=-tops20 + ;; + pdp11-*) + os=-none + ;; + *-dec | vax-*) + os=-ultrix4.2 + ;; + m68*-apollo) + os=-domain + ;; + i386-sun) + os=-sunos4.0.2 + ;; + m68000-sun) + os=-sunos3 + # This also exists in the configure program, but was not the + # default. + # os=-sunos4 + ;; + m68*-cisco) + os=-aout + ;; + mips*-cisco) + os=-elf + ;; + mips*-*) + os=-elf + ;; + or32-*) + os=-coff + ;; + *-tti) # must be before sparc entry or we get the wrong os. + os=-sysv3 + ;; + sparc-* | *-sun) + os=-sunos4.1.1 + ;; + *-be) + os=-beos + ;; + *-ibm) + os=-aix + ;; + *-wec) + os=-proelf + ;; + *-winbond) + os=-proelf + ;; + *-oki) + os=-proelf + ;; + *-hp) + os=-hpux + ;; + *-hitachi) + os=-hiux + ;; + i860-* | *-att | *-ncr | *-altos | *-motorola | *-convergent) + os=-sysv + ;; + *-cbm) + os=-amigaos + ;; + *-dg) + os=-dgux + ;; + *-dolphin) + os=-sysv3 + ;; + m68k-ccur) + os=-rtu + ;; + m88k-omron*) + os=-luna + ;; + *-next ) + os=-nextstep + ;; + *-sequent) + os=-ptx + ;; + *-crds) + os=-unos + ;; + *-ns) + os=-genix + ;; + i370-*) + os=-mvs + ;; + *-next) + os=-nextstep3 + ;; + *-gould) + os=-sysv + ;; + *-highlevel) + os=-bsd + ;; + *-encore) + os=-bsd + ;; + *-sgi) + os=-irix + ;; + *-siemens) + os=-sysv4 + ;; + *-masscomp) + os=-rtu + ;; + f30[01]-fujitsu | f700-fujitsu) + os=-uxpv + ;; + *-rom68k) + os=-coff + ;; + *-*bug) + os=-coff + ;; + *-apple) + os=-macos + ;; + *-atari*) + os=-mint + ;; + *) + os=-none + ;; +esac +fi + +# Here we handle the case where we know the os, and the CPU type, but not the +# manufacturer. We pick the logical manufacturer. +vendor=unknown +case $basic_machine in + *-unknown) + case $os in + -riscix*) + vendor=acorn + ;; + -sunos*) + vendor=sun + ;; + -aix*) + vendor=ibm + ;; + -beos*) + vendor=be + ;; + -hpux*) + vendor=hp + ;; + -mpeix*) + vendor=hp + ;; + -hiux*) + vendor=hitachi + ;; + -unos*) + vendor=crds + ;; + -dgux*) + vendor=dg + ;; + -luna*) + vendor=omron + ;; + -genix*) + vendor=ns + ;; + -mvs* | -opened*) + vendor=ibm + ;; + -os400*) + vendor=ibm + ;; + -ptx*) + vendor=sequent + ;; + -tpf*) + vendor=ibm + ;; + -vxsim* | -vxworks* | -windiss*) + vendor=wrs + ;; + -aux*) + vendor=apple + ;; + -hms*) + vendor=hitachi + ;; + -mpw* | -macos*) + vendor=apple + ;; + -*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*) + vendor=atari + ;; + -vos*) + vendor=stratus + ;; + esac + basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"` + ;; +esac + +echo $basic_machine$os +exit 0 + +# Local variables: +# eval: (add-hook 'write-file-hooks 'time-stamp) +# time-stamp-start: "timestamp='" +# time-stamp-format: "%:y-%02m-%02d" +# time-stamp-end: "'" +# End: diff --git a/contrib/bind9/configure.in b/contrib/bind9/configure.in new file mode 100644 index 000000000000..d1ca87c3d9c0 --- /dev/null +++ b/contrib/bind9/configure.in @@ -0,0 +1,2180 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 1998-2003 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +dnl +AC_DIVERT_PUSH(1)dnl +esyscmd([sed "s/^/# /" COPYRIGHT])dnl +AC_DIVERT_POP()dnl + +AC_REVISION($Revision: 1.294.2.23.2.30 $) + +AC_INIT(lib/dns/name.c) +AC_PREREQ(2.13) + +AC_CONFIG_HEADER(config.h) +AC_CONFIG_SUBDIRS(lib/bind) + +AC_CANONICAL_HOST + +AC_PROG_MAKE_SET +AC_PROG_RANLIB +AC_PROG_INSTALL + +AC_SUBST(STD_CINCLUDES) +AC_SUBST(STD_CDEFINES) +AC_SUBST(STD_CWARNINGS) +AC_SUBST(CCOPT) + +AC_PATH_PROG(AR, ar) +ARFLAGS="cruv" +AC_SUBST(AR) +AC_SUBST(ARFLAGS) + +# The POSIX ln(1) program. Non-POSIX systems may substitute +# "copy" or something. +LN=ln +AC_SUBST(LN) + +case "$AR" in + "") + AC_MSG_ERROR([ +ar program not found. Please fix your PATH to include the directory in +which ar resides, or set AR in the environment with the full path to ar. +]) + + ;; +esac + +# +# Etags. +# +AC_PATH_PROGS(ETAGS, etags emacs-etags) + +# +# Some systems, e.g. RH7, have the Exuberant Ctags etags instead of +# GNU emacs etags, and it requires the -L flag. +# +if test "X$ETAGS" != "X"; then + AC_MSG_CHECKING(for Exuberant Ctags etags) + if $ETAGS --version 2>&1 | grep 'Exuberant Ctags' >/dev/null 2>&1; then + AC_MSG_RESULT(yes) + ETAGS="$ETAGS -L" + else + AC_MSG_RESULT(no) + fi +fi +AC_SUBST(ETAGS) + +# +# Perl is optional; it is used only by some of the system test scripts. +# +AC_PATH_PROGS(PERL, perl5 perl) +AC_SUBST(PERL) + +# +# Special processing of paths depending on whether --prefix, +# --sysconfdir or --localstatedir arguments were given. What's +# desired is some compatibility with the way previous versions +# of BIND built; they defaulted to /usr/local for most parts of +# the installation, but named.boot/named.conf was in /etc +# and named.pid was in /var/run. +# +# So ... if none of --prefix, --sysconfdir or --localstatedir are +# specified, set things up that way. If --prefix is given, use +# it for sysconfdir and localstatedir the way configure normally +# would. To change the prefix for everything but leave named.conf +# in /etc or named.pid in /var/run, then do this the usual configure way: +# ./configure --prefix=/somewhere --sysconfdir=/etc +# ./configure --prefix=/somewhere --localstatedir=/var +# +# To put named.conf and named.pid in /usr/local with everything else, +# set the prefix explicitly to /usr/local even though that's the default: +# ./configure --prefix=/usr/local +# +case "$prefix" in + NONE) + case "$sysconfdir" in + '${prefix}/etc') + sysconfdir=/etc + ;; + esac + case "$localstatedir" in + '${prefix}/var') + localstatedir=/var + ;; + esac + ;; +esac + +# +# Make sure INSTALL uses an absolute path, else it will be wrong in all +# Makefiles, since they use make/rules.in and INSTALL will be adjusted by +# configure based on the location of the file where it is substituted. +# Since in BIND9 INSTALL is only substituted into make/rules.in, an immediate +# subdirectory of install-sh, This relative path will be wrong for all +# directories more than one level down from install-sh. +# +case "$INSTALL" in + /*) + ;; + *) + # + # Not all systems have dirname. + # + changequote({, }) + ac_dir="`echo $INSTALL | sed 's%/[^/]*$%%'`" + changequote([, ]) + + ac_prog="`echo $INSTALL | sed 's%.*/%%'`" + test "$ac_dir" = "$ac_prog" && ac_dir=. + test -d "$ac_dir" && ac_dir="`(cd \"$ac_dir\" && pwd)`" + INSTALL="$ac_dir/$ac_prog" + ;; +esac + +# +# On these hosts, we really want to use cc, not gcc, even if it is +# found. The gcc that these systems have will not correctly handle +# pthreads. +# +# However, if the user sets $CC to be something, let that override +# our change. +# +if test "X$CC" = "X" ; then + case "$host" in + *-dec-osf*) + CC="cc" + ;; + *-solaris*) + # Use Sun's cc if it is available, but watch + # out for /usr/ucb/cc; it will never be the right + # compiler to use. + # + # If setting CC here fails, the AC_PROG_CC done + # below might still find gcc. + IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":" + for ac_dir in $PATH; do + test -z "$ac_dir" && ac_dir=. + case "$ac_dir" in + /usr/ucb) + # exclude + ;; + *) + if test -f "$ac_dir/cc"; then + CC="$ac_dir/cc" + break + fi + ;; + esac + done + IFS="$ac_save_ifs" + ;; + *-hp-hpux*) + CC="cc" + ;; + mips-sgi-irix*) + CC="cc" + ;; + esac +fi + +AC_PROG_CC + +# +# gcc's optimiser is broken at -02 for ultrasparc +# +if test "$ac_env_CFLAGS_set" != set -a "X$GCC" = "Xyes"; then + case "$host" in + sparc-*) + CCFLAGS="-g -O1" + ;; + esac +fi + +# +# OS dependent CC flags +# +case "$host" in + # OSF 5.0: recv/send are only avaliable with -D_POSIX_PII_SOCKET or + # -D_XOPEN_SOURCE_EXTENDED. + *-dec-osf*) + STD_CDEFINES="$STD_CDEFINES -D_POSIX_PII_SOCKET" + CPPFLAGS="$CPPFLAGS -D_POSIX_PII_SOCKET" + ;; + #HP-UX: need -D_XOPEN_SOURCE_EXTENDED and -lxnet for CMSG macros + *-hp-hpux*) + STD_CDEFINES="$STD_CDEFINES -D_XOPEN_SOURCE_EXTENDED" + CPPFLAGS="$CPPFLAGS -D_XOPEN_SOURCE_EXTENDED" + LIBS="-lxnet $LIBS" + ;; + # Solaris: need -D_XPG4_2 and -D__EXTENSIONS__ for CMSG macros + *-solaris*) + STD_CDEFINES="$STD_CDEFINES -D_XPG4_2 -D__EXTENSIONS__" + CPPFLAGS="$CPPFLAGS -D_XPG4_2 -D__EXTENSIONS__" + ;; +esac + +AC_HEADER_STDC + +AC_CHECK_HEADERS(fcntl.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/param.h sys/sysctl.h net/if6.h,,, +[$ac_includes_default +#ifdef HAVE_SYS_PARAM_H +# include +#endif +]) + +AC_C_CONST +AC_C_INLINE +AC_CHECK_FUNC(sysctlbyname, AC_DEFINE(HAVE_SYSCTLBYNAME)) + +# +# UnixWare 7.1.1 with the feature supplement to the UDK compiler +# is reported to not support "static inline" (RT #1212). +# +AC_MSG_CHECKING(for static inline breakage) +AC_TRY_COMPILE(, [ + foo1(); + } + + static inline int foo1() { + return 0; + } + + static inline int foo2() { + return foo1(); + ], + [AC_MSG_RESULT(no)], + [AC_MSG_RESULT(yes) + AC_DEFINE(inline, )]) + +AC_TYPE_SIZE_T +AC_CHECK_TYPE(ssize_t, int) +AC_HEADER_TIME +AC_MSG_CHECKING(for long long) +AC_TRY_COMPILE([],[long long i = 0; return (0);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_HAVELONGLONG="#define ISC_PLATFORM_HAVELONGLONG 1"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_HAVELONGLONG="#undef ISC_PLATFORM_HAVELONGLONG"]) +AC_SUBST(ISC_PLATFORM_HAVELONGLONG) + +# +# check if we have lifconf +# +AC_MSG_CHECKING(for struct lifconf) +AC_TRY_COMPILE([ +#include +#include +#include +], +[ +struct lifconf lifconf; +lifconf.lifc_len = 0; +] +, + [AC_MSG_RESULT(yes) + ISC_PLATFORM_HAVELIFCONF="#define ISC_PLATFORM_HAVELIFCONF 1"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_HAVELIFCONF="#undef ISC_PLATFORM_HAVELIFCONF"]) +AC_SUBST(ISC_PLATFORM_HAVELIFCONF) + + +# +# check if we need to #include sys/select.h explicitly +# +case $ac_cv_header_unistd_h in +yes) +AC_MSG_CHECKING(if unistd.h or sys/types.h defines fd_set) +AC_TRY_COMPILE([ +#include /* Ultrix */ +#include ], +[fd_set read_set; return (0);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_NEEDSYSSELECTH="#undef ISC_PLATFORM_NEEDSYSSELECTH" + LWRES_PLATFORM_NEEDSYSSELECTH="#undef LWRES_PLATFORM_NEEDSYSSELECTH"], + [AC_MSG_RESULT(no) + case $ac_cv_header_sys_select_h in + yes) + ISC_PLATFORM_NEEDSYSSELECTH="#define ISC_PLATFORM_NEEDSYSSELECTH 1" + LWRES_PLATFORM_NEEDSYSSELECTH="#define LWRES_PLATFORM_NEEDSYSSELECTH 1" + ;; + no) + AC_MSG_ERROR([need either working unistd.h or sys/select.h]) + ;; + esac + ]) + ;; +no) + case $ac_cv_header_sys_select_h in + yes) + ISC_PLATFORM_NEEDSYSSELECTH="#define ISC_PLATFORM_NEEDSYSSELECTH 1" + LWRES_PLATFORM_NEEDSYSSELECTH="#define LWRES_PLATFORM_NEEDSYSSELECTH 1" + ;; + no) + AC_MSG_ERROR([need either unistd.h or sys/select.h]) + ;; + esac + ;; +esac +AC_SUBST(ISC_PLATFORM_NEEDSYSSELECTH) +AC_SUBST(LWRES_PLATFORM_NEEDSYSSELECTH) + +# +# Find the machine's endian flavor. +# +AC_C_BIGENDIAN + +# +# was --with-openssl specified? +# +AC_MSG_CHECKING(for OpenSSL library) +AC_ARG_WITH(openssl, +[ --with-openssl[=PATH] Build with OpenSSL [yes|no|path]. + (Required for DNSSEC)], + use_openssl="$withval", use_openssl="auto") + +case "$use_openssl" in + no) + AC_MSG_RESULT(no) + DST_OPENSSL_INC="" + USE_OPENSSL="" + ;; + *) + if test "$use_openssl" = "yes" -o "$use_openssl" = "auto" + then + # User did not specify a path - guess it + openssldirs="/usr /usr/local /usr/local/ssl /usr/pkg" + for d in $openssldirs + do + if test -f $d/include/openssl/opensslv.h + then + use_openssl=$d + break + fi + done + if test "$use_openssl" = "yes" + then + AC_MSG_RESULT(not found) + AC_MSG_ERROR( +[OpenSSL was not found in any of $openssldirs; use --with-openssl=/path]) + elif test "$use_openssl" = "auto" + then + DST_OPENSSL_INC="" + USE_OPENSSL="" + AC_MSG_RESULT(not found) + break + fi + fi + USE_OPENSSL='-DOPENSSL' + if test "$use_openssl" = "/usr" + then + DST_OPENSSL_INC="" + DNS_OPENSSL_LIBS="-lcrypto" + else + DST_OPENSSL_INC="-I$use_openssl/include" + case $host in + *-solaris*) + DNS_OPENSSL_LIBS="-L$use_openssl/lib -R$use_openssl/lib -lcrypto" + ;; + *) + DNS_OPENSSL_LIBS="-L$use_openssl/lib -lcrypto" + ;; + esac + fi + AC_MSG_RESULT(using openssl from $use_openssl/lib and $use_openssl/include) + + saved_cflags="$CFLAGS" + saved_libs="$LIBS" + CFLAGS="$CFLAGS $DST_OPENSSL_INC" + LIBS="$LIBS $DNS_OPENSSL_LIBS" + AC_MSG_CHECKING(whether linking with OpenSSL works) + AC_TRY_RUN([ +#include +int main() { + ERR_clear_error(); + return (0); +} +], + [AC_MSG_RESULT(yes)], + [AC_MSG_RESULT(no) + AC_MSG_ERROR(Could not run test program using OpenSSL from +$use_openssl/lib and $use_openssl/include. +Please check the argument to --with-openssl and your +shared library configuration (e.g., LD_LIBRARY_PATH).)], + [AC_MSG_RESULT(assuming it does work on target platform)]) + + AC_MSG_CHECKING(whether linking with OpenSSL requires -ldl) + AC_TRY_LINK([ +#include ], +[ DSO_METHOD_dlfcn(); ], + [AC_MSG_RESULT(no)], + [LIBS="$LIBS -ldl" + AC_TRY_LINK([ +#include +],[ DSO_METHOD_dlfcn(); ], + [AC_MSG_RESULT(yes) + DNS_OPENSSL_LIBS="$DNS_OPENSSL_LIBS -ldl" + ], + [AC_MSG_RESULT(unknown) + AC_MSG_ERROR(OpenSSL has unsupported dynamic loading)], + [AC_MSG_RESULT(assuming it does work on target platform)]) + ], + [AC_MSG_RESULT(assuming it does work on target platform)] + ) + +# +# OpenSSLDie is new with CERT CS-2002-23. If we see it we have may +# have a patched library otherwise check that we are greater than +# the fixed versions +# + AC_CHECK_FUNC(OpenSSLDie, + AC_MSG_CHECKING(OpenSSL library version) + AC_TRY_RUN([ +#include +#include +int main() { + if (OPENSSL_VERSION_NUMBER >= 0x0090581fL) + return (0); + printf("\n\nFound OPENSSL_VERSION_NUMBER %#010x\n", + OPENSSL_VERSION_NUMBER); + printf("Require OPENSSL_VERSION_NUMBER 0x0090581f or greater\n\n"); + return (1); +} +], + [AC_MSG_RESULT(ok)], + [AC_MSG_RESULT(not compatible) + AC_MSG_ERROR(you need OpenSSL 0.9.5a or newer)], + [AC_MSG_RESULT(assuming target platform has compatible version)]) + , + AC_MSG_RESULT(did not find fixes for CERT CA-2002-23) + AC_MSG_CHECKING(OpenSSL library version) + AC_TRY_RUN([ +#include +#include +int main() { + if ((OPENSSL_VERSION_NUMBER >= 0x0090605fL && + OPENSSL_VERSION_NUMBER < 0x009070000L) || + OPENSSL_VERSION_NUMBER >= 0x00907003L) + return (0); + printf("\n\nFound OPENSSL_VERSION_NUMBER %#010x\n", + OPENSSL_VERSION_NUMBER); + printf("Require OPENSSL_VERSION_NUMBER 0x0090605f or greater (0.9.6e)\n" + "Require OPENSSL_VERSION_NUMBER 0x00907003 or greater (0.9.7-beta2)\n\n"); + return (1); +} +], + [AC_MSG_RESULT(ok)], + [AC_MSG_RESULT(not compatible) + AC_MSG_ERROR(you need OpenSSL 0.9.6e/0.9.7-beta2 (or newer): CERT CA-2002-23)], + [AC_MSG_RESULT(assuming target platform has compatible version)])) + AC_MSG_CHECKING(for OpenSSL DSA support) + if test -f $use_openssl/include/openssl/dsa.h + then + AC_DEFINE(HAVE_OPENSSL_DSA) + AC_MSG_RESULT(yes) + else + AC_MSG_RESULT(no) + fi + CFLAGS="$saved_cflags" + LIBS="$saved_libs" + ;; +esac + +# +# This would include the system openssl path (and linker options to use +# it as needed) if it is found. +# + +AC_SUBST(USE_OPENSSL) +AC_SUBST(DST_OPENSSL_INC) +DNS_CRYPTO_LIBS="$DNS_CRYPTO_LIBS $DNS_OPENSSL_LIBS" + +# +# was --with-gssapi specified? +# +#AC_MSG_CHECKING(for GSSAPI library) +#AC_ARG_WITH(gssapi, +#[ --with-gssapi=PATH Specify path for system-supplied GSSAPI], +# use_gssapi="$withval", use_gssapi="no") +# +#case "$use_gssapi" in +# no) +# USE_GSSAPI='' +# DST_GSSAPI_INC='' +# DNS_GSSAPI_LIBS='' +# AC_MSG_RESULT(not specified) +# ;; +# yes) +# AC_MSG_ERROR([--with-gssapi must specify a path]) +# ;; +# *) +# USE_GSSAPI='-DGSSAPI' +# DST_GSSAPI_INC="-I$use_gssapi/include" +# DNS_GSSAPI_LIBS="-L$use_gssapi/lib -lgssapi_krb5" +# AC_MSG_RESULT(using gssapi from $use_gssapi/lib and $use_gssapi/include) +# ;; +#esac + +USE_GSSAPI='' +DST_GSSAPI_INC='' +DNS_GSSAPI_LIBS='' + +AC_SUBST(USE_GSSAPI) +AC_SUBST(DST_GSSAPI_INC) +DNS_CRYPTO_LIBS="$DNS_CRYPTO_LIBS $DNS_GSSAPI_LIBS" + +# +# Applications linking with libdns also need to link with these libraries. +# + +AC_SUBST(DNS_CRYPTO_LIBS) + +# +# was --with-randomdev specified? +# +AC_MSG_CHECKING(for random device) +AC_ARG_WITH(randomdev, +[ --with-randomdev=PATH Specify path for random device], + use_randomdev="$withval", use_randomdev="unspec") + +case "$use_randomdev" in + unspec) + case "$host" in + *-openbsd*) + devrandom=/dev/arandom + ;; + *) + devrandom=/dev/random + ;; + esac + AC_MSG_RESULT($devrandom) + AC_CHECK_FILE($devrandom, + AC_DEFINE_UNQUOTED(PATH_RANDOMDEV, + "$devrandom"),) + ;; + yes) + AC_MSG_ERROR([--with-randomdev must specify a path]) + ;; + no) + AC_MSG_RESULT(disabled) + ;; + *) + AC_DEFINE_UNQUOTED(PATH_RANDOMDEV, "$use_randomdev") + AC_MSG_RESULT(using "$use_randomdev") + ;; +esac + +# +# Do we have arc4random() ? +# +AC_CHECK_FUNC(arc4random, AC_DEFINE(HAVE_ARC4RANDOM)) + +# +# Begin pthreads checking. +# +# First, decide whether to use multithreading or not. +# +# Enable multithreading by default on systems where it is known +# to work well, and where debugging of multithreaded programs +# is supported. +# + +AC_MSG_CHECKING(whether to build with thread support) + +case $host in +*-dec-osf*) + use_threads=true ;; +[*-solaris2.[0-6]]) + # Thread signals are broken on Solaris 2.6; they are sometimes + # delivered to the wrong thread. + use_threads=false ;; +*-solaris*) + use_threads=true ;; +*-ibm-aix*) + use_threads=true ;; +*-hp-hpux10*) + use_threads=false ;; +*-hp-hpux11*) + use_threads=true ;; +*-sgi-irix*) + use_threads=true ;; +*-sco-sysv*uw*|*-*-sysv*UnixWare*) + # UnixWare + use_threads=false ;; +*-*-sysv*OpenUNIX*) + # UnixWare + use_threads=true ;; +*-netbsd*) + if test -r /usr/lib/libpthread.so ; then + use_threads=true + else + # Socket I/O optimizations introduced in 9.2 expose a + # bug in unproven-pthreads; see PR #12650 + use_threads=false + fi + ;; +*-openbsd*) + # OpenBSD users have reported that named dumps core on + # startup when built with threads. + use_threads=false ;; +*-freebsd*) + use_threads=false ;; +*-bsdi[234]*) + # Thread signals do not work reliably on some versions of BSD/OS. + use_threads=false ;; +*-bsdi5*) + use_threads=true ;; +*-linux*) + # Threads are disabled on Linux by default because most + # Linux kernels produce unusable core dumps from multithreaded + # programs, and because of limitations in setuid(). + use_threads=false ;; +*) + use_threads=false ;; +esac + +AC_ARG_ENABLE(threads, + [ --enable-threads enable multithreading]) +case "$enable_threads" in + yes) + use_threads=true + ;; + no) + use_threads=false + ;; + '') + # Use system-dependent default + ;; + *) + AC_MSG_ERROR([--enable-threads takes yes or no]) + ;; +esac + +if $use_threads +then + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) +fi + +if $use_threads +then + # + # Search for / configure pthreads in a system-dependent fashion. + # + case "$host" in + *-netbsd*) + # NetBSD has multiple pthreads implementations. The + # recommended one to use is "unproven-pthreads". The + # older "mit-pthreads" may also work on some NetBSD + # versions. The PTL2 thread library does not + # currently work with bind9, but can be chosen with + # the --with-ptl2 option for those who wish to + # experiment with it. + CC="gcc" + AC_MSG_CHECKING(which NetBSD thread library to use) + + AC_ARG_WITH(ptl2, +[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)], + use_ptl2="$withval", use_ptl2="no") + + : ${LOCALBASE:=/usr/pkg} + + if test "X$use_ptl2" = "Xyes" + then + AC_MSG_RESULT(PTL2) + AC_MSG_WARN( +[linking with PTL2 is highly experimental and not expected to work]) + CC=ptlgcc + else + if test -r /usr/lib/libpthread.so + then + AC_MSG_RESULT(native) + LIBS="-lpthread $LIBS" + else + if test ! -d $LOCALBASE/pthreads + then + AC_MSG_RESULT(none) + AC_MSG_ERROR("could not find thread libraries") + fi + + if $use_threads + then + AC_MSG_RESULT(mit-pthreads/unproven-pthreads) + pkg="$LOCALBASE/pthreads" + lib1="-L$pkg/lib -Wl,-R$pkg/lib" + lib2="-lpthread -lm -lgcc -lpthread" + LIBS="$lib1 $lib2 $LIBS" + CPPFLAGS="$CPPFLAGS -I$pkg/include" + STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include" + fi + fi + fi + ;; + *) + AC_CHECK_LIB(pthread, pthread_create,, + AC_CHECK_LIB(pthread, __pthread_create,, + AC_CHECK_LIB(pthread, __pthread_create_system,, + AC_CHECK_LIB(c_r, pthread_create,, + AC_CHECK_LIB(c, pthread_create,, + AC_MSG_ERROR("could not find thread libraries")))))) + ;; + esac +fi + +if $use_threads +then + # + # We'd like to use sigwait() too + # + AC_CHECK_LIB(c, sigwait, + AC_DEFINE(HAVE_SIGWAIT), + AC_CHECK_LIB(pthread, sigwait, + AC_DEFINE(HAVE_SIGWAIT), + AC_CHECK_LIB(pthread, _Psigwait, + AC_DEFINE(HAVE_SIGWAIT),)) + ) + + AC_CHECK_FUNC(pthread_attr_getstacksize, + AC_DEFINE(HAVE_PTHREAD_ATTR_GETSTACKSIZE),) + + AC_CHECK_FUNC(pthread_attr_setstacksize, + AC_DEFINE(HAVE_PTHREAD_ATTR_SETSTACKSIZE),) + + # + # Additional OS-specific issues related to pthreads and sigwait. + # + case "$host" in + # + # One more place to look for sigwait. + # + *-freebsd*) + AC_CHECK_LIB(c_r, sigwait, AC_DEFINE(HAVE_SIGWAIT),) + ;; + # + # BSDI 3.0 through 4.0.1 needs pthread_init() to be + # called before certain pthreads calls. This is deprecated + # in BSD/OS 4.1. + # + *-bsdi3.*|*-bsdi4.0*) + AC_DEFINE(NEED_PTHREAD_INIT) + ;; + # + # LinuxThreads requires some changes to the way we + # deal with signals. + # + *-linux*) + AC_DEFINE(HAVE_LINUXTHREADS) + ;; + # + # Ensure the right sigwait() semantics on Solaris and make + # sure we call pthread_setconcurrency. + # + *-solaris*) + AC_DEFINE(_POSIX_PTHREAD_SEMANTICS) + AC_CHECK_FUNC(pthread_setconcurrency, + AC_DEFINE(CALL_PTHREAD_SETCONCURRENCY)) + ;; + # + # UnixWare does things its own way. + # + *-sco-sysv*uw*|*-*-sysv*UnixWare*|*-*-sysv*OpenUNIX*) + AC_DEFINE(HAVE_UNIXWARE_SIGWAIT) + ;; + esac + + # + # Look for sysconf to allow detection of the number of processors. + # + AC_CHECK_FUNC(sysconf, AC_DEFINE(HAVE_SYSCONF),) + + if test "X$GCC" = "Xyes"; then + case "$host" in + *-freebsd*) + CC="$CC -pthread" + CCOPT="$CCOPT -pthread" + STD_CDEFINES="$STD_CDEFINES -D_THREAD_SAFE" + ;; + *-openbsd*) + CC="$CC -pthread" + CCOPT="$CCOPT -pthread" + ;; + *-solaris*) + LIBS="$LIBS -lthread" + ;; + *-ibm-aix*) + STD_CDEFINES="$STD_CDEFINES -D_THREAD_SAFE" + ;; + esac + else + case $host in + *-dec-osf*) + CC="$CC -pthread" + CCOPT="$CCOPT -pthread" + ;; + *-solaris*) + CC="$CC -mt" + CCOPT="$CCOPT -mt" + ;; + *-ibm-aix*) + STD_CDEFINES="$STD_CDEFINES -D_THREAD_SAFE" + ;; + *-sco-sysv*uw*|*-*-sysv*UnixWare*) + CC="$CC -Kthread" + CCOPT="$CCOPT -Kthread" + ;; + *-*-sysv*OpenUNIX*) + CC="$CC -Kpthread" + CCOPT="$CCOPT -Kpthread" + ;; + esac + fi + ALWAYS_DEFINES="-D_REENTRANT" + ISC_PLATFORM_USETHREADS="#define ISC_PLATFORM_USETHREADS 1" + thread_dir=pthreads +else + ISC_PLATFORM_USETHREADS="#undef ISC_PLATFORM_USETHREADS" + thread_dir=nothreads + ALWAYS_DEFINES="" +fi + +AC_SUBST(ALWAYS_DEFINES) +AC_SUBST(ISC_PLATFORM_USETHREADS) + +ISC_THREAD_DIR=$thread_dir +AC_SUBST(ISC_THREAD_DIR) + +# +# In solaris 10, SMF can manage named service +# +AC_CHECK_LIB(scf, smf_enable_instance) + +# +# flockfile is usually provided by pthreads, but we may want to use it +# even if compiled with --disable-threads. getc_unlocked might also not +# be defined. +# +AC_CHECK_FUNC(flockfile, AC_DEFINE(HAVE_FLOCKFILE),) +AC_CHECK_FUNC(getc_unlocked, AC_DEFINE(HAVE_GETCUNLOCKED),) + +# +# Indicate what the final decision was regarding threads. +# +AC_MSG_CHECKING(whether to build with threads) +if $use_threads; then + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) +fi + +# +# End of pthreads stuff. +# + +# +# Large File +# +AC_ARG_ENABLE(largefile, [ --enable-largefile 64-bit file support], + want_largefile="yes", want_largefile="no") +case $want_largefile in + yes) + ALWAYS_DEFINES="$ALWAYS_DEFINES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" + ;; + *) + ;; +esac + +# +# Additional compiler settings. +# +MKDEPCC="$CC" +MKDEPCFLAGS="-M" +IRIX_DNSSEC_WARNINGS_HACK="" + +if test "X$GCC" = "Xyes"; then + STD_CWARNINGS="$STD_CWARNINGS -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat" +else + case $host in + *-dec-osf*) + CC="$CC -std" + CCOPT="$CCOPT -std" + MKDEPCC="$CC" + ;; + *-hp-hpux*) + CC="$CC -Ae -z" + # The version of the C compiler that constantly warns about + # 'const' as well as alignment issues is unfortunately not + # able to be discerned via the version of the operating + # system, nor does cc have a version flag. + case "`$CC +W 123 2>&1`" in + *Unknown?option*) + STD_CWARNINGS="+w1" + ;; + *) + # Turn off the pointlessly noisy warnings. + STD_CWARNINGS="+w1 +W 474,530" + ;; + esac + CCOPT="$CCOPT -Ae -z" + LIBS="-Wl,+vnocompatwarnings $LIBS" + MKDEPPROG='cc -Ae -E -Wp,-M >/dev/null 2>>$TMP' + ;; + *-sgi-irix*) + STD_CWARNINGS="-fullwarn -woff 1209" + # + # Silence more than 250 instances of + # "prototyped function redeclared without prototype" + # and 11 instances of + # "variable ... was set but never used" + # from lib/dns/sec/openssl. + # + IRIX_DNSSEC_WARNINGS_HACK="-woff 1692,1552" + ;; + *-solaris*) + MKDEPCFLAGS="-xM" + ;; + *-sco-sysv*uw*|*-*-sysv*UnixWare*|*-*-sysv*OpenUNIX*) + # UnixWare + CC="$CC -w" + ;; + esac +fi + +AC_SUBST(MKDEPCC) +AC_SUBST(MKDEPCFLAGS) +AC_SUBST(MKDEPPROG) +AC_SUBST(IRIX_DNSSEC_WARNINGS_HACK) + +# +# NLS +# +AC_CHECK_FUNC(catgets, AC_DEFINE(HAVE_CATGETS),) + +# +# -lxnet buys us one big porting headache... standards, gotta love 'em. +# +# AC_CHECK_LIB(xnet, socket, , +# AC_CHECK_LIB(socket, socket) +# AC_CHECK_LIB(nsl, inet_ntoa) +# ) +# +# Use this for now, instead: +# +case "$host" in + mips-sgi-irix*) + ;; + *) + AC_CHECK_LIB(socket, socket) + AC_CHECK_LIB(nsl, inet_ntoa) + ;; +esac + +# +# Purify support +# +AC_MSG_CHECKING(whether to use purify) +AC_ARG_WITH(purify, + [ --with-purify[=PATH] use Rational purify], + use_purify="$withval", use_purify="no") + +case "$use_purify" in + no) + ;; + yes) + AC_PATH_PROG(purify_path, purify, purify) + ;; + *) + purify_path="$use_purify" + ;; +esac + +case "$use_purify" in + no) + AC_MSG_RESULT(no) + PURIFY="" + ;; + *) + if test -f $purify_path || test $purify_path = purify; then + AC_MSG_RESULT($purify_path) + PURIFYFLAGS="`echo $PURIFYOPTIONS`" + PURIFY="$purify_path $PURIFYFLAGS" + else + AC_MSG_ERROR([$purify_path not found. + +Please choose the proper path with the following command: + + configure --with-purify=PATH +]) + fi + ;; +esac + +AC_SUBST(PURIFY) + +# +# GNU libtool support +# +AC_ARG_WITH(libtool, + [ --with-libtool use GNU libtool (following indented options supported)], + use_libtool="$withval", use_libtool="no") + +case $use_libtool in + yes) + AM_PROG_LIBTOOL + O=lo + A=la + LIBTOOL_MKDEP_SED='s;\.o;\.lo;' + LIBTOOL_MODE_COMPILE='--mode=compile' + LIBTOOL_MODE_INSTALL='--mode=install' + LIBTOOL_MODE_LINK='--mode=link' + ;; + *) + O=o + A=a + LIBTOOL= + AC_SUBST(LIBTOOL) + LIBTOOL_MKDEP_SED= + LIBTOOL_MODE_COMPILE= + LIBTOOL_MODE_INSTALL= + LIBTOOL_MODE_LINK= + ;; +esac + +# +# File name extension for static archive files, for those few places +# where they are treated differently from dynamic ones. +# +SA=a + +AC_SUBST(O) +AC_SUBST(A) +AC_SUBST(SA) +AC_SUBST(LIBTOOL_MKDEP_SED) +AC_SUBST(LIBTOOL_MODE_COMPILE) +AC_SUBST(LIBTOOL_MODE_INSTALL) +AC_SUBST(LIBTOOL_MODE_LINK) + +# +# build libbind? +# +AC_ARG_ENABLE(libbind, + [ --enable-libbind build libbind [default=no]]) + +case "$enable_libbind" in + yes) + LIBBIND=lib/bind + AC_SUBST(LIBBIND) + ;; + no|'') + ;; +esac + +# +# Here begins a very long section to determine the system's networking +# capabilities. The order of the tests is signficant. +# + +# +# IPv6 +# +AC_ARG_ENABLE(ipv6, + [ --enable-ipv6 use IPv6 [default=autodetect]]) + +case "$enable_ipv6" in + yes|''|autodetect) + AC_DEFINE(WANT_IPV6) + ;; + no) + ;; +esac + +# +# We do the IPv6 compilation checking after libtool so that we can put +# the right suffix on the files. +# +AC_MSG_CHECKING(for IPv6 structures) +AC_TRY_COMPILE([ +#include +#include +#include ], +[struct sockaddr_in6 sin6; return (0);], + [AC_MSG_RESULT(yes) + found_ipv6=yes], + [AC_MSG_RESULT(no) + found_ipv6=no]) + +# +# See whether IPv6 support is provided via a Kame add-on. +# This is done before other IPv6 linking tests to LIBS is properly set. +# +AC_MSG_CHECKING(for Kame IPv6 support) +AC_ARG_WITH(kame, + [ --with-kame[=PATH] use Kame IPv6 [default path /usr/local/v6]], + use_kame="$withval", use_kame="no") + +case "$use_kame" in + no) + ;; + yes) + kame_path=/usr/local/v6 + ;; + *) + kame_path="$use_kame" + ;; +esac + +case "$use_kame" in + no) + AC_MSG_RESULT(no) + ;; + *) + if test -f $kame_path/lib/libinet6.a; then + AC_MSG_RESULT($kame_path/lib/libinet6.a) + LIBS="-L$kame_path/lib -linet6 $LIBS" + else + AC_MSG_ERROR([$kame_path/lib/libinet6.a not found. + +Please choose the proper path with the following command: + + configure --with-kame=PATH +]) + fi + ;; +esac + +# +# Whether netinet6/in6.h is needed has to be defined in isc/platform.h. +# Including it on Kame-using platforms is very bad, though, because +# Kame uses #error against direct inclusion. So include it on only +# the platform that is otherwise broken without it -- BSD/OS 4.0 through 4.1. +# This is done before the in6_pktinfo check because that's what +# netinet6/in6.h is needed for. +# +changequote({, }) +case "$host" in +*-bsdi4.[01]*) + ISC_PLATFORM_NEEDNETINET6IN6H="#define ISC_PLATFORM_NEEDNETINET6IN6H 1" + LWRES_PLATFORM_NEEDNETINET6IN6H="#define LWRES_PLATFORM_NEEDNETINET6IN6H 1" + isc_netinet6in6_hack="#include " + ;; +*) + ISC_PLATFORM_NEEDNETINET6IN6H="#undef ISC_PLATFORM_NEEDNETINET6IN6H" + LWRES_PLATFORM_NEEDNETINET6IN6H="#undef LWRES_PLATFORM_NEEDNETINET6IN6H" + isc_netinet6in6_hack="" + ;; +esac +changequote([, ]) + +# +# This is similar to the netinet6/in6.h issue. +# +case "$host" in +*-sco-sysv*uw*|*-*-sysv*UnixWare*|*-*-sysv*OpenUNIX*) + # UnixWare + ISC_PLATFORM_NEEDNETINETIN6H="#define ISC_PLATFORM_NEEDNETINETIN6H 1" + LWRES_PLATFORM_NEEDNETINETIN6H="#define LWRES_PLATFORM_NEEDNETINETIN6H 1" + ISC_PLATFORM_FIXIN6ISADDR="#define ISC_PLATFORM_FIXIN6ISADDR 1" + isc_netinetin6_hack="#include " + ;; +*) + ISC_PLATFORM_NEEDNETINETIN6H="#undef ISC_PLATFORM_NEEDNETINETIN6H" + LWRES_PLATFORM_NEEDNETINETIN6H="#undef LWRES_PLATFORM_NEEDNETINETIN6H" + ISC_PLATFORM_FIXIN6ISADDR="#undef ISC_PLATFORM_FIXIN6ISADDR" + isc_netinetin6_hack="" + ;; +esac + +# +# Now delve deeper into the suitability of the IPv6 support. +# +case "$found_ipv6" in + yes) + ISC_PLATFORM_HAVEIPV6="#define ISC_PLATFORM_HAVEIPV6 1" + LWRES_PLATFORM_HAVEIPV6="#define LWRES_PLATFORM_HAVEIPV6 1" + + AC_MSG_CHECKING(for in6_addr) + AC_TRY_COMPILE([ +#include +#include +#include +$isc_netinetin6_hack +$isc_netinet6in6_hack +], +[struct in6_addr in6; return (0);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_HAVEINADDR6="#undef ISC_PLATFORM_HAVEINADDR6" + LWRES_PLATFORM_HAVEINADDR6="#undef LWRES_PLATFORM_HAVEINADDR6" + isc_in_addr6_hack=""], + [AC_MSG_RESULT(no) + ISC_PLATFORM_HAVEINADDR6="#define ISC_PLATFORM_HAVEINADDR6 1" + LWRES_PLATFORM_HAVEINADDR6="#define LWRES_PLATFORM_HAVEINADDR6 1" + isc_in_addr6_hack="#define in6_addr in_addr6"]) + + AC_MSG_CHECKING(for in6addr_any) + AC_TRY_LINK([ +#include +#include +#include +$isc_netinetin6_hack +$isc_netinet6in6_hack +$isc_in_addr6_hack +], + [struct in6_addr in6; in6 = in6addr_any; return (in6.s6_addr[0]);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_NEEDIN6ADDRANY="#undef ISC_PLATFORM_NEEDIN6ADDRANY" + LWRES_PLATFORM_NEEDIN6ADDRANY="#undef LWRES_PLATFORM_NEEDIN6ADDRANY"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_NEEDIN6ADDRANY="#define ISC_PLATFORM_NEEDIN6ADDRANY 1" + LWRES_PLATFORM_NEEDIN6ADDRANY="#define LWRES_PLATFORM_NEEDIN6ADDRANY 1"]) + + AC_MSG_CHECKING(for in6addr_loopback) + AC_TRY_LINK([ +#include +#include +#include +$isc_netinetin6_hack +$isc_netinet6in6_hack +$isc_in_addr6_hack +], + [struct in6_addr in6; in6 = in6addr_loopback; return (in6.s6_addr[0]);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_NEEDIN6ADDRLOOPBACK="#undef ISC_PLATFORM_NEEDIN6ADDRLOOPBACK" + LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK="#undef LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_NEEDIN6ADDRLOOPBACK="#define ISC_PLATFORM_NEEDIN6ADDRLOOPBACK 1" + LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK="#define LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK 1"]) + + AC_MSG_CHECKING(for sin6_scope_id in struct sockaddr_in6) + AC_TRY_COMPILE([ +#include +#include +#include +$isc_netinetin6_hack +$isc_netinet6in6_hack +], + [struct sockaddr_in6 xyzzy; xyzzy.sin6_scope_id = 0; return (0);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_HAVESCOPEID="#define ISC_PLATFORM_HAVESCOPEID 1" + result="#define LWRES_HAVE_SIN6_SCOPE_ID 1"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_HAVESCOPEID="#undef ISC_PLATFORM_HAVESCOPEID" + result="#undef LWRES_HAVE_SIN6_SCOPE_ID"]) + LWRES_HAVE_SIN6_SCOPE_ID="$result" + + AC_MSG_CHECKING(for in6_pktinfo) + AC_TRY_COMPILE([ +#include +#include +#include +$isc_netinetin6_hack +$isc_netinet6in6_hack +], + [struct in6_pktinfo xyzzy; return (0);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_HAVEIN6PKTINFO="#define ISC_PLATFORM_HAVEIN6PKTINFO 1"], + [AC_MSG_RESULT(no -- disabling runtime ipv6 support) + ISC_PLATFORM_HAVEIN6PKTINFO="#undef ISC_PLATFORM_HAVEIN6PKTINFO"]) + ;; + no) + ISC_PLATFORM_HAVEIPV6="#undef ISC_PLATFORM_HAVEIPV6" + LWRES_PLATFORM_HAVEIPV6="#undef LWRES_PLATFORM_HAVEIPV6" + ISC_PLATFORM_NEEDIN6ADDRANY="#undef ISC_PLATFORM_NEEDIN6ADDRANY" + LWRES_PLATFORM_NEEDIN6ADDRANY="#undef LWRES_PLATFORM_NEEDIN6ADDRANY" + ISC_PLATFORM_HAVEIN6PKTINFO="#undef ISC_PLATFORM_HAVEIN6PKTINFO" + LWRES_HAVE_SIN6_SCOPE_ID="#define LWRES_HAVE_SIN6_SCOPE_ID 1" + ISC_PLATFORM_HAVESCOPEID="#define ISC_PLATFORM_HAVESCOPEID 1" + ISC_IPV6_H="ipv6.h" + ISC_IPV6_O="ipv6.$O" + ISC_ISCIPV6_O="unix/ipv6.$O" + ISC_IPV6_C="ipv6.c" + ;; +esac + +AC_SUBST(ISC_PLATFORM_HAVEIPV6) +AC_SUBST(LWRES_PLATFORM_HAVEIPV6) +AC_SUBST(ISC_PLATFORM_NEEDNETINETIN6H) +AC_SUBST(LWRES_PLATFORM_NEEDNETINETIN6H) +AC_SUBST(ISC_PLATFORM_NEEDNETINET6IN6H) +AC_SUBST(LWRES_PLATFORM_NEEDNETINET6IN6H) +AC_SUBST(ISC_PLATFORM_HAVEINADDR6) +AC_SUBST(LWRES_PLATFORM_HAVEINADDR6) +AC_SUBST(ISC_PLATFORM_NEEDIN6ADDRANY) +AC_SUBST(LWRES_PLATFORM_NEEDIN6ADDRANY) +AC_SUBST(ISC_PLATFORM_NEEDIN6ADDRLOOPBACK) +AC_SUBST(LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK) +AC_SUBST(ISC_PLATFORM_HAVEIN6PKTINFO) +AC_SUBST(ISC_PLATFORM_FIXIN6ISADDR) +AC_SUBST(ISC_IPV6_H) +AC_SUBST(ISC_IPV6_O) +AC_SUBST(ISC_ISCIPV6_O) +AC_SUBST(ISC_IPV6_C) +AC_SUBST(LWRES_HAVE_SIN6_SCOPE_ID) +AC_SUBST(ISC_PLATFORM_HAVESCOPEID) + +AC_MSG_CHECKING([for struct if_laddrreq]) +AC_TRY_LINK([ +#include +#include +],[ struct if_laddrreq a; ], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_HAVEIF_LADDRREQ="#define ISC_PLATFORM_HAVEIF_LADDRREQ 1"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_HAVEIF_LADDRREQ="#undef ISC_PLATFORM_HAVEIF_LADDRREQ"]) +AC_SUBST(ISC_PLATFORM_HAVEIF_LADDRREQ) + +AC_MSG_CHECKING([for struct if_laddrconf]) +AC_TRY_LINK([ +#include +#include +],[ struct if_laddrconf a; ], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_HAVEIF_LADDRCONF="#define ISC_PLATFORM_HAVEIF_LADDRCONF 1"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_HAVEIF_LADDRCONF="#undef ISC_PLATFORM_HAVEIF_LADDRCONF"]) +AC_SUBST(ISC_PLATFORM_HAVEIF_LADDRCONF) + +# +# Check for network functions that are often missing. We do this +# after the libtool checking, so we can put the right suffix on +# the files. It also needs to come after checking for a Kame add-on, +# which provides some (all?) of the desired functions. +# + +AC_MSG_CHECKING([for inet_ntop with IPv6 support]) +AC_TRY_RUN([ +#include +#include +#include +#include +main() { +char a[16],b[64]; return(inet_ntop(AF_INET6, a, b, sizeof(b)) == (char*)0);}], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_NEEDNTOP="#undef ISC_PLATFORM_NEEDNTOP"], + + [AC_MSG_RESULT(no) + ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_ntop.$O" + ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_ntop.c" + ISC_PLATFORM_NEEDNTOP="#define ISC_PLATFORM_NEEDNTOP 1"]) + + +# On NetBSD 1.4.2 and maybe others, inet_pton() incorrectly accepts +# addresses with less than four octets, like "1.2.3". Also leading +# zeros should also be rejected. + +AC_MSG_CHECKING([for working inet_pton with IPv6 support]) +AC_TRY_RUN([ +#include +#include +#include +#include +main() { char a[16]; return (inet_pton(AF_INET, "1.2.3", a) == 1 ? 1 : + inet_pton(AF_INET, "1.2.3.04", a) == 1 ? 1 : + (inet_pton(AF_INET6, "::1.2.3.4", a) != 1)); }], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"], + [AC_MSG_RESULT(no) + ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_pton.$O" + ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_pton.c" + ISC_PLATFORM_NEEDPTON="#define ISC_PLATFORM_NEEDPTON 1"], + [AC_MSG_RESULT(assuming target platform has working inet_pton) + ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"]) + +AC_MSG_CHECKING([for inet_aton]) +AC_TRY_LINK([ +#include +#include +#include ], + [struct in_addr in; inet_aton(0, &in); return (0);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_NEEDATON="#undef ISC_PLATFORM_NEEDATON"], + + [AC_MSG_RESULT(no) + ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_aton.$O" + ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_aton.c" + ISC_PLATFORM_NEEDATON="#define ISC_PLATFORM_NEEDATON 1"]) + +AC_SUBST(ISC_PLATFORM_NEEDNTOP) +AC_SUBST(ISC_PLATFORM_NEEDPTON) +AC_SUBST(ISC_PLATFORM_NEEDATON) + +# +# Look for a 4.4BSD-style sa_len member in struct sockaddr. +# +case "$host" in + *-dec-osf*) + # Turn on 4.4BSD style sa_len support. + AC_DEFINE(_SOCKADDR_LEN) + ;; +esac + +AC_MSG_CHECKING(for sa_len in struct sockaddr) +AC_TRY_COMPILE([ +#include +#include ], +[struct sockaddr sa; sa.sa_len = 0; return (0);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_HAVESALEN="#define ISC_PLATFORM_HAVESALEN 1" + LWRES_PLATFORM_HAVESALEN="#define LWRES_PLATFORM_HAVESALEN 1"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_HAVESALEN="#undef ISC_PLATFORM_HAVESALEN" + LWRES_PLATFORM_HAVESALEN="#undef LWRES_PLATFORM_HAVESALEN"]) +AC_SUBST(ISC_PLATFORM_HAVESALEN) +AC_SUBST(LWRES_PLATFORM_HAVESALEN) + +# +# Look for a 4.4BSD or 4.3BSD struct msghdr +# +AC_MSG_CHECKING(for struct msghdr flavor) +AC_TRY_COMPILE([ +#include +#include ], +[struct msghdr msg; msg.msg_flags = 0; return (0);], + [AC_MSG_RESULT(4.4BSD) + ISC_PLATFORM_MSGHDRFLAVOR="#define ISC_NET_BSD44MSGHDR 1"], + [AC_MSG_RESULT(4.3BSD) + ISC_PLATFORM_MSGHDRFLAVOR="#define ISC_NET_BSD43MSGHDR 1"]) +AC_SUBST(ISC_PLATFORM_MSGHDRFLAVOR) + +# +# Look for in_port_t. +# +AC_MSG_CHECKING(for type in_port_t) +AC_TRY_COMPILE([ +#include +#include ], +[in_port_t port = 25; return (0);], + [AC_MSG_RESULT(yes) + ISC_PLATFORM_NEEDPORTT="#undef ISC_PLATFORM_NEEDPORTT"], + [AC_MSG_RESULT(no) + ISC_PLATFORM_NEEDPORTT="#define ISC_PLATFORM_NEEDPORTT 1"]) +AC_SUBST(ISC_PLATFORM_NEEDPORTT) + +# +# Check for addrinfo +# +AC_MSG_CHECKING(for struct addrinfo) +AC_TRY_COMPILE([ +#include ], +[struct addrinfo a; return (0);], + [AC_MSG_RESULT(yes) + ISC_LWRES_NEEDADDRINFO="#undef ISC_LWRES_NEEDADDRINFO" + AC_DEFINE(HAVE_ADDRINFO)], + [AC_MSG_RESULT(no) + ISC_LWRES_NEEDADDRINFO="#define ISC_LWRES_NEEDADDRINFO 1"]) +AC_SUBST(ISC_LWRES_NEEDADDRINFO) + +# +# Check for rrsetinfo +# +AC_MSG_CHECKING(for struct rrsetinfo) +AC_TRY_COMPILE([ +#include ], +[struct rrsetinfo r; return (0);], + [AC_MSG_RESULT(yes) + ISC_LWRES_NEEDRRSETINFO="#undef ISC_LWRES_NEEDRRSETINFO"], + [AC_MSG_RESULT(no) + ISC_LWRES_NEEDRRSETINFO="#define ISC_LWRES_NEEDRRSETINFO 1"]) +AC_SUBST(ISC_LWRES_NEEDRRSETINFO) + +AC_MSG_CHECKING(for int sethostent) +AC_TRY_COMPILE([ +#include ], +[int i = sethostent(0); return(0);], + [AC_MSG_RESULT(yes) + ISC_LWRES_SETHOSTENTINT="#define ISC_LWRES_SETHOSTENTINT 1"], + [AC_MSG_RESULT(no) + ISC_LWRES_SETHOSTENTINT="#undef ISC_LWRES_SETHOSTENTINT"]) +AC_SUBST(ISC_LWRES_SETHOSTENTINT) + +AC_MSG_CHECKING(for int endhostent) +AC_TRY_COMPILE([ +#include ], +[int i = endhostent(); return(0);], + [AC_MSG_RESULT(yes) + ISC_LWRES_ENDHOSTENTINT="#define ISC_LWRES_ENDHOSTENTINT 1"], + [AC_MSG_RESULT(no) + ISC_LWRES_ENDHOSTENTINT="#undef ISC_LWRES_ENDHOSTENTINT"]) +AC_SUBST(ISC_LWRES_ENDHOSTENTINT) + +AC_MSG_CHECKING(for getnetbyaddr(in_addr_t, ...)) +AC_TRY_COMPILE([ +#include +struct netent *getnetbyaddr(in_addr_t, int);], +[], + [AC_MSG_RESULT(yes) + ISC_LWRES_GETNETBYADDRINADDR="#define ISC_LWRES_GETNETBYADDRINADDR 1"], + [AC_MSG_RESULT(no) + ISC_LWRES_GETNETBYADDRINADDR="#undef ISC_LWRES_GETNETBYADDRINADDR"]) +AC_SUBST(ISC_LWRES_GETNETBYADDRINADDR) + +AC_MSG_CHECKING(for int setnetent) +AC_TRY_COMPILE([ +#include ], +[int i = setnetent(0); return(0);], + [AC_MSG_RESULT(yes) + ISC_LWRES_SETNETENTINT="#define ISC_LWRES_SETNETENTINT 1"], + [AC_MSG_RESULT(no) + ISC_LWRES_SETNETENTINT="#undef ISC_LWRES_SETNETENTINT"]) +AC_SUBST(ISC_LWRES_SETNETENTINT) + +AC_MSG_CHECKING(for int endnetent) +AC_TRY_COMPILE([ +#include ], +[int i = endnetent(); return(0);], + [AC_MSG_RESULT(yes) + ISC_LWRES_ENDNETENTINT="#define ISC_LWRES_ENDNETENTINT 1"], + [AC_MSG_RESULT(no) + ISC_LWRES_ENDNETENTINT="#undef ISC_LWRES_ENDNETENTINT"]) +AC_SUBST(ISC_LWRES_ENDNETENTINT) + +AC_MSG_CHECKING(for gethostbyaddr(const void *, size_t, ...)) +AC_TRY_COMPILE([ +#include +struct hostent *gethostbyaddr(const void *, size_t, int);], +[return(0);], + [AC_MSG_RESULT(yes) + ISC_LWRES_GETHOSTBYADDRVOID="#define ISC_LWRES_GETHOSTBYADDRVOID 1"], + [AC_MSG_RESULT(no) + ISC_LWRES_GETHOSTBYADDRVOID="#undef ISC_LWRES_GETHOSTBYADDRVOID"]) +AC_SUBST(ISC_LWRES_GETHOSTBYADDRVOID) + +AC_MSG_CHECKING(for h_errno in netdb.h) +AC_TRY_COMPILE([ +#include ], +[h_errno = 1; return(0);], + [AC_MSG_RESULT(yes) + ISC_LWRES_NEEDHERRNO="#undef ISC_LWRES_NEEDHERRNO"], + [AC_MSG_RESULT(no) + ISC_LWRES_NEEDHERRNO="#define ISC_LWRES_NEEDHERRNO 1"]) +AC_SUBST(ISC_LWRES_NEEDHERRNO) + +AC_CHECK_FUNC(getipnodebyname, + [ISC_LWRES_GETIPNODEPROTO="#undef ISC_LWRES_GETIPNODEPROTO"], + [ISC_LWRES_GETIPNODEPROTO="#define ISC_LWRES_GETIPNODEPROTO 1"]) +AC_CHECK_FUNC(getnameinfo, + [ISC_LWRES_GETNAMEINFOPROTO="#undef ISC_LWRES_GETNAMEINFOPROTO"], + [ISC_LWRES_GETNAMEINFOPROTO="#define ISC_LWRES_GETNAMEINFOPROTO 1"]) +AC_CHECK_FUNC(getaddrinfo, + [ISC_LWRES_GETADDRINFOPROTO="#undef ISC_LWRES_GETADDRINFOPROTO" + AC_DEFINE(HAVE_GETADDRINFO)], + [ISC_LWRES_GETADDRINFOPROTO="#define ISC_LWRES_GETADDRINFOPROTO 1"]) +AC_CHECK_FUNC(gai_strerror, AC_DEFINE(HAVE_GAISTRERROR)) +AC_SUBST(ISC_LWRES_GETIPNODEPROTO) +AC_SUBST(ISC_LWRES_GETADDRINFOPROTO) +AC_SUBST(ISC_LWRES_GETNAMEINFOPROTO) + +AC_ARG_ENABLE(getifaddrs, +[ --enable-getifaddrs Enable the use of getifaddrs() [[yes|no|glibc]]. + glibc: Use getifaddrs() in glibc if you know it supports IPv6.], + want_getifaddrs="$enableval", want_getifaddrs="yes") + +case $want_getifaddrs in +yes|glibc) +# +# Do we have getifaddrs() ? +# +case $host in +*-linux*) + # Some recent versions of glibc support getifaddrs() which does not + # provide AF_INET6 addresses while the function provided by the USAGI + # project handles the AF_INET6 case correctly. We need to avoid + # using the former but prefer the latter unless overridden by + # --enable-getifaddrs=glibc. + if test $use_getifaddrs = glibc + then + AC_CHECK_FUNC(getifaddrs, AC_DEFINE(HAVE_GETIFADDRS)) + else + save_LIBS="$LIBS" + LIBS="-L/usr/local/v6/lib $LIBS" + AC_CHECK_LIB(inet6, getifaddrs, + LIBS="$LIBS -linet6" + AC_DEFINE(HAVE_GETIFADDRS), + LIBS=${save_LIBS}) + fi + ;; +*) + AC_CHECK_FUNC(getifaddrs, AC_DEFINE(HAVE_GETIFADDRS)) + ;; +esac +;; +no) +;; +esac + +# +# Look for a sysctl call to get the list of network interfaces. +# +case $ac_cv_header_sys_sysctl_h in +yes) +AC_MSG_CHECKING(for interface list sysctl) +AC_EGREP_CPP(found_rt_iflist, [ +#include +#include +#include +#ifdef NET_RT_IFLIST +found_rt_iflist +#endif +], + [AC_MSG_RESULT(yes) + AC_DEFINE(HAVE_IFLIST_SYSCTL)], + [AC_MSG_RESULT(no)]) +;; +esac + +# +# Check for some other useful functions that are not ever-present. +# + +# We test for strsep() using AC_TRY_LINK instead of AC_CHECK_FUNC +# because AIX 4.3.3 with patches for bos.adt.include to version 4.3.3.77 +# reportedly defines strsep() without declaring it in when +# -D_LINUX_SOURCE_COMPAT is not defined [RT #2190], and +# AC_CHECK_FUNC() incorrectly succeeds because it declares +# the function itself. +AC_MSG_CHECKING(for correctly declared strsep()) +AC_TRY_LINK([#include ], [char *sp; char *foo = strsep(&sp, ".");], + [AC_MSG_RESULT(yes); ISC_PLATFORM_NEEDSTRSEP="#undef ISC_PLATFORM_NEEDSTRSEP"], + [AC_MSG_RESULT(no); ISC_PLATFORM_NEEDSTRSEP="#define ISC_PLATFORM_NEEDSTRSEP 1"]) +AC_SUBST(ISC_PLATFORM_NEEDSTRSEP) + +AC_CHECK_FUNC(memmove, + [ISC_PLATFORM_NEEDMEMMOVE="#undef ISC_PLATFORM_NEEDMEMMOVE"], + [ISC_PLATFORM_NEEDMEMMOVE="#define ISC_PLATFORM_NEEDMEMMOVE 1"]) +AC_SUBST(ISC_PLATFORM_NEEDMEMMOVE) + +AC_CHECK_FUNC(strtoul, + [ISC_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL"], + [ISC_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1"]) +AC_SUBST(ISC_PLATFORM_NEEDSTRTOUL) + +AC_CHECK_FUNC(strlcpy, + [ISC_PLATFORM_NEEDSTRLCPY="#undef ISC_PLATFORM_NEEDSTRLCPY"], + [ISC_PLATFORM_NEEDSTRLCPY="#define ISC_PLATFORM_NEEDSTRLCPY 1"]) +AC_SUBST(ISC_PLATFORM_NEEDSTRLCPY) + +AC_CHECK_FUNC(strlcat, + [ISC_PLATFORM_NEEDSTRLCAT="#undef ISC_PLATFORM_NEEDSTRLCAT"], + [ISC_PLATFORM_NEEDSTRLCAT="#define ISC_PLATFORM_NEEDSTRLCAT 1"]) +AC_SUBST(ISC_PLATFORM_NEEDSTRLCAT) + +ISC_PRINT_OBJS= +ISC_PRINT_SRCS= +AC_MSG_CHECKING(sprintf) +AC_TRY_COMPILE([ +#include +], +[ char buf[2]; return(*sprintf(buf,"x"));], +[ +ISC_PRINT_OBJS="print.$O" +ISC_PRINT_SRCS="print.c" +ISC_PLATFORM_NEEDSPRINTF="#define ISC_PLATFORM_NEEDSPRINTF" +LWRES_PLATFORM_NEEDSPRINTF="#define LWRES_PLATFORM_NEEDSPRINTF" +], +[ISC_PLATFORM_NEEDSPRINTF="#undef ISC_PLATFORM_NEEDSPRINTF" + LWRES_PLATFORM_NEEDSPRINTF="#undef LWRES_PLATFORM_NEEDSPRINTF"] +) +AC_SUBST(ISC_PLATFORM_NEEDSPRINTF) +AC_SUBST(LWRES_PLATFORM_NEEDSPRINTF) + +AC_CHECK_FUNC(vsnprintf, + [ISC_PLATFORM_NEEDVSNPRINTF="#undef ISC_PLATFORM_NEEDVSNPRINTF" + LWRES_PLATFORM_NEEDVSNPRINTF="#undef LWRES_PLATFORM_NEEDVSNPRINTF"], + [ISC_PRINT_OBJS="print.$O" + ISC_PRINT_SRCS="print.c" + ISC_PLATFORM_NEEDVSNPRINTF="#define ISC_PLATFORM_NEEDVSNPRINTF 1" + LWRES_PLATFORM_NEEDVSNPRINTF="#define LWRES_PLATFORM_NEEDVSNPRINTF 1"]) +AC_SUBST(ISC_PLATFORM_NEEDVSNPRINTF) +AC_SUBST(LWRES_PLATFORM_NEEDVSNPRINTF) +ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS $ISC_PRINT_OBJS" +ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS $ISC_PRINT_SRCS" + +AC_CHECK_FUNC(strerror, AC_DEFINE(HAVE_STRERROR)) + +AC_SUBST(ISC_EXTRA_OBJS) +AC_SUBST(ISC_EXTRA_SRCS) + +# Determine the printf format characters to use when printing +# values of type isc_int64_t. This will normally be "ll", but where +# the compiler treats "long long" as a alias for "long" and printf +# doesn't know about "long long" use "l". Hopefully the sprintf +# will produce a inconsistant result in the later case. If the compiler +# fails due to seeing "%lld" we fall back to "l". +# +# Win32 uses "%I64d", but that's defined elsewhere since we don't use +# configure on Win32. +# +AC_MSG_CHECKING(printf format modifier for 64-bit integers) +AC_TRY_RUN([ +#include +main() { + long long int j = 0; + char buf[100]; + buf[0] = 0; + sprintf(buf, "%lld", j); + exit((sizeof(long long int) != sizeof(long int))? 0 : + (strcmp(buf, "0") != 0)); +} +], + [AC_MSG_RESULT(ll) + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'], + [AC_MSG_RESULT(l) + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'], + [AC_MSG_RESULT(assuming target platform uses ll) + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"']) +AC_SUBST(ISC_PLATFORM_QUADFORMAT) + +# +# Security Stuff +# +AC_CHECK_FUNC(chroot, AC_DEFINE(HAVE_CHROOT)) +AC_ARG_ENABLE(linux-caps, + [ --disable-linux-caps disable linux capabilities]) +case "$enable_linux_caps" in + yes|'') + AC_CHECK_HEADERS(linux/capability.h) + ;; + no) + ;; +esac +AC_CHECK_HEADERS(sys/prctl.h) + +# +# Time Zone Stuff +# +AC_CHECK_FUNC(tzset, AC_DEFINE(HAVE_TZSET)) + +# +# BSD/OS, and perhaps some others, don't define rlim_t. +# +AC_MSG_CHECKING(for type rlim_t) +AC_TRY_COMPILE([ +#include +#include +#include ], +[rlim_t rl = 19671212; return (0);], +[AC_MSG_RESULT(yes) + ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE rlim_t"], +[AC_MSG_RESULT(no) + +AC_MSG_CHECKING(type of rlim_cur) +AC_TRY_RUN([ +#include +#include +#include +main() { struct rlimit r; exit(!(sizeof(r.rlim_cur) == sizeof(int)));}], +[AC_MSG_RESULT(int) +ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE int"], +[ +AC_TRY_RUN([ +#include +#include +#include +main() { struct rlimit r; exit(!(sizeof(r.rlim_cur) == sizeof(long int)));}], +[AC_MSG_RESULT(long int) +ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE long int"], +[ +AC_TRY_RUN([ +#include +#include +#include +main() { struct rlimit r; exit((!sizeof(r.rlim_cur) == sizeof(long long int)));}], +[AC_MSG_RESULT(long long int) +ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE long long int"], +[AC_MSG_ERROR([unable to determine sizeof rlim_cur]) +],[AC_MSG_ERROR(this cannot happen)]) +],[AC_MSG_ERROR(this cannot happen)]) +],[AC_MSG_ERROR(cannot determine type of rlim_cur when cross compiling - define rlim_t)]) +]) +AC_SUBST(ISC_PLATFORM_RLIMITTYPE) + +# +# Compaq TruCluster requires more code for handling cluster IP aliases +# +case "$host" in + *-dec-osf*) + AC_CHECK_LIB(clua, clua_getaliasaddress, LIBS="-lclua $LIBS") + AC_CHECK_FUNC(clua_getaliasaddress, + AC_DEFINE(HAVE_TRUCLUSTER, 1, + [Define if running under Compaq TruCluster])) + ;; + *) + ;; +esac + +# +# Microsoft has their own way of handling shared libraries that requires +# additional qualifiers on extern variables. Unix systems don't need it. +# +AC_SUBST(ISC_PLATFORM_USEDECLSPEC) +ISC_PLATFORM_USEDECLSPEC="#undef ISC_PLATFORM_USEDECLSPEC" +AC_SUBST(LWRES_PLATFORM_USEDECLSPEC) +LWRES_PLATFORM_USEDECLSPEC="#undef LWRES_PLATFORM_USEDECLSPEC" + +# +# Random remaining OS-specific issues involving compiler warnings. +# XXXDCL print messages to indicate some compensation is being done? +# +AC_SUBST(ISC_PLATFORM_BRACEPTHREADONCEINIT) +ISC_PLATFORM_BRACEPTHREADONCEINIT="#undef ISC_PLATFORM_BRACEPTHREADONCEINIT" + +case "$host" in + *-bsdi3.1*) + hack_shutup_sputaux=yes + ;; + *-bsdi4.0*) + hack_shutup_sigwait=yes + hack_shutup_sputaux=yes + ;; + [*-bsdi4.[12]*]) + hack_shutup_stdargcast=yes + ;; + [*-solaris2.[89]]) + hack_shutup_pthreadonceinit=yes + ;; +esac + +case "$hack_shutup_pthreadonceinit" in + yes) + # + # Shut up PTHREAD_ONCE_INIT unbraced initializer warnings. + # + ISC_PLATFORM_BRACEPTHREADONCEINIT="#define ISC_PLATFORM_BRACEPTHREADONCEINIT 1" + ;; +esac + +case "$hack_shutup_sigwait" in + yes) + # + # Shut up a -Wmissing-prototypes warning for sigwait(). + # + AC_DEFINE(SHUTUP_SIGWAIT) + ;; +esac + +case "$hack_shutup_sputaux" in + yes) + # + # Shut up a -Wmissing-prototypes warning from . + # + AC_DEFINE(SHUTUP_SPUTAUX) + ;; +esac + +case "$hack_shutup_stdargcast" in + yes) + # + # Shut up a -Wcast-qual warning from va_start(). + # + AC_DEFINE(SHUTUP_STDARG_CAST) + ;; +esac + +# +# Check for if_nametoindex() for IPv6 scoped addresses support +# +AC_CHECK_FUNC(if_nametoindex, ac_cv_have_if_nametoindex=yes, + ac_cv_have_if_nametoindex=no) +case $ac_cv_have_if_nametoindex in +no) + case "$host" in + *-hp-hpux*) + AC_CHECK_LIB(ipv6, if_nametoindex, + ac_cv_have_if_nametoindex=yes + LIBS="-lipv6 $LIBS",) + ;; + esac +esac +case $ac_cv_have_if_nametoindex in +yes) + ISC_PLATFORM_HAVEIFNAMETOINDEX="#define ISC_PLATFORM_HAVEIFNAMETOINDEX 1" + ;; +*) + ISC_PLATFORM_HAVEIFNAMETOINDEX="#undef ISC_PLATFORM_HAVEIFNAMETOINDEX" + ;; +esac +AC_SUBST(ISC_PLATFORM_HAVEIFNAMETOINDEX) + +# +# The following sections deal with tools used for formatting +# the documentation. They are all optional, unless you are +# a developer editing the documentation source. +# + +# Directory trees where SGML files are commonly found. +sgmltrees="/usr/pkg/share/sgml /usr/local/share/sgml /usr/share/sgml" + +# +# Look for openjade. Plain jade is no longer supported. +# + +AC_PATH_PROGS(OPENJADE, openjade, openjade) +AC_SUBST(OPENJADE) + +# +# Look for TeX. +# + +AC_PATH_PROGS(JADETEX, jadetex, jadetex) +AC_SUBST(JADETEX) + +AC_PATH_PROGS(PDFJADETEX, pdfjadetex, pdfjadetex) +AC_SUBST(PDFJADETEX) + +# +# Subroutine for searching for an ordinary file (e.g., a stylesheet) +# in a number of directories: +# +# NOM_PATH_FILE(VARIABLE, FILENAME, DIRECTORIES) +# +# If the file FILENAME is found in one of the DIRECTORIES, the shell +# variable VARIABLE is defined to its absolute pathname. Otherwise, +# it is set to FILENAME, with no directory prefix (that's not terribly +# useful, but looks less confusing in substitutions than leaving it +# empty). The variable VARIABLE will be substituted into output files. +# + +AC_DEFUN(NOM_PATH_FILE, [ +$1="" +AC_MSG_CHECKING(for $2) +for d in $3 +do + f=$d/$2 + if test -f $f + then + $1=$f + AC_MSG_RESULT($f) + break + fi +done +if test "X[$]$1" = "X" +then + AC_MSG_RESULT("not found"); + $1=$2 +fi +AC_SUBST($1) +]) + +# +# Look for the SGML catalog. +# Its location varies, so far we have seen: +# +# NetBSD /usr/pkg/share/sgml/docbook/catalog +# FreeBSD /usr/local/share/sgml/docbook/catalog +# Linux /usr/local/share/dsssl/docbook/catalog +# /usr/share/sgml/docbook/dsssl-stylesheets/catalog +# +catalogpath="" +for d in $sgmltrees +do + catalogpath="$catalogpath $d" + for s in docbook/dsssl-stylesheets + do + catalogpath="$catalogpath $d/$s" + done +done +NOM_PATH_FILE(SGMLCATALOG, catalog, $catalogpath) + +# +# Look for the HTML stylesheet html/docbook.dsl, used for +# formatting man pages in HTML. Its location varies, +# so far we have seen: +# +# NetBSD /usr/pkg/share/sgml/docbook/dsssl/modular/ +# FreeBSD /usr/local/share/sgml/docbook/dsssl/modular/ +# Linux /usr/local/share/dsssl/docbook/ +# /usr/share/sgml/docbook/dsssl-stylesheets/ +# +# Ditto for the print stylesheet print/docbook.dsl. +# + +stylepath="" +for d in $sgmltrees +do + for s in docbook/dsssl/modular dsssl/docbook docbook/dsssl-stylesheets + do + stylepath="$stylepath $d/$s" + done +done +NOM_PATH_FILE(HTMLSTYLE, html/docbook.dsl, $stylepath) +NOM_PATH_FILE(PRINTSTYLE, print/docbook.dsl, $stylepath) + +# +# Look for XML declarations. +# Its location varies, so far we have seen: +# +# NetBSD /usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/ +# FreeBSD /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/ +# Linux /usr/local/share/dsssl/docbook/dtds/decls/ +# /usr/share/sgml/docbook/dsssl-stylesheets/dtds/decls/ +# + +xmlpath="" +for d in $sgmltrees +do + for s in docbook/dsssl/modular dsssl/docbook docbook/dsssl-stylesheets + do + xmlpath="$xmlpath $d/$s" + done +done +NOM_PATH_FILE(XMLDCL, dtds/decls/xml.dcl, $xmlpath) + +# +# Look for docbook2man-spec.pl +# + +NOM_PATH_FILE(DOCBOOK2MANSPEC, docbook2X/docbook2man-spec.pl, $sgmltrees) + +# +# Substitutions +# +AC_SUBST(BIND9_TOP_BUILDDIR) +BIND9_TOP_BUILDDIR=`pwd` + +AC_SUBST(BIND9_ISC_BUILDINCLUDE) +AC_SUBST(BIND9_ISCCC_BUILDINCLUDE) +AC_SUBST(BIND9_ISCCFG_BUILDINCLUDE) +AC_SUBST(BIND9_DNS_BUILDINCLUDE) +AC_SUBST(BIND9_LWRES_BUILDINCLUDE) +AC_SUBST(BIND9_BIND9_BUILDINCLUDE) +if test "X$srcdir" != "X"; then + BIND9_ISC_BUILDINCLUDE="-I${BIND9_TOP_BUILDDIR}/lib/isc/include" + BIND9_ISCCC_BUILDINCLUDE="-I${BIND9_TOP_BUILDDIR}/lib/isccc/include" + BIND9_ISCCFG_BUILDINCLUDE="-I${BIND9_TOP_BUILDDIR}/lib/isccfg/include" + BIND9_DNS_BUILDINCLUDE="-I${BIND9_TOP_BUILDDIR}/lib/dns/include" + BIND9_LWRES_BUILDINCLUDE="-I${BIND9_TOP_BUILDDIR}/lib/lwres/include" + BIND9_BIND9_BUILDINCLUDE="-I${BIND9_TOP_BUILDDIR}/lib/bind9/include" +else + BIND9_ISC_BUILDINCLUDE="" + BIND9_ISCCC_BUILDINCLUDE="" + BIND9_ISCCFG_BUILDINCLUDE="" + BIND9_DNS_BUILDINCLUDE="" + BIND9_LWRES_BUILDINCLUDE="" + BIND9_BIND9_BUILDINCLUDE="" +fi + +AC_SUBST_FILE(BIND9_MAKE_INCLUDES) +BIND9_MAKE_INCLUDES=$BIND9_TOP_BUILDDIR/make/includes + +AC_SUBST_FILE(BIND9_MAKE_RULES) +BIND9_MAKE_RULES=$BIND9_TOP_BUILDDIR/make/rules + +. $srcdir/version +BIND9_VERSION="VERSION=${MAJORVER}.${MINORVER}.${PATCHVER}${RELEASETYPE}${RELEASEVER}" +AC_SUBST(BIND9_VERSION) + +AC_SUBST_FILE(LIBISC_API) +LIBISC_API=$srcdir/lib/isc/api + +AC_SUBST_FILE(LIBISCCC_API) +LIBISCCC_API=$srcdir/lib/isccc/api + +AC_SUBST_FILE(LIBISCCFG_API) +LIBISCCFG_API=$srcdir/lib/isccfg/api + +AC_SUBST_FILE(LIBDNS_API) +LIBDNS_API=$srcdir/lib/dns/api + +AC_SUBST_FILE(LIBBIND9_API) +LIBBIND9_API=$srcdir/lib/bind9/api + +AC_SUBST_FILE(LIBLWRES_API) +LIBLWRES_API=$srcdir/lib/lwres/api + +AC_OUTPUT( + make/rules + make/includes + Makefile + make/Makefile + make/mkdep + lib/Makefile + lib/isc/Makefile + lib/isc/include/Makefile + lib/isc/include/isc/Makefile + lib/isc/include/isc/platform.h + lib/isc/unix/Makefile + lib/isc/unix/include/Makefile + lib/isc/unix/include/isc/Makefile + lib/isc/nls/Makefile + lib/isc/$thread_dir/Makefile + lib/isc/$thread_dir/include/Makefile + lib/isc/$thread_dir/include/isc/Makefile + lib/isccc/Makefile + lib/isccc/include/Makefile + lib/isccc/include/isccc/Makefile + lib/isccfg/Makefile + lib/isccfg/include/Makefile + lib/isccfg/include/isccfg/Makefile + lib/dns/Makefile + lib/dns/include/Makefile + lib/dns/include/dns/Makefile + lib/dns/sec/Makefile + lib/dns/sec/dst/Makefile + lib/dns/sec/dst/include/Makefile + lib/dns/sec/dst/include/dst/Makefile + lib/bind9/Makefile + lib/bind9/include/Makefile + lib/bind9/include/bind9/Makefile + lib/lwres/Makefile + lib/lwres/include/Makefile + lib/lwres/include/lwres/Makefile + lib/lwres/include/lwres/netdb.h + lib/lwres/include/lwres/platform.h + lib/lwres/man/Makefile + lib/lwres/unix/Makefile + lib/lwres/unix/include/Makefile + lib/lwres/unix/include/lwres/Makefile + lib/tests/Makefile + lib/tests/include/Makefile + lib/tests/include/tests/Makefile + bin/Makefile + bin/check/Makefile + bin/named/Makefile + bin/named/unix/Makefile + bin/rndc/Makefile + bin/rndc/unix/Makefile + bin/dig/Makefile + bin/nsupdate/Makefile + bin/tests/Makefile + bin/tests/names/Makefile + bin/tests/master/Makefile + bin/tests/rbt/Makefile + bin/tests/db/Makefile + bin/tests/tasks/Makefile + bin/tests/timers/Makefile + bin/tests/dst/Makefile + bin/tests/mem/Makefile + bin/tests/net/Makefile + bin/tests/sockaddr/Makefile + bin/tests/system/Makefile + bin/tests/system/conf.sh + bin/tests/system/lwresd/Makefile + bin/tests/system/tkey/Makefile + bin/tests/headerdep_test.sh + bin/dnssec/Makefile + doc/Makefile + doc/arm/Makefile + doc/arm/nominum-docbook-html.dsl + doc/arm/nominum-docbook-print.dsl + doc/arm/validate.sh + doc/misc/Makefile + docutil/docbook2man-wrapper.sh + isc-config.sh +) +chmod a+x isc-config.sh + +# Tell Emacs to edit this file in shell mode. +# Local Variables: +# mode: sh +# End: diff --git a/contrib/bind9/doc/Makefile.in b/contrib/bind9/doc/Makefile.in new file mode 100644 index 000000000000..e7dd9ca35ef3 --- /dev/null +++ b/contrib/bind9/doc/Makefile.in @@ -0,0 +1,29 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000, 2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.4.206.1 2004/03/06 13:16:14 marka Exp $ + +# This Makefile is a placeholder. It exists merely to make +# sure that its directory gets created in the object directory +# tree when doing a build using separate object directories. + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +SUBDIRS = arm misc +TARGETS = + +@BIND9_MAKE_RULES@ diff --git a/contrib/bind9/doc/arm/Bv9ARM-book.xml b/contrib/bind9/doc/arm/Bv9ARM-book.xml new file mode 100644 index 000000000000..2a03a9ed026d --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM-book.xml @@ -0,0 +1,6571 @@ + + + + + + +BIND 9 Administrator Reference Manual + + + +2004 +Internet Systems Consortium, Inc. ("ISC") + + +2000-2003 +Internet Software Consortium + + + + + Introduction + The Internet Domain Name System (DNS) consists of the syntax + to specify the names of entities in the Internet in a hierarchical + manner, the rules used for delegating authority over names, and the + system implementation that actually maps names to Internet + addresses. DNS data is maintained in a group of distributed + hierarchical databases. + + + Scope of Document + + The Berkeley Internet Name Domain (BIND) implements an + domain name server for a number of operating systems. This + document provides basic information about the installation and + care of the Internet Software Consortium (ISC) + BIND version 9 software package for system + administrators. + + This version of the manual corresponds to BIND version 9.3. + + + Organization of This Document + In this document, Section 1 introduces + the basic DNS and BIND concepts. Section 2 + describes resource requirements for running BIND in various + environments. Information in Section 3 is + task-oriented in its presentation and is + organized functionally, to aid in the process of installing the + BIND 9 software. The task-oriented section is followed by + Section 4, which contains more advanced + concepts that the system administrator may need for implementing + certain options. Section 5 + describes the BIND 9 lightweight + resolver. The contents of Section 6 are + organized as in a reference manual to aid in the ongoing + maintenance of the software. Section 7 + addresses security considerations, and + Section 8 contains troubleshooting help. The + main body of the document is followed by several + Appendices which contain useful reference + information, such as a Bibliography and + historic information related to BIND and the Domain Name + System. + + Conventions Used in This Document + + In this document, we use the following general typographic + conventions: + + + + + + + + +To +describe: + +We use the style: + + + +a pathname, filename, URL, hostname, +mailing list name, or new term or concept + Fixed width + + + literal user +input + Fixed Width Bold + + + program output + Fixed Width + + + + + + The following conventions are used in descriptions of the +BIND configuration file: + + + + + + To +describe: + We use the style: + + + keywords + Fixed Width + + + variables + Fixed Width + + +Optional input + Text is enclosed in square brackets + + + +The Domain Name System (<acronym>DNS</acronym>) +The purpose of this document is to explain the installation +and upkeep of the BIND software package, and we +begin by reviewing the fundamentals of the Domain Name System +(DNS) as they relate to BIND. + + + +DNS Fundamentals + +The Domain Name System (DNS) is the hierarchical, distributed +database. It stores information for mapping Internet host names to IP +addresses and vice versa, mail routing information, and other data +used by Internet applications. + +Clients look up information in the DNS by calling a +resolver library, which sends queries to one or +more name servers and interprets the responses. +The BIND 9 software distribution contains a +name server, named, and two resolver +libraries, liblwres and libbind. + + + +Domains and Domain Names + +The data stored in the DNS is identified by domain +names that are organized as a tree according to +organizational or administrative boundaries. Each node of the tree, +called a domain, is given a label. The domain name of the +node is the concatenation of all the labels on the path from the +node to the root node. This is represented +in written form as a string of labels listed from right to left and +separated by dots. A label need only be unique within its parent +domain. + +For example, a domain name for a host at the +company Example, Inc. could be +mail.example.com, +where com is the +top level domain to which +ourhost.example.com belongs, +example is +a subdomain of com, and +ourhost is the +name of the host. + +For administrative purposes, the name space is partitioned into +areas called zones, each starting at a node and +extending down to the leaf nodes or to nodes where other zones start. +The data for each zone is stored in a name +server, which answers queries about the zone using the +DNS protocol. + + +The data associated with each domain name is stored in the +form of resource records (RRs). +Some of the supported resource record types are described in +. + +For more detailed information about the design of the DNS and +the DNS protocol, please refer to the standards documents listed in +. + + +Zones +To properly operate a name server, it is important to understand +the difference between a zone +and a domain. + +As we stated previously, a zone is a point of delegation in +the DNS tree. A zone consists of +those contiguous parts of the domain +tree for which a name server has complete information and over which +it has authority. It contains all domain names from a certain point +downward in the domain tree except those which are delegated to +other zones. A delegation point is marked by one or more +NS records in the +parent zone, which should be matched by equivalent NS records at +the root of the delegated zone. + +For instance, consider the example.com +domain which includes names +such as host.aaa.example.com and +host.bbb.example.com even though +the example.com zone includes +only delegations for the aaa.example.com and +bbb.example.com zones. A zone can map +exactly to a single domain, but could also include only part of a +domain, the rest of which could be delegated to other +name servers. Every name in the DNS tree is a +domain, even if it is +terminal, that is, has no +subdomains. Every subdomain is a domain and +every domain except the root is also a subdomain. The terminology is +not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to +gain a complete understanding of this difficult and subtle +topic. + +Though BIND is called a "domain name server", +it deals primarily in terms of zones. The master and slave +declarations in the named.conf file specify +zones, not domains. When you ask some other site if it is willing to +be a slave server for your domain, you are +actually asking for slave service for some collection of zones. + + +Authoritative Name Servers + +Each zone is served by at least +one authoritative name server, +which contains the complete data for the zone. +To make the DNS tolerant of server and network failures, +most zones have two or more authoritative servers. + + +Responses from authoritative servers have the "authoritative +answer" (AA) bit set in the response packets. This makes them +easy to identify when debugging DNS configurations using tools like +dig (). + +The Primary Master + + +The authoritative server where the master copy of the zone data is maintained is +called the primary master server, or simply the +primary. It loads the zone contents from some +local file edited by humans or perhaps generated mechanically from +some other local file which is edited by humans. This file is called +the zone file or master file. + + +Slave Servers +The other authoritative servers, the slave +servers (also known as secondary servers) load +the zone contents from another server using a replication process +known as a zone transfer. Typically the data are +transferred directly from the primary master, but it is also possible +to transfer it from another slave. In other words, a slave server +may itself act as a master to a subordinate slave server. + + +Stealth Servers + +Usually all of the zone's authoritative servers are listed in +NS records in the parent zone. These NS records constitute +a delegation of the zone from the parent. +The authoritative servers are also listed in the zone file itself, +at the top level or apex +of the zone. You can list servers in the zone's top-level NS +records that are not in the parent's NS delegation, but you cannot +list servers in the parent's delegation that are not present at +the zone's top level. + +A stealth server is a server that is +authoritative for a zone but is not listed in that zone's NS +records. Stealth servers can be used for keeping a local copy of a +zone to speed up access to the zone's records or to make sure that the +zone is available even if all the "official" servers for the zone are +inaccessible. + +A configuration where the primary master server itself is a +stealth server is often referred to as a "hidden primary" +configuration. One use for this configuration is when the primary master +is behind a firewall and therefore unable to communicate directly +with the outside world. + + + + + + +Caching Name Servers + +The resolver libraries provided by most operating systems are +stub resolvers, meaning that they are not capable of +performing the full DNS resolution process by themselves by talking +directly to the authoritative servers. Instead, they rely on a local +name server to perform the resolution on their behalf. Such a server +is called a recursive name server; it performs +recursive lookups for local clients. + +To improve performance, recursive servers cache the results of +the lookups they perform. Since the processes of recursion and +caching are intimately connected, the terms +recursive server and +caching server are often used synonymously. + +The length of time for which a record may be retained in +in the cache of a caching name server is controlled by the +Time To Live (TTL) field associated with each resource record. + + +Forwarding + +Even a caching name server does not necessarily perform +the complete recursive lookup itself. Instead, it can +forward some or all of the queries +that it cannot satisfy from its cache to another caching name server, +commonly referred to as a forwarder. + + +There may be one or more forwarders, +and they are queried in turn until the list is exhausted or an answer +is found. Forwarders are typically used when you do not +wish all the servers at a given site to interact directly with the rest of +the Internet servers. A typical scenario would involve a number +of internal DNS servers and an Internet firewall. Servers unable +to pass packets through the firewall would forward to the server +that can do it, and that server would query the Internet DNS servers +on the internal server's behalf. An added benefit of using the forwarding +feature is that the central machine develops a much more complete +cache of information that all the clients can take advantage +of. + + + + +Name Servers in Multiple Roles + +The BIND name server can simultaneously act as +a master for some zones, a slave for other zones, and as a caching +(recursive) server for a set of local clients. + +However, since the functions of authoritative name service +and caching/recursive name service are logically separate, it is +often advantageous to run them on separate server machines. + +A server that only provides authoritative name service +(an authoritative-only server) can run with +recursion disabled, improving reliability and security. + +A server that is not authoritative for any zones and only provides +recursive service to local +clients (a caching-only server) +does not need to be reachable from the Internet at large and can +be placed inside a firewall. + + + + + + +<acronym>BIND</acronym> Resource Requirements + + +Hardware requirements + +DNS hardware requirements have traditionally been quite modest. +For many installations, servers that have been pensioned off from +active duty have performed admirably as DNS servers. +The DNSSEC and IPv6 features of BIND 9 may prove to be quite +CPU intensive however, so organizations that make heavy use of these +features may wish to consider larger systems for these applications. +BIND 9 is fully multithreaded, allowing full utilization of +multiprocessor systems for installations that need it. +CPU Requirements +CPU requirements for BIND 9 range from i486-class machines +for serving of static zones without caching, to enterprise-class +machines if you intend to process many dynamic updates and DNSSEC +signed zones, serving many thousands of queries per second. + +Memory Requirements +The memory of the server has to be large enough to fit the +cache and zones loaded off disk. The max-cache-size +option can be used to limit the amount of memory used by the cache, +at the expense of reducing cache hit rates and causing more DNS +traffic. It is still good practice to have enough memory to load +all zone and cache data into memory — unfortunately, the best way +to determine this for a given installation is to watch the name server +in operation. After a few weeks the server process should reach +a relatively stable size where entries are expiring from the cache as +fast as they are being inserted. + +Name Server Intensive Environment Issues +For name server intensive environments, there are two alternative +configurations that may be used. The first is where clients and +any second-level internal name servers query a main name server, which +has enough memory to build a large cache. This approach minimizes +the bandwidth used by external name lookups. The second alternative +is to set up second-level internal name servers to make queries independently. +In this configuration, none of the individual machines needs to +have as much memory or CPU power as in the first alternative, but +this has the disadvantage of making many more external queries, +as none of the name servers share their cached data. + +Supported Operating Systems +ISC BIND 9 compiles and runs on a large number +of Unix-like operating system and on Windows NT / 2000. For an up-to-date +list of supported systems, see the README file in the top level directory +of the BIND 9 source distribution. + + + + +Name Server Configuration +In this section we provide some suggested configurations along +with guidelines for their use. We also address the topic of reasonable +option setting. + + +Sample Configurations + +A Caching-only Name Server +The following sample configuration is appropriate for a caching-only +name server for use by clients internal to a corporation. All queries +from outside clients are refused using the allow-query +option. Alternatively, the same effect could be achieved using suitable +firewall rules. + + +// Two corporate subnets we wish to allow queries from. +acl corpnets { 192.168.4.0/24; 192.168.7.0/24; }; +options { + directory "/etc/namedb"; // Working directory + allow-query { corpnets; }; +}; +// Provide a reverse mapping for the loopback address 127.0.0.1 +zone "0.0.127.in-addr.arpa" { + type master; + file "localhost.rev"; + notify no; +}; + + + + +An Authoritative-only Name Server +This sample configuration is for an authoritative-only server +that is the master server for "example.com" +and a slave for the subdomain "eng.example.com". + + +options { + directory "/etc/namedb"; // Working directory + allow-query { any; }; // This is the default + recursion no; // Do not provide recursive service +}; + +// Provide a reverse mapping for the loopback address 127.0.0.1 +zone "0.0.127.in-addr.arpa" { + type master; + file "localhost.rev"; + notify no; +}; +// We are the master server for example.com +zone "example.com" { + type master; + file "example.com.db"; + // IP addresses of slave servers allowed to transfer example.com + allow-transfer { + 192.168.4.14; + 192.168.5.53; + }; +}; +// We are a slave server for eng.example.com +zone "eng.example.com" { + type slave; + file "eng.example.com.bk"; + // IP address of eng.example.com master server + masters { 192.168.4.12; }; +}; + + + + + +Load Balancing + +A primitive form of load balancing can be achieved in +the DNS by using multiple A records for one name. + +For example, if you have three WWW servers with network addresses +of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the +following means that clients will connect to each machine one third +of the time: + + + + + + + + + + +Name +TTL +CLASS +TYPE +Resource Record (RR) Data + + +www +600 +IN +A +10.0.0.1 + + + +600 +IN +A +10.0.0.2 + + + +600 +IN +A +10.0.0.3 + + + + + When a resolver queries for these records, BIND will rotate + them and respond to the query with the records in a different + order. In the example above, clients will randomly receive + records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients + will use the first record returned and discard the rest. + For more detail on ordering responses, check the + rrset-order substatement in the + options statement, see + . + This substatement is not supported in + BIND 9, and only the ordering scheme described above is + available. + + + + +Name Server Operations + + +Tools for Use With the Name Server Daemon +There are several indispensable diagnostic, administrative +and monitoring tools available to the system administrator for controlling +and debugging the name server daemon. We describe several in this +section + +Diagnostic Tools +The dig, host, and +nslookup programs are all command line tools +for manually querying name servers. They differ in style and +output format. + + + + +dig + +The domain information groper (dig) +is the most versatile and complete of these lookup tools. +It has two modes: simple interactive +mode for a single query, and batch mode which executes a query for +each in a list of several query lines. All query options are accessible +from the command line. + + dig + @server + domain + query-type + query-class + +query-option + -dig-option + %comment + +The usual simple use of dig will take the form +dig @server domain query-type query-class +For more information and a list of available commands and +options, see the dig man page. + + + + +host + +The host utility emphasizes simplicity +and ease of use. By default, it converts +between host names and Internet addresses, but its functionality +can be extended with the use of options. + + host + -aCdlrTwv + -c class + -N ndots + -t type + -W timeout + -R retries + hostname + server + +For more information and a list of available commands and +options, see the host man page. + + + + +nslookup + +nslookup has two modes: interactive +and non-interactive. Interactive mode allows the user to query name servers +for information about various hosts and domains or to print a list +of hosts in a domain. Non-interactive mode is used to print just +the name and requested information for a host or domain. + + nslookup + -option + + host-to-find + - server + + +Interactive mode is entered when no arguments are given (the +default name server will be used) or when the first argument is a +hyphen (`-') and the second argument is the host name or Internet address +of a name server. +Non-interactive mode is used when the name or Internet address +of the host to be looked up is given as the first argument. The +optional second argument specifies the host name or address of a name server. +Due to its arcane user interface and frequently inconsistent +behavior, we do not recommend the use of nslookup. +Use dig instead. + + + + + + + + Administrative Tools + Administrative tools play an integral part in the management +of a server. + + + named-checkconf + + The named-checkconf program + checks the syntax of a named.conf file. + + named-checkconf + -t directory + filename + + + + + named-checkzone + + The named-checkzone program checks a master file for + syntax and consistency. + + named-checkzone + -dq + -c class + zone + filename + + + + + rndc + + The remote name daemon control + (rndc) program allows the system + administrator to control the operation of a name server. + If you run rndc without any options + it will display a usage message as follows: + + rndc + -c config + -s server + -p port + -y key + command + command + + command is one of the following: + + + + reload + Reload configuration file and zones. + + + reload zone + class + view + Reload the given zone. + + + refresh zone + class + view + Schedule zone maintenance for the given zone. + + + retransfer zone + class + view + Retransfer the given zone from the master. + + + freeze zone + class + view + Suspend updates to a dynamic zone. This allows manual + edits to be made to a zone normally updated by dynamic update. It + also causes changes in the journal file to be synced into the master + and the journal file to be removed. All dynamic update attempts will + be refused while the zone is frozen. + + + unfreeze zone + class + view + Enable updates to a frozen dynamic zone. This causes + the server to reload the zone from disk, and re-enables dynamic updates + after the load has completed. After a zone is unfrozen, dynamic updates + will no longer be refused. + + + reconfig + Reload the configuration file and load new zones, + but do not reload existing zone files even if they have changed. + This is faster than a full reload when there + is a large number of zones because it avoids the need to examine the + modification times of the zones files. + + + + stats + Write server statistics to the statistics file. + + + querylog + Toggle query logging. Query logging can also be enabled + by explicitly directing the queries + category to a channel in the + logging section of + named.conf. + + dumpdb + Dump the server's caches to the dump file. + + stop + Stop the server, + making sure any recent changes + made through dynamic update or IXFR are first saved to the master files + of the updated zones. + + halt + Stop the server immediately. Recent changes + made through dynamic update or IXFR are not saved to the master files, + but will be rolled forward from the journal files when the server + is restarted. + + trace + Increment the servers debugging level by one. + + trace level + Sets the server's debugging level to an explicit + value. + + notrace + Sets the server's debugging level to 0. + + flush + Flushes the server's cache. + + status + Display status of the server. +Note the number of zones includes the internal bind/CH zone +and the default ./IN hint zone if there is not a +explicit root zone configured. + + + +In BIND 9.2, rndc +supports all the commands of the BIND 8 ndc +utility except ndc start and +ndc restart, which were also +not supported in ndc's channel mode. + +A configuration file is required, since all +communication with the server is authenticated with +digital signatures that rely on a shared secret, and +there is no way to provide that secret other than with a +configuration file. The default location for the +rndc configuration file is +/etc/rndc.conf, but an alternate +location can be specified with the +option. If the configuration file is not found, +rndc will also look in +/etc/rndc.key (or whatever +sysconfdir was defined when +the BIND build was configured). +The rndc.key file is generated by +running rndc-confgen -a as described in +. + +The format of the configuration file is similar to +that of named.conf, but limited to +only four statements, the options, +key, server and +include +statements. These statements are what associate the +secret keys to the servers with which they are meant to +be shared. The order of statements is not +significant. + +The options statement has three clauses: +default-server, default-key, +and default-port. +default-server takes a +host name or address argument and represents the server that will +be contacted if no +option is provided on the command line. +default-key takes +the name of a key as its argument, as defined by a key statement. +default-port specifies the port to which +rndc should connect if no +port is given on the command line or in a +server statement. + +The key statement defines an key to be used +by rndc when authenticating with +named. Its syntax is identical to the +key statement in named.conf. +The keyword key is +followed by a key name, which must be a valid +domain name, though it need not actually be hierarchical; thus, +a string like "rndc_key" is a valid name. +The key statement has two clauses: +algorithm and secret. +While the configuration parser will accept any string as the argument +to algorithm, currently only the string "hmac-md5" +has any meaning. The secret is a base-64 encoded string. + +The server statement associates a key +defined using the key statement with a server. +The keyword server is followed by a +host name or address. The server statement +has two clauses: key and port. +The key clause specifies the name of the key +to be used when communicating with this server, and the +port clause can be used to +specify the port rndc should connect +to on the server. + +A sample minimal configuration file is as follows: + +key rndc_key { + algorithm "hmac-md5"; + secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; +}; +options { + default-server 127.0.0.1; + default-key rndc_key; +}; + + +This file, if installed as /etc/rndc.conf, +would allow the command: + +$ rndc reload + +to connect to 127.0.0.1 port 953 and cause the name server +to reload, if a name server on the local machine were running with +following controls statements: + +controls { + inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; +}; + +and it had an identical key statement for +rndc_key. + +Running the rndc-confgen program will +conveniently create a rndc.conf +file for you, and also display the +corresponding controls statement that you need to +add to named.conf. Alternatively, +you can run rndc-confgen -a to set up +a rndc.key file and not modify +named.conf at all. + + + + + + + + + + +Signals +Certain UNIX signals cause the name server to take specific +actions, as described in the following table. These signals can +be sent using the kill command. + + + + + +SIGHUP +Causes the server to read named.conf and +reload the database. + + +SIGTERM +Causes the server to clean up and exit. + + + +SIGINT + + Causes the server to clean up and exit. + + + + + + + + + +Advanced DNS Features + + + +Notify +DNS NOTIFY is a mechanism that allows master +servers to notify their slave servers of changes to a zone's data. In +response to a NOTIFY 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. + +DNS +For more information about +NOTIFY, see the description of the +notify option in and +the description of the zone option also-notify in +. The NOTIFY +protocol is specified in RFC 1996. + + + + + +Dynamic Update + + 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 + in RFC 2136. + + Dynamic update is enabled on a zone-by-zone basis, by + including an allow-update or + update-policy clause in the + zone statement. + + Updating of secure zones (zones using DNSSEC) follows + RFC 3007: RRSIG and NSEC records affected by updates are automatically + regenerated by the server using an online zone key. + Update authorization is based + on transaction signatures and an explicit server policy. + + + The journal file + + 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 .jnl to the + name of the corresponding zone file. The journal file is in a + binary format and should not be edited manually. + + 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 + up to 15 minutes, allowing additional updates to take place. + + 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. + + Changes that result from incoming incremental zone transfers are also + journalled in a similar way. + + 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 rndc stop. + + If you have to make changes to a dynamic zone + manually, the following procedure will work: Disable dynamic updates + to the zone using + rndc freeze zone. + This will also remove the zone's .jnl file + and update the master file. Edit the zone file. Run + rndc unfreeze zone + to reload the changed zone and re-enable dynamic updates. + + + + + + +Incremental Zone Transfers (IXFR) + +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 specified in RFC +1995. See . + +When acting as a master, BIND 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. For manually maintained master +zones, and for slave zones obtained by performing a full zone +transfer (AXFR), IXFR is supported only if the option +ixfr-from-differences is set +to yes. + + +When acting as a slave, BIND 9 will +attempt to use IXFR unless +it is explicitly disabled. For more information about disabling +IXFR, see the description of the request-ixfr clause +of the server statement. + + +Split DNS +Setting up different views, or visibility, of the DNS space to +internal and external resolvers is usually referred to as a Split +DNS setup. There are several reasons an organization +would want to set up its DNS this way. +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. +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. +Here is an example of a split DNS setup: +Let's say a company named Example, Inc. +(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. +Example, Inc. 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. +In order to accomplish this, the company will set up two sets +of name servers. 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. +The internal servers will be configured to forward all queries, +except queries for site1.internal, site2.internal, site1.example.com, +and site2.example.com, to the servers in the +DMZ. These internal servers will have complete sets of information +for site1.example.com, site2.example.com, site1.internal, +and site2.internal. +To protect the site1.internal and site2.internal domains, +the internal name servers must be configured to disallow all queries +to these domains from any external hosts, including the bastion +hosts. +The external servers, which are on the bastion hosts, will +be configured to serve the "public" version of the site1 and site2.example.com zones. +This could include things such as the host records for public servers +(www.example.com and ftp.example.com), +and mail exchange (MX) records (a.mx.example.com and b.mx.example.com). +In addition, the public site1 and site2.example.com 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. +Here's an example of a wildcard MX record: +* IN MX 10 external1.example.com. +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 +name servers for DNS resolution. +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. +In order for all this to work properly, internal clients will +need to be configured to query only the internal +name servers for DNS queries. This could also be enforced via selective +filtering on the network. +If everything has been set properly, Example, Inc.'s +internal clients will now be able to: + + Look up any hostnames in the site1 and +site2.example.com zones. + + Look up any hostnames in the site1.internal and +site2.internal domains. + + Look up any hostnames on the Internet. + + Exchange mail with internal AND external people. +Hosts on the Internet will be able to: + + Look up any hostnames in the site1 and +site2.example.com zones. + + Exchange mail with anyone in the site1 and +site2.example.com zones. + + Here is an example configuration for the setup we just + described above. Note that this is only configuration information; + for information on how to configure your zone files, see + +Internal DNS server config: + + +acl internals { 172.16.72.0/24; 192.168.1.0/24; }; + +acl externals { bastion-ips-go-here; }; + +options { + ... + ... + forward only; + forwarders { // forward to external servers + bastion-ips-go-here; + }; + allow-transfer { none; }; // sample allow-transfer (no one) + allow-query { internals; externals; }; // restrict query access + allow-recursion { internals; }; // restrict recursion + ... + ... +}; + +zone "site1.example.com" { // sample master zone + type master; + file "m/site1.example.com"; + forwarders { }; // do normal iterative + // resolution (do not forward) + allow-query { internals; externals; }; + allow-transfer { internals; }; +}; + +zone "site2.example.com" { // sample slave zone + type slave; + file "s/site2.example.com"; + masters { 172.16.72.3; }; + forwarders { }; + allow-query { internals; externals; }; + allow-transfer { internals; }; +}; + +zone "site1.internal" { + type master; + file "m/site1.internal"; + forwarders { }; + allow-query { internals; }; + allow-transfer { internals; } +}; + +zone "site2.internal" { + type slave; + file "s/site2.internal"; + masters { 172.16.72.3; }; + forwarders { }; + allow-query { internals }; + allow-transfer { internals; } +}; + + External (bastion host) DNS server config: + +acl internals { 172.16.72.0/24; 192.168.1.0/24; }; + +acl externals { bastion-ips-go-here; }; + +options { + ... + ... + allow-transfer { none; }; // sample allow-transfer (no one) + allow-query { internals; externals; }; // restrict query access + allow-recursion { internals; externals; }; // restrict recursion + ... + ... +}; + +zone "site1.example.com" { // sample slave zone + type master; + file "m/site1.foo.com"; + allow-query { any; }; + allow-transfer { internals; externals; }; +}; + +zone "site2.example.com" { + type slave; + file "s/site2.foo.com"; + masters { another_bastion_host_maybe; }; + allow-query { any; }; + allow-transfer { internals; externals; } +}; + +In the resolv.conf (or equivalent) on +the bastion host(s): + +search ... +nameserver 172.16.72.2 +nameserver 172.16.72.3 +nameserver 172.16.72.4 + + +TSIG +This is a short guide to setting up Transaction SIGnatures +(TSIG) based transaction security in BIND. 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 BIND. +BIND primarily supports TSIG for server to server communication. +This includes zone transfer, notify, and recursive query messages. +Resolvers based on newer versions of BIND 8 have limited support +for TSIG. + + 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. + The cryptographic access control provided by TSIG + is far superior. The nsupdate + program supports TSIG via the and + command line options. + +Generate Shared Keys for Each Pair of Hosts +A shared secret is generated to be shared between host1 and host2. +An arbitrary key name is chosen: "host1-host2.". The key name must +be the same on both hosts. +Automatic Generation +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. + dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2. +The key is in the file Khost1-host2.+157+00000.private. +Nothing directly uses this file, but the base-64 encoded string +following "Key:" +can be extracted from the file and used as a shared secret: +Key: La/E5CjG9O+os1jq0a2jdA== +The string "La/E5CjG9O+os1jq0a2jdA==" can +be used as the shared secret. +Manual Generation +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. +Also, a known string can be run through mmencode or +a similar program to generate base-64 encoded data. +Copying the Shared Secret to Both Machines +This is beyond the scope of DNS. A secure transport mechanism +should be used. This could be secure FTP, ssh, telephone, etc. +Informing the Servers of the Key's Existence +Imagine host1 and host 2 are +both servers. The following is added to each server's named.conf file: + +key host1-host2. { + algorithm hmac-md5; + secret "La/E5CjG9O+os1jq0a2jdA=="; +}; + +The algorithm, hmac-md5, is the only one supported by BIND. +The secret is the one generated above. Since this is a secret, it +is recommended that either named.conf be non-world +readable, or the key directive be added to a non-world readable +file that is included by named.conf. +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 is successfully verified, the +response is signed by the same key. + +Instructing the Server to Use the Key +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 named.conf file +for host1, if the IP address of host2 is +10.1.2.3: + +server 10.1.2.3 { + keys { host1-host2. ;}; +}; + +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. +If host1 sends a message that is a request +to that address, the message will be signed with the specified key. host1 will +expect any responses to signed messages to be signed with the same +key. +A similar statement must be present in host2's +configuration file (with host1's address) for host2 to +sign request messages to host1. +TSIG Key Based Access Control +BIND allows IP addresses and ranges to be specified in ACL +definitions and +allow-{ query | transfer | update } directives. +This has been extended to allow TSIG keys also. The above key would +be denoted key host1-host2. +An example of an allow-update directive would be: + +allow-update { key host1-host2. ;}; + + + This allows dynamic updates to succeed only if the request + was signed by a key named + "host1-host2.". You may want to read about the more + powerful update-policy statement in . + + + + Errors + + 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. + + 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. + + + + + TKEY + + TKEY is a mechanism for automatically + generating a shared secret between two hosts. There are several + "modes" of TKEY that specify how the key is + generated or assigned. BIND 9 + 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 TKEY process + must use signed messages, signed either by TSIG or SIG(0). The + result of TKEY is a shared secret that can be + used to sign messages with TSIG. TKEY can also + be used to delete shared secrets that it had previously + generated. + + The TKEY process is initiated by a client + or server by sending a signed TKEY query + (including any appropriate KEYs) to a TKEY-aware server. The + server response, if it indicates success, will contain a + TKEY record and any appropriate keys. After + this exchange, both participants have enough information to + determine the shared secret; the exact process depends on the + TKEY mode. When using the Diffie-Hellman + TKEY mode, Diffie-Hellman keys are exchanged, + and the shared secret is derived by both participants. + + + + SIG(0) + + BIND 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. + + 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. + + SIG(0) signing of multiple-message TCP streams is not + supported. + + The only tool shipped with BIND 9 that + generates SIG(0) signed messages is nsupdate. + + + + DNSSEC + + Cryptographic authentication of DNS information is possible + through the DNS Security (DNSSEC-bis) extensions, + defined in RFC <TBA>. This section describes the creation and use + of DNSSEC signed zones. + + In order to set up a DNSSEC secure zone, there are a series + of steps which must be followed. BIND 9 ships + with several tools + that are used in this process, which are explained in more detail + below. In all cases, the option prints a + full list of parameters. Note that the DNSSEC tools require the + keyset files to be in the working directory or the + directory specified by the option, and + that the tools shipped with BIND 9.2.x and earlier are not compatible + with the current ones. + + There must also be communication with the administrators of + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presense + or absence of a DS record at the delegation + point. + + 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. + + + Generating Keys + + The dnssec-keygen program is used to + generate keys. + + 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 + ZONE, and must be usable for authentication. + It is recommended that zone keys use a cryptographic algorithm + designated as "mandatory to implement" by the IETF; currently + the only one is RSASHA1. + + The following command will generate a 768 bit RSASHA1 key for + the child.example zone: + + dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example. + + Two output files will be produced: + Kchild.example.+005+12345.key and + Kchild.example.+005+12345.private (where + 12345 is an example of a key tag). The key file names contain + the key name (child.example.), algorithm (3 + is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case). + The private key (in the .private file) is + used to generate signatures, and the public key (in the + .key file) is used for signature + verification. + + To generate another key with the same properties (but with + a different key tag), repeat the above command. + + The public keys should be inserted into the zone file by + including the .key files using + $INCLUDE statements. + + + + + Signing the Zone + + The dnssec-signzone program is used to + sign a zone. + + Any keyset files corresponding + to secure subzones should be present. The zone signer will + generate NSEC and RRSIG + records for the zone, as well as DS for + the child zones if '-d' is specified. + If '-d' is not specified then DS RRsets for + the secure child zones need to be added manually. + + The following command signs the zone, assuming it is in a + file called zone.child.example. By + default, all zone keys which have an available private key are + used to generate signatures. + +dnssec-signzone -o child.example zone.child.example + + One output file is produced: + zone.child.example.signed. This file + should be referenced by named.conf as the + input file for the zone. + + dnssec-signzone will also produce a + keyset and dsset files and optionally a dlvset file. These + are used to provide the parent zone administators with the + DNSKEYs (or their corresponding DS + records) that are the secure entry point to the zone. + + + +Configuring Servers + +Unlike BIND 8, +BIND 9 does not verify signatures on load, +so zone keys for authoritative zones do not need to be specified +in the configuration file. + +The public key for any security root must be present in +the configuration file's trusted-keys +statement, as described later in this document. + + + + + + IPv6 Support in <acronym>BIND</acronym> 9 + + BIND 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. + + For forward lookups, BIND 9 supports only AAAA + records. The use of A6 records is deprecated by RFC 3363, and the + support for forward lookups in BIND 9 is + removed accordingly. + However, authoritative BIND 9 name servers still + load zone files containing A6 records correctly, answer queries + for A6 records, and accept zone transfer for a zone containing A6 + records. + + For IPv6 reverse lookups, BIND 9 supports + the traditional "nibble" format used in the + ip6.arpa domain, as well as the older, deprecated + ip6.int domain. + BIND 9 formerly + supported the "binary label" (also known as "bitstring") format. + The support of binary labels, however, is now completely removed + according to the changes in RFC 3363. + Any applications in BIND 9 do not understand + the format any more, and will return an error if given. + In particular, an authoritative BIND 9 name + server rejects to load a zone file containing binary labels. + + For an overview of the format and structure of IPv6 addresses, + see . + + + Address Lookups Using AAAA Records + + The AAAA record is a parallel to the IPv4 A record. It + specifies the entire address in a single record. For + example, + + +$ORIGIN example.com. +host 3600 IN AAAA 2001:db8::1 + + + It is recommended that IPv4-in-IPv6 mapped addresses not + be used. If a host has an IPv4 address, use an A record, not + a AAAA, with ::ffff:192.168.42.1 as the + address. + + + Address to Name Lookups Using Nibble Format + + When looking up an address in nibble format, the address + components are simply reversed, just as in IPv4, and + ip6.arpa. is appended to the resulting name. + For example, the following would provide reverse name lookup for + a host with address + 2001:db8::1. + + +$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. +1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR host.example.com. + + + + + + The <acronym>BIND</acronym> 9 Lightweight Resolver +The Lightweight Resolver Library +Traditionally applications have been linked with a stub resolver +library that sends recursive DNS queries to a local caching name +server. +IPv6 once introduced new complexity into the resolution process, +such as following A6 chains and DNAME records, and simultaneous +lookup of IPv4 and IPv6 addresses. Though most of the complexity was +then removed, these are hard or impossible +to implement in a traditional stub resolver. +Instead, BIND 9 provides resolution services to local clients +using a combination of a lightweight resolver library and a resolver +daemon process running on the local host. These communicate using +a simple UDP-based protocol, the "lightweight resolver protocol" +that is distinct from and simpler than the full DNS protocol. +Running a Resolver Daemon + +To use the lightweight resolver interface, the system must +run the resolver daemon lwresd or a local +name server configured with a lwres statement. + +By default, applications using the lightweight resolver library will make +UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. The +address can be overridden by lwserver lines in +/etc/resolv.conf. + +The daemon currently only looks in the DNS, but in the future +it may use other sources such as /etc/hosts, +NIS, etc. + +The lwresd daemon is essentially a +caching-only name server that responds to requests using the lightweight +resolver protocol rather than the DNS protocol. Because it needs +to run on each host, it is designed to require no or minimal configuration. +Unless configured otherwise, it uses the name servers listed on +nameserver lines in /etc/resolv.conf +as forwarders, but is also capable of doing the resolution autonomously if +none are specified. +The lwresd daemon may also be configured with a +named.conf style configuration file, in +/etc/lwresd.conf by default. A name server may also +be configured to act as a lightweight resolver daemon using the +lwres statement in named.conf. + + + +<acronym>BIND</acronym> 9 Configuration Reference + +BIND 9 configuration is broadly similar +to BIND 8; however, there are a few new areas +of configuration, such as views. BIND +8 configuration files should work with few alterations in BIND +9, although more complex configurations should be reviewed to check +if they can be more efficiently implemented using the new features +found in BIND 9. + +BIND 4 configuration files can be converted to the new format +using the shell script +contrib/named-bootconf/named-bootconf.sh. +Configuration File Elements +Following is a list of elements used throughout the BIND configuration +file documentation: + + + + + +acl_name +The name of an address_match_list as +defined by the acl statement. + + +address_match_list +A list of one or more ip_addr, +ip_prefix, key_id, +or acl_name elements, see +. + + +domain_name +A quoted string which will be used as +a DNS name, for example "my.test.domain". + + +dotted_decimal +One to four integers valued 0 through +255 separated by dots (`.'), such as 123, +45.67 or 89.123.45.67. + + +ip4_addr +An IPv4 address with exactly four elements +in dotted_decimal notation. + + +ip6_addr +An IPv6 address, such as 2001:db8::1234. +IPv6 scoped addresses that have ambiguity on their scope zones must be +disambiguated by an appropriate zone ID with the percent character +(`%') as delimiter. +It is strongly recommended to use string zone names rather than +numeric identifiers, in order to be robust against system +configuration changes. +However, since there is no standard mapping for such names and +identifier values, currently only interface names as link identifiers +are supported, assuming one-to-one mapping between interfaces and links. +For example, a link-local address fe80::1 on the +link attached to the interface ne0 +can be specified as fe80::1%ne0. +Note that on most systems link-local addresses always have the +ambiguity, and need to be disambiguated. + + +ip_addr +An ip4_addr or ip6_addr. + + +ip_port +An IP port number. +number is limited to 0 through 65535, with values +below 1024 typically restricted to use by processes running as root. +In some cases an asterisk (`*') character can be used as a placeholder to +select a random high-numbered port. + + +ip_prefix +An IP network specified as an ip_addr, +followed by a slash (`/') and then the number of bits in the netmask. +Trailing zeros in a ip_addr may omitted. +For example, 127/8 is the network 127.0.0.0 with +netmask 255.0.0.0 and 1.2.3.0/28 is +network 1.2.3.0 with netmask 255.255.255.240. + + +key_id +A domain_name representing +the name of a shared key, to be used for transaction security. + + +key_list +A list of one or more key_ids, +separated by semicolons and ending with a semicolon. + + +number +A non-negative 32 bit integer +(i.e., a number between 0 and 4294967295, inclusive). +Its acceptable value might further +be limited by the context in which it is used. + + +path_name +A quoted string which will be used as +a pathname, such as zones/master/my.test.domain. + + +size_spec +A number, the word unlimited, +or the word default. +An unlimited size_spec requests unlimited +use, or the maximum available amount. A default size_spec uses +the limit that was in force when the server was started.A number can +optionally be followed by a scaling factor: K or k for +kilobytes, M or m for +megabytes, and G or g for gigabytes, +which scale by 1024, 1024*1024, and 1024*1024*1024 respectively. +The value must be representable as a 64-bit unsigned integer +(0 to 18446744073709551615, inclusive). +Using unlimited is the best way +to safely set a really large number. + + +yes_or_no +Either yes or no. +The words true and false are +also accepted, as are the numbers 1 and 0. + + +dialup_option +One of yes, +no, notify, +notify-passive, refresh or +passive. +When used in a zone, notify-passive, +refresh, and passive +are restricted to slave and stub zones. + + + +Address Match Lists +Syntax + address_match_list = address_match_list_element ; + address_match_list_element; ... +address_match_list_element = ! (ip_address /length | + key key_id | acl_name | { address_match_list } ) + + +Definition and Usage +Address match lists are primarily used to determine access +control for various server operations. They are also used in +the listen-on and sortlist +statements. The elements +which constitute an address match list can be any of the following: + + an IP address (IPv4 or IPv6) + + an IP prefix (in `/' notation) + + a key ID, as defined by the key statement + + the name of an address match list previously defined with +the acl statement + + a nested address match list enclosed in braces + +Elements can be negated with a leading exclamation mark (`!'), +and the match list names "any", "none", "localhost", and "localnets" +are predefined. More information on those names can be found in +the description of the acl statement. + +The addition of the key clause made the name of this syntactic +element something of a misnomer, since security keys can be used +to validate access without regard to a host or network address. Nonetheless, +the term "address match list" is still used throughout the documentation. + +When a given IP address or prefix is compared to an address +match list, the list is traversed in order until an element matches. +The interpretation of a match depends on whether the list is being used +for access control, defining listen-on ports, or in a sortlist, +and whether the element was negated. + +When used as an access control list, a non-negated match allows +access and a negated match denies access. If there is no match, +access is denied. The clauses allow-notify, +allow-query, allow-transfer, +allow-update, allow-update-forwarding, +and blackhole all +use address match lists this. Similarly, the listen-on option will cause +the server to not accept queries on any of the machine's addresses +which do not match the list. + +Because of the first-match aspect of the algorithm, an element +that defines a subset of another element in the list should come +before the broader element, regardless of whether either is negated. For +example, in +1.2.3/24; ! 1.2.3.13; the 1.2.3.13 element is +completely useless because the algorithm will match any lookup for +1.2.3.13 to the 1.2.3/24 element. +Using ! 1.2.3.13; 1.2.3/24 fixes +that problem by having 1.2.3.13 blocked by the negation but all +other 1.2.3.* hosts fall through. + + + + +Comment Syntax + +The BIND 9 comment syntax allows for comments to appear +anywhere that white space may appear in a BIND configuration +file. To appeal to programmers of all kinds, they can be written +in the C, C++, or shell/perl style. + + +Syntax + +/* This is a BIND comment as in C */ +// This is a BIND comment as in C++ +# This is a BIND comment as in common UNIX shells and perl + + + + Definition and Usage +Comments may appear anywhere that whitespace may appear in +a BIND configuration file. +C-style comments start with the two characters /* (slash, +star) and end with */ (star, slash). Because they are completely +delimited with these characters, they can be used to comment only +a portion of a line or to span multiple lines. +C-style comments cannot be nested. For example, the following +is not valid because the entire comment ends with the first */: + /* This is the start of a comment. + This is still part of the comment. +/* This is an incorrect attempt at nesting a comment. */ + This is no longer in any comment. */ + + +C++-style comments start with the two characters // (slash, +slash) and continue to the end of the physical line. They cannot +be continued across multiple physical lines; to have one logical +comment span multiple lines, each line must use the // pair. +For example: + // This is the start of a comment. The next line +// is a new comment, even though it is logically +// part of the previous comment. + +Shell-style (or perl-style, if you prefer) comments start +with the character # (number sign) and continue to the end of the +physical line, as in C++ comments. +For example: + +# This is the start of a comment. The next line +# is a new comment, even though it is logically +# part of the previous comment. + + + + + You cannot use the semicolon (`;') character + to start a comment such as you would in a zone file. The + semicolon indicates the end of a configuration + statement. + + + + + + +Configuration File Grammar + + A BIND 9 configuration consists of statements and comments. + Statements end with a semicolon. Statements and comments are the + only elements that can appear without enclosing braces. Many + statements contain a block of sub-statements, which are also + terminated with a semicolon. + + The following statements are supported: + + + + + + + + acl + defines a named IP address +matching list, for access control and other uses. + + + controls + declares control channels to be used +by the rndc utility. + + + include + includes a file. + + + key + specifies key information for use in +authentication and authorization using TSIG. + + + logging + specifies what the server logs, and where +the log messages are sent. + + + lwres + configures named to +also act as a light weight resolver daemon (lwresd). + + + masters + defines a named masters list for +inclusion in stub and slave zone masters clauses. + + + options + controls global server configuration +options and sets defaults for other statements. + + + server + sets certain configuration options on +a per-server basis. + + + trusted-keys + defines trusted DNSSEC keys. + + + view + defines a view. + + + zone + defines a zone. + + + + + The logging and + options statements may only occur once per + configuration. + + + <command>acl</command> Statement Grammar + + acl acl-name { + address_match_list +}; + + + + <command>acl</command> Statement Definition and +Usage + + The acl statement assigns a symbolic + name to an address match list. It gets its name from a primary + use of address match lists: Access Control Lists (ACLs). + + Note that an address match list's name must be defined + with acl before it can be used elsewhere; no + forward references are allowed. + + The following ACLs are built-in: + + + + + + +any +Matches all hosts. + + +none +Matches no hosts. + + +localhost +Matches the IPv4 and IPv6 addresses of all network +interfaces on the system. + + +localnets +Matches any host on an IPv4 or IPv6 network +for which the system has an interface. +Some systems do not provide a way to determine the prefix lengths of +local IPv6 addresses. +In such a case, localnets only matches the local +IPv6 addresses, just like localhost. + + + + + + + + <command>controls</command> Statement Grammar +controls { + inet ( ip_addr | * ) port ip_port allow { address_match_list } + keys { key_list }; + inet ...; +}; + + + + +<command>controls</command> Statement Definition and Usage + + The controls statement declares control + channels to be used by system administrators to control the + operation of the name server. These control channels are + used by the rndc utility to send commands to + and retrieve non-DNS results from a name server. + + An inet control channel is a TCP + socket listening at the specified + ip_port on the specified + ip_addr, which can be an IPv4 or IPv6 + address. An ip_addr + of * is interpreted as the IPv4 wildcard + address; connections will be accepted on any of the system's + IPv4 addresses. To listen on the IPv6 wildcard address, + use an ip_addr of ::. + If you will only use rndc on the local host, + using the loopback address (127.0.0.1 + or ::1) is recommended for maximum + security. + + + + If no port is specified, port 953 + is used. "*" cannot be used for + ip_port. + + The ability to issue commands over the control channel is + restricted by the allow and + keys clauses. Connections to the control + channel are permitted based on the + address_match_list. This is for simple + IP address based filtering only; any key_id + elements of the address_match_list are + ignored. + + + The primary authorization mechanism of the command + channel is the key_list, which contains + a list of key_ids. + Each key_id in + the key_list is authorized to execute + commands over the control channel. + See in + ) for information about + configuring keys in rndc. + + +If no controls statement is present, +named will set up a default +control channel listening on the loopback address 127.0.0.1 +and its IPv6 counterpart ::1. +In this case, and also when the controls statement +is present but does not have a keys clause, +named will attempt to load the command channel key +from the file rndc.key in +/etc (or whatever sysconfdir +was specified as when BIND was built). +To create a rndc.key file, run +rndc-confgen -a. + + + The rndc.key feature was created to + ease the transition of systems from BIND 8, + which did not have digital signatures on its command channel messages + and thus did not have a keys clause. + +It makes it possible to use an existing BIND 8 +configuration file in BIND 9 unchanged, +and still have rndc work the same way +ndc worked in BIND 8, simply by executing the +command rndc-confgen -a after BIND 9 is +installed. + + + + Since the rndc.key feature + is only intended to allow the backward-compatible usage of + BIND 8 configuration files, this feature does not + have a high degree of configurability. You cannot easily change + the key name or the size of the secret, so you should make a + rndc.conf with your own key if you wish to change + those things. The rndc.key file also has its + permissions set such that only the owner of the file (the user that + named is running as) can access it. If you + desire greater flexibility in allowing other users to access + rndc commands then you need to create an + rndc.conf and make it group readable by a group + that contains the users who should have access. + + The UNIX control channel type of BIND 8 is not supported + in BIND 9, and is not expected to be added in future + releases. If it is present in the controls statement from a + BIND 8 configuration file, it is ignored + and a warning is logged. + + +To disable the command channel, use an empty controls +statement: controls { };. + + + + + <command>include</command> Statement Grammar + include filename; + + + <command>include</command> Statement Definition and Usage + + The include statement inserts the + specified file at the point where the include + statement is encountered. The include + statement facilitates the administration of configuration files + by permitting the reading or writing of some things but not + others. For example, the statement could include private keys + that are readable only by the name server. + + + + <command>key</command> Statement Grammar +key key_id { + algorithm string; + secret string; +}; + + + + +<command>key</command> Statement Definition and Usage + +The key statement defines a shared +secret key for use with TSIG (see ) +or the command channel +(see ). + + + +The key statement can occur at the top level +of the configuration file or inside a view +statement. Keys defined in top-level key +statements can be used in all views. Keys intended for use in +a controls statement +(see ) +must be defined at the top level. + + +The key_id, also known as the +key name, is a domain name uniquely identifying the key. It can +be used in a server +statement to cause requests sent to that +server to be signed with this key, or in address match lists to +verify that incoming requests have been signed with a key +matching this name, algorithm, and secret. + +The algorithm_id is a string +that specifies a security/authentication algorithm. The only +algorithm currently supported with TSIG authentication is +hmac-md5. The +secret_string is the secret to be +used by the algorithm, and is treated as a base-64 encoded +string. + + + + <command>logging</command> Statement Grammar + logging { + [ channel channel_name { + ( file path name + [ versions ( number | unlimited ) ] + [ size size spec ] + | syslog syslog_facility + | stderr + | null ); + [ severity ( | | | | + | [ level ] | ); ] + [ print-category or ; ] + [ print-severity or ; ] + [ print-time or ; ] + }; ] + [ category category_name { + channel_name ; [ channel_name ; ... ] + }; ] + ... +}; + + + + +<command>logging</command> Statement Definition and Usage + +The logging statement configures a wide +variety of logging options for the name server. Its channel phrase +associates output methods, format options and severity levels with +a name that can then be used with the category phrase +to select how various classes of messages are logged. +Only one logging statement is used to define +as many channels and categories as are wanted. If there is no logging statement, +the logging configuration will be: + +logging { + category default { default_syslog; default_debug; }; + category unmatched { null; }; +}; + + +In BIND 9, the logging configuration is only established when +the entire configuration file has been parsed. In BIND 8, it was +established as soon as the logging statement +was parsed. When the server is starting up, all logging messages +regarding syntax errors in the configuration file go to the default +channels, or to standard error if the "" option +was specified. + + +The <command>channel</command> Phrase + +All log output goes to one or more channels; +you can make as many of them as you want. + +Every channel definition must include a destination clause that +says whether messages selected for the channel go to a file, to a +particular syslog facility, to the standard error stream, or are +discarded. It can optionally also limit the message severity level +that will be accepted by the channel (the default is +info), and whether to include a +named-generated time stamp, the category name +and/or severity level (the default is not to include any). + +The null destination clause +causes all messages sent to the channel to be discarded; +in that case, other options for the channel are meaningless. + +The file destination clause directs the channel +to a disk file. It can include limitations +both on how large the file is allowed to become, and how many versions +of the file will be saved each time the file is opened. + +If you use the versions log file option, then +named will retain that many backup versions of the file by +renaming them when opening. For example, if you choose to keep 3 old versions +of the file lamers.log then just before it is opened +lamers.log.1 is renamed to +lamers.log.2, lamers.log.0 is renamed +to lamers.log.1, and lamers.log is +renamed to lamers.log.0. +You can say versions unlimited to not limit +the number of versions. +If a size option is associated with the log file, +then renaming is only done when the file being opened exceeds the +indicated size. No backup versions are kept by default; any existing +log file is simply appended. + +The size option for files is used to limit log +growth. If the file ever exceeds the size, then named will +stop writing to the file unless it has a versions option +associated with it. If backup versions are kept, the files are rolled as +described above and a new one begun. If there is no +versions option, no more data will be written to the log +until some out-of-band mechanism removes or truncates the log to less than the +maximum size. The default behavior is not to limit the size of the +file. + +Example usage of the size and +versions options: + +channel an_example_channel { + file "example.log" versions 3 size 20m; + print-time yes; + print-category yes; +}; + + +The syslog destination clause directs the +channel to the system log. Its argument is a +syslog facility as described in the syslog man +page. Known facilities are kern, user, +mail, daemon, auth, +syslog, lpr, news, +uucp, cron, authpriv, +ftp, local0, local1, +local2, local3, local4, +local5, local6 and +local7, however not all facilities are supported on +all operating systems. +How syslog will handle messages sent to +this facility is described in the syslog.conf man +page. If you have a system which uses a very old version of syslog that +only uses two arguments to the openlog() function, +then this clause is silently ignored. +The severity clause works like syslog's +"priorities", except that they can also be used if you are writing +straight to a file rather than using syslog. +Messages which are not at least of the severity level given will +not be selected for the channel; messages of higher severity levels +will be accepted. +If you are using syslog, then the syslog.conf priorities +will also determine what eventually passes through. For example, +defining a channel facility and severity as daemon and debug but +only logging daemon.warning via syslog.conf will +cause messages of severity info and notice to +be dropped. If the situation were reversed, with named writing +messages of only warning or higher, then syslogd would +print all messages it received from the channel. + +The stderr destination clause directs the +channel to the server's standard error stream. This is intended for +use when the server is running as a foreground process, for example +when debugging a configuration. + +The server can supply extensive debugging information when +it is in debugging mode. If the server's global debug level is greater +than zero, then debugging mode will be active. The global debug +level is set either by starting the named server +with the flag followed by a positive integer, +or by running rndc trace. +The global debug level +can be set to zero, and debugging mode turned off, by running ndc +notrace. All debugging messages in the server have a debug +level, and higher debug levels give more detailed output. Channels +that specify a specific debug severity, for example: +channel specific_debug_level { + file "foo"; + severity debug 3; +}; + + will get debugging output of level 3 or less any time the +server is in debugging mode, regardless of the global debugging +level. Channels with dynamic severity use the +server's global debug level to determine what messages to print. + If print-time has been turned on, then +the date and time will be logged. print-time may +be specified for a syslog channel, but is usually +pointless since syslog also prints the date and +time. If print-category is requested, then the +category of the message will be logged as well. Finally, if print-severity is +on, then the severity level of the message will be logged. The print- options may +be used in any combination, and will always be printed in the following +order: time, category, severity. Here is an example where all three print- options +are on: + +28-Feb-2000 15:05:32.863 general: notice: running + +There are four predefined channels that are used for +named's default logging as follows. How they are +used is described in . + + +channel default_syslog { + syslog daemon; // send to syslog's daemon + // facility + severity info; // only send priority info + // and higher +}; + +channel default_debug { + file "named.run"; // write to named.run in + // the working directory + // Note: stderr is used instead + // of "named.run" + // if the server is started + // with the '-f' option. + severity dynamic; // log at the server's + // current debug level +}; + +channel default_stderr { + stderr; // writes to stderr + severity info; // only send priority info + // and higher +}; + +channel null { + null; // toss anything sent to + // this channel +}; + + +The default_debug channel has the special +property that it only produces output when the server's debug level is +nonzero. It normally writes to a file named.run +in the server's working directory. + +For security reasons, when the "" +command line option is used, the named.run file +is created only after named has changed to the +new UID, and any debug output generated while named is +starting up and still running as root is discarded. If you need +to capture this output, you must run the server with the "" +option and redirect standard error to a file. + +Once a channel is defined, it cannot be redefined. Thus you +cannot alter the built-in channels directly, but you can modify +the default logging by pointing categories at channels you have defined. + + +The <command>category</command> Phrase + +There are many categories, so you can send the logs you want +to see wherever you want, without seeing logs you don't want. If +you don't specify a list of channels for a category, then log messages +in that category will be sent to the default category +instead. If you don't specify a default category, the following +"default default" is used: +category default { default_syslog; default_debug; }; + +As an example, let's say you want to log security events to +a file, but you also want keep the default logging behavior. You'd +specify the following: +channel my_security_channel { + file "my_security_file"; + severity info; +}; +category security { + my_security_channel; + default_syslog; + default_debug; +}; +To discard all messages in a category, specify the null channel: +category xfer-out { null; }; +category notify { null; }; + +Following are the available categories and brief descriptions +of the types of log information they contain. More +categories may be added in future BIND releases. + + + + + +default +The default category defines the logging +options for those categories where no specific configuration has been +defined. + + +general +The catch-all. Many things still aren't +classified into categories, and they all end up here. + + +database +Messages relating to the databases used +internally by the name server to store zone and cache data. + + +security +Approval and denial of requests. + + +config +Configuration file parsing and processing. + + +resolver +DNS resolution, such as the recursive +lookups performed on behalf of clients by a caching name server. + + +xfer-in +Zone transfers the server is receiving. + + +xfer-out +Zone transfers the server is sending. + + +notify +The NOTIFY protocol. + + +client +Processing of client requests. + + +unmatched +Messages that named was unable to determine the +class of or for which there was no matching view. +A one line summary is also logged to the client category. +This category is best sent to a file or stderr, by default it is sent to +the null channel. + + +network +Network operations. + + +update +Dynamic updates. + + +update-security +Approval and denial of update requests. + + +queries +Specify where queries should be logged to. + +At startup, specifing the category queries will also +enable query logging unless querylog option has been +specified. + + +The query log entry reports the client's IP address and port number. The +query name, class and type. It also reports whether the Recursion Desired +flag was set (+ if set, - if not set), EDNS was in use (E) or if the +query was signed (S). +client 127.0.0.1#62536: query: www.example.com IN AAAA +SE +client ::1#62537: query: www.example.net IN AAAA -SE + + + + +dispatch +Dispatching of incoming packets to the +server modules where they are to be processed. + + + +dnssec +DNSSEC and TSIG protocol processing. + + + +lame-servers +Lame servers. These are misconfigurations +in remote servers, discovered by BIND 9 when trying to query +those servers during resolution. + + + +delegation-only +Delegation only. Logs queries that have have +been forced to NXDOMAIN as the result of a delegation-only zone or +a delegation-only in a hint or stub zone declaration. + + + + + + + + +<command>lwres</command> Statement Grammar + + This is the grammar of the lwres +statement in the named.conf file: + +lwres { + listen-on { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + view view_name; + search { domain_name ; domain_name ; ... }; + ndots number; +}; + + + + +<command>lwres</command> Statement Definition and Usage + +The lwres statement configures the name +server to also act as a lightweight resolver server, see +. There may be be multiple +lwres statements configuring +lightweight resolver servers with different properties. + +The listen-on statement specifies a list of +addresses (and ports) that this instance of a lightweight resolver daemon +should accept requests on. If no port is specified, port 921 is used. +If this statement is omitted, requests will be accepted on 127.0.0.1, +port 921. + +The view statement binds this instance of a +lightweight resolver daemon to a view in the DNS namespace, so that the +response will be constructed in the same manner as a normal DNS query +matching this view. If this statement is omitted, the default view is +used, and if there is no default view, an error is triggered. + +The search statement is equivalent to the +search statement in +/etc/resolv.conf. It provides a list of domains +which are appended to relative names in queries. + +The ndots statement is equivalent to the +ndots statement in +/etc/resolv.conf. It indicates the minimum +number of dots in a relative domain name that should result in an +exact match lookup before search path elements are appended. + + + <command>masters</command> Statement Grammar + +masters name port ip_port { ( masters_list | ip_addr port ip_port key key ) ; ... } ; + + + + <command>masters</command> Statement Definition and Usage +masters lists allow for a common set of masters +to be easily used by multiple stub and slave zones. + + +<command>options</command> Statement Grammar + +This is the grammar of the options +statement in the named.conf file: + +options { + version version_string; + hostname hostname_string; + server-id server_id_string; + directory path_name; + key-directory path_name; + named-xfer path_name; + tkey-domain domainname; + tkey-dhkey key_name key_tag; + dump-file path_name; + memstatistics-file path_name; + pid-file path_name; + statistics-file path_name; + zone-statistics yes_or_no; + auth-nxdomain yes_or_no; + deallocate-on-exit yes_or_no; + dialup dialup_option; + fake-iquery yes_or_no; + fetch-glue yes_or_no; + flush-zones-on-shutdown yes_or_no; + has-old-clients yes_or_no; + host-statistics yes_or_no; + minimal-responses yes_or_no; + multiple-cnames yes_or_no; + notify yes_or_no | explicit; + recursion yes_or_no; + rfc2308-type1 yes_or_no; + use-id-pool yes_or_no; + maintain-ixfr-base yes_or_no; + dnssec-enable yes_or_no; + dnssec-lookaside domain trust-anchor domain; + dnssec-must-be-secure domain yes_or_no; + forward ( only | first ); + forwarders { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + dual-stack-servers port ip_port { ( domain_name port ip_port | ip_addr port ip_port ) ; ... }; + check-names ( master | slave | response )( warn | fail | ignore ); + allow-notify { address_match_list }; + allow-query { address_match_list }; + allow-transfer { address_match_list }; + allow-recursion { address_match_list }; + allow-update-forwarding { address_match_list }; + allow-v6-synthesis { address_match_list }; + blackhole { address_match_list }; + avoid-v4-udp-ports { port_list }; + avoid-v6-udp-ports { port_list }; + listen-on port ip_port { address_match_list }; + listen-on-v6 port ip_port { address_match_list }; + query-source address ( ip_addr | * ) port ( ip_port | * ) ; + query-source-v6 address ( ip_addr | * ) port ( ip_port | * ) ; + max-transfer-time-in number; + max-transfer-time-out number; + max-transfer-idle-in number; + max-transfer-idle-out number; + tcp-clients number; + recursive-clients number; + serial-query-rate number; + serial-queries number; + tcp-listen-queue number; + transfer-format ( one-answer | many-answers ); + transfers-in number; + transfers-out number; + transfers-per-ns number; + transfer-source (ip4_addr | *) port ip_port ; + transfer-source-v6 (ip6_addr | *) port ip_port ; + alt-transfer-source (ip4_addr | *) port ip_port ; + alt-transfer-source-v6 (ip6_addr | *) port ip_port ; + use-alt-transfer-source yes_or_no; + notify-source (ip4_addr | *) port ip_port ; + notify-source-v6 (ip6_addr | *) port ip_port ; + also-notify { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + max-ixfr-log-size number; + max-journal-size size_spec; + coresize size_spec ; + datasize size_spec ; + files size_spec ; + stacksize size_spec ; + cleaning-interval number; + heartbeat-interval number; + interface-interval number; + statistics-interval number; + topology { address_match_list }; + sortlist { address_match_list }; + rrset-order { order_spec ; order_spec ; ... }; + lame-ttl number; + max-ncache-ttl number; + max-cache-ttl number; + sig-validity-interval number ; + min-roots number; + use-ixfr yes_or_no ; + provide-ixfr yes_or_no; + request-ixfr yes_or_no; + treat-cr-as-space yes_or_no ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + port ip_port; + additional-from-auth yes_or_no ; + additional-from-cache yes_or_no ; + random-device path_name ; + max-cache-size size_spec ; + match-mapped-addresses yes_or_no; + preferred-glue ( A | AAAA | NONE ); + edns-udp-size number; + root-delegation-only exclude { namelist } ; + querylog yes_or_no ; +}; + disable-algorithms domain { algorithm; algorithm; }; + + + +<command>options</command> Statement Definition and Usage + +The options statement sets up global options +to be used by BIND. This statement may appear only +once in a configuration file. If there is no options +statement, an options block with each option set to its default will +be used. + + + +directory +The working directory of the server. +Any non-absolute pathnames in the configuration file will be taken +as relative to this directory. The default location for most server +output files (e.g. named.run) is this directory. +If a directory is not specified, the working directory defaults +to `.', the directory from which the server +was started. The directory specified should be an absolute path. + + +key-directory +When performing dynamic update of secure zones, the +directory where the public and private key files should be found, +if different than the current working directory. The directory specified +must be an absolute path. + + +named-xfer +This option is obsolete. +It was used in BIND 8 to +specify the pathname to the named-xfer program. +In BIND 9, no separate named-xfer program is +needed; its functionality is built into the name server. + + + +tkey-domain +The domain appended to the names of all +shared keys generated with TKEY. When a client +requests a TKEY exchange, it may or may not specify +the desired name for the key. If present, the name of the shared +key will be "client specified part" + +"tkey-domain". +Otherwise, the name of the shared key will be "random hex +digits" + "tkey-domain". In most cases, +the domainname should be the server's domain +name. + + +tkey-dhkey +The Diffie-Hellman key used by the server +to generate shared keys with clients using the Diffie-Hellman mode +of TKEY. The server must be able to load the +public and private keys from files in the working directory. In +most cases, the keyname should be the server's host name. + + +dump-file +The pathname of the file the server dumps +the database to when instructed to do so with +rndc dumpdb. +If not specified, the default is named_dump.db. + +memstatistics-file +The pathname of the file the server writes memory +usage statistics to on exit. If not specified, +the default is named.memstats. + + +pid-file +The pathname of the file the server writes its process ID +in. If not specified, the default is /var/run/named.pid. +The pid-file is used by programs that want to send signals to the running +name server. Specifying pid-file none disables the +use of a PID file — no file will be written and any +existing one will be removed. Note that none +is a keyword, not a file name, and therefore is not enclosed in +double quotes. + + +statistics-file +The pathname of the file the server appends statistics +to when instructed to do so using rndc stats. +If not specified, the default is named.stats in the +server's current directory. The format of the file is described +in + + +port + +The UDP/TCP port number the server uses for +receiving and sending DNS protocol traffic. +The default is 53. This option is mainly intended for server testing; +a server using a port other than 53 will not be able to communicate with +the global DNS. + + + +random-device + +The source of entropy to be used by the server. Entropy is primarily needed +for DNSSEC operations, such as TKEY transactions and dynamic update of signed +zones. This options specifies the device (or file) from which to read +entropy. If this is a file, operations requiring entropy will fail when the +file has been exhausted. If not specified, the default value is +/dev/random +(or equivalent) when present, and none otherwise. The +random-device option takes effect during +the initial configuration load at server startup time and +is ignored on subsequent reloads. + + +preferred-glue + +If specified the listed type (A or AAAA) will be emitted before other glue +in the additional section of a query response. +The default is not to preference any type (NONE). + + + +root-delegation-only + +Turn on enforcement of delegation-only in TLDs and root zones with an optional +exclude list. + + +Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM"). + + +options { + root-delegation-only exclude { "de"; "lv"; "us"; "museum"; }; +}; + + + +disable-algorithms + +Disable the specified DNSSEC algorithms at and below the specified name. +Multiple disable-algorithms statements are allowed. +Only the most specific will be applied. + + +dnssec-lookaside + +When set dnssec-lookaside provides the +validator with an alternate method to validate DNSKEY records at the +top of a zone. When a DNSKEY is at or below a domain specified by the +deepest dnssec-lookaside, and the normal dnssec validation +has left the key untrusted, the trust-anchor will be append to the key +name and a DLV record will be looked up to see if it can validate the +key. If the DLV record validates a DNSKEY (similarly to the way a DS +record does) the DNSKEY RRset is deemed to be trusted. + + +dnssec-must-be-secure + +Specify heirachies which must / may not be secure (signed and validated). +If yes then named will only accept answers if they +are secure. +If no then normal dnssec validation applies +allowing for insecure answers to be accepted. +The specified domain must be under a trusted-key or +dnssec-lookaside must be active. + + + + +Boolean Options + + + +auth-nxdomain +If yes, then the AA bit +is always set on NXDOMAIN responses, even if the server is not actually +authoritative. The default is no; this is +a change from BIND 8. If you are using very old DNS software, you +may need to set it to yes. + +deallocate-on-exit +This option was used in BIND 8 to enable checking +for memory leaks on exit. BIND 9 ignores the option and always performs +the checks. + +dialup +If yes, then the +server treats all zones as if they are doing zone transfers across +a dial on demand dialup link, which can be brought up by traffic +originating from this server. This has different effects according +to zone type and concentrates the zone maintenance so that it all +happens in a short interval, once every heartbeat-interval and +hopefully during the one call. It also suppresses some of the normal +zone maintenance traffic. The default is no. +The dialup option +may also be specified in the view and +zone statements, +in which case it overrides the global dialup +option. +If the zone is a master zone then the server will send out a NOTIFY +request to all the slaves (default). This should trigger the zone serial +number check in the slave (providing it supports NOTIFY) allowing the slave +to verify the zone while the connection is active. +The set of servers to which NOTIFY is sent can be controlled by +notify and also-notify. +If the +zone is a slave or stub zone, then the server will suppress the regular +"zone up to date" (refresh) queries and only perform them when the +heartbeat-interval expires in addition to sending +NOTIFY requests.Finer control can be achieved by using +notify which only sends NOTIFY messages, +notify-passive which sends NOTIFY messages and +suppresses the normal refresh queries, refresh +which suppresses normal refresh processing and sends refresh queries +when the heartbeat-interval expires, and +passive which just disables normal refresh +processing. + + + + + + + + + +dialup mode +normal refresh +heart-beat refresh +heart-beat notify + + +no (default) +yes +no +no + + +yes +no +yes +yes + + +notify +yes +no +yes + + +refresh +no +yes +no + + +passive +no +no +no + + +notify-passive +no +no +yes + + + + +Note that normal NOTIFY processing is not affected by +dialup. + + + +fake-iquery +In BIND 8, this option +enabled simulating the obsolete DNS query type +IQUERY. BIND 9 never does IQUERY simulation. + + +fetch-glue +This option is obsolete. +In BIND 8, fetch-glue yes +caused the server to attempt to fetch glue resource records it +didn't have when constructing the additional +data section of a response. This is now considered a bad idea +and BIND 9 never does it. + +flush-zones-on-shutdown +When the nameserver exits due receiving SIGTERM, +flush / do not flush any pending zone writes. The default is +flush-zones-on-shutdown no. + + +has-old-clients +This option was incorrectly implemented +in BIND 8, and is ignored by BIND 9. +To achieve the intended effect +of +has-old-clients yes, specify +the two separate options auth-nxdomain yes +and rfc2308-type1 no instead. + + +host-statistics +In BIND 8, this enables keeping of +statistics for every host that the name server interacts with. +Not implemented in BIND 9. + + +maintain-ixfr-base +This option is obsolete. + It was used in BIND 8 to determine whether a transaction log was +kept for Incremental Zone Transfer. BIND 9 maintains a transaction +log whenever possible. If you need to disable outgoing incremental zone +transfers, use provide-ixfr no. + + +minimal-responses +If yes, then when generating +responses the server will only add records to the authority and +additional data sections when they are required (e.g. delegations, +negative responses). This may improve the performance of the server. +The default is no. + + +multiple-cnames +This option was used in BIND 8 to allow +a domain name to have multiple CNAME records in violation of the +DNS standards. BIND 9.2 always strictly +enforces the CNAME rules both in master files and dynamic updates. + + +notify +If yes (the default), +DNS NOTIFY messages are sent when a zone the server is authoritative for +changes, see . The messages are sent to the +servers listed in the zone's NS records (except the master server identified +in the SOA MNAME field), and to any servers listed in the +also-notify option. + +If explicit, notifies are sent only to +servers explicitly listed using also-notify. +If no, no notifies are sent. + +The notify option may also be +specified in the zone statement, +in which case it overrides the options notify statement. +It would only be necessary to turn off this option if it caused slaves +to crash. + +recursion +If yes, and a +DNS query requests recursion, then the server will attempt to do +all the work required to answer the query. If recursion is off +and the server does not already know the answer, it will return a +referral response. The default is yes. +Note that setting recursion no does not prevent +clients from getting data from the server's cache; it only +prevents new data from being cached as an effect of client queries. +Caching may still occur as an effect the server's internal +operation, such as NOTIFY address lookups. +See also fetch-glue above. + + +rfc2308-type1 +Setting this to yes will +cause the server to send NS records along with the SOA record for negative +answers. The default is no. +Not yet implemented in BIND 9. + + +use-id-pool +This option is obsolete. +BIND 9 always allocates query IDs from a pool. + + +zone-statistics +If yes, the server will collect +statistical data on all zones (unless specifically turned off +on a per-zone basis by specifying zone-statistics no +in the zone statement). These statistics may be accessed +using rndc stats, which will dump them to the file listed +in the statistics-file. See also . + + +use-ixfr +This option is obsolete. +If you need to disable IXFR to a particular server or servers see +the information on the provide-ixfr option +in . See also +. + + +provide-ixfr + + +See the description of +provide-ixfr in + + + +request-ixfr + + +See the description of +request-ixfr in + + + +treat-cr-as-space +This option was used in BIND 8 to make +the server treat carriage return ("\r") characters the same way +as a space or tab character, +to facilitate loading of zone files on a UNIX system that were generated +on an NT or DOS machine. In BIND 9, both UNIX "\n" +and NT/DOS "\r\n" newlines are always accepted, +and the option is ignored. + + +additional-from-auth +additional-from-cache + + + +These options control the behavior of an authoritative server when +answering queries which have additional data, or when following CNAME +and DNAME chains. + + + +When both of these options are set to yes +(the default) and a +query is being answered from authoritative data (a zone +configured into the server), the additional data section of the +reply will be filled in using data from other authoritative zones +and from the cache. In some situations this is undesirable, such +as when there is concern over the correctness of the cache, or +in servers where slave zones may be added and modified by +untrusted third parties. Also, avoiding +the search for this additional data will speed up server operations +at the possible expense of additional queries to resolve what would +otherwise be provided in the additional section. + + + +For example, if a query asks for an MX record for host foo.example.com, +and the record found is "MX 10 mail.example.net", normally the address +records (A and AAAA) for mail.example.net will be provided as well, +if known, even though they are not in the example.com zone. +Setting these options to no disables this behavior and makes +the server only search for additional data in the zone it answers from. + + + +These options are intended for use in authoritative-only +servers, or in authoritative-only views. Attempts to set +them to no without also specifying +recursion no will cause the server to +ignore the options and log a warning message. + + + +Specifying additional-from-cache no actually +disables the use of the cache not only for additional data lookups +but also when looking up the answer. This is usually the desired +behavior in an authoritative-only server where the correctness of +the cached data is an issue. + + + +When a name server is non-recursively queried for a name that is not +below the apex of any served zone, it normally answers with an +"upwards referral" to the root servers or the servers of some other +known parent of the query name. Since the data in an upwards referral +comes from the cache, the server will not be able to provide upwards +referrals when additional-from-cache no +has been specified. Instead, it will respond to such queries +with REFUSED. This should not cause any problems since +upwards referrals are not required for the resolution process. + + + + +match-mapped-addresses +If yes, then an +IPv4-mapped IPv6 address will match any address match +list entries that match the corresponding IPv4 address. +Enabling this option is sometimes useful on IPv6-enabled Linux +systems, to work around a kernel quirk that causes IPv4 +TCP connections such as zone transfers to be accepted +on an IPv6 socket using mapped addresses, causing +address match lists designed for IPv4 to fail to match. +The use of this option for any other purpose is discouraged. + + +ixfr-from-differences + + +When 'yes' and the server loads a new version of a master +zone from its zone file or receives a new version of a slave +file by a non-incremental zone transfer, it will compare +the new version to the previous one and calculate a set +of differences. The differences are then logged in the +zone's journal file such that the changes can be transmitted +to downstream slaves as an incremental zone transfer. + +By allowing incremental zone transfers to be used for +non-dynamic zones, this option saves bandwidth at the +expense of increased CPU and memory consumption at the master. +In particular, if the new version of a zone is completely +different from the previous one, the set of differences +will be of a size comparable to the combined size of the +old and new zone version, and the server will need to +temporarily allocate memory to hold this complete +difference set. + + +multi-master + + +This should be set when you have multiple masters for a zone and the +addresses refer to different machines. If 'yes' named will not log +when the serial number on the master is less than what named currently +has. The default is no. + + +dnssec-enable + + +Enable DNSSEC support in named. Unless set to yes +named behaves as if it does not support DNSSEC. +The default is no. + + +querylog + + +Specify whether query logging should be started when named start. +If querylog is not specified then the query logging +is determined by the presence of the logging category queries. + + + + + + +Forwarding +The forwarding facility can be used to create a large site-wide +cache on a few servers, reducing traffic over links to external +name servers. It can also be used to allow queries by servers that +do not have direct access to the Internet, but wish to look up exterior +names anyway. Forwarding occurs only on those queries for which +the server is not authoritative and does not have the answer in +its cache. + + +forward +This option is only meaningful if the +forwarders list is not empty. A value of first, +the default, causes the server to query the forwarders first, and +if that doesn't answer the question the server will then look for +the answer itself. If only is specified, the +server will only query the forwarders. + + +forwarders +Specifies the IP addresses to be used +for forwarding. The default is the empty list (no forwarding). + + + + +Forwarding can also be configured on a per-domain basis, allowing +for the global forwarding options to be overridden in a variety +of ways. You can set particular domains to use different forwarders, +or have a different forward only/first behavior, +or not forward at all, see . + + +Dual-stack Servers +Dual-stack servers are used as servers of last resort to work around +problems in reachability due the lack of support for either IPv4 or IPv6 +on the host machine. + + +dual-stack-servers +Specifies host names / addresses of machines with access to +both IPv4 and IPv6 transports. If a hostname is used the server must be able +to resolve the name using only the transport it has. If the machine is dual +stacked then the dual-stack-servers have no effect unless +access to a transport has been disabled on the command line +(e.g. named -4). + + + + +Access Control + +Access to the server can be restricted based on the IP address +of the requesting system. See for +details on how to specify IP address lists. + + + +allow-notify +Specifies which hosts are allowed to +notify this server, a slave, of zone changes in addition +to the zone masters. +allow-notify may also be specified in the +zone statement, in which case it overrides the +options allow-notify statement. It is only meaningful +for a slave zone. If not specified, the default is to process notify messages +only from a zone's master. + + +allow-query +Specifies which hosts are allowed to +ask ordinary DNS questions. allow-query may also +be specified in the zone statement, in which +case it overrides the options allow-query statement. If +not specified, the default is to allow queries from all hosts. + + + +allow-recursion +Specifies which hosts are allowed to +make recursive queries through this server. If not specified, the +default is to allow recursive queries from all hosts. +Note that disallowing recursive queries for a host does not prevent the +host from retrieving data that is already in the server's cache. + + + +allow-update-forwarding +Specifies which hosts are allowed to +submit Dynamic DNS updates to slave zones to be forwarded to the +master. The default is { none; }, which +means that no update forwarding will be performed. To enable +update forwarding, specify +allow-update-forwarding { any; };. +Specifying values other than { none; } or +{ any; } is usually counterproductive, since +the responsibility for update access control should rest with the +master server, not the slaves. +Note that enabling the update forwarding feature on a slave server +may expose master servers relying on insecure IP address based +access control to attacks; see +for more details. + + +allow-v6-synthesis +This option was introduced for the smooth transition from AAAA +to A6 and from "nibble labels" to binary labels. +However, since both A6 and binary labels were then deprecated, +this option was also deprecated. +It is now ignored with some warning messages. + + + +allow-transfer +Specifies which hosts are allowed to +receive zone transfers from the server. allow-transfer may +also be specified in the zone statement, in which +case it overrides the options allow-transfer statement. +If not specified, the default is to allow transfers to all hosts. + + +blackhole +Specifies a list of addresses that the +server will not accept queries from or use to resolve a query. Queries +from these addresses will not be responded to. The default is none. + + + + + + +Interfaces +The interfaces and ports that the server will answer queries +from may be specified using the listen-on option. listen-on takes +an optional port, and an address_match_list. +The server will listen on all interfaces allowed by the address +match list. If a port is not specified, port 53 will be used. +Multiple listen-on statements are allowed. +For example, + +listen-on { 5.6.7.8; }; +listen-on port 1234 { !1.2.3.4; 1.2/16; }; + + +will enable the name server on port 53 for the IP address +5.6.7.8, and on port 1234 of an address on the machine in net +1.2 that is not 1.2.3.4. + +If no listen-on is specified, the +server will listen on port 53 on all interfaces. + +The listen-on-v6 option is used to +specify the interfaces and the ports on which the server will listen +for incoming queries sent using IPv6. + +When { any; } is specified +as the address_match_list for the +listen-on-v6 option, +the server does not bind a separate socket to each IPv6 interface +address as it does for IPv4 if the operating system has enough API +support for IPv6 (specifically if it conforms to RFC 3493 and RFC 3542). +Instead, it listens on the IPv6 wildcard address. +If the system only has incomplete API support for IPv6, however, +the behavior is the same as that for IPv4. + +A list of particular IPv6 addresses can also be specified, in which case +the server listens on a separate socket for each specified address, +regardless of whether the desired API is supported by the system. + +Multiple listen-on-v6 options can be used. +For example, + +listen-on-v6 { any; }; +listen-on-v6 port 1234 { !2001:db8::/32; any; }; + + +will enable the name server on port 53 for any IPv6 addresses +(with a single wildcard socket), +and on port 1234 of IPv6 addresses that is not in the prefix +2001:db8::/32 (with separate sockets for each matched address.) + +To make the server not listen on any IPv6 address, use +listen-on-v6 { none; }; + +If no listen-on-v6 option is specified, +the server will not listen on any IPv6 address. + +Query Address +If the server doesn't know the answer to a question, it will +query other name servers. query-source specifies +the address and port used for such queries. For queries sent over +IPv6, there is a separate query-source-v6 option. +If address is * or is omitted, +a wildcard IP address (INADDR_ANY) will be used. +If port is * or is omitted, +a random unprivileged port will be used, avoid-v4-udp-ports +and avoid-v6-udp-ports can be used to prevent named +from selecting certain ports. The defaults are +query-source address * port *; +query-source-v6 address * port *; + + +The address specified in the query-source option +is used for both UDP and TCP queries, but the port applies only to +UDP queries. TCP queries always use a random +unprivileged port. + +See also transfer-source and +notify-source. + + +Zone Transfers +BIND has mechanisms in place to facilitate zone transfers +and set limits on the amount of load that transfers place on the +system. The following options apply to zone transfers. + + + +also-notify +Defines a global list of IP addresses of name servers +that are also sent NOTIFY messages whenever a fresh copy of the +zone is loaded, in addition to the servers listed in the zone's NS records. +This helps to ensure that copies of the zones will +quickly converge on stealth servers. If an also-notify list +is given in a zone statement, it will override +the options also-notify statement. When a zone notify statement +is set to no, the IP addresses in the global also-notify list will +not be sent NOTIFY messages for that zone. The default is the empty +list (no global notification list). + + +max-transfer-time-in +Inbound zone transfers running longer than +this many minutes will be terminated. The default is 120 minutes +(2 hours). The maximum value is 28 days (40320 minutes). + + +max-transfer-idle-in +Inbound zone transfers making no progress +in this many minutes will be terminated. The default is 60 minutes +(1 hour). The maximum value is 28 days (40320 minutes). + + +max-transfer-time-out +Outbound zone transfers running longer than +this many minutes will be terminated. The default is 120 minutes +(2 hours). The maximum value is 28 days (40320 minutes). + + +max-transfer-idle-out +Outbound zone transfers making no progress +in this many minutes will be terminated. The default is 60 minutes (1 +hour). The maximum value is 28 days (40320 minutes). + + +serial-query-rate +Slave servers will periodically query master servers +to find out if zone serial numbers have changed. Each such query uses +a minute amount of the slave server's network bandwidth. To limit the +amount of bandwidth used, BIND 9 limits the rate at which queries are +sent. The value of the serial-query-rate option, +an integer, is the maximum number of queries sent per second. +The default is 20. + + + +serial-queries +In BIND 8, the serial-queries option +set the maximum number of concurrent serial number queries +allowed to be outstanding at any given time. +BIND 9 does not limit the number of outstanding +serial queries and ignores the serial-queries option. +Instead, it limits the rate at which the queries are sent +as defined using the serial-query-rate option. + + + +transfer-format + + + +Zone transfers can be sent using two different formats, +one-answer and many-answers. +The transfer-format option is used +on the master server to determine which format it sends. +one-answer uses one DNS message per +resource record transferred. +many-answers packs as many resource records as +possible into a message. many-answers is more +efficient, but is only supported by relatively new slave servers, +such as BIND 9, BIND 8.x and patched +versions of BIND 4.9.5. The default is +many-answers. transfer-format +may be overridden on a per-server basis by using the +server statement. + + + + +transfers-in +The maximum number of inbound zone transfers +that can be running concurrently. The default value is 10. +Increasing transfers-in may speed up the convergence +of slave zones, but it also may increase the load on the local system. + + +transfers-out +The maximum number of outbound zone transfers +that can be running concurrently. Zone transfer requests in excess +of the limit will be refused. The default value is 10. + + +transfers-per-ns +The maximum number of inbound zone transfers +that can be concurrently transferring from a given remote name server. +The default value is 2. Increasing transfers-per-ns may +speed up the convergence of slave zones, but it also may increase +the load on the remote name server. transfers-per-ns may +be overridden on a per-server basis by using the transfers phrase +of the server statement. + + +transfer-source +transfer-source determines +which local address will be bound to IPv4 TCP connections used to +fetch zones transferred inbound by the server. It also determines +the source IPv4 address, and optionally the UDP port, used for the +refresh queries and forwarded dynamic updates. If not set, it defaults +to a system controlled value which will usually be the address of +the interface "closest to" the remote end. This address must appear +in the remote end's allow-transfer option for +the zone being transferred, if one is specified. This statement +sets the transfer-source for all zones, but can +be overridden on a per-view or per-zone basis by including a +transfer-source statement within the +view or zone block +in the configuration file. + + +transfer-source-v6 +The same as transfer-source, +except zone transfers are performed using IPv6. + + +alt-transfer-source +An alternate transfer source if the one listed in +transfer-source fails and +use-alt-transfer-source is set. + + +alt-transfer-source-v6 +An alternate transfer source if the one listed in +transfer-source-v6 fails and +use-alt-transfer-source is set. + + +use-alt-transfer-source +Use the alternate transfer sources or not. If views are +specified this defaults to no otherwise it defaults to +yes (for BIND 8 compatibility). + + +notify-source +notify-source determines +which local source address, and optionally UDP port, will be used to +send NOTIFY messages. +This address must appear in the slave server's masters +zone clause or in an allow-notify clause. +This statement sets the notify-source for all zones, +but can be overridden on a per-zone / per-view basis by including a +notify-source statement within the zone +or view block in the configuration file. + + +notify-source-v6 +Like notify-source, +but applies to notify messages sent to IPv6 addresses. + + + + + + + +Bad UDP Port Lists + +avoid-v4-udp-ports and avoid-v6-udp-ports +specify a list of IPv4 and IPv6 UDP ports that will not be used as system +assigned source ports for UDP sockets. These lists prevent named +from choosing as its random source port a port that is blocked by +your firewall. If a query went out with such a source port, the +answer would not get by the firewall and the name server would have +to query again. + + + + +Operating System Resource Limits + +The server's usage of many system resources can be limited. +Scaled values are allowed when specifying resource limits. For +example, 1G can be used instead of +1073741824 to specify a limit of one +gigabyte. unlimited requests unlimited use, or the +maximum available amount. default uses the limit +that was in force when the server was started. See the description of +size_spec in . + +The following options set operating system resource limits for +the name server process. Some operating systems don't support some or +any of the limits. On such systems, a warning will be issued if the +unsupported limit is used. + + + +coresize +The maximum size of a core dump. The default +is default. + + +datasize +The maximum amount of data memory the server +may use. The default is default. +This is a hard limit on server memory usage. +If the server attempts to allocate memory in excess of this +limit, the allocation will fail, which may in turn leave +the server unable to perform DNS service. Therefore, +this option is rarely useful as a way of limiting the +amount of memory used by the server, but it can be used +to raise an operating system data size limit that is +too small by default. If you wish to limit the amount +of memory used by the server, use the +max-cache-size and +recursive-clients +options instead. + + +files +The maximum number of files the server +may have open concurrently. The default is unlimited. + + + +stacksize +The maximum amount of stack memory the server +may use. The default is default. + + + + + + + +Server Resource Limits + +The following options set limits on the server's +resource consumption that are enforced internally by the +server rather than the operating system. + + + +max-ixfr-log-size +This option is obsolete; it is accepted +and ignored for BIND 8 compatibility. The option +max-journal-size performs a similar +function in BIND 8. + + + +max-journal-size +Sets a maximum size for each journal file +(). When the journal file approaches +the specified size, some of the oldest transactions in the journal +will be automatically removed. The default is +unlimited. + + +recursive-clients +The maximum number of simultaneous recursive lookups +the server will perform on behalf of clients. The default is +1000. Because each recursing client uses a fair +bit of memory, on the order of 20 kilobytes, the value of the +recursive-clients option may have to be decreased +on hosts with limited memory. + + + +tcp-clients +The maximum number of simultaneous client TCP +connections that the server will accept. +The default is 100. + + +max-cache-size +The maximum amount of memory to use for the +server's cache, in bytes. When the amount of data in the cache +reaches this limit, the server will cause records to expire +prematurely so that the limit is not exceeded. In a server with +multiple views, the limit applies separately to the cache of each +view. The default is unlimited, meaning that +records are purged from the cache only when their TTLs expire. + + + +tcp-listen-queue +The listen queue depth. The default and minimum is 3. +If the kernel supports the accept filter "dataready" this also controls how +many TCP connections that will be queued in kernel space waiting for +some data before being passed to accept. Values less than 3 will be +silently raised. + + + + + + + +Periodic Task Intervals + + + +cleaning-interval +The server will remove expired resource records +from the cache every cleaning-interval minutes. +The default is 60 minutes. The maximum value is 28 days (40320 minutes). +If set to 0, no periodic cleaning will occur. + + +heartbeat-interval +The server will perform zone maintenance tasks +for all zones marked as dialup whenever this +interval expires. The default is 60 minutes. Reasonable values are up +to 1 day (1440 minutes). The maximum value is 28 days (40320 minutes). +If set to 0, no zone maintenance for these zones will occur. + + +interface-interval +The server will scan the network interface list +every interface-interval minutes. The default +is 60 minutes. The maximum value is 28 days (40320 minutes). +If set to 0, interface scanning will only occur when +the configuration file is loaded. After the scan, the server will +begin listening for queries on any newly discovered +interfaces (provided they are allowed by the +listen-on configuration), and will +stop listening on interfaces that have gone away. + + +statistics-interval +Name server statistics will be logged +every statistics-interval minutes. The default is +60. The maximum value is 28 days (40320 minutes). +If set to 0, no statistics will be logged. +Not yet implemented in BIND9. + + + + + + +Topology + +All other things being equal, when the server chooses a name server +to query from a list of name servers, it prefers the one that is +topologically closest to itself. The topology statement +takes an address_match_list and interprets it +in a special way. Each top-level list element is assigned a distance. +Non-negated elements get a distance based on their position in the +list, where the closer the match is to the start of the list, the +shorter the distance is between it and the server. A negated match +will be assigned the maximum distance from the server. If there +is no match, the address will get a distance which is further than +any non-negated list element, and closer than any negated element. +For example, +topology { + 10/8; + !1.2.3/24; + { 1.2/16; 3/8; }; +}; +will prefer servers on network 10 the most, followed by hosts +on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the +exception of hosts on network 1.2.3 (netmask 255.255.255.0), which +is preferred least of all. +The default topology is + topology { localhost; localnets; }; + +The topology option +is not implemented in BIND 9. + + + + + +The <command>sortlist</command> Statement + +The response to a DNS query may consist of multiple resource +records (RRs) forming a resource records set (RRset). +The name server will normally return the +RRs within the RRset in an indeterminate order +(but see the rrset-order +statement in ). +The client resolver code should rearrange the RRs as appropriate, +that is, using any addresses on the local net in preference to other addresses. +However, not all resolvers can do this or are correctly configured. +When a client is using a local server the sorting can be performed +in the server, based on the client's address. This only requires +configuring the name servers, not all the clients. + +The sortlist statement (see below) takes +an address_match_list and interprets it even +more specifically than the topology statement +does (). +Each top level statement in the sortlist must +itself be an explicit address_match_list with +one or two elements. The first element (which may be an IP address, +an IP prefix, an ACL name or a nested address_match_list) +of each top level list is checked against the source address of +the query until a match is found. +Once the source address of the query has been matched, if +the top level statement contains only one element, the actual primitive +element that matched the source address is used to select the address +in the response to move to the beginning of the response. If the +statement is a list of two elements, then the second element is +treated the same as the address_match_list in +a topology statement. Each top level element +is assigned a distance and the address in the response with the minimum +distance is moved to the beginning of the response. +In the following example, any queries received from any of +the addresses of the host itself will get responses preferring addresses +on any of the locally connected networks. Next most preferred are addresses +on the 192.168.1/24 network, and after that either the 192.168.2/24 +or +192.168.3/24 network with no preference shown between these two +networks. Queries received from a host on the 192.168.1/24 network +will prefer other addresses on that network to the 192.168.2/24 +and +192.168.3/24 networks. Queries received from a host on the 192.168.4/24 +or the 192.168.5/24 network will only prefer other addresses on +their directly connected networks. +sortlist { + { localhost; // IF the local host + { localnets; // THEN first fit on the + 192.168.1/24; // following nets + { 192.168.2/24; 192.168.3/24; }; }; }; + { 192.168.1/24; // IF on class C 192.168.1 + { 192.168.1/24; // THEN use .1, or .2 or .3 + { 192.168.2/24; 192.168.3/24; }; }; }; + { 192.168.2/24; // IF on class C 192.168.2 + { 192.168.2/24; // THEN use .2, or .1 or .3 + { 192.168.1/24; 192.168.3/24; }; }; }; + { 192.168.3/24; // IF on class C 192.168.3 + { 192.168.3/24; // THEN use .3, or .1 or .2 + { 192.168.1/24; 192.168.2/24; }; }; }; + { { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net + }; +}; +The following example will give reasonable behavior for the +local host and hosts on directly connected networks. It is similar +to the behavior of the address sort in BIND 4.9.x. Responses sent +to queries from the local host will favor any of the directly connected +networks. Responses sent to queries from any other hosts on a directly +connected network will prefer addresses on that same network. Responses +to other queries will not be sorted. +sortlist { + { localhost; localnets; }; + { localnets; }; +}; + + +RRset Ordering +When multiple records are returned in an answer it may be +useful to configure the order of the records placed into the response. +The rrset-order statement permits configuration +of the ordering of the records in a multiple record response. +See also the sortlist statement, +. + + +An order_spec is defined as follows: + class class_name type type_name name "domain_name" + order ordering + +If no class is specified, the default is ANY. +If no type is specified, the default is ANY. +If no name is specified, the default is "*". +The legal values for ordering are: + + + + + +fixed +Records are returned in the order they +are defined in the zone file. + + +random +Records are returned in some random order. + + +cyclic +Records are returned in a round-robin +order. + + + +For example: +rrset-order { + class IN type A name "host.example.com" order random; + order cyclic; +}; + +will cause any responses for type A records in class IN that +have "host.example.com" as a suffix, to always be returned +in random order. All other records are returned in cyclic order. +If multiple rrset-order statements appear, +they are not combined — the last one applies. + + +The rrset-order statement +is not yet fully implemented in BIND 9. +BIND 9 currently does not support "fixed" ordering. + + + +Tuning + + + +lame-ttl +Sets the number of seconds to cache a +lame server indication. 0 disables caching. (This is +NOT recommended.) +Default is 600 (10 minutes). Maximum value is +1800 (30 minutes). + + + +max-ncache-ttl +To reduce network traffic and increase performance +the server stores negative answers. max-ncache-ttl is +used to set a maximum retention time for these answers in the server +in seconds. The default +max-ncache-ttl is 10800 seconds (3 hours). +max-ncache-ttl cannot exceed 7 days and will +be silently truncated to 7 days if set to a greater value. + + +max-cache-ttl +max-cache-ttl sets +the maximum time for which the server will cache ordinary (positive) +answers. The default is one week (7 days). + + +min-roots +The minimum number of root servers that +is required for a request for the root servers to be accepted. Default +is 2. + +Not implemented in BIND9. + + +sig-validity-interval +Specifies the number of days into the +future when DNSSEC signatures automatically generated as a result +of dynamic updates () +will expire. The default is 30 days. +The maximum value is 10 years (3660 days). The signature +inception time is unconditionally set to one hour before the current time +to allow for a limited amount of clock skew. + + + +min-refresh-time +max-refresh-time +min-retry-time +max-retry-time + +These options control the server's behavior on refreshing a zone +(querying for SOA changes) or retrying failed transfers. +Usually the SOA values for the zone are used, but these values +are set by the master, giving slave server administrators little +control over their contents. + +These options allow the administrator to set a minimum and maximum +refresh and retry time either per-zone, per-view, or globally. +These options are valid for slave and stub zones, +and clamp the SOA refresh and retry times to the specified values. + + + +edns-udp-size + +edns-udp-size sets the advertised EDNS UDP buffer +size. Valid values are 512 to 4096 (values outside this range will be +silently adjusted). The default value is 4096. The usual reason for +setting edns-udp-size to a non default value it to get UDP answers to +pass through broken firewalls that block fragmented packets and/or +block UDP packets that are greater than 512 bytes. + + + + + + +Built-in server information zones + +The server provides some helpful diagnostic information +through a number of built-in zones under the +pseudo-top-level-domain bind in the +CHAOS class. These zones are part of a +built-in view (see ) of class +CHAOS which is separate from the default view of +class IN; therefore, any global server options +such as allow-query do not apply the these zones. +If you feel the need to disable these zones, use the options +below, or hide the built-in CHAOS view by +defining an explicit view of class CHAOS +that matches all clients. + + + +version +The version the server should report +via a query of the name version.bind +with type TXT, class CHAOS. +The default is the real version number of this server. +Specifying version none +disables processing of the queries. + + +hostname +The hostname the server should report via a query of +the name hostname.bind +with type TXT, class CHAOS. +This defaults to the hostname of the machine hosting the name server as +found by gethostname(). The primary purpose of such queries is to +identify which of a group of anycast servers is actually +answering your queries. Specifying hostname none; +disables processing of the queries. + + +server-id +The ID of the server should report via a query of +the name ID.SERVER +with type TXT, class CHAOS. +The primary purpose of such queries is to +identify which of a group of anycast servers is actually +answering your queries. Specifying server-id none; +disables processing of the queries. +Specifying server-id hostname; will cause named to +use the hostname as found by gethostname(). +The default server-id is none. + + + + + + + + +The Statistics File + +The statistics file generated by BIND 9 +is similar, but not identical, to that +generated by BIND 8. + +The statistics dump begins with the line +++ Statistics Dump ++++ (973798949), where the number in parentheses is a standard +Unix-style timestamp, measured as seconds since January 1, 1970. Following +that line are a series of lines containing a counter type, the value of the +counter, optionally a zone name, and optionally a view name. +The lines without view and zone listed are global statistics for the entire server. +Lines with a zone and view name for the given view and zone (the view name is +omitted for the default view). The statistics dump ends +with the line --- Statistics Dump --- (973798949), where the +number is identical to the number in the beginning line. +The following statistics counters are maintained: + + + + + +success +The number of +successful queries made to the server or zone. A successful query +is defined as query which returns a NOERROR response with at least +one answer RR. + + +referral +The number of queries which resulted +in referral responses. + + +nxrrset +The number of queries which resulted in +NOERROR responses with no data. + + +nxdomain +The number +of queries which resulted in NXDOMAIN responses. + + +failure +The number of queries which resulted in a +failure response other than those above. + + +recursion +The number of queries which caused the server +to perform recursion in order to find the final answer. + + + + + +Each query received by the server will cause exactly one of +success, +referral, +nxrrset, +nxdomain, or +failure +to be incremented, and may additionally cause the +recursion counter to be incremented. + + + + + + + +<command>server</command> Statement Grammar + +server ip_addr { + bogus yes_or_no ; + provide-ixfr yes_or_no ; + request-ixfr yes_or_no ; + edns yes_or_no ; + transfers number ; + transfer-format ( one-answer | many-answers ) ; ] + keys { string ; string ; ... } ; + transfer-source (ip4_addr | *) port ip_port ; + transfer-source-v6 (ip6_addr | *) port ip_port ; +}; + + + + + +<command>server</command> Statement Definition and Usage + +The server statement defines characteristics +to be associated with a remote name server. + + +The server statement can occur at the top level of the +configuration file or inside a view statement. +If a view statement contains +one or more server statements, only those +apply to the view and any top-level ones are ignored. +If a view contains no server statements, +any top-level server statements are used as +defaults. + + +If you discover that a remote server is giving out bad data, +marking it as bogus will prevent further queries to it. The default +value of bogus is no. +The provide-ixfr clause determines whether +the local server, acting as master, will respond with an incremental +zone transfer when the given remote server, a slave, requests it. +If set to yes, incremental transfer will be provided +whenever possible. If set to no, all transfers +to the remote server will be non-incremental. If not set, the value +of the provide-ixfr option in the view or +global options block is used as a default. + +The request-ixfr clause determines whether +the local server, acting as a slave, will request incremental zone +transfers from the given remote server, a master. If not set, the +value of the request-ixfr option in the view or +global options block is used as a default. + +IXFR requests to servers that do not support IXFR will automatically +fall back to AXFR. Therefore, there is no need to manually list +which servers support IXFR and which ones do not; the global default +of yes should always work. +The purpose of the provide-ixfr and +request-ixfr clauses is +to make it possible to disable the use of IXFR even when both master +and slave claim to support it, for example if one of the servers +is buggy and crashes or corrupts data when IXFR is used. + +The edns clause determines whether the local server +will attempt to use EDNS when communicating with the remote server. The +default is yes. + +The server supports two zone transfer methods. The first, one-answer, +uses one DNS message per resource record transferred. many-answers packs +as many resource records as possible into a message. many-answers is +more efficient, but is only known to be understood by BIND 9, BIND +8.x, and patched versions of BIND 4.9.5. You can specify which method +to use for a server with the transfer-format option. +If transfer-format is not specified, the transfer-format specified +by the options statement will be used. + +transfers is used to limit the number of +concurrent inbound zone transfers from the specified server. If +no transfers clause is specified, the limit is +set according to the transfers-per-ns option. + +The keys clause identifies a +key_id defined by the key statement, +to be used for transaction security (TSIG, ) +when talking to the remote server. +When a request is sent to the remote server, a request signature +will be generated using the key specified here and appended to the +message. A request originating from the remote server is not required +to be signed by this key. + +Although the grammar of the keys clause +allows for multiple keys, only a single key per server is currently +supported. + +The transfer-source and +transfer-source-v6 clauses specify the IPv4 and IPv6 source +address to be used for zone transfer with the remote server, respectively. +For an IPv4 remote server, only transfer-source can +be specified. +Similarly, for an IPv6 remote server, only +transfer-source-v6 can be specified. +Form more details, see the description of +transfer-source and +transfer-source-v6 in +. + + + +<command>trusted-keys</command> Statement Grammar +trusted-keys { + string number number number string ; + string number number number string ; ... +}; + + +<command>trusted-keys</command> Statement Definition +and Usage +The trusted-keys statement defines DNSSEC +security roots. DNSSEC is described in . A security root is defined when the public key for a non-authoritative +zone is known, but cannot be securely obtained through DNS, either +because it is the DNS root zone or because its parent zone is unsigned. +Once a key has been configured as a trusted key, it is treated as +if it had been validated and proven secure. The resolver attempts +DNSSEC validation on all DNS data in subdomains of a security root. +The trusted-keys statement can contain +multiple key entries, each consisting of the key's domain name, +flags, protocol, algorithm, and the base-64 representation of the +key data. + + +<command>view</command> Statement Grammar +view view_name + class { + match-clients { address_match_list } ; + match-destinations { address_match_list } ; + match-recursive-only yes_or_no ; + view_option; ... + zone_statement; ... +}; + +<command>view</command> Statement Definition and Usage + +The view statement is a powerful new feature +of BIND 9 that lets a name server answer a DNS query differently +depending on who is asking. It is particularly useful for implementing +split DNS setups without having to run multiple servers. + +Each view statement defines a view of the +DNS namespace that will be seen by a subset of clients. A client matches +a view if its source IP address matches the +address_match_list of the view's +match-clients clause and its destination IP address matches +the address_match_list of the view's +match-destinations clause. If not specified, both +match-clients and match-destinations +default to matching all addresses. In addition to checking IP addresses +match-clients and match-destinations +can also take keys which provide an mechanism for the +client to select the view. A view can also be specified +as match-recursive-only, which means that only recursive +requests from matching clients will match that view. +The order of the view statements is significant — +a client request will be resolved in the context of the first +view that it matches. + +Zones defined within a view statement will +be only be accessible to clients that match the view. + By defining a zone of the same name in multiple views, different +zone data can be given to different clients, for example, "internal" +and "external" clients in a split DNS setup. + +Many of the options given in the options statement +can also be used within a view statement, and then +apply only when resolving queries with that view. When no view-specific +value is given, the value in the options statement +is used as a default. Also, zone options can have default values specified +in the view statement; these view-specific defaults +take precedence over those in the options statement. + +Views are class specific. If no class is given, class IN +is assumed. Note that all non-IN views must contain a hint zone, +since only the IN class has compiled-in default hints. + +If there are no view statements in the config +file, a default view that matches any client is automatically created +in class IN. Any zone statements specified on +the top level of the configuration file are considered to be part of +this default view, and the options statement will +apply to the default view. If any explicit view +statements are present, all zone statements must +occur inside view statements. + +Here is an example of a typical split DNS setup implemented +using view statements. +view "internal" { + // This should match our internal networks. + match-clients { 10.0.0.0/8; }; + + // Provide recursive service to internal clients only. + recursion yes; + + // Provide a complete view of the example.com zone + // including addresses of internal hosts. + zone "example.com" { + type master; + file "example-internal.db"; + }; +}; + +view "external" { + // Match all clients not matched by the previous view. + match-clients { any; }; + + // Refuse recursive service to external clients. + recursion no; + + // Provide a restricted view of the example.com zone + // containing only publicly accessible hosts. + zone "example.com" { + type master; + file "example-external.db"; + }; +}; + + +<command>zone</command> +Statement Grammar + zone zone_name class { + type ( master | slave | hint | stub | forward | delegation-only ) ; + allow-notify { address_match_list } ; + allow-query { address_match_list } ; + allow-transfer { address_match_list } ; + allow-update { address_match_list } ; + update-policy { update_policy_rule ... } ; + allow-update-forwarding { address_match_list } ; + also-notify { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + check-names (warn|fail|ignore) ; + dialup dialup_option ; + delegation-only yes_or_no ; + file string ; + forward (only|first) ; + forwarders { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + ixfr-base string ; + ixfr-tmp-file string ; + maintain-ixfr-base yes_or_no ; + masters port ip_port { ( masters_list | ip_addr port ip_port key key ) ; ... } ; + max-ixfr-log-size number ; + max-transfer-idle-in number ; + max-transfer-idle-out number ; + max-transfer-time-in number ; + max-transfer-time-out number ; + notify yes_or_no | explicit ; + pubkey number number number string ; + transfer-source (ip4_addr | *) port ip_port ; + transfer-source-v6 (ip6_addr | *) port ip_port ; + alt-transfer-source (ip4_addr | *) port ip_port ; + alt-transfer-source-v6 (ip6_addr | *) port ip_port ; + use-alt-transfer-source yes_or_no; + notify-source (ip4_addr | *) port ip_port ; + notify-source-v6 (ip6_addr | *) port ip_port ; + zone-statistics yes_or_no ; + sig-validity-interval number ; + database string ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + multi-master yes_or_no ; + key-directory path_name; + +}; + + +<command>zone</command> Statement Definition and Usage +Zone Types + + + + + + +master +The server has a master copy of the data +for the zone and will be able to provide authoritative answers for +it. + + +slave +A slave zone is a replica of a master +zone. The masters list specifies one or more IP addresses +of master servers that the slave contacts to update its copy of the zone. +Masters list elements can also be names of other masters lists. +By default, transfers are made from port 53 on the servers; this can +be changed for all servers by specifying a port number before the +list of IP addresses, or on a per-server basis after the IP address. +Authentication to the master can also be done with per-server TSIG keys. +If a file is specified, then the +replica will be written to this file whenever the zone is changed, +and reloaded from this file on a server restart. Use of a file is +recommended, since it often speeds server start-up and eliminates +a needless waste of bandwidth. Note that for large numbers (in the +tens or hundreds of thousands) of zones per server, it is best to +use a two level naming scheme for zone file names. For example, +a slave server for the zone example.com might place +the zone contents into a file called +ex/example.com where ex/ is +just the first two letters of the zone name. (Most operating systems +behave very slowly if you put 100 000 files into +a single directory.) + + +stub +A stub zone is similar to a slave zone, +except that it replicates only the NS records of a master zone instead +of the entire zone. Stub zones are not a standard part of the DNS; +they are a feature specific to the BIND implementation. + + +Stub zones can be used to eliminate the need for glue NS record +in a parent zone at the expense of maintaining a stub zone entry and +a set of name server addresses in named.conf. +This usage is not recommended for new configurations, and BIND 9 +supports it only in a limited way. +In BIND 4/8, zone transfers of a parent zone +included the NS records from stub children of that zone. This meant +that, in some cases, users could get away with configuring child stubs +only in the master server for the parent zone. BIND +9 never mixes together zone data from different zones in this +way. Therefore, if a BIND 9 master serving a parent +zone has child stub zones configured, all the slave servers for the +parent zone also need to have the same child stub zones +configured. + +Stub zones can also be used as a way of forcing the resolution +of a given domain to use a particular set of authoritative servers. +For example, the caching name servers on a private network using +RFC1981 addressing may be configured with stub zones for +10.in-addr.arpa +to use a set of internal name servers as the authoritative +servers for that domain. + + + +forward +A "forward zone" is a way to configure +forwarding on a per-domain basis. A zone statement +of type forward can contain a forward and/or forwarders statement, +which will apply to queries within the domain given by the zone +name. If no forwarders statement is present or +an empty list for forwarders is given, then no +forwarding will be done for the domain, canceling the effects of +any forwarders in the options statement. Thus +if you want to use this type of zone to change the behavior of the +global forward option (that is, "forward first +to", then "forward only", or vice versa, but want to use the same +servers as set globally) you need to re-specify the global forwarders. + + + +hint +The initial set of root name servers is +specified using a "hint zone". When the server starts up, it uses +the root hints to find a root name server and get the most recent +list of root name servers. If no hint zone is specified for class +IN, the server uses a compiled-in default set of root servers hints. +Classes other than IN have no built-in defaults hints. + + +delegation-only +This is used to enforce the delegation only +status of infrastructure zones (e.g. COM, NET, ORG). Any answer that +is received without a explicit or implicit delegation in the authority +section will be treated as NXDOMAIN. This does not apply to the zone +apex. This SHOULD NOT be applied to leaf zones. +delegation-only has no effect on answers received +from forwarders. + + + + +Class +The zone's name may optionally be followed by a class. If +a class is not specified, class IN (for Internet), +is assumed. This is correct for the vast majority of cases. +The hesiod class is +named for an information service from MIT's Project Athena. It is +used to share information about various systems databases, such +as users, groups, printers and so on. The keyword +HS is +a synonym for hesiod. +Another MIT development is CHAOSnet, a LAN protocol created +in the mid-1970s. Zone data for it can be specified with the CHAOS class. + + +Zone Options + + + +allow-notify +See the description of +allow-notify in + + +allow-query +See the description of +allow-query in + + +allow-transfer +See the description of allow-transfer +in . + + +allow-update +Specifies which hosts are allowed to +submit Dynamic DNS updates for master zones. The default is to deny +updates from all hosts. Note that allowing updates based +on the requestor's IP address is insecure; see + for details. + + + +update-policy +Specifies a "Simple Secure Update" policy. See +. + + +allow-update-forwarding +See the description of allow-update-forwarding +in . + + +also-notify +Only meaningful if notify is +active for this zone. The set of machines that will receive a +DNS NOTIFY message +for this zone is made up of all the listed name servers (other than +the primary master) for the zone plus any IP addresses specified +with also-notify. A port may be specified +with each also-notify address to send the notify +messages to a port other than the default of 53. +also-notify is not meaningful for stub zones. +The default is the empty list. + + +check-names + +This option is used to restrict the character set and syntax of +certain domain names in master files and/or DNS responses received from the +network. + + + +database +Specify the type of database to be used for storing the +zone data. The string following the database keyword +is interpreted as a list of whitespace-delimited words. The first word +identifies the database type, and any subsequent words are passed +as arguments to the database to be interpreted in a way specific +to the database type. +The default is "rbt", BIND 9's native in-memory +red-black-tree database. This database does not take arguments. +Other values are possible if additional database drivers +have been linked into the server. Some sample drivers are included +with the distribution but none are linked in by default. + + +dialup +See the description of +dialup in . + + +delegation-only +The flag only applies to hint and stub zones. If set +to yes then the zone will also be treated as if it +is also a delegation-only type zone. + + + +forward +Only meaningful if the zone has a forwarders +list. The only value causes the lookup to fail +after trying the forwarders and getting no answer, while first would +allow a normal lookup to be tried. + + +forwarders +Used to override the list of global forwarders. +If it is not specified in a zone of type forward, +no forwarding is done for the zone; the global options are not used. + + +ixfr-base +Was used in BIND 8 to specify the name +of the transaction log (journal) file for dynamic update and IXFR. +BIND 9 ignores the option and constructs the name of the journal +file by appending ".jnl" to the name of the +zone file. + + +ixfr-tmp-file +Was an undocumented option in BIND 8. +Ignored in BIND 9. + + +max-transfer-time-in +See the description of +max-transfer-time-in in . + + +max-transfer-idle-in +See the description of +max-transfer-idle-in in . + + +max-transfer-time-out +See the description of +max-transfer-time-out in . + + +max-transfer-idle-out +See the description of +max-transfer-idle-out in . + + +notify +See the description of +notify in . + + +pubkey +In BIND 8, this option was intended for specifying +a public zone key for verification of signatures in DNSSEC signed +zones when they are loaded from disk. BIND 9 does not verify signatures +on load and ignores the option. + + +zone-statistics +If yes, the server will keep statistical +information for this zone, which can be dumped to the +statistics-file defined in the server options. + + +sig-validity-interval +See the description of +sig-validity-interval in . + + +transfer-source +See the description of +transfer-source in + + + +transfer-source-v6 +See the description of +transfer-source-v6 in + + + +alt-transfer-source +See the description of +alt-transfer-source in + + + +alt-transfer-source-v6 +See the description of +alt-transfer-source-v6 in + + + +use-alt-transfer-source +See the description of +use-alt-transfer-source in + + + + +notify-source +See the description of +notify-source in + + + +notify-source-v6 +See the description of +notify-source-v6 in . + + + + +min-refresh-time +max-refresh-time +min-retry-time +max-retry-time + +See the description in . + + +ixfr-from-differences +See the description of +ixfr-from-differences in . + + +key-directory +See the description of +key-directory in + + +multi-master +See the description of +multi-master in . + + + + + +Dynamic Update Policies +BIND 9 supports two alternative methods of granting clients +the right to perform dynamic updates to a zone, +configured by the allow-update and +update-policy option, respectively. +The allow-update clause works the same +way as in previous versions of BIND. It grants given clients the +permission to update any record of any name in the zone. +The update-policy clause is new in BIND +9 and allows more fine-grained control over what updates are allowed. +A set of rules is specified, where each rule either grants or denies +permissions for one or more names to be updated by one or more identities. + If the dynamic update request message is signed (that is, it includes +either a TSIG or SIG(0) record), the identity of the signer can +be determined. +Rules are specified in the update-policy zone +option, and are only meaningful for master zones. When the update-policy statement +is present, it is a configuration error for the allow-update statement +to be present. The update-policy statement only +examines the signer of a message; the source address is not relevant. +This is how a rule definition looks: + +( grant | deny ) identity nametype name types + +Each rule grants or denies privileges. Once a message has +successfully matched a rule, the operation is immediately granted +or denied and no further rules are examined. A rule is matched +when the signer matches the identity field, the name matches the +name field in accordance with the nametype field, and the type matches +the types specified in the type field. + +The identity field specifies a name or a wildcard name. Normally, this +is the name of the TSIG or SIG(0) key used to sign the update request. When a +TKEY exchange has been used to create a shared secret, the identity of the +shared secret is the same as the identity of the key used to authenticate the +TKEY exchange. When the identity field specifies a +wildcard name, it is subject to DNS wildcard expansion, so the rule will apply +to multiple identities. The identity field must +contain a fully qualified domain name. + +The nametype field has 4 values: +name, subdomain, +wildcard, and self. + + + + + + + +name +Exact-match semantics. This rule matches when the +name being updated is identical to the contents of the +name field. + + +subdomain +This rule matches when the name being updated +is a subdomain of, or identical to, the contents of the +name field. + + +wildcard +The name field is +subject to DNS wildcard expansion, and this rule matches when the name +being updated name is a valid expansion of the wildcard. + + +self +This rule matches when the name being updated +matches the contents of the identity field. +The name field is ignored, but should be +the same as the identity field. The +self nametype is most useful when allowing using +one key per name to update, where the key has the same name as the name +to be updated. The identity would be +specified as * in this case. + + + + +In all cases, the name field must +specify a fully qualified domain name. + +If no types are explicitly specified, this rule matches all types except +SIG, NS, SOA, and NXT. Types may be specified by name, including +"ANY" (ANY matches all types except NXT, which can never be updated). +Note that when an attempt is made to delete all records associated with a +name, the rules are checked for each existing record type. + + + + + + Zone File + + Types of Resource Records and When to Use Them +This section, largely borrowed from RFC 1034, describes the +concept of a Resource Record (RR) and explains when each is used. +Since the publication of RFC 1034, several new RRs have been identified +and implemented in the DNS. These are also included. + + Resource Records + + A domain name identifies a node. Each node has a set of + resource information, which may be empty. The set of resource + information associated with a particular name is composed of + separate RRs. The order of RRs in a set is not significant and + need not be preserved by name servers, resolvers, or other + parts of the DNS. However, sorting of multiple RRs is + permitted for optimization purposes, for example, to specify + that a particular nearby server be tried first. See and . + +The components of a Resource Record are: + + + + + +owner name +the domain name where the RR is found. + + +type +an encoded 16 bit value that specifies +the type of the resource record. + + +TTL +the time to live of the RR. This field +is a 32 bit integer in units of seconds, and is primarily used by +resolvers when they cache RRs. The TTL describes how long a RR can +be cached before it should be discarded. + + +class +an encoded 16 bit value that identifies +a protocol family or instance of a protocol. + + +RDATA +the resource data. The format of the +data is type (and sometimes class) specific. + + + +The following are types of valid RRs: + + + + + +A +a host address. In the IN class, this is a +32-bit IP address. Described in RFC 1035. + + +AAAA +IPv6 address. Described in RFC 1886. + + +A6 +IPv6 address. This can be a partial +address (a suffix) and an indirection to the name where the rest of the +address (the prefix) can be found. Experimental. Described in RFC 2874. + + +AFSDB +location of AFS database servers. +Experimental. Described in RFC 1183. + + +APL +address prefix list. Experimental. +Described in RFC 3123. + + +CERT +holds a digital certificate. +Described in RFC 2538. + + +CNAME +identifies the canonical name of an alias. +Described in RFC 1035. + + +DNAME +Replaces the domain name specified with +another name to be looked up, effectively aliasing an entire +subtree of the domain name space rather than a single record +as in the case of the CNAME RR. +Described in RFC 2672. + + +GPOS +Specifies the global position. Superseded by LOC. + + +HINFO +identifies the CPU and OS used by a host. +Described in RFC 1035. + + +ISDN +representation of ISDN addresses. +Experimental. Described in RFC 1183. + + +KEY +stores a public key associated with a +DNS name. Described in RFC 2535. + + +KX +identifies a key exchanger for this +DNS name. Described in RFC 2230. + + +LOC +for storing GPS info. Described in RFC 1876. +Experimental. + + +MX +identifies a mail exchange for the domain. +a 16 bit preference value (lower is better) +followed by the host name of the mail exchange. +Described in RFC 974, RFC 1035. + + +NAPTR +name authority pointer. Described in RFC 2915. + + +NSAP +a network service access point. +Described in RFC 1706. + + +NS +the authoritative name server for the +domain. Described in RFC 1035. + + +NXT +used in DNSSEC to securely indicate that +RRs with an owner name in a certain name interval do not exist in +a zone and indicate what RR types are present for an existing name. +Described in RFC 2535. + + +PTR +a pointer to another part of the domain +name space. Described in RFC 1035. + + +PX +provides mappings between RFC 822 and X.400 +addresses. Described in RFC 2163. + + +RP +information on persons responsible +for the domain. Experimental. Described in RFC 1183. + + +RT +route-through binding for hosts that +do not have their own direct wide area network addresses. +Experimental. Described in RFC 1183. + + +SIG +("signature") contains data authenticated +in the secure DNS. Described in RFC 2535. + + +SOA +identifies the start of a zone of authority. +Described in RFC 1035. + + +SRV +information about well known network +services (replaces WKS). Described in RFC 2782. + + +TXT +text records. Described in RFC 1035. + + +WKS +information about which well known +network services, such as SMTP, that a domain supports. Historical. + + + +X25 +representation of X.25 network addresses. +Experimental. Described in RFC 1183. + + + +The following classes of resource records +are currently valid in the DNS: + + + + + +IN +The Internet. + + + +CH + +CHAOSnet, a LAN protocol created at MIT in the mid-1970s. +Rarely used for its historical purpose, but reused for BIND's +built-in server information zones, e.g., +version.bind. + + + + +HS + +Hesiod, an information service +developed by MIT's Project Athena. It is used to share information +about various systems databases, such as users, groups, printers +and so on. + + + + + + +The owner name is often implicit, rather than forming an integral +part of the RR. For example, many name servers internally form tree +or hash structures for the name space, and chain RRs off nodes. + The remaining RR parts are the fixed header (type, class, TTL) +which is consistent for all RRs, and a variable part (RDATA) that +fits the needs of the resource being described. +The meaning of the TTL field is a time limit on how long an +RR can be kept in a cache. This limit does not apply to authoritative +data in zones; it is also timed out, but by the refreshing policies +for the zone. The TTL is assigned by the administrator for the +zone where the data originates. While short TTLs can be used to +minimize caching, and a zero TTL prohibits caching, the realities +of Internet performance suggest that these times should be on the +order of days for the typical host. If a change can be anticipated, +the TTL can be reduced prior to the change to minimize inconsistency +during the change, and then increased back to its former value following +the change. +The data in the RDATA section of RRs is carried as a combination +of binary strings and domain names. The domain names are frequently +used as "pointers" to other data in the DNS. +Textual expression of RRs +RRs are represented in binary form in the packets of the DNS +protocol, and are usually represented in highly encoded form when +stored in a name server or resolver. In the examples provided in +RFC 1034, a style similar to that used in master files was employed +in order to show the contents of RRs. In this format, most RRs +are shown on a single line, although continuation lines are possible +using parentheses. +The start of the line gives the owner of the RR. If a line +begins with a blank, then the owner is assumed to be the same as +that of the previous RR. Blank lines are often included for readability. +Following the owner, we list the TTL, type, and class of the +RR. Class and type use the mnemonics defined above, and TTL is +an integer before the type field. In order to avoid ambiguity in +parsing, type and class mnemonics are disjoint, TTLs are integers, +and the type mnemonic is always last. The IN class and TTL values +are often omitted from examples in the interests of clarity. +The resource data or RDATA section of the RR are given using +knowledge of the typical representation for the data. +For example, we might show the RRs carried in a message as: + + + + + +ISI.EDU. +MX +10 VENERA.ISI.EDU. + + + +MX +10 VAXA.ISI.EDU + + +VENERA.ISI.EDU +A +128.9.0.32 + + + +A +10.1.0.52 + + +VAXA.ISI.EDU +A +10.2.0.27 + + + +A +128.9.0.33 + + + +The MX RRs have an RDATA section which consists of a 16 bit +number followed by a domain name. The address RRs use a standard +IP address format to contain a 32 bit internet address. +This example shows six RRs, with two RRs at each of three +domain names. +Similarly we might see: + + + + + +XX.LCS.MIT.EDU. IN +A +10.0.0.44 + + +CH +A +MIT.EDU. 2420 + + + +This example shows two addresses for XX.LCS.MIT.EDU, +each of a different class. + +Discussion of MX Records + +As described above, domain servers store information as a +series of resource records, each of which contains a particular +piece of information about a given domain name (which is usually, +but not always, a host). The simplest way to think of a RR is as +a typed pair of data, a domain name matched with a relevant datum, +and stored with some additional type information to help systems +determine when the RR is relevant. + +MX records are used to control delivery of email. The data +specified in the record is a priority and a domain name. The priority +controls the order in which email delivery is attempted, with the +lowest number first. If two priorities are the same, a server is +chosen randomly. If no servers at a given priority are responding, +the mail transport agent will fall back to the next largest priority. +Priority numbers do not have any absolute meaning — they are relevant +only respective to other MX records for that domain name. The domain +name given is the machine to which the mail will be delivered. It must have +an associated A record — CNAME is not sufficient. +For a given domain, if there is both a CNAME record and an +MX record, the MX record is in error, and will be ignored. Instead, +the mail will be delivered to the server specified in the MX record +pointed to by the CNAME. + + + + + + + + +example.com. +IN +MX +10 +mail.example.com. + + + +IN +MX +10 +mail2.example.com. + + + +IN +MX +20 +mail.backup.org. + + +mail.example.com. +IN +A +10.0.0.1 + + + +mail2.example.com. +IN +A +10.0.0.2 + + + +For example: +Mail delivery will be attempted to mail.example.com and +mail2.example.com (in +any order), and if neither of those succeed, delivery to mail.backup.org will +be attempted. +Setting TTLs +The time to live of the RR field is a 32 bit integer represented +in units of seconds, and is primarily used by resolvers when they +cache RRs. The TTL describes how long a RR can be cached before it +should be discarded. The following three types of TTL are currently +used in a zone file. + + + + + +SOA +The last field in the SOA is the negative +caching TTL. This controls how long other servers will cache no-such-domain +(NXDOMAIN) responses from you.The maximum time for +negative caching is 3 hours (3h). + + +$TTL +The $TTL directive at the top of the +zone file (before the SOA) gives a default TTL for every RR without +a specific TTL set. + + +RR TTLs +Each RR can have a TTL as the second +field in the RR, which will control how long other servers can cache +the it. + + + +All of these TTLs default to units of seconds, though units +can be explicitly specified, for example, 1h30m. +Inverse Mapping in IPv4 +Reverse name resolution (that is, translation from IP address +to name) is achieved by means of the in-addr.arpa domain +and PTR records. Entries in the in-addr.arpa domain are made in +least-to-most significant order, read left to right. This is the +opposite order to the way IP addresses are usually written. Thus, +a machine with an IP address of 10.1.2.3 would have a corresponding +in-addr.arpa name of +3.2.1.10.in-addr.arpa. This name should have a PTR resource record +whose data field is the name of the machine or, optionally, multiple +PTR records if the machine has more than one name. For example, +in the example.com domain: + + + + + + +$ORIGIN +2.1.10.in-addr.arpa + + +3 +IN PTR foo.example.com. + + + + +The $ORIGIN lines in the examples +are for providing context to the examples only-they do not necessarily +appear in the actual usage. They are only used here to indicate +that the example is relative to the listed origin. +Other Zone File Directives +The Master File Format was initially defined in RFC 1035 and +has subsequently been extended. While the Master File Format itself +is class independent all records in a Master File must be of the same +class. +Master File Directives include $ORIGIN, $INCLUDE, +and $TTL. +The <command>$ORIGIN</command> Directive +Syntax: $ORIGIN +domain-name comment +$ORIGIN sets the domain name that will +be appended to any unqualified records. When a zone is first read +in there is an implicit $ORIGIN <zone-name>. The +current $ORIGIN is appended to the domain specified +in the $ORIGIN argument if it is not absolute. +$ORIGIN example.com. +WWW CNAME MAIN-SERVER +is equivalent to +WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. +The <command>$INCLUDE</command> Directive +Syntax: $INCLUDE +filename +origin comment +Read and process the file filename as +if it were included into the file at this point. If origin is +specified the file is processed with $ORIGIN set +to that value, otherwise the current $ORIGIN is +used. +The origin and the current domain name +revert to the values they had prior to the $INCLUDE once +the file has been read. + +RFC 1035 specifies that the current origin should be restored after +an $INCLUDE, but it is silent on whether the current +domain name should also be restored. BIND 9 restores both of them. +This could be construed as a deviation from RFC 1035, a feature, or both. + + +The <command>$TTL</command> Directive +Syntax: $TTL +default-ttl +comment +Set the default Time To Live (TTL) for subsequent records +with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds. +$TTL is defined in RFC 2308. +<acronym>BIND</acronym> Master File Extension: the <command>$GENERATE</command> Directive + Syntax: $GENERATE range lhs ttl class type rhs comment +$GENERATE is used to create a series of +resource records that only differ from each other by an iterator. $GENERATE can +be used to easily generate the sets of records required to support +sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA +delegation. +$ORIGIN 0.0.192.IN-ADDR.ARPA. +$GENERATE 1-2 0 NS SERVER$.EXAMPLE. +$GENERATE 1-127 $ CNAME $.0 +is equivalent to +0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE. +0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE. +1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA. +2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA. +... +127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA. + + + + + + + + range + This can be one of two forms: start-stop +or start-stop/step. If the first form is used then step is set to + 1. All of start, stop and step must be positive. + + + lhs + lhs describes the +owner name of the resource records to be created. Any single $ symbols +within the lhs side are replaced by the iterator +value. +To get a $ in the output you need to escape the $ +using a backslash \, +e.g. \$. The $ may optionally be followed +by modifiers which change the offset from the iterator, field width and base. +Modifiers are introduced by a { immediately following the +$ as ${offset[,width[,base]]}. +e.g. ${-20,3,d} which subtracts 20 from the current value, +prints the result as a decimal in a zero padded field of with 3. Available +output forms are decimal (d), octal (o) +and hexadecimal (x or X for uppercase). +The default modifier is ${0,0,d}. +If the lhs is not +absolute, the current $ORIGIN is appended to +the name. +For compatibility with earlier versions $$ is still +recognized a indicating a literal $ in the output. + + + ttl + ttl specifies the + ttl of the generated records. If not specified this will be + inherited using the normal ttl inheritance rules. + class and ttl can be + entered in either order. + + + class + class specifies the + class of the generated records. This must match the zone class if + it is specified. + class and ttl can be + entered in either order. + + + type + At present the only supported types are +PTR, CNAME, DNAME, A, AAAA and NS. + + + rhs + rhs is a domain name. It is processed +similarly to lhs. + + + + The $GENERATE directive is a BIND extension +and not part of the standard zone file format. + BIND 8 does not support the optional TTL and CLASS fields. + + + +<acronym>BIND</acronym> 9 Security Considerations +Access Control Lists +Access Control Lists (ACLs), are address match lists that +you can set up and nickname for future use in allow-notify, +allow-query, allow-recursion, +blackhole, allow-transfer, +etc. +Using ACLs allows you to have finer control over who can access +your name server, without cluttering up your config files with huge +lists of IP addresses. +It is a good idea to use ACLs, and to +control access to your server. Limiting access to your server by +outside parties can help prevent spoofing and DoS attacks against +your server. +Here is an example of how to properly apply ACLs: + +// Set up an ACL named "bogusnets" that will block RFC1918 space, +// which is commonly used in spoofing attacks. +acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; +// Set up an ACL called our-nets. Replace this with the real IP numbers. +acl our-nets { x.x.x.x/24; x.x.x.x/21; }; +options { + ... + ... + allow-query { our-nets; }; + allow-recursion { our-nets; }; + ... + blackhole { bogusnets; }; + ... +}; +zone "example.com" { + type master; + file "m/example.com"; + allow-query { any; }; +}; + +This allows recursive queries of the server from the outside +unless recursion has been previously disabled. +For more information on how to use ACLs to protect your server, +see the AUSCERT advisory at +ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos +<command>chroot</command> and <command>setuid</command> (for +UNIX servers) +On UNIX servers, it is possible to run BIND in a chrooted environment +(chroot()) by specifying the "" +option. This can help improve system security by placing BIND in +a "sandbox", which will limit the damage done if a server is compromised. +Another useful feature in the UNIX version of BIND is the +ability to run the daemon as an unprivileged user ( user ). +We suggest running as an unprivileged user when using the chroot feature. +Here is an example command line to load BIND in a chroot() sandbox, +/var/named, and to run named setuid to +user 202: +/usr/local/bin/named -u 202 -t /var/named + +The <command>chroot</command> Environment + +In order for a chroot() environment to +work properly in a particular directory +(for example, /var/named), +you will need to set up an environment that includes everything +BIND needs to run. +From BIND's point of view, /var/named is +the root of the filesystem. You will need to adjust the values of options like +like directory and pid-file to account +for this. + + +Unlike with earlier versions of BIND, you will typically +not need to compile named +statically nor install shared libraries under the new root. +However, depending on your operating system, you may need +to set up things like +/dev/zero, +/dev/random, +/dev/log, and/or +/etc/localtime. + + + +Using the <command>setuid</command> Function + +Prior to running the named daemon, use +the touch utility (to change file access and +modification times) or the chown utility (to +set the user id and/or group id) on files +to which you want BIND +to write. Note that if the named daemon is running as an +unprivileged user, it will not be able to bind to new restricted ports if the +server is reloaded. + + + +Dynamic Update Security + +Access to the dynamic +update facility should be strictly limited. In earlier versions of +BIND the only way to do this was based on the IP +address of the host requesting the update, by listing an IP address or +network prefix in the allow-update zone option. +This method is insecure since the source address of the update UDP packet +is easily forged. Also note that if the IP addresses allowed by the +allow-update option include the address of a slave +server which performs forwarding of dynamic updates, the master can be +trivially attacked by sending the update to the slave, which will +forward it to the master with its own source IP address causing the +master to approve it without question. + +For these reasons, we strongly recommend that updates be +cryptographically authenticated by means of transaction signatures +(TSIG). That is, the allow-update option should +list only TSIG key names, not IP addresses or network +prefixes. Alternatively, the new update-policy +option can be used. + +Some sites choose to keep all dynamically updated DNS data +in a subdomain and delegate that subdomain to a separate zone. This +way, the top-level zone containing critical data such as the IP addresses +of public web and mail servers need not allow dynamic update at +all. + + + + + Troubleshooting + + Common Problems + + It's not working; how can I figure out what's wrong? + + The best solution to solving installation and + configuration issues is to take preventative measures by setting + up logging files beforehand. The log files provide a + source of hints and information that can be used to figure out + what went wrong and how to fix the problem. + + + + + Incrementing and Changing the Serial Number + + Zone serial numbers are just numbers-they aren't date + related. A lot of people set them to a number that represents a + date, usually of the form YYYYMMDDRR. A number of people have been + testing these numbers for Y2K compliance and have set the number + to the year 2000 to see if it will work. They then try to restore + the old serial number. This will cause problems because serial + numbers are used to indicate that a zone has been updated. If the + serial number on the slave server is lower than the serial number + on the master, the slave server will attempt to update its copy of + the zone. + + Setting the serial number to a lower number on the master + server than the slave server means that the slave will not perform + updates to its copy of the zone. + + The solution to this is to add 2147483647 (2^31-1) to the + number, reload the zone and make sure all slaves have updated to + the new zone serial number, then reset the number to what you want + it to be, and reload the zone again. + + + + Where Can I Get Help? + + The Internet Software Consortium (ISC) offers a wide range + of support and service agreements for BIND and DHCP servers. Four + levels of premium support are available and each level includes + support for all ISC programs, significant discounts on products + and training, and a recognized priority on bug fixes and + non-funded feature requests. In addition, ISC offers a standard + support agreement package which includes services ranging from bug + fix announcements to remote support. It also includes training in + BIND and DHCP. + + To discuss arrangements for support, contact + info@isc.org or visit the + ISC web page at http://www.isc.org/services/support/ + to read more. + + + + Appendices + + Acknowledgments + + A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym> + + Although the "official" beginning of the Domain Name + System occurred in 1984 with the publication of RFC 920, the + core of the new system was described in 1983 in RFCs 882 and + 883. From 1984 to 1987, the ARPAnet (the precursor to today's + Internet) became a testbed of experimentation for developing the + new naming/addressing scheme in an rapidly expanding, + operational network environment. New RFCs were written and + published in 1987 that modified the original documents to + incorporate improvements based on the working model. RFC 1034, + "Domain Names-Concepts and Facilities", and RFC 1035, "Domain + Names-Implementation and Specification" were published and + became the standards upon which all DNS implementations are + built. + + + The first working domain name server, called "Jeeves", was +written in 1983-84 by Paul Mockapetris for operation on DEC Tops-20 +machines located at the University of Southern California's Information +Sciences Institute (USC-ISI) and SRI International's Network Information +Center (SRI-NIC). A DNS server for Unix machines, the Berkeley Internet +Name Domain (BIND) package, was written soon after by a group of +graduate students at the University of California at Berkeley under +a grant from the US Defense Advanced Research Projects Administration +(DARPA). Versions of BIND through 4.8.3 were maintained by the Computer +Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark +Painter, David Riggle and Songnian Zhou made up the initial BIND +project team. After that, additional work on the software package +was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation +employee on loan to the CSRG, worked on BIND for 2 years, from 1985 +to 1987. Many other people also contributed to BIND development +during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, +Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently +handled by Mike Karels and O. Kure. + BIND versions 4.9 and 4.9.1 were released by Digital Equipment +Corporation (now Compaq Computer Corporation). Paul Vixie, then +a DEC employee, became BIND's primary caretaker. Paul was assisted +by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew +Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat +Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe +Wolfhugel, and others. + BIND Version 4.9.2 was sponsored by Vixie Enterprises. Paul +Vixie became BIND's principal architect/programmer. + BIND versions from 4.9.3 onward have been developed and maintained +by the Internet Software Consortium with support being provided +by ISC's sponsors. As co-architects/programmers, Bob Halley and +Paul Vixie released the first production-ready version of BIND version +8 in May 1997. + BIND development work is made possible today by the sponsorship +of several corporations, and by the tireless work efforts of numerous +individuals. + + + + +General <acronym>DNS</acronym> Reference Information + + IPv6 addresses (AAAA) + IPv6 addresses are 128-bit identifiers for interfaces and +sets of interfaces which were introduced in the DNS to facilitate +scalable Internet routing. There are three types of addresses: Unicast, +an identifier for a single interface; Anycast, +an identifier for a set of interfaces; and Multicast, +an identifier for a set of interfaces. Here we describe the global +Unicast address scheme. For more information, see RFC 2374. +The aggregatable global Unicast address format is as follows: + + + + + + + + + +3 +13 +8 +24 +16 +64 bits + + +FP +TLA ID +RES +NLA ID +SLA ID +Interface ID + + +<------ Public Topology +------> + + + + + + + + +<-Site Topology-> + + + + + + + + +<------ Interface Identifier ------> + + + + Where + + + + + + +FP += +Format Prefix (001) + + +TLA ID += +Top-Level Aggregation Identifier + + +RES += +Reserved for future use + + +NLA ID += +Next-Level Aggregation Identifier + + +SLA ID += +Site-Level Aggregation Identifier + + +INTERFACE ID += +Interface Identifier + + + + The Public Topology is provided by the +upstream provider or ISP, and (roughly) corresponds to the IPv4 network section +of the address range. The Site Topology is +where you can subnet this space, much the same as subnetting an +IPv4 /16 network into /24 subnets. The Interface Identifier is +the address of an individual interface on a given network. (With +IPv6, addresses belong to interfaces rather than machines.) + The subnetting capability of IPv6 is much more flexible than +that of IPv4: subnetting can now be carried out on bit boundaries, +in much the same way as Classless InterDomain Routing (CIDR). +The Interface Identifier must be unique on that network. On +ethernet networks, one way to ensure this is to set the address +to the first three bytes of the hardware address, "FFFE", then the +last three bytes of the hardware address. The lowest significant +bit of the first byte should then be complemented. Addresses are +written as 32-bit blocks separated with a colon, and leading zeros +of a block may be omitted, for example: +2001:db8:201:9:a00:20ff:fe81:2b32 +IPv6 address specifications are likely to contain long strings +of zeros, so the architects have included a shorthand for specifying +them. The double colon (`::') indicates the longest possible string +of zeros that can fit, and can be used only once in an address. + + + + Bibliography (and Suggested Reading) + + Request for Comments (RFCs) + Specification documents for the Internet protocol suite, including +the DNS, are published as part of the Request for Comments (RFCs) +series of technical notes. The standards themselves are defined +by the Internet Engineering Task Force (IETF) and the Internet Engineering +Steering Group (IESG). RFCs can be obtained online via FTP at +ftp://www.isi.edu/in-notes/RFCxxx.txt (where xxx is +the number of the RFC). RFCs are also available via the Web at +http://www.ietf.org/rfc/. + + + + + Standards + + RFC974 + + Partridge + C. + + Mail Routing and the Domain System + January 1986 + + + RFC1034 + + Mockapetris + P.V. + + Domain Names — Concepts and Facilities + November 1987 + + + RFC1035 + + Mockapetris + P. V. + Domain Names — Implementation and +Specification + November 1987 + + + + + Proposed Standards + + + RFC2181 + + Elz + R., R. Bush + + Clarifications to the <acronym>DNS</acronym> Specification + July 1997 + + + RFC2308 + + Andrews + M. + + Negative Caching of <acronym>DNS</acronym> Queries + March 1998 + + + RFC1995 + + Ohta + M. + + Incremental Zone Transfer in <acronym>DNS</acronym> + August 1996 + + + RFC1996 + + Vixie + P. + + A Mechanism for Prompt Notification of Zone Changes + August 1996 + + + RFC2136 + + + Vixie + P. + + + S. + Thomson + + + Y. + Rekhter + + + J. + Bound + + + Dynamic Updates in the Domain Name System + April 1997 + + + RFC2845 + + + Vixie + P. + + + O. + Gudmundsson + + + D. + Eastlake + 3rd + + B. + Wellington + + Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG) + May 2000 + + + + Proposed Standards Still Under Development + + Note: the following list of +RFCs are undergoing major revision by the IETF. + + + RFC1886 + + + Thomson + S. + + + C. + Huitema + + + <acronym>DNS</acronym> Extensions to support IP version 6 + December 1995 + + + RFC2065 + + + Eastlake + 3rd + D. + + + C. + Kaufman + + + Domain Name System Security Extensions + January 1997 + + + RFC2137 + + Eastlake + 3rd + D. + + Secure Domain Name System Dynamic Update + April 1997 + + + + Other Important RFCs About <acronym>DNS</acronym> Implementation + + RFC1535 + + Gavron + E. + + A Security Problem and Proposed Correction With Widely Deployed <acronym>DNS</acronym> Software. + October 1993 + + + RFC1536 + + + Kumar + A. + + + J. + Postel + + + C. + Neuman + + P. + Danzig + + + S. + Miller + + + Common <acronym>DNS</acronym> Implementation Errors and Suggested Fixes + October 1993 + + + RFC1982 + + + Elz + R. + + + R. + Bush + + + Serial Number Arithmetic + August 1996 + + + + Resource Record Types + + RFC1183 + + + Everhart + C.F. + + + L. A. + Mamakos + + + R. + Ullmann + + + P. + Mockapetris + + + New <acronym>DNS</acronym> RR Definitions + October 1990 + + + RFC1706 + + + Manning + B. + + + R. + Colella + + + <acronym>DNS</acronym> NSAP Resource Records + October 1994 + + + RFC2168 + + + Daniel + R. + + + M. + Mealling + + + Resolution of Uniform Resource Identifiers using +the Domain Name System + June 1997 + + + RFC1876 + + + Davis + C. + + + P. + Vixie + + + T. + Goodwin + + + I. + Dickinson + + + A Means for Expressing Location Information in the Domain +Name System + January 1996 + + + RFC2052 + + + Gulbrandsen + A. + + + P. + Vixie + + + A <acronym>DNS</acronym> RR for Specifying the Location of +Services. + October 1996 + + + RFC2163 + + Allocchio + A. + + Using the Internet <acronym>DNS</acronym> to Distribute MIXER +Conformant Global Address Mapping + January 1998 + + + RFC2230 + + Atkinson + R. + + Key Exchange Delegation Record for the <acronym>DNS</acronym> + October 1997 + + + + <acronym>DNS</acronym> and the Internet + + RFC1101 + + Mockapetris + P. V. + + <acronym>DNS</acronym> Encoding of Network Names and Other Types + April 1989 + + + RFC1123 + + Braden + R. + + Requirements for Internet Hosts - Application and Support + October 1989 + + + RFC1591 + + Postel + J. + Domain Name System Structure and Delegation + March 1994 + + RFC2317 + + + Eidnes + H. + + + G. + de Groot + + + P. + Vixie + + + Classless IN-ADDR.ARPA Delegation + March 1998 + + + + <acronym>DNS</acronym> Operations + + RFC1537 + + Beertema + P. + + Common <acronym>DNS</acronym> Data File Configuration Errors + October 1993 + + + RFC1912 + + Barr + D. + + Common <acronym>DNS</acronym> Operational and Configuration Errors + February 1996 + + + RFC2010 + + + Manning + B. + + + P. + Vixie + + + Operational Criteria for Root Name Servers. + October 1996 + + + RFC2219 + + + Hamilton + M. + + + R. + Wright + + + Use of <acronym>DNS</acronym> Aliases for Network Services. + October 1997 + + + + Other <acronym>DNS</acronym>-related RFCs + + Note: the following list of RFCs, although +DNS-related, are not concerned with implementing software. + + + RFC1464 + + Rosenbaum + R. + + Using the Domain Name System To Store Arbitrary String Attributes + May 1993 + + + RFC1713 + + Romao + A. + + Tools for <acronym>DNS</acronym> Debugging + November 1994 + + RFC1794 + + Brisco + T. + + <acronym>DNS</acronym> Support for Load Balancing + April 1995 + + + RFC2240 + + Vaughan + O. + A Legal Basis for Domain Name Allocation + November 1997 + + + RFC2345 + + + Klensin + J. + + + T. + Wolf + + + G. + Oglesby + + + Domain Names and Company Name Retrieval + May 1998 + + + RFC2352 + + Vaughan + O. + + A Convention For Using Legal Names as Domain Names + May 1998 + + + + Obsolete and Unimplemented Experimental RRs + + RFC1712 + + + Farrell + C. + + + M. + Schulze + + + S. + Pleitner + + + D. + Baldoni + + + <acronym>DNS</acronym> Encoding of Geographical +Location + November 1994 + + + + + + Internet Drafts + Internet Drafts (IDs) are rough-draft working documents of +the Internet Engineering Task Force. They are, in essence, RFCs +in the preliminary stages of development. Implementors are cautioned not +to regard IDs as archival, and they should not be quoted or cited +in any formal documents unless accompanied by the disclaimer that +they are "works in progress." IDs have a lifespan of six months +after which they are deleted unless updated by their authors. + + + + Other Documents About <acronym>BIND</acronym> + + + + + + Albitz + Paul + + + Cricket + Liu + + + <acronym>DNS</acronym> and <acronym>BIND</acronym> + + 1998 + Sebastopol, CA: O'Reilly and Associates + + + + + + + + + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch01.html b/contrib/bind9/doc/arm/Bv9ARM.ch01.html new file mode 100644 index 000000000000..5b3659e61010 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch01.html @@ -0,0 +1,1131 @@ + +Introduction
BIND 9 Administrator Reference Manual
PrevNext

Chapter 1. Introduction

The Internet Domain Name System (DNS) consists of the syntax + to specify the names of entities in the Internet in a hierarchical + manner, the rules used for delegating authority over names, and the + system implementation that actually maps names to Internet + addresses. DNS data is maintained in a group of distributed + hierarchical databases.

1.1. Scope of Document

The Berkeley Internet Name Domain (BIND) implements an + domain name server for a number of operating systems. This + document provides basic information about the installation and + care of the Internet Software Consortium (ISC) + BIND version 9 software package for system + administrators.

This version of the manual corresponds to BIND version 9.3.

1.2. Organization of This Document

In this document, Section 1 introduces + the basic DNS and BIND concepts. Section 2 + describes resource requirements for running BIND in various + environments. Information in Section 3 is + task-oriented in its presentation and is + organized functionally, to aid in the process of installing the + BIND 9 software. The task-oriented section is followed by + Section 4, which contains more advanced + concepts that the system administrator may need for implementing + certain options. Section 5 + describes the BIND 9 lightweight + resolver. The contents of Section 6 are + organized as in a reference manual to aid in the ongoing + maintenance of the software. Section 7 + addresses security considerations, and + Section 8 contains troubleshooting help. The + main body of the document is followed by several + Appendices which contain useful reference + information, such as a Bibliography and + historic information related to BIND and the Domain Name + System.

1.3. Conventions Used in This Document

In this document, we use the following general typographic + conventions:

To +describe:

We use the style:

a pathname, filename, URL, hostname, +mailing list name, or new term or concept

Fixed width

literal user +input

Fixed Width Bold

program output

Fixed Width

The following conventions are used in descriptions of the +BIND configuration file:

To +describe:

We use the style:

keywords

Fixed Width

variables

Fixed Width

Optional input

[Text is enclosed in square brackets]

1.4. The Domain Name System (DNS)

The purpose of this document is to explain the installation +and upkeep of the BIND software package, and we +begin by reviewing the fundamentals of the Domain Name System +(DNS) as they relate to BIND. +

1.4.1. DNS Fundamentals

The Domain Name System (DNS) is the hierarchical, distributed +database. It stores information for mapping Internet host names to IP +addresses and vice versa, mail routing information, and other data +used by Internet applications.

Clients look up information in the DNS by calling a +resolver library, which sends queries to one or +more name servers and interprets the responses. +The BIND 9 software distribution contains a +name server, named, and two resolver +libraries, liblwres and libbind. +

1.4.2. Domains and Domain Names

The data stored in the DNS is identified by domain +names that are organized as a tree according to +organizational or administrative boundaries. Each node of the tree, +called a domain, is given a label. The domain name of the +node is the concatenation of all the labels on the path from the +node to the root node. This is represented +in written form as a string of labels listed from right to left and +separated by dots. A label need only be unique within its parent +domain.

For example, a domain name for a host at the +company Example, Inc. could be +mail.example.com, +where com is the +top level domain to which +ourhost.example.com belongs, +example is +a subdomain of com, and +ourhost is the +name of the host.

For administrative purposes, the name space is partitioned into +areas called zones, each starting at a node and +extending down to the leaf nodes or to nodes where other zones start. +The data for each zone is stored in a name +server, which answers queries about the zone using the +DNS protocol. +

The data associated with each domain name is stored in the +form of resource records (RRs). +Some of the supported resource record types are described in +Section 6.3.1.

For more detailed information about the design of the DNS and +the DNS protocol, please refer to the standards documents listed in +Section A.3.1.

1.4.3. Zones

To properly operate a name server, it is important to understand +the difference between a zone +and a domain.

As we stated previously, a zone is a point of delegation in +the DNS tree. A zone consists of +those contiguous parts of the domain +tree for which a name server has complete information and over which +it has authority. It contains all domain names from a certain point +downward in the domain tree except those which are delegated to +other zones. A delegation point is marked by one or more +NS records in the +parent zone, which should be matched by equivalent NS records at +the root of the delegated zone.

For instance, consider the example.com +domain which includes names +such as host.aaa.example.com and +host.bbb.example.com even though +the example.com zone includes +only delegations for the aaa.example.com and +bbb.example.com zones. A zone can map +exactly to a single domain, but could also include only part of a +domain, the rest of which could be delegated to other +name servers. Every name in the DNS tree is a +domain, even if it is +terminal, that is, has no +subdomains. Every subdomain is a domain and +every domain except the root is also a subdomain. The terminology is +not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to +gain a complete understanding of this difficult and subtle +topic.

Though BIND is called a "domain name server", +it deals primarily in terms of zones. The master and slave +declarations in the named.conf file specify +zones, not domains. When you ask some other site if it is willing to +be a slave server for your domain, you are +actually asking for slave service for some collection of zones.

1.4.4. Authoritative Name Servers

Each zone is served by at least +one authoritative name server, +which contains the complete data for the zone. +To make the DNS tolerant of server and network failures, +most zones have two or more authoritative servers. +

Responses from authoritative servers have the "authoritative +answer" (AA) bit set in the response packets. This makes them +easy to identify when debugging DNS configurations using tools like +dig (Section 3.3.1.1).

1.4.4.1. The Primary Master

The authoritative server where the master copy of the zone data is maintained is +called the primary master server, or simply the +primary. It loads the zone contents from some +local file edited by humans or perhaps generated mechanically from +some other local file which is edited by humans. This file is called +the zone file or master file.

1.4.4.2. Slave Servers

The other authoritative servers, the slave +servers (also known as secondary servers) load +the zone contents from another server using a replication process +known as a zone transfer. Typically the data are +transferred directly from the primary master, but it is also possible +to transfer it from another slave. In other words, a slave server +may itself act as a master to a subordinate slave server.

1.4.4.3. Stealth Servers

Usually all of the zone's authoritative servers are listed in +NS records in the parent zone. These NS records constitute +a delegation of the zone from the parent. +The authoritative servers are also listed in the zone file itself, +at the top level or apex +of the zone. You can list servers in the zone's top-level NS +records that are not in the parent's NS delegation, but you cannot +list servers in the parent's delegation that are not present at +the zone's top level.

A stealth server is a server that is +authoritative for a zone but is not listed in that zone's NS +records. Stealth servers can be used for keeping a local copy of a +zone to speed up access to the zone's records or to make sure that the +zone is available even if all the "official" servers for the zone are +inaccessible.

A configuration where the primary master server itself is a +stealth server is often referred to as a "hidden primary" +configuration. One use for this configuration is when the primary master +is behind a firewall and therefore unable to communicate directly +with the outside world.

1.4.5. Caching Name Servers

The resolver libraries provided by most operating systems are +stub resolvers, meaning that they are not capable of +performing the full DNS resolution process by themselves by talking +directly to the authoritative servers. Instead, they rely on a local +name server to perform the resolution on their behalf. Such a server +is called a recursive name server; it performs +recursive lookups for local clients.

To improve performance, recursive servers cache the results of +the lookups they perform. Since the processes of recursion and +caching are intimately connected, the terms +recursive server and +caching server are often used synonymously.

The length of time for which a record may be retained in +in the cache of a caching name server is controlled by the +Time To Live (TTL) field associated with each resource record. +

1.4.5.1. Forwarding

Even a caching name server does not necessarily perform +the complete recursive lookup itself. Instead, it can +forward some or all of the queries +that it cannot satisfy from its cache to another caching name server, +commonly referred to as a forwarder. +

There may be one or more forwarders, +and they are queried in turn until the list is exhausted or an answer +is found. Forwarders are typically used when you do not +wish all the servers at a given site to interact directly with the rest of +the Internet servers. A typical scenario would involve a number +of internal DNS servers and an Internet firewall. Servers unable +to pass packets through the firewall would forward to the server +that can do it, and that server would query the Internet DNS servers +on the internal server's behalf. An added benefit of using the forwarding +feature is that the central machine develops a much more complete +cache of information that all the clients can take advantage +of.

1.4.6. Name Servers in Multiple Roles

The BIND name server can simultaneously act as +a master for some zones, a slave for other zones, and as a caching +(recursive) server for a set of local clients.

However, since the functions of authoritative name service +and caching/recursive name service are logically separate, it is +often advantageous to run them on separate server machines. + +A server that only provides authoritative name service +(an authoritative-only server) can run with +recursion disabled, improving reliability and security. + +A server that is not authoritative for any zones and only provides +recursive service to local +clients (a caching-only server) +does not need to be reachable from the Internet at large and can +be placed inside a firewall.

PrevHomeNext
BIND 9 Administrator Reference Manual BIND Resource Requirements
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch02.html b/contrib/bind9/doc/arm/Bv9ARM.ch02.html new file mode 100644 index 000000000000..0b293c7edfd6 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch02.html @@ -0,0 +1,284 @@ + +BIND Resource Requirements
BIND 9 Administrator Reference Manual
PrevNext

Chapter 2. BIND Resource Requirements

2.1. Hardware requirements

DNS hardware requirements have traditionally been quite modest. +For many installations, servers that have been pensioned off from +active duty have performed admirably as DNS servers.

The DNSSEC and IPv6 features of BIND 9 may prove to be quite +CPU intensive however, so organizations that make heavy use of these +features may wish to consider larger systems for these applications. +BIND 9 is fully multithreaded, allowing full utilization of +multiprocessor systems for installations that need it.

2.2. CPU Requirements

CPU requirements for BIND 9 range from i486-class machines +for serving of static zones without caching, to enterprise-class +machines if you intend to process many dynamic updates and DNSSEC +signed zones, serving many thousands of queries per second.

2.3. Memory Requirements

The memory of the server has to be large enough to fit the +cache and zones loaded off disk. The max-cache-size +option can be used to limit the amount of memory used by the cache, +at the expense of reducing cache hit rates and causing more DNS +traffic. It is still good practice to have enough memory to load +all zone and cache data into memory — unfortunately, the best way +to determine this for a given installation is to watch the name server +in operation. After a few weeks the server process should reach +a relatively stable size where entries are expiring from the cache as +fast as they are being inserted.

2.4. Name Server Intensive Environment Issues

For name server intensive environments, there are two alternative +configurations that may be used. The first is where clients and +any second-level internal name servers query a main name server, which +has enough memory to build a large cache. This approach minimizes +the bandwidth used by external name lookups. The second alternative +is to set up second-level internal name servers to make queries independently. +In this configuration, none of the individual machines needs to +have as much memory or CPU power as in the first alternative, but +this has the disadvantage of making many more external queries, +as none of the name servers share their cached data.

2.5. Supported Operating Systems

ISC BIND 9 compiles and runs on a large number +of Unix-like operating system and on Windows NT / 2000. For an up-to-date +list of supported systems, see the README file in the top level directory +of the BIND 9 source distribution.

PrevHomeNext
Introduction Name Server Configuration
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch03.html b/contrib/bind9/doc/arm/Bv9ARM.ch03.html new file mode 100644 index 000000000000..204d64ced912 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch03.html @@ -0,0 +1,1458 @@ + +Name Server Configuration
BIND 9 Administrator Reference Manual
PrevNext

Chapter 3. Name Server Configuration

In this section we provide some suggested configurations along +with guidelines for their use. We also address the topic of reasonable +option setting.

3.1. Sample Configurations

3.1.1. A Caching-only Name Server

The following sample configuration is appropriate for a caching-only +name server for use by clients internal to a corporation. All queries +from outside clients are refused using the allow-query +option. Alternatively, the same effect could be achieved using suitable +firewall rules.


// Two corporate subnets we wish to allow queries from.
+acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
+options {
+     directory "/etc/namedb";           // Working directory
+     allow-query { corpnets; };
+};
+// Provide a reverse mapping for the loopback address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+

3.1.2. An Authoritative-only Name Server

This sample configuration is for an authoritative-only server +that is the master server for "example.com" +and a slave for the subdomain "eng.example.com".


options {
+     directory "/etc/namedb";           // Working directory
+     allow-query { any; };              // This is the default
+     recursion no;                      // Do not provide recursive service
+};
+
+// Provide a reverse mapping for the loopback address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+// We are the master server for example.com
+zone "example.com" {
+     type master;
+     file "example.com.db";
+     // IP addresses of slave servers allowed to transfer example.com
+     allow-transfer {
+          192.168.4.14;
+          192.168.5.53;
+     };
+};
+// We are a slave server for eng.example.com
+zone "eng.example.com" {
+     type slave;
+     file "eng.example.com.bk";
+     // IP address of eng.example.com master server
+     masters { 192.168.4.12; };
+};
+

3.2. Load Balancing

A primitive form of load balancing can be achieved in +the DNS by using multiple A records for one name.

For example, if you have three WWW servers with network addresses +of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the +following means that clients will connect to each machine one third +of the time:

Name

TTL

CLASS

TYPE

Resource Record (RR) Data

www

600

IN

A

10.0.0.1

600

IN

A

10.0.0.2

600

IN

A

10.0.0.3

When a resolver queries for these records, BIND will rotate + them and respond to the query with the records in a different + order. In the example above, clients will randomly receive + records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients + will use the first record returned and discard the rest.

For more detail on ordering responses, check the + rrset-order substatement in the + options statement, see + RRset Ordering. + This substatement is not supported in + BIND 9, and only the ordering scheme described above is + available.

3.3. Name Server Operations

3.3.1. Tools for Use With the Name Server Daemon

There are several indispensable diagnostic, administrative +and monitoring tools available to the system administrator for controlling +and debugging the name server daemon. We describe several in this +section

3.3.1.1. Diagnostic Tools

The dig, host, and +nslookup programs are all command line tools +for manually querying name servers. They differ in style and +output format. +

dig

The domain information groper (dig) +is the most versatile and complete of these lookup tools. +It has two modes: simple interactive +mode for a single query, and batch mode which executes a query for +each in a list of several query lines. All query options are accessible +from the command line.

dig [@server] domain [query-type] [query-class] [+query-option] [-dig-option] [%comment]

The usual simple use of dig will take the form

dig @server domain query-type query-class

For more information and a list of available commands and +options, see the dig man page.

host

The host utility emphasizes simplicity +and ease of use. By default, it converts +between host names and Internet addresses, but its functionality +can be extended with the use of options.

host [-aCdlrTwv] [-c class] [-N ndots] [-t type] [-W timeout] [-R retries] hostname [server]

For more information and a list of available commands and +options, see the host man page.

nslookup

nslookup has two modes: interactive +and non-interactive. Interactive mode allows the user to query name servers +for information about various hosts and domains or to print a list +of hosts in a domain. Non-interactive mode is used to print just +the name and requested information for a host or domain.

nslookup [-option...] [host-to-find | - [server]]

Interactive mode is entered when no arguments are given (the +default name server will be used) or when the first argument is a +hyphen (`-') and the second argument is the host name or Internet address +of a name server.

Non-interactive mode is used when the name or Internet address +of the host to be looked up is given as the first argument. The +optional second argument specifies the host name or address of a name server.

Due to its arcane user interface and frequently inconsistent +behavior, we do not recommend the use of nslookup. +Use dig instead.

3.3.1.2. Administrative Tools

Administrative tools play an integral part in the management +of a server.

named-checkconf

The named-checkconf program + checks the syntax of a named.conf file.

named-checkconf [-t directory] [filename]

named-checkzone

The named-checkzone program checks a master file for + syntax and consistency.

named-checkzone [-dq] [-c class] zone [filename]

rndc

The remote name daemon control + (rndc) program allows the system + administrator to control the operation of a name server. + If you run rndc without any options + it will display a usage message as follows:

rndc [-c config] [-s server] [-p port] [-y key] command [command...]

command is one of the following:

reload

Reload configuration file and zones.

reload zone + [class + [view]]

Reload the given zone.

refresh zone + [class + [view]]

Schedule zone maintenance for the given zone.

retransfer zone + [class + [view]]

Retransfer the given zone from the master.

freeze zone + [class + [view]]

Suspend updates to a dynamic zone. This allows manual + edits to be made to a zone normally updated by dynamic update. It + also causes changes in the journal file to be synced into the master + and the journal file to be removed. All dynamic update attempts will + be refused while the zone is frozen.

unfreeze zone + [class + [view]]

Enable updates to a frozen dynamic zone. This causes + the server to reload the zone from disk, and re-enables dynamic updates + after the load has completed. After a zone is unfrozen, dynamic updates + will no longer be refused.

reconfig

Reload the configuration file and load new zones, + but do not reload existing zone files even if they have changed. + This is faster than a full reload when there + is a large number of zones because it avoids the need to examine the + modification times of the zones files. +

stats

Write server statistics to the statistics file.

querylog

Toggle query logging. Query logging can also be enabled + by explicitly directing the queries + category to a channel in the + logging section of + named.conf.

dumpdb

Dump the server's caches to the dump file.

stop

Stop the server, + making sure any recent changes + made through dynamic update or IXFR are first saved to the master files + of the updated zones.

halt

Stop the server immediately. Recent changes + made through dynamic update or IXFR are not saved to the master files, + but will be rolled forward from the journal files when the server + is restarted.

trace

Increment the servers debugging level by one.

trace level

Sets the server's debugging level to an explicit + value.

notrace

Sets the server's debugging level to 0.

flush

Flushes the server's cache.

status

Display status of the server. +Note the number of zones includes the internal bind/CH zone +and the default ./IN hint zone if there is not a +explicit root zone configured.

In BIND 9.2, rndc +supports all the commands of the BIND 8 ndc +utility except ndc start and +ndc restart, which were also +not supported in ndc's channel mode.

A configuration file is required, since all +communication with the server is authenticated with +digital signatures that rely on a shared secret, and +there is no way to provide that secret other than with a +configuration file. The default location for the +rndc configuration file is +/etc/rndc.conf, but an alternate +location can be specified with the -c +option. If the configuration file is not found, +rndc will also look in +/etc/rndc.key (or whatever +sysconfdir was defined when +the BIND build was configured). +The rndc.key file is generated by +running rndc-confgen -a as described in +Section 6.2.4.

The format of the configuration file is similar to +that of named.conf, but limited to +only four statements, the options, +key, server and +include +statements. These statements are what associate the +secret keys to the servers with which they are meant to +be shared. The order of statements is not +significant.

The options statement has three clauses: +default-server, default-key, +and default-port. +default-server takes a +host name or address argument and represents the server that will +be contacted if no -s +option is provided on the command line. +default-key takes +the name of a key as its argument, as defined by a key statement. +default-port specifies the port to which +rndc should connect if no +port is given on the command line or in a +server statement.

The key statement defines an key to be used +by rndc when authenticating with +named. Its syntax is identical to the +key statement in named.conf. +The keyword key is +followed by a key name, which must be a valid +domain name, though it need not actually be hierarchical; thus, +a string like "rndc_key" is a valid name. +The key statement has two clauses: +algorithm and secret. +While the configuration parser will accept any string as the argument +to algorithm, currently only the string "hmac-md5" +has any meaning. The secret is a base-64 encoded string.

The server statement associates a key +defined using the key statement with a server. +The keyword server is followed by a +host name or address. The server statement +has two clauses: key and port. +The key clause specifies the name of the key +to be used when communicating with this server, and the +port clause can be used to +specify the port rndc should connect +to on the server.

A sample minimal configuration file is as follows:


key rndc_key {
+     algorithm "hmac-md5";
+     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
+};
+options {
+     default-server 127.0.0.1;
+     default-key    rndc_key;
+};
+

This file, if installed as /etc/rndc.conf, +would allow the command:

$ rndc reload

to connect to 127.0.0.1 port 953 and cause the name server +to reload, if a name server on the local machine were running with +following controls statements:


controls {
+        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
+};
+

and it had an identical key statement for +rndc_key.

Running the rndc-confgen program will +conveniently create a rndc.conf +file for you, and also display the +corresponding controls statement that you need to +add to named.conf. Alternatively, +you can run rndc-confgen -a to set up +a rndc.key file and not modify +named.conf at all. +

3.3.2. Signals

Certain UNIX signals cause the name server to take specific +actions, as described in the following table. These signals can +be sent using the kill command.

SIGHUP

Causes the server to read named.conf and +reload the database.

SIGTERM

Causes the server to clean up and exit.

SIGINT

+

Causes the server to clean up and exit.

PrevHomeNext
BIND Resource Requirements Advanced DNS Features
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch04.html b/contrib/bind9/doc/arm/Bv9ARM.ch04.html new file mode 100644 index 000000000000..a1f90b4c5128 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch04.html @@ -0,0 +1,1602 @@ + +Advanced DNS Features
BIND 9 Administrator Reference Manual
PrevNext

Chapter 4. Advanced DNS Features

4.1. Notify

DNS NOTIFY is a mechanism that allows master +servers to notify their slave servers of changes to a zone's data. In +response to a NOTIFY 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.

DNS +For more information about +NOTIFY, see the description of the +notify option in Section 6.2.16.1 and +the description of the zone option also-notify in +Section 6.2.16.7. The NOTIFY +protocol is specified in RFC 1996. +

4.2. Dynamic Update

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 + in RFC 2136.

Dynamic update is enabled on a zone-by-zone basis, by + including an allow-update or + update-policy clause in the + zone statement.

Updating of secure zones (zones using DNSSEC) follows + RFC 3007: RRSIG and NSEC records affected by updates are automatically + regenerated by the server using an online zone key. + Update authorization is based + on transaction signatures and an explicit server policy.

4.2.1. The journal file

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 .jnl to the + name of the corresponding zone file. The journal file is in a + binary format and should not be edited manually.

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 + up to 15 minutes, allowing additional updates to take place.

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.

Changes that result from incoming incremental zone transfers are also + journalled in a similar way.

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 rndc stop.

If you have to make changes to a dynamic zone + manually, the following procedure will work: Disable dynamic updates + to the zone using + rndc freeze zone. + This will also remove the zone's .jnl file + and update the master file. Edit the zone file. Run + rndc unfreeze zone + to reload the changed zone and re-enable dynamic updates.

4.3. Incremental Zone Transfers (IXFR)

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 specified in RFC +1995. See Proposed Standards.

When acting as a master, BIND 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. For manually maintained master +zones, and for slave zones obtained by performing a full zone +transfer (AXFR), IXFR is supported only if the option +ixfr-from-differences is set +to yes. +

When acting as a slave, BIND 9 will +attempt to use IXFR unless +it is explicitly disabled. For more information about disabling +IXFR, see the description of the request-ixfr clause +of the server statement.

4.4. Split DNS

Setting up different views, or visibility, of the DNS space to +internal and external resolvers is usually referred to as a Split +DNS setup. There are several reasons an organization +would want to set up its DNS this way.

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.

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.

Here is an example of a split DNS setup:

Let's say a company named Example, Inc. +(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.

Example, Inc. 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.

In order to accomplish this, the company will set up two sets +of name servers. 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.

The internal servers will be configured to forward all queries, +except queries for site1.internal, site2.internal, site1.example.com, +and site2.example.com, to the servers in the +DMZ. These internal servers will have complete sets of information +for site1.example.com, site2.example.com, site1.internal, +and site2.internal.

To protect the site1.internal and site2.internal domains, +the internal name servers must be configured to disallow all queries +to these domains from any external hosts, including the bastion +hosts.

The external servers, which are on the bastion hosts, will +be configured to serve the "public" version of the site1 and site2.example.com zones. +This could include things such as the host records for public servers +(www.example.com and ftp.example.com), +and mail exchange (MX) records (a.mx.example.com and b.mx.example.com).

In addition, the public site1 and site2.example.com 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.

Here's an example of a wildcard MX record:

*   IN MX 10 external1.example.com.

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 +name servers for DNS resolution.

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.

In order for all this to work properly, internal clients will +need to be configured to query only the internal +name servers for DNS queries. This could also be enforced via selective +filtering on the network.

If everything has been set properly, Example, Inc.'s +internal clients will now be able to:

  • Look up any hostnames in the site1 and +site2.example.com zones.

  • Look up any hostnames in the site1.internal and +site2.internal domains.

  • Look up any hostnames on the Internet.

  • Exchange mail with internal AND external people.

Hosts on the Internet will be able to:

  • Look up any hostnames in the site1 and +site2.example.com zones.

  • Exchange mail with anyone in the site1 and +site2.example.com zones.

Here is an example configuration for the setup we just + described above. Note that this is only configuration information; + for information on how to configure your zone files, see Section 3.1

Internal DNS server config:


+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { bastion-ips-go-here; };
+
+options {
+    ...
+    ...
+    forward only;
+    forwarders {                                // forward to external servers
+        bastion-ips-go-here; 
+    };
+    allow-transfer { none; };                   // sample allow-transfer (no one)
+    allow-query { internals; externals; };      // restrict query access
+    allow-recursion { internals; };             // restrict recursion
+    ...
+    ...
+};
+
+zone "site1.example.com" {                      // sample master zone
+  type master;
+  file "m/site1.example.com";
+  forwarders { };                               // do normal iterative
+                                                // resolution (do not forward)
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site2.example.com" {                      // sample slave zone
+  type slave;
+  file "s/site2.example.com";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site1.internal" {
+  type master;
+  file "m/site1.internal";
+  forwarders { };
+  allow-query { internals; };
+  allow-transfer { internals; }
+};
+
+zone "site2.internal" {
+  type slave;
+  file "s/site2.internal";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals };
+  allow-transfer { internals; }
+};
+

External (bastion host) DNS server config:


acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { bastion-ips-go-here; };
+
+options {
+  ...
+  ...
+  allow-transfer { none; };                     // sample allow-transfer (no one)
+  allow-query { internals; externals; };        // restrict query access
+  allow-recursion { internals; externals; };    // restrict recursion
+  ...
+  ...
+};
+
+zone "site1.example.com" {                      // sample slave zone
+  type master;
+  file "m/site1.foo.com";
+  allow-query { any; };
+  allow-transfer { internals; externals; };
+};
+
+zone "site2.example.com" {
+  type slave;
+  file "s/site2.foo.com";
+  masters { another_bastion_host_maybe; };
+  allow-query { any; };
+  allow-transfer { internals; externals; }
+};
+

In the resolv.conf (or equivalent) on +the bastion host(s):


search ...
+nameserver 172.16.72.2
+nameserver 172.16.72.3
+nameserver 172.16.72.4
+

4.5. TSIG

This is a short guide to setting up Transaction SIGnatures +(TSIG) based transaction security in BIND. 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 BIND.

BIND primarily supports TSIG for server to server communication. +This includes zone transfer, notify, and recursive query messages. +Resolvers based on newer versions of BIND 8 have limited support +for TSIG.

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. + The cryptographic access control provided by TSIG + is far superior. The nsupdate + program supports TSIG via the -k and + -y command line options.

4.5.1. Generate Shared Keys for Each Pair of Hosts

A shared secret is generated to be shared between host1 and host2. +An arbitrary key name is chosen: "host1-host2.". The key name must +be the same on both hosts.

4.5.1.1. Automatic Generation

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.

dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.

The key is in the file Khost1-host2.+157+00000.private. +Nothing directly uses this file, but the base-64 encoded string +following "Key:" +can be extracted from the file and used as a shared secret:

Key: La/E5CjG9O+os1jq0a2jdA==

The string "La/E5CjG9O+os1jq0a2jdA==" can +be used as the shared secret.

4.5.1.2. Manual Generation

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.

Also, a known string can be run through mmencode or +a similar program to generate base-64 encoded data.

4.5.2. Copying the Shared Secret to Both Machines

This is beyond the scope of DNS. A secure transport mechanism +should be used. This could be secure FTP, ssh, telephone, etc.

4.5.3. Informing the Servers of the Key's Existence

Imagine host1 and host 2 are +both servers. The following is added to each server's named.conf file:


key host1-host2. {
+  algorithm hmac-md5;
+  secret "La/E5CjG9O+os1jq0a2jdA==";
+};
+

The algorithm, hmac-md5, is the only one supported by BIND. +The secret is the one generated above. Since this is a secret, it +is recommended that either named.conf be non-world +readable, or the key directive be added to a non-world readable +file that is included by named.conf.

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 is successfully verified, the +response is signed by the same key.

4.5.4. Instructing the Server to Use the Key

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 named.conf file +for host1, if the IP address of host2 is +10.1.2.3:


server 10.1.2.3 {
+  keys { host1-host2. ;};
+};
+

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.

If host1 sends a message that is a request +to that address, the message will be signed with the specified key. host1 will +expect any responses to signed messages to be signed with the same +key.

A similar statement must be present in host2's +configuration file (with host1's address) for host2 to +sign request messages to host1.

4.5.5. TSIG Key Based Access Control

BIND allows IP addresses and ranges to be specified in ACL +definitions and +allow-{ query | transfer | update } directives. +This has been extended to allow TSIG keys also. The above key would +be denoted key host1-host2.

An example of an allow-update directive would be:


allow-update { key host1-host2. ;};
+

This allows dynamic updates to succeed only if the request + was signed by a key named + "host1-host2.".

You may want to read about the more + powerful update-policy statement in Section 6.2.24.4.

4.5.6. Errors

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.

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.

4.6. TKEY

TKEY is a mechanism for automatically + generating a shared secret between two hosts. There are several + "modes" of TKEY that specify how the key is + generated or assigned. BIND 9 + 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 TKEY process + must use signed messages, signed either by TSIG or SIG(0). The + result of TKEY is a shared secret that can be + used to sign messages with TSIG. TKEY can also + be used to delete shared secrets that it had previously + generated.

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

4.7. SIG(0)

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

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.

SIG(0) signing of multiple-message TCP streams is not + supported.

The only tool shipped with BIND 9 that + generates SIG(0) signed messages is nsupdate.

4.8. DNSSEC

Cryptographic authentication of DNS information is possible + through the DNS Security (DNSSEC-bis) extensions, + defined in RFC <TBA>. This section describes the creation and use + of DNSSEC signed zones.

In order to set up a DNSSEC secure zone, there are a series + of steps which must be followed. BIND 9 ships + with several tools + that are used in this process, which are explained in more detail + below. In all cases, the -h option prints a + full list of parameters. Note that the DNSSEC tools require the + keyset files to be in the working directory or the + directory specified by the -h option, and + that the tools shipped with BIND 9.2.x and earlier are not compatible + with the current ones.

There must also be communication with the administrators of + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presense + or absence of a DS record at the delegation + point.

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.

4.8.1. Generating Keys

The dnssec-keygen program is used to + generate keys.

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 + ZONE, and must be usable for authentication. + It is recommended that zone keys use a cryptographic algorithm + designated as "mandatory to implement" by the IETF; currently + the only one is RSASHA1.

The following command will generate a 768 bit RSASHA1 key for + the child.example zone:

dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.

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

To generate another key with the same properties (but with + a different key tag), repeat the above command.

The public keys should be inserted into the zone file by + including the .key files using + $INCLUDE statements. +

4.8.2. Signing the Zone

The dnssec-signzone program is used to + sign a zone.

Any keyset files corresponding + to secure subzones should be present. The zone signer will + generate NSEC and RRSIG + records for the zone, as well as DS for + the child zones if '-d' is specified. + If '-d' is not specified then DS RRsets for + the secure child zones need to be added manually.

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

dnssec-signzone -o child.example zone.child.example

One output file is produced: + zone.child.example.signed. This file + should be referenced by named.conf as the + input file for the zone.

dnssec-signzone will also produce a + keyset and dsset files and optionally a dlvset file. These + are used to provide the parent zone administators with the + DNSKEYs (or their corresponding DS + records) that are the secure entry point to the zone.

4.8.3. Configuring Servers

Unlike BIND 8, +BIND 9 does not verify signatures on load, +so zone keys for authoritative zones do not need to be specified +in the configuration file.

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

4.9. IPv6 Support in BIND 9

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

For forward lookups, BIND 9 supports only AAAA + records. The use of A6 records is deprecated by RFC 3363, and the + support for forward lookups in BIND 9 is + removed accordingly. + However, authoritative BIND 9 name servers still + load zone files containing A6 records correctly, answer queries + for A6 records, and accept zone transfer for a zone containing A6 + records.

For IPv6 reverse lookups, BIND 9 supports + the traditional "nibble" format used in the + ip6.arpa domain, as well as the older, deprecated + ip6.int domain. + BIND 9 formerly + supported the "binary label" (also known as "bitstring") format. + The support of binary labels, however, is now completely removed + according to the changes in RFC 3363. + Any applications in BIND 9 do not understand + the format any more, and will return an error if given. + In particular, an authoritative BIND 9 name + server rejects to load a zone file containing binary labels.

For an overview of the format and structure of IPv6 addresses, + see Section A.2.1.

4.9.1. Address Lookups Using AAAA Records

The AAAA record is a parallel to the IPv4 A record. It + specifies the entire address in a single record. For + example,


$ORIGIN example.com.
+host            3600    IN      AAAA    2001:db8::1
+

It is recommended that IPv4-in-IPv6 mapped addresses not + be used. If a host has an IPv4 address, use an A record, not + a AAAA, with ::ffff:192.168.42.1 as the + address.

4.9.2. Address to Name Lookups Using Nibble Format

When looking up an address in nibble format, the address + components are simply reversed, just as in IPv4, and + ip6.arpa. is appended to the resulting name. + For example, the following would provide reverse name lookup for + a host with address + 2001:db8::1.


$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
+1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
+
PrevHomeNext
Name Server Configuration The BIND 9 Lightweight Resolver
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch05.html b/contrib/bind9/doc/arm/Bv9ARM.ch05.html new file mode 100644 index 000000000000..2ae7f2ec1302 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch05.html @@ -0,0 +1,265 @@ + +The BIND 9 Lightweight Resolver
BIND 9 Administrator Reference Manual
PrevNext

Chapter 5. The BIND 9 Lightweight Resolver

5.1. The Lightweight Resolver Library

Traditionally applications have been linked with a stub resolver +library that sends recursive DNS queries to a local caching name +server.

IPv6 once introduced new complexity into the resolution process, +such as following A6 chains and DNAME records, and simultaneous +lookup of IPv4 and IPv6 addresses. Though most of the complexity was +then removed, these are hard or impossible +to implement in a traditional stub resolver.

Instead, BIND 9 provides resolution services to local clients +using a combination of a lightweight resolver library and a resolver +daemon process running on the local host. These communicate using +a simple UDP-based protocol, the "lightweight resolver protocol" +that is distinct from and simpler than the full DNS protocol.

5.2. Running a Resolver Daemon

To use the lightweight resolver interface, the system must +run the resolver daemon lwresd or a local +name server configured with a lwres statement.

By default, applications using the lightweight resolver library will make +UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. The +address can be overridden by lwserver lines in +/etc/resolv.conf.

The daemon currently only looks in the DNS, but in the future +it may use other sources such as /etc/hosts, +NIS, etc.

The lwresd daemon is essentially a +caching-only name server that responds to requests using the lightweight +resolver protocol rather than the DNS protocol. Because it needs +to run on each host, it is designed to require no or minimal configuration. +Unless configured otherwise, it uses the name servers listed on +nameserver lines in /etc/resolv.conf +as forwarders, but is also capable of doing the resolution autonomously if +none are specified.

The lwresd daemon may also be configured with a +named.conf style configuration file, in +/etc/lwresd.conf by default. A name server may also +be configured to act as a lightweight resolver daemon using the +lwres statement in named.conf.

PrevHomeNext
Advanced DNS Features BIND 9 Configuration Reference
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch06.html b/contrib/bind9/doc/arm/Bv9ARM.ch06.html new file mode 100644 index 000000000000..a83ec38ef3fc --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch06.html @@ -0,0 +1,11479 @@ + +BIND 9 Configuration Reference
BIND 9 Administrator Reference Manual
PrevNext

Chapter 6. BIND 9 Configuration Reference

BIND 9 configuration is broadly similar +to BIND 8; however, there are a few new areas +of configuration, such as views. BIND +8 configuration files should work with few alterations in BIND +9, although more complex configurations should be reviewed to check +if they can be more efficiently implemented using the new features +found in BIND 9.

BIND 4 configuration files can be converted to the new format +using the shell script +contrib/named-bootconf/named-bootconf.sh.

6.1. Configuration File Elements

Following is a list of elements used throughout the BIND configuration +file documentation:

acl_name

The name of an address_match_list as +defined by the acl statement.

address_match_list

A list of one or more ip_addr, +ip_prefix, key_id, +or acl_name elements, see +Section 6.1.1.

domain_name

A quoted string which will be used as +a DNS name, for example "my.test.domain".

dotted_decimal

One to four integers valued 0 through +255 separated by dots (`.'), such as 123, +45.67 or 89.123.45.67.

ip4_addr

An IPv4 address with exactly four elements +in dotted_decimal notation.

ip6_addr

An IPv6 address, such as 2001:db8::1234. +IPv6 scoped addresses that have ambiguity on their scope zones must be +disambiguated by an appropriate zone ID with the percent character +(`%') as delimiter. +It is strongly recommended to use string zone names rather than +numeric identifiers, in order to be robust against system +configuration changes. +However, since there is no standard mapping for such names and +identifier values, currently only interface names as link identifiers +are supported, assuming one-to-one mapping between interfaces and links. +For example, a link-local address fe80::1 on the +link attached to the interface ne0 +can be specified as fe80::1%ne0. +Note that on most systems link-local addresses always have the +ambiguity, and need to be disambiguated.

ip_addr

An ip4_addr or ip6_addr.

ip_port

An IP port number. +number is limited to 0 through 65535, with values +below 1024 typically restricted to use by processes running as root. +In some cases an asterisk (`*') character can be used as a placeholder to +select a random high-numbered port.

ip_prefix

An IP network specified as an ip_addr, +followed by a slash (`/') and then the number of bits in the netmask. +Trailing zeros in a ip_addr may omitted. +For example, 127/8 is the network 127.0.0.0 with +netmask 255.0.0.0 and 1.2.3.0/28 is +network 1.2.3.0 with netmask 255.255.255.240.

key_id

A domain_name representing +the name of a shared key, to be used for transaction security.

key_list

A list of one or more key_ids, +separated by semicolons and ending with a semicolon.

number

A non-negative 32 bit integer +(i.e., a number between 0 and 4294967295, inclusive). +Its acceptable value might further +be limited by the context in which it is used.

path_name

A quoted string which will be used as +a pathname, such as zones/master/my.test.domain.

size_spec

A number, the word unlimited, +or the word default.

An unlimited size_spec requests unlimited +use, or the maximum available amount. A default size_spec uses +the limit that was in force when the server was started.

A number can +optionally be followed by a scaling factor: K or k for +kilobytes, M or m for +megabytes, and G or g for gigabytes, +which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.

+

The value must be representable as a 64-bit unsigned integer +(0 to 18446744073709551615, inclusive). +Using unlimited is the best way +to safely set a really large number.

yes_or_no

Either yes or no. +The words true and false are +also accepted, as are the numbers 1 and 0.

dialup_option

One of yes, +no, notify, +notify-passive, refresh or +passive. +When used in a zone, notify-passive, +refresh, and passive +are restricted to slave and stub zones.

6.1.1. Address Match Lists

6.1.1.1. Syntax

address_match_list = address_match_list_element ;
+  [ address_match_list_element; ... ]
+address_match_list_element = [ ! ] (ip_address [/length] |
+   key key_id | acl_name | { address_match_list } )
+

6.1.1.2. Definition and Usage

Address match lists are primarily used to determine access +control for various server operations. They are also used in +the listen-on and sortlist +statements. The elements +which constitute an address match list can be any of the following:

  • an IP address (IPv4 or IPv6)

  • an IP prefix (in `/' notation)

  • a key ID, as defined by the key statement

  • the name of an address match list previously defined with +the acl statement

  • a nested address match list enclosed in braces

Elements can be negated with a leading exclamation mark (`!'), +and the match list names "any", "none", "localhost", and "localnets" +are predefined. More information on those names can be found in +the description of the acl statement.

The addition of the key clause made the name of this syntactic +element something of a misnomer, since security keys can be used +to validate access without regard to a host or network address. Nonetheless, +the term "address match list" is still used throughout the documentation.

When a given IP address or prefix is compared to an address +match list, the list is traversed in order until an element matches. +The interpretation of a match depends on whether the list is being used +for access control, defining listen-on ports, or in a sortlist, +and whether the element was negated.

When used as an access control list, a non-negated match allows +access and a negated match denies access. If there is no match, +access is denied. The clauses allow-notify, +allow-query, allow-transfer, +allow-update, allow-update-forwarding, +and blackhole all +use address match lists this. Similarly, the listen-on option will cause +the server to not accept queries on any of the machine's addresses +which do not match the list.

Because of the first-match aspect of the algorithm, an element +that defines a subset of another element in the list should come +before the broader element, regardless of whether either is negated. For +example, in +1.2.3/24; ! 1.2.3.13; the 1.2.3.13 element is +completely useless because the algorithm will match any lookup for +1.2.3.13 to the 1.2.3/24 element. +Using ! 1.2.3.13; 1.2.3/24 fixes +that problem by having 1.2.3.13 blocked by the negation but all +other 1.2.3.* hosts fall through.

6.1.2. Comment Syntax

The BIND 9 comment syntax allows for comments to appear +anywhere that white space may appear in a BIND configuration +file. To appeal to programmers of all kinds, they can be written +in the C, C++, or shell/perl style.

6.1.2.1. Syntax

/* This is a BIND comment as in C */
+
// This is a BIND comment as in C++
+
# This is a BIND comment as in common UNIX shells and perl
+

6.1.2.2. Definition and Usage

Comments may appear anywhere that whitespace may appear in +a BIND configuration file.

C-style comments start with the two characters /* (slash, +star) and end with */ (star, slash). Because they are completely +delimited with these characters, they can be used to comment only +a portion of a line or to span multiple lines.

C-style comments cannot be nested. For example, the following +is not valid because the entire comment ends with the first */:

/* This is the start of a comment.
+   This is still part of the comment.
+/* This is an incorrect attempt at nesting a comment. */
+   This is no longer in any comment. */
+

C++-style comments start with the two characters // (slash, +slash) and continue to the end of the physical line. They cannot +be continued across multiple physical lines; to have one logical +comment span multiple lines, each line must use the // pair.

For example:

// This is the start of a comment.  The next line
+// is a new comment, even though it is logically
+// part of the previous comment.
+

Shell-style (or perl-style, if you prefer) comments start +with the character # (number sign) and continue to the end of the +physical line, as in C++ comments.

For example:

# This is the start of a comment.  The next line
+# is a new comment, even though it is logically
+# part of the previous comment.
+
+

Warning

You cannot use the semicolon (`;') character + to start a comment such as you would in a zone file. The + semicolon indicates the end of a configuration + statement.

6.2. Configuration File Grammar

A BIND 9 configuration consists of statements and comments. + Statements end with a semicolon. Statements and comments are the + only elements that can appear without enclosing braces. Many + statements contain a block of sub-statements, which are also + terminated with a semicolon.

The following statements are supported:

acl

defines a named IP address +matching list, for access control and other uses.

controls

declares control channels to be used +by the rndc utility.

include

includes a file.

key

specifies key information for use in +authentication and authorization using TSIG.

logging

specifies what the server logs, and where +the log messages are sent.

lwres

configures named to +also act as a light weight resolver daemon (lwresd).

masters

defines a named masters list for +inclusion in stub and slave zone masters clauses.

options

controls global server configuration +options and sets defaults for other statements.

server

sets certain configuration options on +a per-server basis.

trusted-keys

defines trusted DNSSEC keys.

view

defines a view.

zone

defines a zone.

The logging and + options statements may only occur once per + configuration.

6.2.1. acl Statement Grammar

acl acl-name { 
+    address_match_list 
+};
+

6.2.2. acl Statement Definition and +Usage

The acl statement assigns a symbolic + name to an address match list. It gets its name from a primary + use of address match lists: Access Control Lists (ACLs).

Note that an address match list's name must be defined + with acl before it can be used elsewhere; no + forward references are allowed.

The following ACLs are built-in:

any

Matches all hosts.

none

Matches no hosts.

localhost

Matches the IPv4 and IPv6 addresses of all network +interfaces on the system.

localnets

Matches any host on an IPv4 or IPv6 network +for which the system has an interface. +Some systems do not provide a way to determine the prefix lengths of +local IPv6 addresses. +In such a case, localnets only matches the local +IPv6 addresses, just like localhost. +

6.2.3. controls Statement Grammar

controls {
+   inet ( ip_addr | * ) [ port ip_port ] allow {  address_match_list  }
+                keys {  key_list  };
+   [ inet ...; ]
+};
+

6.2.4. controls Statement Definition and Usage

The controls statement declares control + channels to be used by system administrators to control the + operation of the name server. These control channels are + used by the rndc utility to send commands to + and retrieve non-DNS results from a name server.

An inet control channel is a TCP + socket listening at the specified + ip_port on the specified + ip_addr, which can be an IPv4 or IPv6 + address. An ip_addr + of * is interpreted as the IPv4 wildcard + address; connections will be accepted on any of the system's + IPv4 addresses. To listen on the IPv6 wildcard address, + use an ip_addr of ::. + If you will only use rndc on the local host, + using the loopback address (127.0.0.1 + or ::1) is recommended for maximum + security. +

If no port is specified, port 953 + is used. "*" cannot be used for + ip_port.

The ability to issue commands over the control channel is + restricted by the allow and + keys clauses. Connections to the control + channel are permitted based on the + address_match_list. This is for simple + IP address based filtering only; any key_id + elements of the address_match_list are + ignored. +

The primary authorization mechanism of the command + channel is the key_list, which contains + a list of key_ids. + Each key_id in + the key_list is authorized to execute + commands over the control channel. + See Remote Name Daemon Control application in + Section 3.3.1.2) for information about + configuring keys in rndc.

If no controls statement is present, +named will set up a default +control channel listening on the loopback address 127.0.0.1 +and its IPv6 counterpart ::1. +In this case, and also when the controls statement +is present but does not have a keys clause, +named will attempt to load the command channel key +from the file rndc.key in +/etc (or whatever sysconfdir +was specified as when BIND was built). +To create a rndc.key file, run +rndc-confgen -a. +

The rndc.key feature was created to + ease the transition of systems from BIND 8, + which did not have digital signatures on its command channel messages + and thus did not have a keys clause. + +It makes it possible to use an existing BIND 8 +configuration file in BIND 9 unchanged, +and still have rndc work the same way +ndc worked in BIND 8, simply by executing the +command rndc-confgen -a after BIND 9 is +installed. +

Since the rndc.key feature + is only intended to allow the backward-compatible usage of + BIND 8 configuration files, this feature does not + have a high degree of configurability. You cannot easily change + the key name or the size of the secret, so you should make a + rndc.conf with your own key if you wish to change + those things. The rndc.key file also has its + permissions set such that only the owner of the file (the user that + named is running as) can access it. If you + desire greater flexibility in allowing other users to access + rndc commands then you need to create an + rndc.conf and make it group readable by a group + that contains the users who should have access.

The UNIX control channel type of BIND 8 is not supported + in BIND 9, and is not expected to be added in future + releases. If it is present in the controls statement from a + BIND 8 configuration file, it is ignored + and a warning is logged.

To disable the command channel, use an empty controls +statement: controls { };. +

6.2.6. include Statement Definition and Usage

The include statement inserts the + specified file at the point where the include + statement is encountered. The include + statement facilitates the administration of configuration files + by permitting the reading or writing of some things but not + others. For example, the statement could include private keys + that are readable only by the name server.

6.2.7. key Statement Grammar

key key_id {
+    algorithm string;
+    secret string;
+};
+

6.2.8. key Statement Definition and Usage

The key statement defines a shared +secret key for use with TSIG (see Section 4.5) +or the command channel +(see Section 6.2.4). +

The key statement can occur at the top level +of the configuration file or inside a view +statement. Keys defined in top-level key +statements can be used in all views. Keys intended for use in +a controls statement +(see Section 6.2.4) +must be defined at the top level. +

The key_id, also known as the +key name, is a domain name uniquely identifying the key. It can +be used in a server +statement to cause requests sent to that +server to be signed with this key, or in address match lists to +verify that incoming requests have been signed with a key +matching this name, algorithm, and secret.

The algorithm_id is a string +that specifies a security/authentication algorithm. The only +algorithm currently supported with TSIG authentication is +hmac-md5. The +secret_string is the secret to be +used by the algorithm, and is treated as a base-64 encoded +string.

6.2.9. logging Statement Grammar

logging {
+   [ channel channel_name {
+     ( file path name
+         [ versions ( number | unlimited ) ]
+         [ size size spec ]
+       | syslog syslog_facility
+       | stderr
+       | null );
+     [ severity (critical | error | warning | notice |
+                 info | debug [ level ] | dynamic ); ]
+     [ print-category yes or no; ]
+     [ print-severity yes or no; ]
+     [ print-time yes or no; ]
+   }; ]
+   [ category category_name {
+     channel_name ; [ channel_name ; ... ]
+   }; ]
+   ...
+};
+

6.2.10. logging Statement Definition and Usage

The logging statement configures a wide +variety of logging options for the name server. Its channel phrase +associates output methods, format options and severity levels with +a name that can then be used with the category phrase +to select how various classes of messages are logged.

Only one logging statement is used to define +as many channels and categories as are wanted. If there is no logging statement, +the logging configuration will be:

logging {
+     category default { default_syslog; default_debug; };
+     category unmatched { null; };
+};
+

In BIND 9, the logging configuration is only established when +the entire configuration file has been parsed. In BIND 8, it was +established as soon as the logging statement +was parsed. When the server is starting up, all logging messages +regarding syntax errors in the configuration file go to the default +channels, or to standard error if the "-g" option +was specified.

6.2.10.1. The channel Phrase

All log output goes to one or more channels; +you can make as many of them as you want.

Every channel definition must include a destination clause that +says whether messages selected for the channel go to a file, to a +particular syslog facility, to the standard error stream, or are +discarded. It can optionally also limit the message severity level +that will be accepted by the channel (the default is +info), and whether to include a +named-generated time stamp, the category name +and/or severity level (the default is not to include any).

The null destination clause +causes all messages sent to the channel to be discarded; +in that case, other options for the channel are meaningless.

The file destination clause directs the channel +to a disk file. It can include limitations +both on how large the file is allowed to become, and how many versions +of the file will be saved each time the file is opened.

If you use the versions log file option, then +named will retain that many backup versions of the file by +renaming them when opening. For example, if you choose to keep 3 old versions +of the file lamers.log then just before it is opened +lamers.log.1 is renamed to +lamers.log.2, lamers.log.0 is renamed +to lamers.log.1, and lamers.log is +renamed to lamers.log.0. +You can say versions unlimited to not limit +the number of versions. +If a size option is associated with the log file, +then renaming is only done when the file being opened exceeds the +indicated size. No backup versions are kept by default; any existing +log file is simply appended.

The size option for files is used to limit log +growth. If the file ever exceeds the size, then named will +stop writing to the file unless it has a versions option +associated with it. If backup versions are kept, the files are rolled as +described above and a new one begun. If there is no +versions option, no more data will be written to the log +until some out-of-band mechanism removes or truncates the log to less than the +maximum size. The default behavior is not to limit the size of the +file.

Example usage of the size and +versions options:

channel an_example_channel {
+    file "example.log" versions 3 size 20m;
+    print-time yes;
+    print-category yes;
+};
+

The syslog destination clause directs the +channel to the system log. Its argument is a +syslog facility as described in the syslog man +page. Known facilities are kern, user, +mail, daemon, auth, +syslog, lpr, news, +uucp, cron, authpriv, +ftp, local0, local1, +local2, local3, local4, +local5, local6 and +local7, however not all facilities are supported on +all operating systems. +How syslog will handle messages sent to +this facility is described in the syslog.conf man +page. If you have a system which uses a very old version of syslog that +only uses two arguments to the openlog() function, +then this clause is silently ignored.

The severity clause works like syslog's +"priorities", except that they can also be used if you are writing +straight to a file rather than using syslog. +Messages which are not at least of the severity level given will +not be selected for the channel; messages of higher severity levels +will be accepted.

If you are using syslog, then the syslog.conf priorities +will also determine what eventually passes through. For example, +defining a channel facility and severity as daemon and debug but +only logging daemon.warning via syslog.conf will +cause messages of severity info and notice to +be dropped. If the situation were reversed, with named writing +messages of only warning or higher, then syslogd would +print all messages it received from the channel.

The stderr destination clause directs the +channel to the server's standard error stream. This is intended for +use when the server is running as a foreground process, for example +when debugging a configuration.

The server can supply extensive debugging information when +it is in debugging mode. If the server's global debug level is greater +than zero, then debugging mode will be active. The global debug +level is set either by starting the named server +with the -d flag followed by a positive integer, +or by running rndc trace. +The global debug level +can be set to zero, and debugging mode turned off, by running ndc +notrace. All debugging messages in the server have a debug +level, and higher debug levels give more detailed output. Channels +that specify a specific debug severity, for example:

channel specific_debug_level {
+    file "foo";
+    severity debug 3;
+};
+

will get debugging output of level 3 or less any time the +server is in debugging mode, regardless of the global debugging +level. Channels with dynamic severity use the +server's global debug level to determine what messages to print.

If print-time has been turned on, then +the date and time will be logged. print-time may +be specified for a syslog channel, but is usually +pointless since syslog also prints the date and +time. If print-category is requested, then the +category of the message will be logged as well. Finally, if print-severity is +on, then the severity level of the message will be logged. The print- options may +be used in any combination, and will always be printed in the following +order: time, category, severity. Here is an example where all three print- options +are on:

28-Feb-2000 15:05:32.863 general: notice: running

There are four predefined channels that are used for +named's default logging as follows. How they are +used is described in Section 6.2.10.2. +

channel default_syslog {
+    syslog daemon;                      // send to syslog's daemon
+                                        // facility
+    severity info;                      // only send priority info
+                                        // and higher
+};
+
+channel default_debug {
+    file "named.run";                   // write to named.run in
+                                        // the working directory
+                                        // Note: stderr is used instead
+                                        // of "named.run"
+                                        // if the server is started
+                                        // with the '-f' option.
+    severity dynamic;                   // log at the server's
+                                        // current debug level
+};
+
+channel default_stderr {
+    stderr;                             // writes to stderr
+    severity info;                      // only send priority info
+                                        // and higher
+};
+
+channel null {
+   null;                                // toss anything sent to
+                                        // this channel
+};
+

The default_debug channel has the special +property that it only produces output when the server's debug level is +nonzero. It normally writes to a file named.run +in the server's working directory.

For security reasons, when the "-u" +command line option is used, the named.run file +is created only after named has changed to the +new UID, and any debug output generated while named is +starting up and still running as root is discarded. If you need +to capture this output, you must run the server with the "-g" +option and redirect standard error to a file.

Once a channel is defined, it cannot be redefined. Thus you +cannot alter the built-in channels directly, but you can modify +the default logging by pointing categories at channels you have defined.

6.2.10.2. The category Phrase

There are many categories, so you can send the logs you want +to see wherever you want, without seeing logs you don't want. If +you don't specify a list of channels for a category, then log messages +in that category will be sent to the default category +instead. If you don't specify a default category, the following +"default default" is used:

category default { default_syslog; default_debug; };
+

As an example, let's say you want to log security events to +a file, but you also want keep the default logging behavior. You'd +specify the following:

channel my_security_channel {
+    file "my_security_file";
+    severity info;
+};
+category security {
+    my_security_channel;
+    default_syslog;
+    default_debug;
+};

To discard all messages in a category, specify the null channel:

category xfer-out { null; };
+category notify { null; };
+

Following are the available categories and brief descriptions +of the types of log information they contain. More +categories may be added in future BIND releases.

default

The default category defines the logging +options for those categories where no specific configuration has been +defined.

general

The catch-all. Many things still aren't +classified into categories, and they all end up here.

database

Messages relating to the databases used +internally by the name server to store zone and cache data.

security

Approval and denial of requests.

config

Configuration file parsing and processing.

resolver

DNS resolution, such as the recursive +lookups performed on behalf of clients by a caching name server.

xfer-in

Zone transfers the server is receiving.

xfer-out

Zone transfers the server is sending.

notify

The NOTIFY protocol.

client

Processing of client requests.

unmatched

Messages that named was unable to determine the +class of or for which there was no matching view. +A one line summary is also logged to the client category. +This category is best sent to a file or stderr, by default it is sent to +the null channel.

network

Network operations.

update

Dynamic updates.

update-security

Approval and denial of update requests.

queries

Specify where queries should be logged to.

+

At startup, specifing the category queries will also +enable query logging unless querylog option has been +specified. +

+

The query log entry reports the client's IP address and port number. The +query name, class and type. It also reports whether the Recursion Desired +flag was set (+ if set, - if not set), EDNS was in use (E) or if the +query was signed (S).

+
client 127.0.0.1#62536: query: www.example.com IN AAAA +SE
+client ::1#62537: query: www.example.net IN AAAA -SE
+
+

dispatch

Dispatching of incoming packets to the +server modules where they are to be processed. +

dnssec

DNSSEC and TSIG protocol processing. +

lame-servers

Lame servers. These are misconfigurations +in remote servers, discovered by BIND 9 when trying to query +those servers during resolution. +

delegation-only

Delegation only. Logs queries that have have +been forced to NXDOMAIN as the result of a delegation-only zone or +a delegation-only in a hint or stub zone declaration. +

6.2.11. lwres Statement Grammar

This is the grammar of the lwres +statement in the named.conf file:

lwres {
+    [ listen-on { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ view view_name; ]
+    [ search { domain_name ; [ domain_name ; ... ] }; ]
+    [ ndots number; ]
+};
+

6.2.12. lwres Statement Definition and Usage

The lwres statement configures the name +server to also act as a lightweight resolver server, see +Section 5.2. There may be be multiple +lwres statements configuring +lightweight resolver servers with different properties.

The listen-on statement specifies a list of +addresses (and ports) that this instance of a lightweight resolver daemon +should accept requests on. If no port is specified, port 921 is used. +If this statement is omitted, requests will be accepted on 127.0.0.1, +port 921.

The view statement binds this instance of a +lightweight resolver daemon to a view in the DNS namespace, so that the +response will be constructed in the same manner as a normal DNS query +matching this view. If this statement is omitted, the default view is +used, and if there is no default view, an error is triggered.

The search statement is equivalent to the +search statement in +/etc/resolv.conf. It provides a list of domains +which are appended to relative names in queries.

The ndots statement is equivalent to the +ndots statement in +/etc/resolv.conf. It indicates the minimum +number of dots in a relative domain name that should result in an +exact match lookup before search path elements are appended.

6.2.13. masters Statement Grammar


masters name [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] } ; 
+

6.2.14. masters Statement Definition and Usage

masters lists allow for a common set of masters +to be easily used by multiple stub and slave zones.

6.2.15. options Statement Grammar

This is the grammar of the options +statement in the named.conf file:

options {
+    [ version version_string; ]
+    [ hostname hostname_string; ]
+    [ server-id server_id_string; ]
+    [ directory path_name; ]
+    [ key-directory path_name; ]
+    [ named-xfer path_name; ]
+    [ tkey-domain domainname; ]
+    [ tkey-dhkey key_name key_tag; ]
+    [ dump-file path_name; ]
+    [ memstatistics-file path_name; ]
+    [ pid-file path_name; ]
+    [ statistics-file path_name; ]
+    [ zone-statistics yes_or_no; ]
+    [ auth-nxdomain yes_or_no; ]
+    [ deallocate-on-exit yes_or_no; ]
+    [ dialup dialup_option; ]
+    [ fake-iquery yes_or_no; ]
+    [ fetch-glue yes_or_no; ]
+    [ flush-zones-on-shutdown yes_or_no; ]
+    [ has-old-clients yes_or_no; ]
+    [ host-statistics yes_or_no; ]
+    [ minimal-responses yes_or_no; ]
+    [ multiple-cnames yes_or_no; ]
+    [ notify yes_or_no | explicit; ]
+    [ recursion yes_or_no; ]
+    [ rfc2308-type1 yes_or_no; ]
+    [ use-id-pool yes_or_no; ]
+    [ maintain-ixfr-base yes_or_no; ]
+    [ dnssec-enable yes_or_no; ]
+    [ dnssec-lookaside domain trust-anchor domain; ]
+    [ dnssec-must-be-secure domain yes_or_no; ]
+    [ forward ( only | first ); ]
+    [ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ dual-stack-servers [port ip_port] { ( domain_name [port ip_port] | ip_addr [port ip_port] ) ; ... }; ]
+    [ check-names ( master | slave |  response )( warn | fail | ignore ); ]
+    [ allow-notify { address_match_list }; ]
+    [ allow-query { address_match_list }; ]
+    [ allow-transfer { address_match_list }; ]
+    [ allow-recursion { address_match_list }; ]
+    [ allow-update-forwarding { address_match_list }; ]
+    [ allow-v6-synthesis { address_match_list }; ]
+    [ blackhole { address_match_list }; ]
+    [ avoid-v4-udp-ports { port_list }; ]
+    [ avoid-v6-udp-ports { port_list }; ]
+    [ listen-on [ port ip_port ] { address_match_list }; ]
+    [ listen-on-v6 [ port ip_port ] { address_match_list }; ]
+    [ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
+    [ query-source-v6 [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
+    [ max-transfer-time-in number; ]
+    [ max-transfer-time-out number; ]
+    [ max-transfer-idle-in number; ]
+    [ max-transfer-idle-out number; ]
+    [ tcp-clients number; ]
+    [ recursive-clients number; ]
+    [ serial-query-rate number; ]
+    [ serial-queries number; ]
+    [ tcp-listen-queue number; ]
+    [ transfer-format ( one-answer | many-answers ); ]
+    [ transfers-in  number; ]
+    [ transfers-out number; ]
+    [ transfers-per-ns number; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ use-alt-transfer-source yes_or_no; ]
+    [ notify-source (ip4_addr | *) [port ip_port] ; ]
+    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ max-ixfr-log-size number; ]
+    [ max-journal-size size_spec; ]
+    [ coresize size_spec ; ]
+    [ datasize size_spec ; ]
+    [ files size_spec ; ]
+    [ stacksize size_spec ; ]
+    [ cleaning-interval number; ]
+    [ heartbeat-interval number; ]
+    [ interface-interval number; ]
+    [ statistics-interval number; ]
+    [ topology { address_match_list }];
+    [ sortlist { address_match_list }];
+    [ rrset-order { order_spec ; [ order_spec ; ... ] ] };
+    [ lame-ttl number; ]
+    [ max-ncache-ttl number; ]
+    [ max-cache-ttl number; ]
+    [ sig-validity-interval number ; ]
+    [ min-roots number; ]
+    [ use-ixfr yes_or_no ; ]
+    [ provide-ixfr yes_or_no; ]
+    [ request-ixfr yes_or_no; ]
+    [ treat-cr-as-space yes_or_no ; ]
+    [ min-refresh-time number ; ]
+    [ max-refresh-time number ; ]
+    [ min-retry-time number ; ]
+    [ max-retry-time number ; ]
+    [ port ip_port; ]
+    [ additional-from-auth yes_or_no ; ]
+    [ additional-from-cache yes_or_no ; ]
+    [ random-device path_name ; ]
+    [ max-cache-size size_spec ; ]
+    [ match-mapped-addresses yes_or_no; ]
+    [ preferred-glue ( A | AAAA | NONE ); ]
+    [ edns-udp-size number; ]
+    [ root-delegation-only [ exclude { namelist } ] ; ]
+    [ querylog yes_or_no ; ]
+};
+    [ disable-algorithms domain { algorithm; [ algorithm; ] }; ]
+

6.2.16. options Statement Definition and Usage

The options statement sets up global options +to be used by BIND. This statement may appear only +once in a configuration file. If there is no options +statement, an options block with each option set to its default will +be used.

directory

The working directory of the server. +Any non-absolute pathnames in the configuration file will be taken +as relative to this directory. The default location for most server +output files (e.g. named.run) is this directory. +If a directory is not specified, the working directory defaults +to `.', the directory from which the server +was started. The directory specified should be an absolute path.

key-directory

When performing dynamic update of secure zones, the +directory where the public and private key files should be found, +if different than the current working directory. The directory specified +must be an absolute path.

named-xfer

This option is obsolete. +It was used in BIND 8 to +specify the pathname to the named-xfer program. +In BIND 9, no separate named-xfer program is +needed; its functionality is built into the name server.

tkey-domain

The domain appended to the names of all +shared keys generated with TKEY. When a client +requests a TKEY exchange, it may or may not specify +the desired name for the key. If present, the name of the shared +key will be "client specified part" + +"tkey-domain". +Otherwise, the name of the shared key will be "random hex +digits" + "tkey-domain". In most cases, +the domainname should be the server's domain +name.

tkey-dhkey

The Diffie-Hellman key used by the server +to generate shared keys with clients using the Diffie-Hellman mode +of TKEY. The server must be able to load the +public and private keys from files in the working directory. In +most cases, the keyname should be the server's host name.

dump-file

The pathname of the file the server dumps +the database to when instructed to do so with +rndc dumpdb. +If not specified, the default is named_dump.db.

memstatistics-file

The pathname of the file the server writes memory +usage statistics to on exit. If not specified, +the default is named.memstats.

pid-file

The pathname of the file the server writes its process ID +in. If not specified, the default is /var/run/named.pid. +The pid-file is used by programs that want to send signals to the running +name server. Specifying pid-file none disables the +use of a PID file — no file will be written and any +existing one will be removed. Note that none +is a keyword, not a file name, and therefore is not enclosed in +double quotes.

statistics-file

The pathname of the file the server appends statistics +to when instructed to do so using rndc stats. +If not specified, the default is named.stats in the +server's current directory. The format of the file is described +in Section 6.2.16.17

port

The UDP/TCP port number the server uses for +receiving and sending DNS protocol traffic. +The default is 53. This option is mainly intended for server testing; +a server using a port other than 53 will not be able to communicate with +the global DNS. +

random-device

The source of entropy to be used by the server. Entropy is primarily needed +for DNSSEC operations, such as TKEY transactions and dynamic update of signed +zones. This options specifies the device (or file) from which to read +entropy. If this is a file, operations requiring entropy will fail when the +file has been exhausted. If not specified, the default value is +/dev/random +(or equivalent) when present, and none otherwise. The +random-device option takes effect during +the initial configuration load at server startup time and +is ignored on subsequent reloads.

preferred-glue

If specified the listed type (A or AAAA) will be emitted before other glue +in the additional section of a query response. +The default is not to preference any type (NONE). +

root-delegation-only

Turn on enforcement of delegation-only in TLDs and root zones with an optional +exclude list. +

Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM"). +


options {
+	root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
+};
+
disable-algorithms

Disable the specified DNSSEC algorithms at and below the specified name. +Multiple disable-algorithms statements are allowed. +Only the most specific will be applied. +

dnssec-lookaside

When set dnssec-lookaside provides the +validator with an alternate method to validate DNSKEY records at the +top of a zone. When a DNSKEY is at or below a domain specified by the +deepest dnssec-lookaside, and the normal dnssec validation +has left the key untrusted, the trust-anchor will be append to the key +name and a DLV record will be looked up to see if it can validate the +key. If the DLV record validates a DNSKEY (similarly to the way a DS +record does) the DNSKEY RRset is deemed to be trusted. +

dnssec-must-be-secure

Specify heirachies which must / may not be secure (signed and validated). +If yes then named will only accept answers if they +are secure. +If no then normal dnssec validation applies +allowing for insecure answers to be accepted. +The specified domain must be under a trusted-key or +dnssec-lookaside must be active. +

6.2.16.1. Boolean Options

auth-nxdomain

If yes, then the AA bit +is always set on NXDOMAIN responses, even if the server is not actually +authoritative. The default is no; this is +a change from BIND 8. If you are using very old DNS software, you +may need to set it to yes.

deallocate-on-exit

This option was used in BIND 8 to enable checking +for memory leaks on exit. BIND 9 ignores the option and always performs +the checks.

dialup

If yes, then the +server treats all zones as if they are doing zone transfers across +a dial on demand dialup link, which can be brought up by traffic +originating from this server. This has different effects according +to zone type and concentrates the zone maintenance so that it all +happens in a short interval, once every heartbeat-interval and +hopefully during the one call. It also suppresses some of the normal +zone maintenance traffic. The default is no.

The dialup option +may also be specified in the view and +zone statements, +in which case it overrides the global dialup +option.

If the zone is a master zone then the server will send out a NOTIFY +request to all the slaves (default). This should trigger the zone serial +number check in the slave (providing it supports NOTIFY) allowing the slave +to verify the zone while the connection is active. +The set of servers to which NOTIFY is sent can be controlled by +notify and also-notify.

If the +zone is a slave or stub zone, then the server will suppress the regular +"zone up to date" (refresh) queries and only perform them when the +heartbeat-interval expires in addition to sending +NOTIFY requests.

Finer control can be achieved by using +notify which only sends NOTIFY messages, +notify-passive which sends NOTIFY messages and +suppresses the normal refresh queries, refresh +which suppresses normal refresh processing and sends refresh queries +when the heartbeat-interval expires, and +passive which just disables normal refresh +processing.

dialup mode

normal refresh

heart-beat refresh

heart-beat notify

no (default)

yes

no

no

yes

no

yes

yes

notify

yes

no

yes

refresh

no

yes

no

passive

no

no

no

notify-passive

no

no

yes

Note that normal NOTIFY processing is not affected by +dialup.

fake-iquery

In BIND 8, this option +enabled simulating the obsolete DNS query type +IQUERY. BIND 9 never does IQUERY simulation. +

fetch-glue

This option is obsolete. +In BIND 8, fetch-glue yes +caused the server to attempt to fetch glue resource records it +didn't have when constructing the additional +data section of a response. This is now considered a bad idea +and BIND 9 never does it.

flush-zones-on-shutdown

When the nameserver exits due receiving SIGTERM, +flush / do not flush any pending zone writes. The default is +flush-zones-on-shutdown no. +

has-old-clients

This option was incorrectly implemented +in BIND 8, and is ignored by BIND 9. +To achieve the intended effect +of +has-old-clients yes, specify +the two separate options auth-nxdomain yes +and rfc2308-type1 no instead. +

host-statistics

In BIND 8, this enables keeping of +statistics for every host that the name server interacts with. +Not implemented in BIND 9. +

maintain-ixfr-base

This option is obsolete. + It was used in BIND 8 to determine whether a transaction log was +kept for Incremental Zone Transfer. BIND 9 maintains a transaction +log whenever possible. If you need to disable outgoing incremental zone +transfers, use provide-ixfr no. +

minimal-responses

If yes, then when generating +responses the server will only add records to the authority and +additional data sections when they are required (e.g. delegations, +negative responses). This may improve the performance of the server. +The default is no. +

multiple-cnames

This option was used in BIND 8 to allow +a domain name to have multiple CNAME records in violation of the +DNS standards. BIND 9.2 always strictly +enforces the CNAME rules both in master files and dynamic updates. +

notify

If yes (the default), +DNS NOTIFY messages are sent when a zone the server is authoritative for +changes, see Section 4.1. The messages are sent to the +servers listed in the zone's NS records (except the master server identified +in the SOA MNAME field), and to any servers listed in the +also-notify option. +

If explicit, notifies are sent only to +servers explicitly listed using also-notify. +If no, no notifies are sent. +

The notify option may also be +specified in the zone statement, +in which case it overrides the options notify statement. +It would only be necessary to turn off this option if it caused slaves +to crash.

recursion

If yes, and a +DNS query requests recursion, then the server will attempt to do +all the work required to answer the query. If recursion is off +and the server does not already know the answer, it will return a +referral response. The default is yes. +Note that setting recursion no does not prevent +clients from getting data from the server's cache; it only +prevents new data from being cached as an effect of client queries. +Caching may still occur as an effect the server's internal +operation, such as NOTIFY address lookups. +See also fetch-glue above. +

rfc2308-type1

Setting this to yes will +cause the server to send NS records along with the SOA record for negative +answers. The default is no.

Note: Not yet implemented in BIND 9.

use-id-pool

This option is obsolete. +BIND 9 always allocates query IDs from a pool. +

zone-statistics

If yes, the server will collect +statistical data on all zones (unless specifically turned off +on a per-zone basis by specifying zone-statistics no +in the zone statement). These statistics may be accessed +using rndc stats, which will dump them to the file listed +in the statistics-file. See also Section 6.2.16.17. +

use-ixfr

This option is obsolete. +If you need to disable IXFR to a particular server or servers see +the information on the provide-ixfr option +in Section 6.2.18. See also +Section 4.3. +

provide-ixfr

See the description of +provide-ixfr in +Section 6.2.18 +

request-ixfr

See the description of +request-ixfr in +Section 6.2.18 +

treat-cr-as-space

This option was used in BIND 8 to make +the server treat carriage return ("\r") characters the same way +as a space or tab character, +to facilitate loading of zone files on a UNIX system that were generated +on an NT or DOS machine. In BIND 9, both UNIX "\n" +and NT/DOS "\r\n" newlines are always accepted, +and the option is ignored.

additional-from-auth, additional-from-cache

These options control the behavior of an authoritative server when +answering queries which have additional data, or when following CNAME +and DNAME chains. +

When both of these options are set to yes +(the default) and a +query is being answered from authoritative data (a zone +configured into the server), the additional data section of the +reply will be filled in using data from other authoritative zones +and from the cache. In some situations this is undesirable, such +as when there is concern over the correctness of the cache, or +in servers where slave zones may be added and modified by +untrusted third parties. Also, avoiding +the search for this additional data will speed up server operations +at the possible expense of additional queries to resolve what would +otherwise be provided in the additional section. +

For example, if a query asks for an MX record for host foo.example.com, +and the record found is "MX 10 mail.example.net", normally the address +records (A and AAAA) for mail.example.net will be provided as well, +if known, even though they are not in the example.com zone. +Setting these options to no disables this behavior and makes +the server only search for additional data in the zone it answers from. +

These options are intended for use in authoritative-only +servers, or in authoritative-only views. Attempts to set +them to no without also specifying +recursion no will cause the server to +ignore the options and log a warning message. +

Specifying additional-from-cache no actually +disables the use of the cache not only for additional data lookups +but also when looking up the answer. This is usually the desired +behavior in an authoritative-only server where the correctness of +the cached data is an issue. +

When a name server is non-recursively queried for a name that is not +below the apex of any served zone, it normally answers with an +"upwards referral" to the root servers or the servers of some other +known parent of the query name. Since the data in an upwards referral +comes from the cache, the server will not be able to provide upwards +referrals when additional-from-cache no +has been specified. Instead, it will respond to such queries +with REFUSED. This should not cause any problems since +upwards referrals are not required for the resolution process. +

match-mapped-addresses

If yes, then an +IPv4-mapped IPv6 address will match any address match +list entries that match the corresponding IPv4 address. +Enabling this option is sometimes useful on IPv6-enabled Linux +systems, to work around a kernel quirk that causes IPv4 +TCP connections such as zone transfers to be accepted +on an IPv6 socket using mapped addresses, causing +address match lists designed for IPv4 to fail to match. +The use of this option for any other purpose is discouraged. +

ixfr-from-differences

When 'yes' and the server loads a new version of a master +zone from its zone file or receives a new version of a slave +file by a non-incremental zone transfer, it will compare +the new version to the previous one and calculate a set +of differences. The differences are then logged in the +zone's journal file such that the changes can be transmitted +to downstream slaves as an incremental zone transfer. +

By allowing incremental zone transfers to be used for +non-dynamic zones, this option saves bandwidth at the +expense of increased CPU and memory consumption at the master. +In particular, if the new version of a zone is completely +different from the previous one, the set of differences +will be of a size comparable to the combined size of the +old and new zone version, and the server will need to +temporarily allocate memory to hold this complete +difference set. +

multi-master

This should be set when you have multiple masters for a zone and the +addresses refer to different machines. If 'yes' named will not log +when the serial number on the master is less than what named currently +has. The default is no. +

dnssec-enable

Enable DNSSEC support in named. Unless set to yes +named behaves as if it does not support DNSSEC. +The default is no. +

querylog

Specify whether query logging should be started when named start. +If querylog is not specified then the query logging +is determined by the presence of the logging category queries. +

6.2.16.2. Forwarding

The forwarding facility can be used to create a large site-wide +cache on a few servers, reducing traffic over links to external +name servers. It can also be used to allow queries by servers that +do not have direct access to the Internet, but wish to look up exterior +names anyway. Forwarding occurs only on those queries for which +the server is not authoritative and does not have the answer in +its cache.

forward

This option is only meaningful if the +forwarders list is not empty. A value of first, +the default, causes the server to query the forwarders first, and +if that doesn't answer the question the server will then look for +the answer itself. If only is specified, the +server will only query the forwarders. +

forwarders

Specifies the IP addresses to be used +for forwarding. The default is the empty list (no forwarding). +

Forwarding can also be configured on a per-domain basis, allowing +for the global forwarding options to be overridden in a variety +of ways. You can set particular domains to use different forwarders, +or have a different forward only/first behavior, +or not forward at all, see Section 6.2.23.

6.2.16.3. Dual-stack Servers

Dual-stack servers are used as servers of last resort to work around +problems in reachability due the lack of support for either IPv4 or IPv6 +on the host machine.

dual-stack-servers

Specifies host names / addresses of machines with access to +both IPv4 and IPv6 transports. If a hostname is used the server must be able +to resolve the name using only the transport it has. If the machine is dual +stacked then the dual-stack-servers have no effect unless +access to a transport has been disabled on the command line +(e.g. named -4).

6.2.16.4. Access Control

Access to the server can be restricted based on the IP address +of the requesting system. See Section 6.1.1 for +details on how to specify IP address lists.

allow-notify

Specifies which hosts are allowed to +notify this server, a slave, of zone changes in addition +to the zone masters. +allow-notify may also be specified in the +zone statement, in which case it overrides the +options allow-notify statement. It is only meaningful +for a slave zone. If not specified, the default is to process notify messages +only from a zone's master.

allow-query

Specifies which hosts are allowed to +ask ordinary DNS questions. allow-query may also +be specified in the zone statement, in which +case it overrides the options allow-query statement. If +not specified, the default is to allow queries from all hosts.

allow-recursion

Specifies which hosts are allowed to +make recursive queries through this server. If not specified, the +default is to allow recursive queries from all hosts. +Note that disallowing recursive queries for a host does not prevent the +host from retrieving data that is already in the server's cache. +

allow-update-forwarding

Specifies which hosts are allowed to +submit Dynamic DNS updates to slave zones to be forwarded to the +master. The default is { none; }, which +means that no update forwarding will be performed. To enable +update forwarding, specify +allow-update-forwarding { any; };. +Specifying values other than { none; } or +{ any; } is usually counterproductive, since +the responsibility for update access control should rest with the +master server, not the slaves.

Note that enabling the update forwarding feature on a slave server +may expose master servers relying on insecure IP address based +access control to attacks; see Section 7.3 +for more details.

allow-v6-synthesis

This option was introduced for the smooth transition from AAAA +to A6 and from "nibble labels" to binary labels. +However, since both A6 and binary labels were then deprecated, +this option was also deprecated. +It is now ignored with some warning messages. +

allow-transfer

Specifies which hosts are allowed to +receive zone transfers from the server. allow-transfer may +also be specified in the zone statement, in which +case it overrides the options allow-transfer statement. +If not specified, the default is to allow transfers to all hosts.

blackhole

Specifies a list of addresses that the +server will not accept queries from or use to resolve a query. Queries +from these addresses will not be responded to. The default is none.

6.2.16.5. Interfaces

The interfaces and ports that the server will answer queries +from may be specified using the listen-on option. listen-on takes +an optional port, and an address_match_list. +The server will listen on all interfaces allowed by the address +match list. If a port is not specified, port 53 will be used.

Multiple listen-on statements are allowed. +For example,

listen-on { 5.6.7.8; };
+listen-on port 1234 { !1.2.3.4; 1.2/16; };
+

will enable the name server on port 53 for the IP address +5.6.7.8, and on port 1234 of an address on the machine in net +1.2 that is not 1.2.3.4.

If no listen-on is specified, the +server will listen on port 53 on all interfaces.

The listen-on-v6 option is used to +specify the interfaces and the ports on which the server will listen +for incoming queries sent using IPv6.

When 

{ any; }
is specified +as the address_match_list for the +listen-on-v6 option, +the server does not bind a separate socket to each IPv6 interface +address as it does for IPv4 if the operating system has enough API +support for IPv6 (specifically if it conforms to RFC 3493 and RFC 3542). +Instead, it listens on the IPv6 wildcard address. +If the system only has incomplete API support for IPv6, however, +the behavior is the same as that for IPv4.

A list of particular IPv6 addresses can also be specified, in which case +the server listens on a separate socket for each specified address, +regardless of whether the desired API is supported by the system.

Multiple listen-on-v6 options can be used. +For example,

listen-on-v6 { any; };
+listen-on-v6 port 1234 { !2001:db8::/32; any; };
+

will enable the name server on port 53 for any IPv6 addresses +(with a single wildcard socket), +and on port 1234 of IPv6 addresses that is not in the prefix +2001:db8::/32 (with separate sockets for each matched address.)

To make the server not listen on any IPv6 address, use

listen-on-v6 { none; };
+

If no listen-on-v6 option is specified, +the server will not listen on any IPv6 address.

6.2.16.6. Query Address

If the server doesn't know the answer to a question, it will +query other name servers. query-source specifies +the address and port used for such queries. For queries sent over +IPv6, there is a separate query-source-v6 option. +If address is * or is omitted, +a wildcard IP address (INADDR_ANY) will be used. +If port is * or is omitted, +a random unprivileged port will be used, avoid-v4-udp-ports +and avoid-v6-udp-ports can be used to prevent named +from selecting certain ports. The defaults are

query-source address * port *;
+query-source-v6 address * port *;
+

Note: The address specified in the query-source option +is used for both UDP and TCP queries, but the port applies only to +UDP queries. TCP queries always use a random +unprivileged port.

Note: See also transfer-source and +notify-source.

6.2.16.7. Zone Transfers

BIND has mechanisms in place to facilitate zone transfers +and set limits on the amount of load that transfers place on the +system. The following options apply to zone transfers.

also-notify

Defines a global list of IP addresses of name servers +that are also sent NOTIFY messages whenever a fresh copy of the +zone is loaded, in addition to the servers listed in the zone's NS records. +This helps to ensure that copies of the zones will +quickly converge on stealth servers. If an also-notify list +is given in a zone statement, it will override +the options also-notify statement. When a zone notify statement +is set to no, the IP addresses in the global also-notify list will +not be sent NOTIFY messages for that zone. The default is the empty +list (no global notification list).

max-transfer-time-in

Inbound zone transfers running longer than +this many minutes will be terminated. The default is 120 minutes +(2 hours). The maximum value is 28 days (40320 minutes).

max-transfer-idle-in

Inbound zone transfers making no progress +in this many minutes will be terminated. The default is 60 minutes +(1 hour). The maximum value is 28 days (40320 minutes).

max-transfer-time-out

Outbound zone transfers running longer than +this many minutes will be terminated. The default is 120 minutes +(2 hours). The maximum value is 28 days (40320 minutes).

max-transfer-idle-out

Outbound zone transfers making no progress +in this many minutes will be terminated. The default is 60 minutes (1 +hour). The maximum value is 28 days (40320 minutes).

serial-query-rate

Slave servers will periodically query master servers +to find out if zone serial numbers have changed. Each such query uses +a minute amount of the slave server's network bandwidth. To limit the +amount of bandwidth used, BIND 9 limits the rate at which queries are +sent. The value of the serial-query-rate option, +an integer, is the maximum number of queries sent per second. +The default is 20. +

serial-queries

In BIND 8, the serial-queries option +set the maximum number of concurrent serial number queries +allowed to be outstanding at any given time. +BIND 9 does not limit the number of outstanding +serial queries and ignores the serial-queries option. +Instead, it limits the rate at which the queries are sent +as defined using the serial-query-rate option. +

transfer-format

Zone transfers can be sent using two different formats, +one-answer and many-answers. +The transfer-format option is used +on the master server to determine which format it sends. +one-answer uses one DNS message per +resource record transferred. +many-answers packs as many resource records as +possible into a message. many-answers is more +efficient, but is only supported by relatively new slave servers, +such as BIND 9, BIND 8.x and patched +versions of BIND 4.9.5. The default is +many-answers. transfer-format +may be overridden on a per-server basis by using the +server statement. +

transfers-in

The maximum number of inbound zone transfers +that can be running concurrently. The default value is 10. +Increasing transfers-in may speed up the convergence +of slave zones, but it also may increase the load on the local system.

transfers-out

The maximum number of outbound zone transfers +that can be running concurrently. Zone transfer requests in excess +of the limit will be refused. The default value is 10.

transfers-per-ns

The maximum number of inbound zone transfers +that can be concurrently transferring from a given remote name server. +The default value is 2. Increasing transfers-per-ns may +speed up the convergence of slave zones, but it also may increase +the load on the remote name server. transfers-per-ns may +be overridden on a per-server basis by using the transfers phrase +of the server statement.

transfer-source

transfer-source determines +which local address will be bound to IPv4 TCP connections used to +fetch zones transferred inbound by the server. It also determines +the source IPv4 address, and optionally the UDP port, used for the +refresh queries and forwarded dynamic updates. If not set, it defaults +to a system controlled value which will usually be the address of +the interface "closest to" the remote end. This address must appear +in the remote end's allow-transfer option for +the zone being transferred, if one is specified. This statement +sets the transfer-source for all zones, but can +be overridden on a per-view or per-zone basis by including a +transfer-source statement within the +view or zone block +in the configuration file.

transfer-source-v6

The same as transfer-source, +except zone transfers are performed using IPv6.

alt-transfer-source

An alternate transfer source if the one listed in +transfer-source fails and +use-alt-transfer-source is set.

alt-transfer-source-v6

An alternate transfer source if the one listed in +transfer-source-v6 fails and +use-alt-transfer-source is set.

use-alt-transfer-source

Use the alternate transfer sources or not. If views are +specified this defaults to no otherwise it defaults to +yes (for BIND 8 compatibility).

notify-source

notify-source determines +which local source address, and optionally UDP port, will be used to +send NOTIFY messages. +This address must appear in the slave server's masters +zone clause or in an allow-notify clause. +This statement sets the notify-source for all zones, +but can be overridden on a per-zone / per-view basis by including a +notify-source statement within the zone +or view block in the configuration file.

notify-source-v6

Like notify-source, +but applies to notify messages sent to IPv6 addresses.

6.2.16.8. Bad UDP Port Lists

avoid-v4-udp-ports and avoid-v6-udp-ports +specify a list of IPv4 and IPv6 UDP ports that will not be used as system +assigned source ports for UDP sockets. These lists prevent named +from choosing as its random source port a port that is blocked by +your firewall. If a query went out with such a source port, the +answer would not get by the firewall and the name server would have +to query again. +

6.2.16.9. Operating System Resource Limits

The server's usage of many system resources can be limited. +Scaled values are allowed when specifying resource limits. For +example, 1G can be used instead of +1073741824 to specify a limit of one +gigabyte. unlimited requests unlimited use, or the +maximum available amount. default uses the limit +that was in force when the server was started. See the description of +size_spec in Section 6.1.

The following options set operating system resource limits for +the name server process. Some operating systems don't support some or +any of the limits. On such systems, a warning will be issued if the +unsupported limit is used.

coresize

The maximum size of a core dump. The default +is default.

datasize

The maximum amount of data memory the server +may use. The default is default. +This is a hard limit on server memory usage. +If the server attempts to allocate memory in excess of this +limit, the allocation will fail, which may in turn leave +the server unable to perform DNS service. Therefore, +this option is rarely useful as a way of limiting the +amount of memory used by the server, but it can be used +to raise an operating system data size limit that is +too small by default. If you wish to limit the amount +of memory used by the server, use the +max-cache-size and +recursive-clients +options instead. +

files

The maximum number of files the server +may have open concurrently. The default is unlimited. +

stacksize

The maximum amount of stack memory the server +may use. The default is default.

6.2.16.10. Server Resource Limits

The following options set limits on the server's +resource consumption that are enforced internally by the +server rather than the operating system.

max-ixfr-log-size

This option is obsolete; it is accepted +and ignored for BIND 8 compatibility. The option +max-journal-size performs a similar +function in BIND 8. +

max-journal-size

Sets a maximum size for each journal file +(Section 4.2.1). When the journal file approaches +the specified size, some of the oldest transactions in the journal +will be automatically removed. The default is +unlimited.

recursive-clients

The maximum number of simultaneous recursive lookups +the server will perform on behalf of clients. The default is +1000. Because each recursing client uses a fair +bit of memory, on the order of 20 kilobytes, the value of the +recursive-clients option may have to be decreased +on hosts with limited memory. +

tcp-clients

The maximum number of simultaneous client TCP +connections that the server will accept. +The default is 100.

max-cache-size

The maximum amount of memory to use for the +server's cache, in bytes. When the amount of data in the cache +reaches this limit, the server will cause records to expire +prematurely so that the limit is not exceeded. In a server with +multiple views, the limit applies separately to the cache of each +view. The default is unlimited, meaning that +records are purged from the cache only when their TTLs expire. +

tcp-listen-queue

The listen queue depth. The default and minimum is 3. +If the kernel supports the accept filter "dataready" this also controls how +many TCP connections that will be queued in kernel space waiting for +some data before being passed to accept. Values less than 3 will be +silently raised. +

6.2.16.11. Periodic Task Intervals

cleaning-interval

The server will remove expired resource records +from the cache every cleaning-interval minutes. +The default is 60 minutes. The maximum value is 28 days (40320 minutes). +If set to 0, no periodic cleaning will occur.

heartbeat-interval

The server will perform zone maintenance tasks +for all zones marked as dialup whenever this +interval expires. The default is 60 minutes. Reasonable values are up +to 1 day (1440 minutes). The maximum value is 28 days (40320 minutes). +If set to 0, no zone maintenance for these zones will occur.

interface-interval

The server will scan the network interface list +every interface-interval minutes. The default +is 60 minutes. The maximum value is 28 days (40320 minutes). +If set to 0, interface scanning will only occur when +the configuration file is loaded. After the scan, the server will +begin listening for queries on any newly discovered +interfaces (provided they are allowed by the +listen-on configuration), and will +stop listening on interfaces that have gone away.

statistics-interval

Name server statistics will be logged +every statistics-interval minutes. The default is +60. The maximum value is 28 days (40320 minutes). +If set to 0, no statistics will be logged.

Note: Not yet implemented in BIND9.

6.2.16.12. Topology

All other things being equal, when the server chooses a name server +to query from a list of name servers, it prefers the one that is +topologically closest to itself. The topology statement +takes an address_match_list and interprets it +in a special way. Each top-level list element is assigned a distance. +Non-negated elements get a distance based on their position in the +list, where the closer the match is to the start of the list, the +shorter the distance is between it and the server. A negated match +will be assigned the maximum distance from the server. If there +is no match, the address will get a distance which is further than +any non-negated list element, and closer than any negated element. +For example,

topology {
+    10/8;
+    !1.2.3/24;
+    { 1.2/16; 3/8; };
+};

will prefer servers on network 10 the most, followed by hosts +on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the +exception of hosts on network 1.2.3 (netmask 255.255.255.0), which +is preferred least of all.

The default topology is

    topology { localhost; localnets; };
+

Note: The topology option +is not implemented in BIND 9. +

6.2.16.13. The sortlist Statement

The response to a DNS query may consist of multiple resource +records (RRs) forming a resource records set (RRset). +The name server will normally return the +RRs within the RRset in an indeterminate order +(but see the rrset-order +statement in Section 6.2.16.14). +The client resolver code should rearrange the RRs as appropriate, +that is, using any addresses on the local net in preference to other addresses. +However, not all resolvers can do this or are correctly configured. +When a client is using a local server the sorting can be performed +in the server, based on the client's address. This only requires +configuring the name servers, not all the clients.

The sortlist statement (see below) takes +an address_match_list and interprets it even +more specifically than the topology statement +does (Section 6.2.16.12). +Each top level statement in the sortlist must +itself be an explicit address_match_list with +one or two elements. The first element (which may be an IP address, +an IP prefix, an ACL name or a nested address_match_list) +of each top level list is checked against the source address of +the query until a match is found.

Once the source address of the query has been matched, if +the top level statement contains only one element, the actual primitive +element that matched the source address is used to select the address +in the response to move to the beginning of the response. If the +statement is a list of two elements, then the second element is +treated the same as the address_match_list in +a topology statement. Each top level element +is assigned a distance and the address in the response with the minimum +distance is moved to the beginning of the response.

In the following example, any queries received from any of +the addresses of the host itself will get responses preferring addresses +on any of the locally connected networks. Next most preferred are addresses +on the 192.168.1/24 network, and after that either the 192.168.2/24 +or +192.168.3/24 network with no preference shown between these two +networks. Queries received from a host on the 192.168.1/24 network +will prefer other addresses on that network to the 192.168.2/24 +and +192.168.3/24 networks. Queries received from a host on the 192.168.4/24 +or the 192.168.5/24 network will only prefer other addresses on +their directly connected networks.

sortlist {
+    { localhost;                                   // IF   the local host
+        { localnets;                               // THEN first fit on the
+            192.168.1/24;                          //   following nets
+            { 192.168.2/24; 192.168.3/24; }; }; };
+    { 192.168.1/24;                                // IF   on class C 192.168.1
+        { 192.168.1/24;                            // THEN use .1, or .2 or .3
+            { 192.168.2/24; 192.168.3/24; }; }; };
+    { 192.168.2/24;                                // IF   on class C 192.168.2
+        { 192.168.2/24;                            // THEN use .2, or .1 or .3
+            { 192.168.1/24; 192.168.3/24; }; }; };
+    { 192.168.3/24;                                // IF   on class C 192.168.3
+        { 192.168.3/24;                            // THEN use .3, or .1 or .2
+            { 192.168.1/24; 192.168.2/24; }; }; };
+    { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
+    };
+};

The following example will give reasonable behavior for the +local host and hosts on directly connected networks. It is similar +to the behavior of the address sort in BIND 4.9.x. Responses sent +to queries from the local host will favor any of the directly connected +networks. Responses sent to queries from any other hosts on a directly +connected network will prefer addresses on that same network. Responses +to other queries will not be sorted.

sortlist {
+           { localhost; localnets; };
+           { localnets; };
+};
+

6.2.16.14. RRset Ordering

When multiple records are returned in an answer it may be +useful to configure the order of the records placed into the response. +The rrset-order statement permits configuration +of the ordering of the records in a multiple record response. +See also the sortlist statement, +Section 6.2.16.13. +

An order_spec is defined as follows:

[ class class_name ][ type type_name ][ name "domain_name"]
+      order ordering
+

If no class is specified, the default is ANY. +If no type is specified, the default is ANY. +If no name is specified, the default is "*".

The legal values for ordering are:

fixed

Records are returned in the order they +are defined in the zone file.

random

Records are returned in some random order.

cyclic

Records are returned in a round-robin +order.

For example:

rrset-order {
+   class IN type A name "host.example.com" order random;
+   order cyclic;
+};
+

will cause any responses for type A records in class IN that +have "host.example.com" as a suffix, to always be returned +in random order. All other records are returned in cyclic order.

If multiple rrset-order statements appear, +they are not combined — the last one applies.

Note: The rrset-order statement +is not yet fully implemented in BIND 9. +BIND 9 currently does not support "fixed" ordering. +

6.2.16.15. Tuning

lame-ttl

Sets the number of seconds to cache a +lame server indication. 0 disables caching. (This is +NOT recommended.) +Default is 600 (10 minutes). Maximum value is +1800 (30 minutes).

max-ncache-ttl

To reduce network traffic and increase performance +the server stores negative answers. max-ncache-ttl is +used to set a maximum retention time for these answers in the server +in seconds. The default +max-ncache-ttl is 10800 seconds (3 hours). +max-ncache-ttl cannot exceed 7 days and will +be silently truncated to 7 days if set to a greater value.

max-cache-ttl

max-cache-ttl sets +the maximum time for which the server will cache ordinary (positive) +answers. The default is one week (7 days).

min-roots

The minimum number of root servers that +is required for a request for the root servers to be accepted. Default +is 2.

Note: Not implemented in BIND9.

sig-validity-interval

Specifies the number of days into the +future when DNSSEC signatures automatically generated as a result +of dynamic updates (Section 4.2) +will expire. The default is 30 days. +The maximum value is 10 years (3660 days). The signature +inception time is unconditionally set to one hour before the current time +to allow for a limited amount of clock skew.

min-refresh-time, max-refresh-time, min-retry-time, max-retry-time

These options control the server's behavior on refreshing a zone +(querying for SOA changes) or retrying failed transfers. +Usually the SOA values for the zone are used, but these values +are set by the master, giving slave server administrators little +control over their contents. +

These options allow the administrator to set a minimum and maximum +refresh and retry time either per-zone, per-view, or globally. +These options are valid for slave and stub zones, +and clamp the SOA refresh and retry times to the specified values. +

edns-udp-size

edns-udp-size sets the advertised EDNS UDP buffer +size. Valid values are 512 to 4096 (values outside this range will be +silently adjusted). The default value is 4096. The usual reason for +setting edns-udp-size to a non default value it to get UDP answers to +pass through broken firewalls that block fragmented packets and/or +block UDP packets that are greater than 512 bytes. +

6.2.16.16. Built-in server information zones

The server provides some helpful diagnostic information +through a number of built-in zones under the +pseudo-top-level-domain bind in the +CHAOS class. These zones are part of a +built-in view (see Section 6.2.21) of class +CHAOS which is separate from the default view of +class IN; therefore, any global server options +such as allow-query do not apply the these zones. +If you feel the need to disable these zones, use the options +below, or hide the built-in CHAOS view by +defining an explicit view of class CHAOS +that matches all clients.

version

The version the server should report +via a query of the name version.bind +with type TXT, class CHAOS. +The default is the real version number of this server. +Specifying version none +disables processing of the queries.

hostname

The hostname the server should report via a query of +the name hostname.bind +with type TXT, class CHAOS. +This defaults to the hostname of the machine hosting the name server as +found by gethostname(). The primary purpose of such queries is to +identify which of a group of anycast servers is actually +answering your queries. Specifying hostname none; +disables processing of the queries.

server-id

The ID of the server should report via a query of +the name ID.SERVER +with type TXT, class CHAOS. +The primary purpose of such queries is to +identify which of a group of anycast servers is actually +answering your queries. Specifying server-id none; +disables processing of the queries. +Specifying server-id hostname; will cause named to +use the hostname as found by gethostname(). +The default server-id is none. +

6.2.16.17. The Statistics File

The statistics file generated by BIND 9 +is similar, but not identical, to that +generated by BIND 8. +

The statistics dump begins with the line +++ Statistics Dump ++++ (973798949), where the number in parentheses is a standard +Unix-style timestamp, measured as seconds since January 1, 1970. Following +that line are a series of lines containing a counter type, the value of the +counter, optionally a zone name, and optionally a view name. +The lines without view and zone listed are global statistics for the entire server. +Lines with a zone and view name for the given view and zone (the view name is +omitted for the default view). The statistics dump ends +with the line --- Statistics Dump --- (973798949), where the +number is identical to the number in the beginning line.

The following statistics counters are maintained:

success

The number of +successful queries made to the server or zone. A successful query +is defined as query which returns a NOERROR response with at least +one answer RR.

referral

The number of queries which resulted +in referral responses.

nxrrset

The number of queries which resulted in +NOERROR responses with no data.

nxdomain

The number +of queries which resulted in NXDOMAIN responses.

failure

The number of queries which resulted in a +failure response other than those above.

recursion

The number of queries which caused the server +to perform recursion in order to find the final answer.

Each query received by the server will cause exactly one of +success, +referral, +nxrrset, +nxdomain, or +failure +to be incremented, and may additionally cause the +recursion counter to be incremented. +

6.2.17. server Statement Grammar

server ip_addr {
+    [ bogus yes_or_no ; ]
+    [ provide-ixfr yes_or_no ; ]
+    [ request-ixfr yes_or_no ; ]
+    [ edns yes_or_no ; ]
+    [ transfers number ; ]
+    [ transfer-format ( one-answer | many-answers ) ; ]]
+    [ keys { string ; [ string ; [...]] } ; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+};
+

6.2.18. server Statement Definition and Usage

The server statement defines characteristics +to be associated with a remote name server.

The server statement can occur at the top level of the +configuration file or inside a view statement. +If a view statement contains +one or more server statements, only those +apply to the view and any top-level ones are ignored. +If a view contains no server statements, +any top-level server statements are used as +defaults. +

If you discover that a remote server is giving out bad data, +marking it as bogus will prevent further queries to it. The default +value of bogus is no.

The provide-ixfr clause determines whether +the local server, acting as master, will respond with an incremental +zone transfer when the given remote server, a slave, requests it. +If set to yes, incremental transfer will be provided +whenever possible. If set to no, all transfers +to the remote server will be non-incremental. If not set, the value +of the provide-ixfr option in the view or +global options block is used as a default.

The request-ixfr clause determines whether +the local server, acting as a slave, will request incremental zone +transfers from the given remote server, a master. If not set, the +value of the request-ixfr option in the view or +global options block is used as a default.

IXFR requests to servers that do not support IXFR will automatically +fall back to AXFR. Therefore, there is no need to manually list +which servers support IXFR and which ones do not; the global default +of yes should always work. +The purpose of the provide-ixfr and +request-ixfr clauses is +to make it possible to disable the use of IXFR even when both master +and slave claim to support it, for example if one of the servers +is buggy and crashes or corrupts data when IXFR is used.

The edns clause determines whether the local server +will attempt to use EDNS when communicating with the remote server. The +default is yes.

The server supports two zone transfer methods. The first, one-answer, +uses one DNS message per resource record transferred. many-answers packs +as many resource records as possible into a message. many-answers is +more efficient, but is only known to be understood by BIND 9, BIND +8.x, and patched versions of BIND 4.9.5. You can specify which method +to use for a server with the transfer-format option. +If transfer-format is not specified, the transfer-format specified +by the options statement will be used.

transfers is used to limit the number of +concurrent inbound zone transfers from the specified server. If +no transfers clause is specified, the limit is +set according to the transfers-per-ns option.

The keys clause identifies a +key_id defined by the key statement, +to be used for transaction security (TSIG, Section 4.5) +when talking to the remote server. +When a request is sent to the remote server, a request signature +will be generated using the key specified here and appended to the +message. A request originating from the remote server is not required +to be signed by this key.

Although the grammar of the keys clause +allows for multiple keys, only a single key per server is currently +supported.

The transfer-source and +transfer-source-v6 clauses specify the IPv4 and IPv6 source +address to be used for zone transfer with the remote server, respectively. +For an IPv4 remote server, only transfer-source can +be specified. +Similarly, for an IPv6 remote server, only +transfer-source-v6 can be specified. +Form more details, see the description of +transfer-source and +transfer-source-v6 in +Section 6.2.16.7.

6.2.19. trusted-keys Statement Grammar

trusted-keys {
+    string number number number string ;
+    [ string number number number string ; [...]]
+};
+

6.2.20. trusted-keys Statement Definition +and Usage

The trusted-keys statement defines DNSSEC +security roots. DNSSEC is described in Section 4.8. A security root is defined when the public key for a non-authoritative +zone is known, but cannot be securely obtained through DNS, either +because it is the DNS root zone or because its parent zone is unsigned. +Once a key has been configured as a trusted key, it is treated as +if it had been validated and proven secure. The resolver attempts +DNSSEC validation on all DNS data in subdomains of a security root.

The trusted-keys statement can contain +multiple key entries, each consisting of the key's domain name, +flags, protocol, algorithm, and the base-64 representation of the +key data.

6.2.21. view Statement Grammar

view view_name 
+      [class] {
+      match-clients { address_match_list } ;
+      match-destinations { address_match_list } ;
+      match-recursive-only yes_or_no ;
+      [ view_option; ...]
+      [ zone_statement; ...]
+};
+

6.2.22. view Statement Definition and Usage

The view statement is a powerful new feature +of BIND 9 that lets a name server answer a DNS query differently +depending on who is asking. It is particularly useful for implementing +split DNS setups without having to run multiple servers.

Each view statement defines a view of the +DNS namespace that will be seen by a subset of clients. A client matches +a view if its source IP address matches the +address_match_list of the view's +match-clients clause and its destination IP address matches +the address_match_list of the view's +match-destinations clause. If not specified, both +match-clients and match-destinations +default to matching all addresses. In addition to checking IP addresses +match-clients and match-destinations +can also take keys which provide an mechanism for the +client to select the view. A view can also be specified +as match-recursive-only, which means that only recursive +requests from matching clients will match that view. +The order of the view statements is significant — +a client request will be resolved in the context of the first +view that it matches.

Zones defined within a view statement will +be only be accessible to clients that match the view. + By defining a zone of the same name in multiple views, different +zone data can be given to different clients, for example, "internal" +and "external" clients in a split DNS setup.

Many of the options given in the options statement +can also be used within a view statement, and then +apply only when resolving queries with that view. When no view-specific +value is given, the value in the options statement +is used as a default. Also, zone options can have default values specified +in the view statement; these view-specific defaults +take precedence over those in the options statement.

Views are class specific. If no class is given, class IN +is assumed. Note that all non-IN views must contain a hint zone, +since only the IN class has compiled-in default hints.

If there are no view statements in the config +file, a default view that matches any client is automatically created +in class IN. Any zone statements specified on +the top level of the configuration file are considered to be part of +this default view, and the options statement will +apply to the default view. If any explicit view +statements are present, all zone statements must +occur inside view statements.

Here is an example of a typical split DNS setup implemented +using view statements.

view "internal" {
+      // This should match our internal networks.
+      match-clients { 10.0.0.0/8; };
+
+      // Provide recursive service to internal clients only.
+      recursion yes;
+
+      // Provide a complete view of the example.com zone
+      // including addresses of internal hosts.
+      zone "example.com" {
+            type master;
+            file "example-internal.db";
+      };
+};
+
+view "external" {
+      // Match all clients not matched by the previous view.
+      match-clients { any; };
+
+      // Refuse recursive service to external clients.
+      recursion no;
+
+      // Provide a restricted view of the example.com zone
+      // containing only publicly accessible hosts.
+      zone "example.com" {
+           type master;
+           file "example-external.db";
+      };
+};
+

6.2.23. zone +Statement Grammar

zone zone_name [class] [{ 
+    type ( master | slave | hint | stub | forward | delegation-only ) ;
+    [ allow-notify { address_match_list } ; ]
+    [ allow-query { address_match_list } ; ]
+    [ allow-transfer { address_match_list } ; ]
+    [ allow-update { address_match_list } ; ]
+    [ update-policy { update_policy_rule [...] } ; ]
+    [ allow-update-forwarding { address_match_list } ; ]
+    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ check-names (warn|fail|ignore) ; ]
+    [ dialup dialup_option ; ]
+    [ delegation-only yes_or_no ; ]
+    [ file string ; ]
+    [ forward (only|first) ; ]
+    [ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ ixfr-base string ; ]
+    [ ixfr-tmp-file string ; ]
+    [ maintain-ixfr-base yes_or_no ; ]
+    [ masters [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] } ; ]
+    [ max-ixfr-log-size number ; ]
+    [ max-transfer-idle-in number ; ]
+    [ max-transfer-idle-out number ; ]
+    [ max-transfer-time-in number ; ]
+    [ max-transfer-time-out number ; ]
+    [ notify yes_or_no | explicit ; ]
+    [ pubkey number number number string ; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ use-alt-transfer-source yes_or_no; ]
+    [ notify-source (ip4_addr | *) [port ip_port] ; ]
+    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ zone-statistics yes_or_no ; ]
+    [ sig-validity-interval number ; ]
+    [ database string ; ]
+    [ min-refresh-time number ; ]
+    [ max-refresh-time number ; ]
+    [ min-retry-time number ; ]
+    [ max-retry-time number ; ]
+    [ multi-master yes_or_no ; ]
+    [ key-directory path_name; ]
+
+}];
+

6.2.24. zone Statement Definition and Usage

6.2.24.1. Zone Types

master

The server has a master copy of the data +for the zone and will be able to provide authoritative answers for +it.

slave

A slave zone is a replica of a master +zone. The masters list specifies one or more IP addresses +of master servers that the slave contacts to update its copy of the zone. +Masters list elements can also be names of other masters lists. +By default, transfers are made from port 53 on the servers; this can +be changed for all servers by specifying a port number before the +list of IP addresses, or on a per-server basis after the IP address. +Authentication to the master can also be done with per-server TSIG keys. +If a file is specified, then the +replica will be written to this file whenever the zone is changed, +and reloaded from this file on a server restart. Use of a file is +recommended, since it often speeds server start-up and eliminates +a needless waste of bandwidth. Note that for large numbers (in the +tens or hundreds of thousands) of zones per server, it is best to +use a two level naming scheme for zone file names. For example, +a slave server for the zone example.com might place +the zone contents into a file called +ex/example.com where ex/ is +just the first two letters of the zone name. (Most operating systems +behave very slowly if you put 100 000 files into +a single directory.)

stub

A stub zone is similar to a slave zone, +except that it replicates only the NS records of a master zone instead +of the entire zone. Stub zones are not a standard part of the DNS; +they are a feature specific to the BIND implementation. +

+ +

Stub zones can be used to eliminate the need for glue NS record +in a parent zone at the expense of maintaining a stub zone entry and +a set of name server addresses in named.conf. +This usage is not recommended for new configurations, and BIND 9 +supports it only in a limited way. +In BIND 4/8, zone transfers of a parent zone +included the NS records from stub children of that zone. This meant +that, in some cases, users could get away with configuring child stubs +only in the master server for the parent zone. BIND +9 never mixes together zone data from different zones in this +way. Therefore, if a BIND 9 master serving a parent +zone has child stub zones configured, all the slave servers for the +parent zone also need to have the same child stub zones +configured.

+ +

Stub zones can also be used as a way of forcing the resolution +of a given domain to use a particular set of authoritative servers. +For example, the caching name servers on a private network using +RFC1981 addressing may be configured with stub zones for +10.in-addr.arpa +to use a set of internal name servers as the authoritative +servers for that domain.

+

forward

A "forward zone" is a way to configure +forwarding on a per-domain basis. A zone statement +of type forward can contain a forward and/or forwarders statement, +which will apply to queries within the domain given by the zone +name. If no forwarders statement is present or +an empty list for forwarders is given, then no +forwarding will be done for the domain, canceling the effects of +any forwarders in the options statement. Thus +if you want to use this type of zone to change the behavior of the +global forward option (that is, "forward first +to", then "forward only", or vice versa, but want to use the same +servers as set globally) you need to re-specify the global forwarders.

+

hint

The initial set of root name servers is +specified using a "hint zone". When the server starts up, it uses +the root hints to find a root name server and get the most recent +list of root name servers. If no hint zone is specified for class +IN, the server uses a compiled-in default set of root servers hints. +Classes other than IN have no built-in defaults hints.

delegation-only

This is used to enforce the delegation only +status of infrastructure zones (e.g. COM, NET, ORG). Any answer that +is received without a explicit or implicit delegation in the authority +section will be treated as NXDOMAIN. This does not apply to the zone +apex. This SHOULD NOT be applied to leaf zones.

+

delegation-only has no effect on answers received +from forwarders.

6.2.24.2. Class

The zone's name may optionally be followed by a class. If +a class is not specified, class IN (for Internet), +is assumed. This is correct for the vast majority of cases.

The hesiod class is +named for an information service from MIT's Project Athena. It is +used to share information about various systems databases, such +as users, groups, printers and so on. The keyword +HS is +a synonym for hesiod.

Another MIT development is CHAOSnet, a LAN protocol created +in the mid-1970s. Zone data for it can be specified with the CHAOS class.

6.2.24.3. Zone Options

allow-notify

See the description of +allow-notify in Section 6.2.16.4

allow-query

See the description of +allow-query in Section 6.2.16.4

allow-transfer

See the description of allow-transfer +in Section 6.2.16.4.

allow-update

Specifies which hosts are allowed to +submit Dynamic DNS updates for master zones. The default is to deny +updates from all hosts. Note that allowing updates based +on the requestor's IP address is insecure; see +Section 7.3 for details. +

update-policy

Specifies a "Simple Secure Update" policy. See +Section 6.2.24.4.

allow-update-forwarding

See the description of allow-update-forwarding +in Section 6.2.16.4.

also-notify

Only meaningful if notify is +active for this zone. The set of machines that will receive a +DNS NOTIFY message +for this zone is made up of all the listed name servers (other than +the primary master) for the zone plus any IP addresses specified +with also-notify. A port may be specified +with each also-notify address to send the notify +messages to a port other than the default of 53. +also-notify is not meaningful for stub zones. +The default is the empty list.

check-names

This option is used to restrict the character set and syntax of +certain domain names in master files and/or DNS responses received from the +network. +

database

Specify the type of database to be used for storing the +zone data. The string following the database keyword +is interpreted as a list of whitespace-delimited words. The first word +identifies the database type, and any subsequent words are passed +as arguments to the database to be interpreted in a way specific +to the database type.

The default is "rbt", BIND 9's native in-memory +red-black-tree database. This database does not take arguments.

Other values are possible if additional database drivers +have been linked into the server. Some sample drivers are included +with the distribution but none are linked in by default.

dialup

See the description of +dialup in Section 6.2.16.1.

delegation-only

The flag only applies to hint and stub zones. If set +to yes then the zone will also be treated as if it +is also a delegation-only type zone. +

forward

Only meaningful if the zone has a forwarders +list. The only value causes the lookup to fail +after trying the forwarders and getting no answer, while first would +allow a normal lookup to be tried.

forwarders

Used to override the list of global forwarders. +If it is not specified in a zone of type forward, +no forwarding is done for the zone; the global options are not used.

ixfr-base

Was used in BIND 8 to specify the name +of the transaction log (journal) file for dynamic update and IXFR. +BIND 9 ignores the option and constructs the name of the journal +file by appending ".jnl" to the name of the +zone file.

ixfr-tmp-file

Was an undocumented option in BIND 8. +Ignored in BIND 9.

max-transfer-time-in

See the description of +max-transfer-time-in in Section 6.2.16.7.

max-transfer-idle-in

See the description of +max-transfer-idle-in in Section 6.2.16.7.

max-transfer-time-out

See the description of +max-transfer-time-out in Section 6.2.16.7.

max-transfer-idle-out

See the description of +max-transfer-idle-out in Section 6.2.16.7.

notify

See the description of +notify in Section 6.2.16.1.

pubkey

In BIND 8, this option was intended for specifying +a public zone key for verification of signatures in DNSSEC signed +zones when they are loaded from disk. BIND 9 does not verify signatures +on load and ignores the option.

zone-statistics

If yes, the server will keep statistical +information for this zone, which can be dumped to the +statistics-file defined in the server options.

sig-validity-interval

See the description of +sig-validity-interval in Section 6.2.16.15.

transfer-source

See the description of +transfer-source in Section 6.2.16.7 +

transfer-source-v6

See the description of +transfer-source-v6 in Section 6.2.16.7 +

alt-transfer-source

See the description of +alt-transfer-source in Section 6.2.16.7 +

alt-transfer-source-v6

See the description of +alt-transfer-source-v6 in Section 6.2.16.7 +

use-alt-transfer-source

See the description of +use-alt-transfer-source in Section 6.2.16.7 +

notify-source

See the description of +notify-source in Section 6.2.16.7 +

notify-source-v6

See the description of +notify-source-v6 in Section 6.2.16.7. +

min-refresh-time, max-refresh-time, min-retry-time, max-retry-time

See the description in Section 6.2.16.15. +

ixfr-from-differences

See the description of +ixfr-from-differences in Section 6.2.16.1.

key-directory

See the description of +key-directory in Section 6.2.16

multi-master

See the description of +multi-master in Section 6.2.16.1.

6.2.24.4. Dynamic Update Policies

BIND 9 supports two alternative methods of granting clients +the right to perform dynamic updates to a zone, +configured by the allow-update and +update-policy option, respectively.

The allow-update clause works the same +way as in previous versions of BIND. It grants given clients the +permission to update any record of any name in the zone.

The update-policy clause is new in BIND +9 and allows more fine-grained control over what updates are allowed. +A set of rules is specified, where each rule either grants or denies +permissions for one or more names to be updated by one or more identities. + If the dynamic update request message is signed (that is, it includes +either a TSIG or SIG(0) record), the identity of the signer can +be determined.

Rules are specified in the update-policy zone +option, and are only meaningful for master zones. When the update-policy statement +is present, it is a configuration error for the allow-update statement +to be present. The update-policy statement only +examines the signer of a message; the source address is not relevant.

This is how a rule definition looks:


( grant | deny ) identity nametype name [ types ]
+

Each rule grants or denies privileges. Once a message has +successfully matched a rule, the operation is immediately granted +or denied and no further rules are examined. A rule is matched +when the signer matches the identity field, the name matches the +name field in accordance with the nametype field, and the type matches +the types specified in the type field.

The identity field specifies a name or a wildcard name. Normally, this +is the name of the TSIG or SIG(0) key used to sign the update request. When a +TKEY exchange has been used to create a shared secret, the identity of the +shared secret is the same as the identity of the key used to authenticate the +TKEY exchange. When the identity field specifies a +wildcard name, it is subject to DNS wildcard expansion, so the rule will apply +to multiple identities. The identity field must +contain a fully qualified domain name.

The nametype field has 4 values: +name, subdomain, +wildcard, and self. +

name

Exact-match semantics. This rule matches when the +name being updated is identical to the contents of the +name field.

subdomain

This rule matches when the name being updated +is a subdomain of, or identical to, the contents of the +name field.

wildcard

The name field is +subject to DNS wildcard expansion, and this rule matches when the name +being updated name is a valid expansion of the wildcard.

self

This rule matches when the name being updated +matches the contents of the identity field. +The name field is ignored, but should be +the same as the identity field. The +self nametype is most useful when allowing using +one key per name to update, where the key has the same name as the name +to be updated. The identity would be +specified as * in this case.

In all cases, the name field must +specify a fully qualified domain name.

If no types are explicitly specified, this rule matches all types except +SIG, NS, SOA, and NXT. Types may be specified by name, including +"ANY" (ANY matches all types except NXT, which can never be updated). +Note that when an attempt is made to delete all records associated with a +name, the rules are checked for each existing record type. +

6.3. Zone File

6.3.1. Types of Resource Records and When to Use Them

This section, largely borrowed from RFC 1034, describes the +concept of a Resource Record (RR) and explains when each is used. +Since the publication of RFC 1034, several new RRs have been identified +and implemented in the DNS. These are also included.

6.3.1.1. Resource Records

A domain name identifies a node. Each node has a set of + resource information, which may be empty. The set of resource + information associated with a particular name is composed of + separate RRs. The order of RRs in a set is not significant and + need not be preserved by name servers, resolvers, or other + parts of the DNS. However, sorting of multiple RRs is + permitted for optimization purposes, for example, to specify + that a particular nearby server be tried first. See Section 6.2.16.13 and Section 6.2.16.14.

The components of a Resource Record are:

owner name

the domain name where the RR is found.

type

an encoded 16 bit value that specifies +the type of the resource record.

TTL

the time to live of the RR. This field +is a 32 bit integer in units of seconds, and is primarily used by +resolvers when they cache RRs. The TTL describes how long a RR can +be cached before it should be discarded.

class

an encoded 16 bit value that identifies +a protocol family or instance of a protocol.

RDATA

the resource data. The format of the +data is type (and sometimes class) specific.

The following are types of valid RRs:

A

a host address. In the IN class, this is a +32-bit IP address. Described in RFC 1035.

AAAA

IPv6 address. Described in RFC 1886.

A6

IPv6 address. This can be a partial +address (a suffix) and an indirection to the name where the rest of the +address (the prefix) can be found. Experimental. Described in RFC 2874.

AFSDB

location of AFS database servers. +Experimental. Described in RFC 1183.

APL

address prefix list. Experimental. +Described in RFC 3123.

CERT

holds a digital certificate. +Described in RFC 2538.

CNAME

identifies the canonical name of an alias. +Described in RFC 1035.

DNAME

Replaces the domain name specified with +another name to be looked up, effectively aliasing an entire +subtree of the domain name space rather than a single record +as in the case of the CNAME RR. +Described in RFC 2672.

GPOS

Specifies the global position. Superseded by LOC.

HINFO

identifies the CPU and OS used by a host. +Described in RFC 1035.

ISDN

representation of ISDN addresses. +Experimental. Described in RFC 1183.

KEY

stores a public key associated with a +DNS name. Described in RFC 2535.

KX

identifies a key exchanger for this +DNS name. Described in RFC 2230.

LOC

for storing GPS info. Described in RFC 1876. +Experimental.

MX

identifies a mail exchange for the domain. +a 16 bit preference value (lower is better) +followed by the host name of the mail exchange. +Described in RFC 974, RFC 1035.

NAPTR

name authority pointer. Described in RFC 2915.

NSAP

a network service access point. +Described in RFC 1706.

NS

the authoritative name server for the +domain. Described in RFC 1035.

NXT

used in DNSSEC to securely indicate that +RRs with an owner name in a certain name interval do not exist in +a zone and indicate what RR types are present for an existing name. +Described in RFC 2535.

PTR

a pointer to another part of the domain +name space. Described in RFC 1035.

PX

provides mappings between RFC 822 and X.400 +addresses. Described in RFC 2163.

RP

information on persons responsible +for the domain. Experimental. Described in RFC 1183.

RT

route-through binding for hosts that +do not have their own direct wide area network addresses. +Experimental. Described in RFC 1183.

SIG

("signature") contains data authenticated +in the secure DNS. Described in RFC 2535.

SOA

identifies the start of a zone of authority. +Described in RFC 1035.

SRV

information about well known network +services (replaces WKS). Described in RFC 2782.

TXT

text records. Described in RFC 1035.

WKS

information about which well known +network services, such as SMTP, that a domain supports. Historical. +

X25

representation of X.25 network addresses. +Experimental. Described in RFC 1183.

The following classes of resource records +are currently valid in the DNS:

IN

The Internet.

CH

CHAOSnet, a LAN protocol created at MIT in the mid-1970s. +Rarely used for its historical purpose, but reused for BIND's +built-in server information zones, e.g., +version.bind. +

HS

Hesiod, an information service +developed by MIT's Project Athena. It is used to share information +about various systems databases, such as users, groups, printers +and so on. +

The owner name is often implicit, rather than forming an integral +part of the RR. For example, many name servers internally form tree +or hash structures for the name space, and chain RRs off nodes. + The remaining RR parts are the fixed header (type, class, TTL) +which is consistent for all RRs, and a variable part (RDATA) that +fits the needs of the resource being described.

The meaning of the TTL field is a time limit on how long an +RR can be kept in a cache. This limit does not apply to authoritative +data in zones; it is also timed out, but by the refreshing policies +for the zone. The TTL is assigned by the administrator for the +zone where the data originates. While short TTLs can be used to +minimize caching, and a zero TTL prohibits caching, the realities +of Internet performance suggest that these times should be on the +order of days for the typical host. If a change can be anticipated, +the TTL can be reduced prior to the change to minimize inconsistency +during the change, and then increased back to its former value following +the change.

The data in the RDATA section of RRs is carried as a combination +of binary strings and domain names. The domain names are frequently +used as "pointers" to other data in the DNS.

6.3.1.2. Textual expression of RRs

RRs are represented in binary form in the packets of the DNS +protocol, and are usually represented in highly encoded form when +stored in a name server or resolver. In the examples provided in +RFC 1034, a style similar to that used in master files was employed +in order to show the contents of RRs. In this format, most RRs +are shown on a single line, although continuation lines are possible +using parentheses.

The start of the line gives the owner of the RR. If a line +begins with a blank, then the owner is assumed to be the same as +that of the previous RR. Blank lines are often included for readability.

Following the owner, we list the TTL, type, and class of the +RR. Class and type use the mnemonics defined above, and TTL is +an integer before the type field. In order to avoid ambiguity in +parsing, type and class mnemonics are disjoint, TTLs are integers, +and the type mnemonic is always last. The IN class and TTL values +are often omitted from examples in the interests of clarity.

The resource data or RDATA section of the RR are given using +knowledge of the typical representation for the data.

For example, we might show the RRs carried in a message as:

ISI.EDU.

MX

10 VENERA.ISI.EDU.

MX

10 VAXA.ISI.EDU

VENERA.ISI.EDU

A

128.9.0.32

A

10.1.0.52

VAXA.ISI.EDU

A

10.2.0.27

A

128.9.0.33

The MX RRs have an RDATA section which consists of a 16 bit +number followed by a domain name. The address RRs use a standard +IP address format to contain a 32 bit internet address.

This example shows six RRs, with two RRs at each of three +domain names.

Similarly we might see:

XX.LCS.MIT.EDU. IN

A

10.0.0.44

CH

A

MIT.EDU. 2420

This example shows two addresses for XX.LCS.MIT.EDU, +each of a different class.

6.3.2. Discussion of MX Records

As described above, domain servers store information as a +series of resource records, each of which contains a particular +piece of information about a given domain name (which is usually, +but not always, a host). The simplest way to think of a RR is as +a typed pair of data, a domain name matched with a relevant datum, +and stored with some additional type information to help systems +determine when the RR is relevant.

MX records are used to control delivery of email. The data +specified in the record is a priority and a domain name. The priority +controls the order in which email delivery is attempted, with the +lowest number first. If two priorities are the same, a server is +chosen randomly. If no servers at a given priority are responding, +the mail transport agent will fall back to the next largest priority. +Priority numbers do not have any absolute meaning — they are relevant +only respective to other MX records for that domain name. The domain +name given is the machine to which the mail will be delivered. It must have +an associated A record — CNAME is not sufficient.

For a given domain, if there is both a CNAME record and an +MX record, the MX record is in error, and will be ignored. Instead, +the mail will be delivered to the server specified in the MX record +pointed to by the CNAME.

example.com.

IN

MX

10

mail.example.com.

IN

MX

10

mail2.example.com.

IN

MX

20

mail.backup.org.

mail.example.com.

IN

A

10.0.0.1

mail2.example.com.

IN

A

10.0.0.2

For example:

Mail delivery will be attempted to mail.example.com and +mail2.example.com (in +any order), and if neither of those succeed, delivery to mail.backup.org will +be attempted.

6.3.3. Setting TTLs

The time to live of the RR field is a 32 bit integer represented +in units of seconds, and is primarily used by resolvers when they +cache RRs. The TTL describes how long a RR can be cached before it +should be discarded. The following three types of TTL are currently +used in a zone file.

SOA

The last field in the SOA is the negative +caching TTL. This controls how long other servers will cache no-such-domain +(NXDOMAIN) responses from you.

The maximum time for +negative caching is 3 hours (3h).

$TTL

The $TTL directive at the top of the +zone file (before the SOA) gives a default TTL for every RR without +a specific TTL set.

RR TTLs

Each RR can have a TTL as the second +field in the RR, which will control how long other servers can cache +the it.

All of these TTLs default to units of seconds, though units +can be explicitly specified, for example, 1h30m.

6.3.4. Inverse Mapping in IPv4

Reverse name resolution (that is, translation from IP address +to name) is achieved by means of the in-addr.arpa domain +and PTR records. Entries in the in-addr.arpa domain are made in +least-to-most significant order, read left to right. This is the +opposite order to the way IP addresses are usually written. Thus, +a machine with an IP address of 10.1.2.3 would have a corresponding +in-addr.arpa name of +3.2.1.10.in-addr.arpa. This name should have a PTR resource record +whose data field is the name of the machine or, optionally, multiple +PTR records if the machine has more than one name. For example, +in the [example.com] domain:

$ORIGIN

2.1.10.in-addr.arpa

3

IN PTR foo.example.com.

Note: The $ORIGIN lines in the examples +are for providing context to the examples only-they do not necessarily +appear in the actual usage. They are only used here to indicate +that the example is relative to the listed origin.

6.3.5. Other Zone File Directives

The Master File Format was initially defined in RFC 1035 and +has subsequently been extended. While the Master File Format itself +is class independent all records in a Master File must be of the same +class.

Master File Directives include $ORIGIN, $INCLUDE, +and $TTL.

6.3.5.1. The $ORIGIN Directive

Syntax: $ORIGIN +domain-name [ comment]

$ORIGIN sets the domain name that will +be appended to any unqualified records. When a zone is first read +in there is an implicit $ORIGIN <zone-name>. The +current $ORIGIN is appended to the domain specified +in the $ORIGIN argument if it is not absolute.

$ORIGIN example.com.
+WWW     CNAME   MAIN-SERVER

is equivalent to

WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.

6.3.5.2. The $INCLUDE Directive

Syntax: $INCLUDE +filename [ origin ] [ comment ]

Read and process the file filename as +if it were included into the file at this point. If origin is +specified the file is processed with $ORIGIN set +to that value, otherwise the current $ORIGIN is +used.

The origin and the current domain name +revert to the values they had prior to the $INCLUDE once +the file has been read.

Note: +RFC 1035 specifies that the current origin should be restored after +an $INCLUDE, but it is silent on whether the current +domain name should also be restored. BIND 9 restores both of them. +This could be construed as a deviation from RFC 1035, a feature, or both. +

6.3.5.3. The $TTL Directive

Syntax: $TTL +default-ttl [ comment ]

Set the default Time To Live (TTL) for subsequent records +with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.

$TTL is defined in RFC 2308.

6.3.6. BIND Master File Extension: the $GENERATE Directive

Syntax: $GENERATE range lhs [ttl] [class] type rhs [ comment ]

$GENERATE is used to create a series of +resource records that only differ from each other by an iterator. $GENERATE can +be used to easily generate the sets of records required to support +sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA +delegation.

$ORIGIN 0.0.192.IN-ADDR.ARPA.
+$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
+$GENERATE 1-127 $ CNAME $.0

is equivalent to

0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
+0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
+1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
+2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
+...
+127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
+

range

This can be one of two forms: start-stop +or start-stop/step. If the first form is used then step is set to + 1. All of start, stop and step must be positive.

lhs

lhs describes the +owner name of the resource records to be created. Any single $ symbols +within the lhs side are replaced by the iterator +value. +To get a $ in the output you need to escape the $ +using a backslash \, +e.g. \$. The $ may optionally be followed +by modifiers which change the offset from the iterator, field width and base. +Modifiers are introduced by a { immediately following the +$ as ${offset[,width[,base]]}. +e.g. ${-20,3,d} which subtracts 20 from the current value, +prints the result as a decimal in a zero padded field of with 3. Available +output forms are decimal (d), octal (o) +and hexadecimal (x or X for uppercase). +The default modifier is ${0,0,d}. +If the lhs is not +absolute, the current $ORIGIN is appended to +the name.

+

For compatibility with earlier versions $$ is still +recognized a indicating a literal $ in the output.

ttl

ttl specifies the + ttl of the generated records. If not specified this will be + inherited using the normal ttl inheritance rules.

+

class and ttl can be + entered in either order.

class

class specifies the + class of the generated records. This must match the zone class if + it is specified.

+

class and ttl can be + entered in either order.

type

At present the only supported types are +PTR, CNAME, DNAME, A, AAAA and NS.

rhs

rhs is a domain name. It is processed +similarly to lhs.

The $GENERATE directive is a BIND extension +and not part of the standard zone file format.

BIND 8 does not support the optional TTL and CLASS fields.

PrevHomeNext
The BIND 9 Lightweight Resolver BIND 9 Security Considerations
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch07.html b/contrib/bind9/doc/arm/Bv9ARM.ch07.html new file mode 100644 index 000000000000..a7c470773876 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch07.html @@ -0,0 +1,500 @@ + +BIND 9 Security Considerations
BIND 9 Administrator Reference Manual
PrevNext

Chapter 7. BIND 9 Security Considerations

7.1. Access Control Lists

Access Control Lists (ACLs), are address match lists that +you can set up and nickname for future use in allow-notify, +allow-query, allow-recursion, +blackhole, allow-transfer, +etc.

Using ACLs allows you to have finer control over who can access +your name server, without cluttering up your config files with huge +lists of IP addresses.

It is a good idea to use ACLs, and to +control access to your server. Limiting access to your server by +outside parties can help prevent spoofing and DoS attacks against +your server.

Here is an example of how to properly apply ACLs:


// Set up an ACL named "bogusnets" that will block RFC1918 space,
+// which is commonly used in spoofing attacks.
+acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
+// Set up an ACL called our-nets. Replace this with the real IP numbers.
+acl our-nets { x.x.x.x/24; x.x.x.x/21; }; 
+options {
+  ...
+  ...
+  allow-query { our-nets; };
+  allow-recursion { our-nets; };
+  ...
+  blackhole { bogusnets; };
+  ...
+};
+zone "example.com" {
+  type master;
+  file "m/example.com";
+  allow-query { any; };
+};
+

This allows recursive queries of the server from the outside +unless recursion has been previously disabled.

For more information on how to use ACLs to protect your server, +see the AUSCERT advisory at +ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos

7.2. chroot and setuid (for +UNIX servers)

On UNIX servers, it is possible to run BIND in a chrooted environment +(chroot()) by specifying the "-t" +option. This can help improve system security by placing BIND in +a "sandbox", which will limit the damage done if a server is compromised.

Another useful feature in the UNIX version of BIND is the +ability to run the daemon as an unprivileged user ( -u user ). +We suggest running as an unprivileged user when using the chroot feature.

Here is an example command line to load BIND in a chroot() sandbox, +/var/named, and to run named setuid to +user 202:

/usr/local/bin/named -u 202 -t /var/named

7.2.1. The chroot Environment

In order for a chroot() environment to +work properly in a particular directory +(for example, /var/named), +you will need to set up an environment that includes everything +BIND needs to run. +From BIND's point of view, /var/named is +the root of the filesystem. You will need to adjust the values of options like +like directory and pid-file to account +for this. +

Unlike with earlier versions of BIND, you will typically +not need to compile named +statically nor install shared libraries under the new root. +However, depending on your operating system, you may need +to set up things like +/dev/zero, +/dev/random, +/dev/log, and/or +/etc/localtime. +

7.2.2. Using the setuid Function

Prior to running the named daemon, use +the touch utility (to change file access and +modification times) or the chown utility (to +set the user id and/or group id) on files +to which you want BIND +to write. Note that if the named daemon is running as an +unprivileged user, it will not be able to bind to new restricted ports if the +server is reloaded.

7.3. Dynamic Update Security

Access to the dynamic +update facility should be strictly limited. In earlier versions of +BIND the only way to do this was based on the IP +address of the host requesting the update, by listing an IP address or +network prefix in the allow-update zone option. +This method is insecure since the source address of the update UDP packet +is easily forged. Also note that if the IP addresses allowed by the +allow-update option include the address of a slave +server which performs forwarding of dynamic updates, the master can be +trivially attacked by sending the update to the slave, which will +forward it to the master with its own source IP address causing the +master to approve it without question.

For these reasons, we strongly recommend that updates be +cryptographically authenticated by means of transaction signatures +(TSIG). That is, the allow-update option should +list only TSIG key names, not IP addresses or network +prefixes. Alternatively, the new update-policy +option can be used.

Some sites choose to keep all dynamically updated DNS data +in a subdomain and delegate that subdomain to a separate zone. This +way, the top-level zone containing critical data such as the IP addresses +of public web and mail servers need not allow dynamic update at +all.

PrevHomeNext
BIND 9 Configuration Reference Troubleshooting
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch08.html b/contrib/bind9/doc/arm/Bv9ARM.ch08.html new file mode 100644 index 000000000000..fe173a8f47a6 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch08.html @@ -0,0 +1,272 @@ + +Troubleshooting
BIND 9 Administrator Reference Manual
PrevNext

Chapter 8. Troubleshooting

8.1. Common Problems

8.1.1. It's not working; how can I figure out what's wrong?

The best solution to solving installation and + configuration issues is to take preventative measures by setting + up logging files beforehand. The log files provide a + source of hints and information that can be used to figure out + what went wrong and how to fix the problem.

8.2. Incrementing and Changing the Serial Number

Zone serial numbers are just numbers-they aren't date + related. A lot of people set them to a number that represents a + date, usually of the form YYYYMMDDRR. A number of people have been + testing these numbers for Y2K compliance and have set the number + to the year 2000 to see if it will work. They then try to restore + the old serial number. This will cause problems because serial + numbers are used to indicate that a zone has been updated. If the + serial number on the slave server is lower than the serial number + on the master, the slave server will attempt to update its copy of + the zone.

Setting the serial number to a lower number on the master + server than the slave server means that the slave will not perform + updates to its copy of the zone.

The solution to this is to add 2147483647 (2^31-1) to the + number, reload the zone and make sure all slaves have updated to + the new zone serial number, then reset the number to what you want + it to be, and reload the zone again.

8.3. Where Can I Get Help?

The Internet Software Consortium (ISC) offers a wide range + of support and service agreements for BIND and DHCP servers. Four + levels of premium support are available and each level includes + support for all ISC programs, significant discounts on products + and training, and a recognized priority on bug fixes and + non-funded feature requests. In addition, ISC offers a standard + support agreement package which includes services ranging from bug + fix announcements to remote support. It also includes training in + BIND and DHCP.

To discuss arrangements for support, contact + info@isc.org or visit the + ISC web page at http://www.isc.org/services/support/ + to read more.

PrevHomeNext
BIND 9 Security Considerations Appendices
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch09.html b/contrib/bind9/doc/arm/Bv9ARM.ch09.html new file mode 100644 index 000000000000..130257c2411f --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.ch09.html @@ -0,0 +1,1587 @@ + +Appendices
BIND 9 Administrator Reference Manual
Prev 

Appendix A. Appendices

A.1. Acknowledgments

A.1.1. A Brief History of the DNS and BIND

Although the "official" beginning of the Domain Name + System occurred in 1984 with the publication of RFC 920, the + core of the new system was described in 1983 in RFCs 882 and + 883. From 1984 to 1987, the ARPAnet (the precursor to today's + Internet) became a testbed of experimentation for developing the + new naming/addressing scheme in an rapidly expanding, + operational network environment. New RFCs were written and + published in 1987 that modified the original documents to + incorporate improvements based on the working model. RFC 1034, + "Domain Names-Concepts and Facilities", and RFC 1035, "Domain + Names-Implementation and Specification" were published and + became the standards upon which all DNS implementations are + built. +

The first working domain name server, called "Jeeves", was +written in 1983-84 by Paul Mockapetris for operation on DEC Tops-20 +machines located at the University of Southern California's Information +Sciences Institute (USC-ISI) and SRI International's Network Information +Center (SRI-NIC). A DNS server for Unix machines, the Berkeley Internet +Name Domain (BIND) package, was written soon after by a group of +graduate students at the University of California at Berkeley under +a grant from the US Defense Advanced Research Projects Administration +(DARPA). Versions of BIND through 4.8.3 were maintained by the Computer +Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark +Painter, David Riggle and Songnian Zhou made up the initial BIND +project team. After that, additional work on the software package +was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation +employee on loan to the CSRG, worked on BIND for 2 years, from 1985 +to 1987. Many other people also contributed to BIND development +during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, +Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently +handled by Mike Karels and O. Kure.

BIND versions 4.9 and 4.9.1 were released by Digital Equipment +Corporation (now Compaq Computer Corporation). Paul Vixie, then +a DEC employee, became BIND's primary caretaker. Paul was assisted +by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew +Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat +Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe +Wolfhugel, and others.

BIND Version 4.9.2 was sponsored by Vixie Enterprises. Paul +Vixie became BIND's principal architect/programmer.

BIND versions from 4.9.3 onward have been developed and maintained +by the Internet Software Consortium with support being provided +by ISC's sponsors. As co-architects/programmers, Bob Halley and +Paul Vixie released the first production-ready version of BIND version +8 in May 1997.

BIND development work is made possible today by the sponsorship +of several corporations, and by the tireless work efforts of numerous +individuals.

A.2. General DNS Reference Information

A.2.1. IPv6 addresses (AAAA)

IPv6 addresses are 128-bit identifiers for interfaces and +sets of interfaces which were introduced in the DNS to facilitate +scalable Internet routing. There are three types of addresses: Unicast, +an identifier for a single interface; Anycast, +an identifier for a set of interfaces; and Multicast, +an identifier for a set of interfaces. Here we describe the global +Unicast address scheme. For more information, see RFC 2374.

The aggregatable global Unicast address format is as follows:

3

13

8

24

16

64 bits

FP

TLA ID

RES

NLA ID

SLA ID

Interface ID

<------ Public Topology +------>

<-Site Topology->

<------ Interface Identifier ------>

Where +

FP

=

Format Prefix (001)

TLA ID

=

Top-Level Aggregation Identifier

RES

=

Reserved for future use

NLA ID

=

Next-Level Aggregation Identifier

SLA ID

=

Site-Level Aggregation Identifier

INTERFACE ID

=

Interface Identifier

The Public Topology is provided by the +upstream provider or ISP, and (roughly) corresponds to the IPv4 network section +of the address range. The Site Topology is +where you can subnet this space, much the same as subnetting an +IPv4 /16 network into /24 subnets. The Interface Identifier is +the address of an individual interface on a given network. (With +IPv6, addresses belong to interfaces rather than machines.)

The subnetting capability of IPv6 is much more flexible than +that of IPv4: subnetting can now be carried out on bit boundaries, +in much the same way as Classless InterDomain Routing (CIDR).

The Interface Identifier must be unique on that network. On +ethernet networks, one way to ensure this is to set the address +to the first three bytes of the hardware address, "FFFE", then the +last three bytes of the hardware address. The lowest significant +bit of the first byte should then be complemented. Addresses are +written as 32-bit blocks separated with a colon, and leading zeros +of a block may be omitted, for example:

2001:db8:201:9:a00:20ff:fe81:2b32

IPv6 address specifications are likely to contain long strings +of zeros, so the architects have included a shorthand for specifying +them. The double colon (`::') indicates the longest possible string +of zeros that can fit, and can be used only once in an address.

A.3. Bibliography (and Suggested Reading)

A.3.1. Request for Comments (RFCs)

Specification documents for the Internet protocol suite, including +the DNS, are published as part of the Request for Comments (RFCs) +series of technical notes. The standards themselves are defined +by the Internet Engineering Task Force (IETF) and the Internet Engineering +Steering Group (IESG). RFCs can be obtained online via FTP at +ftp://www.isi.edu/in-notes/RFCxxx.txt (where xxx is +the number of the RFC). RFCs are also available via the Web at +http://www.ietf.org/rfc/. +

Bibliography

Standards

[RFC974] C. Partridge, Mail Routing and the Domain System, January 1986.

[RFC1034] P.V. Mockapetris, Domain Names — Concepts and Facilities, November 1987.

[RFC1035] P. V. Mockapetris, Domain Names — Implementation and +Specification, November 1987.

Proposed Standards

[RFC2181] R., R. Bush Elz, Clarifications to the DNS Specification, July 1997.

[RFC2308] M. Andrews, Negative Caching of DNS Queries, March 1998.

[RFC1995] M. Ohta, Incremental Zone Transfer in DNS, August 1996.

[RFC1996] P. Vixie, A Mechanism for Prompt Notification of Zone Changes, August 1996.

[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, Dynamic Updates in the Domain Name System, April 1997.

[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington, Secret Key Transaction Authentication for DNS (TSIG), May 2000.

Proposed Standards Still Under Development

[RFC1886] S. Thomson and C. Huitema, DNS Extensions to support IP version 6, December 1995.

[RFC2065] D. Eastlake, 3rd and C. Kaufman, Domain Name System Security Extensions, January 1997.

[RFC2137] D. Eastlake, 3rd, Secure Domain Name System Dynamic Update, April 1997.

Other Important RFCs About DNS Implementation

[RFC1535] E. Gavron, A Security Problem and Proposed Correction With Widely Deployed DNS Software., October 1993.

[RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller, Common DNS Implementation Errors and Suggested Fixes, October 1993.

[RFC1982] R. Elz and R. Bush, Serial Number Arithmetic, August 1996.

Resource Record Types

[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris, New DNS RR Definitions, October 1990.

[RFC1706] B. Manning and R. Colella, DNS NSAP Resource Records, October 1994.

[RFC2168] R. Daniel and M. Mealling, Resolution of Uniform Resource Identifiers using +the Domain Name System, June 1997.

[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson, A Means for Expressing Location Information in the Domain +Name System, January 1996.

[RFC2052] A. Gulbrandsen and P. Vixie, A DNS RR for Specifying the Location of +Services., October 1996.

[RFC2163] A. Allocchio, Using the Internet DNS to Distribute MIXER +Conformant Global Address Mapping, January 1998.

[RFC2230] R. Atkinson, Key Exchange Delegation Record for the DNS, October 1997.

DNS and the Internet

[RFC1101] P. V. Mockapetris, DNS Encoding of Network Names and Other Types, April 1989.

[RFC1123] Braden, Requirements for Internet Hosts - Application and Support, October 1989.

[RFC1591] J. Postel, Domain Name System Structure and Delegation, March 1994.

[RFC2317] H. Eidnes, G. de Groot, and P. Vixie, Classless IN-ADDR.ARPA Delegation, March 1998.

DNS Operations

[RFC1537] P. Beertema, Common DNS Data File Configuration Errors, October 1993.

[RFC1912] D. Barr, Common DNS Operational and Configuration Errors, February 1996.

[RFC2010] B. Manning and P. Vixie, Operational Criteria for Root Name Servers., October 1996.

[RFC2219] M. Hamilton and R. Wright, Use of DNS Aliases for Network Services., October 1997.

Other DNS-related RFCs

[RFC1464] R. Rosenbaum, Using the Domain Name System To Store Arbitrary String Attributes, May 1993.

[RFC1713] A. Romao, Tools for DNS Debugging, November 1994.

[RFC1794] T. Brisco, DNS Support for Load Balancing, April 1995.

[RFC2240] O. Vaughan, A Legal Basis for Domain Name Allocation, November 1997.

[RFC2345] J. Klensin, T. Wolf, and G. Oglesby, Domain Names and Company Name Retrieval, May 1998.

[RFC2352] O. Vaughan, A Convention For Using Legal Names as Domain Names, May 1998.

Obsolete and Unimplemented Experimental RRs

[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni, DNS Encoding of Geographical +Location, November 1994.

A.3.2. Internet Drafts

Internet Drafts (IDs) are rough-draft working documents of +the Internet Engineering Task Force. They are, in essence, RFCs +in the preliminary stages of development. Implementors are cautioned not +to regard IDs as archival, and they should not be quoted or cited +in any formal documents unless accompanied by the disclaimer that +they are "works in progress." IDs have a lifespan of six months +after which they are deleted unless updated by their authors. +

A.3.3. Other Documents About BIND

Bibliography

Paul Albitz and Cricket Liu, DNS and BIND, 1998.

PrevHome 
Troubleshooting  
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Bv9ARM.html b/contrib/bind9/doc/arm/Bv9ARM.html new file mode 100644 index 000000000000..bf8b49e96796 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.html @@ -0,0 +1,851 @@ + +BIND 9 Administrator Reference Manual

BIND 9 Administrator Reference Manual

Copyright © 2004 Internet Systems Consortium, Inc. ("ISC")

Copyright © 2000-2003 Internet Software Consortium

Table of Contents
1. Introduction
1.1. Scope of Document
1.2. Organization of This Document
1.3. Conventions Used in This Document
1.4. The Domain Name System (DNS)
1.4.1. DNS Fundamentals
1.4.2. Domains and Domain Names
1.4.3. Zones
1.4.4. Authoritative Name Servers
1.4.5. Caching Name Servers
1.4.6. Name Servers in Multiple Roles
2. BIND Resource Requirements
2.1. Hardware requirements
2.2. CPU Requirements
2.3. Memory Requirements
2.4. Name Server Intensive Environment Issues
2.5. Supported Operating Systems
3. Name Server Configuration
3.1. Sample Configurations
3.1.1. A Caching-only Name Server
3.1.2. An Authoritative-only Name Server
3.2. Load Balancing
3.3. Name Server Operations
3.3.1. Tools for Use With the Name Server Daemon
3.3.2. Signals
4. Advanced DNS Features
4.1. Notify
4.2. Dynamic Update
4.2.1. The journal file
4.3. Incremental Zone Transfers (IXFR)
4.4. Split DNS
4.5. TSIG
4.5.1. Generate Shared Keys for Each Pair of Hosts
4.5.2. Copying the Shared Secret to Both Machines
4.5.3. Informing the Servers of the Key's Existence
4.5.4. Instructing the Server to Use the Key
4.5.5. TSIG Key Based Access Control
4.5.6. Errors
4.6. TKEY
4.7. SIG(0)
4.8. DNSSEC
4.8.1. Generating Keys
4.8.2. Signing the Zone
4.8.3. Configuring Servers
4.9. IPv6 Support in BIND 9
4.9.1. Address Lookups Using AAAA Records
4.9.2. Address to Name Lookups Using Nibble Format
5. The BIND 9 Lightweight Resolver
5.1. The Lightweight Resolver Library
5.2. Running a Resolver Daemon
6. BIND 9 Configuration Reference
6.1. Configuration File Elements
6.1.1. Address Match Lists
6.1.2. Comment Syntax
6.2. Configuration File Grammar
6.2.1. acl Statement Grammar
6.2.2. acl Statement Definition and +Usage
6.2.3. controls Statement Grammar
6.2.4. controls Statement Definition and Usage
6.2.5. include Statement Grammar
6.2.6. include Statement Definition and Usage
6.2.7. key Statement Grammar
6.2.8. key Statement Definition and Usage
6.2.9. logging Statement Grammar
6.2.10. logging Statement Definition and Usage
6.2.11. lwres Statement Grammar
6.2.12. lwres Statement Definition and Usage
6.2.13. masters Statement Grammar
6.2.14. masters Statement Definition and Usage
6.2.15. options Statement Grammar
6.2.16. options Statement Definition and Usage
6.2.17. server Statement Grammar
6.2.18. server Statement Definition and Usage
6.2.19. trusted-keys Statement Grammar
6.2.20. trusted-keys Statement Definition +and Usage
6.2.21. view Statement Grammar
6.2.22. view Statement Definition and Usage
6.2.23. zone +Statement Grammar
6.2.24. zone Statement Definition and Usage
6.3. Zone File
6.3.1. Types of Resource Records and When to Use Them
6.3.2. Discussion of MX Records
6.3.3. Setting TTLs
6.3.4. Inverse Mapping in IPv4
6.3.5. Other Zone File Directives
6.3.6. BIND Master File Extension: the $GENERATE Directive
7. BIND 9 Security Considerations
7.1. Access Control Lists
7.2. chroot and setuid (for +UNIX servers)
7.2.1. The chroot Environment
7.2.2. Using the setuid Function
7.3. Dynamic Update Security
8. Troubleshooting
8.1. Common Problems
8.1.1. It's not working; how can I figure out what's wrong?
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?
A. Appendices
A.1. Acknowledgments
A.1.1. A Brief History of the DNS and BIND
A.2. General DNS Reference Information
A.2.1. IPv6 addresses (AAAA)
A.3. Bibliography (and Suggested Reading)
A.3.1. Request for Comments (RFCs)
A.3.2. Internet Drafts
A.3.3. Other Documents About BIND
  Next
  Introduction
\ No newline at end of file diff --git a/contrib/bind9/doc/arm/Makefile.in b/contrib/bind9/doc/arm/Makefile.in new file mode 100644 index 000000000000..ede9342535da --- /dev/null +++ b/contrib/bind9/doc/arm/Makefile.in @@ -0,0 +1,69 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2001, 2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.8.2.2.8.3 2004/03/08 09:04:24 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_MAKE_RULES@ + +MANOBJS = Bv9ARM.html + +distclean:: + rm -f validate.sh + rm -f nominum-docbook-html.dsl nominum-docbook-print.dsl + rm -f HTML.index HTML.manifest + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f *.html + +Bv9ARM.html: Bv9ARM-book.xml nominum-docbook-html.dsl + ${OPENJADE} -v \ + -c ${SGMLCATALOG} \ + -t sgml \ + -d ./nominum-docbook-html.dsl \ + ${XMLDCL} ./Bv9ARM-book.xml + rm -f HTML.index HTML.manifest + +Bv9ARM-book.rtf: Bv9ARM-book.xml nominum-docbook-print.dsl + ${OPENJADE} -v \ + -c ${SGMLCATALOG} \ + -t rtf \ + -d ./nominum-docbook-print.dsl \ + ${XMLDCL} ./Bv9ARM-book.xml + +Bv9ARM-book.tex: Bv9ARM-book.xml nominum-docbook-print.dsl + ${OPENJADE} -v \ + -c ${SGMLCATALOG} \ + -d ./nominum-docbook-print.dsl \ + -t tex \ + ${XMLDCL} ./Bv9ARM-book.xml + +Bv9ARM-book.dvi: Bv9ARM-book.tex + rm -f Bv9ARM-book.aux Bv9ARM-book.dvi Bv9ARM-book.log + ${JADETEX} ./Bv9ARM-book.tex || true + ${JADETEX} ./Bv9ARM-book.tex || true + ${JADETEX} ./Bv9ARM-book.tex || true + +Bv9ARM-book.pdf: Bv9ARM-book.tex + rm -f Bv9ARM-book.aux Bv9ARM-book.pdf Bv9ARM-book.log + ${PDFJADETEX} ./Bv9ARM-book.tex || true + ${PDFJADETEX} ./Bv9ARM-book.tex || true + ${PDFJADETEX} ./Bv9ARM-book.tex || true + diff --git a/contrib/bind9/doc/arm/README-SGML b/contrib/bind9/doc/arm/README-SGML new file mode 100644 index 000000000000..8e7bc4ebd849 --- /dev/null +++ b/contrib/bind9/doc/arm/README-SGML @@ -0,0 +1,329 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +The BIND v9 ARM master document is now kept in DocBook XML format. + +Version: $Id: README-SGML,v 1.16.206.1 2004/03/06 13:16:14 marka Exp $ + +The entire ARM is in the single file: + + Bv9ARM-book.xml + +All of the other documents - HTML, PDF, etc - are generated from this +master source. + +This file attempts to describe what tools are necessary for the +maintenance of this document as well as the generation of the +alternate formats of this document. + +This file will also spend a very little time describing the XML and +SGML headers so you can understand a bit what you may need to do to be +able to work with this document in any fashion other than simply +editing it. + +We will spend almost no time on the actual tags and how to write an +XML DocBook compliant document. If you are at all familiar with SGML +or HTML it will be very evident. You only need to know what the tags +are and how to use them. You can find a good resource either for this +either online or in printed form: + + DocBook: The Definitive Guide + By Norman Walsh and Leonard Muellner + ISBN: 156592-580-7 + 1st Edition, October 1999 + Copyright (C) 1999 by O'Reilly & Associates, Inc. All rights reserved. + +The book is available online in HTML format: + + http://docbook.org/ + +and buried in: + + http://www.nwalsh.com/docbook/defguide/index.html + +A lot of useful stuff is at NWalsh's site in general. You may also +want to look at: + + http://www.xml.com/ + +The BIND v9 ARM is based on the XML 4.0 DocBook DTD. Every XML and +SGML document begins with a prefix that tells where to find the file +that describes the meaning and structure of the tags used in the rest +of the document. + +For our XML DocBook 4.0 based document this prefix looks like this: + + + +This "DOCTYPE" statement has three parts, of which we are only using +two: + +o The highest level term that represents this document (in this case + it is "book" + +o The identifier that tells us which DTD to use. This identifier has + two parts, the "Formal Public Identifier" (or FPI) and the system + identifier. In SGML you can have either a FPI or a SYSTEM identifier + but you have to have at least one of them. In XML you have to have a + SYSTEM identifier. + +FP & SYSTEM identifiers - These are names/lookups for the actual +DTD. The FPI is a globally unique name that should, on a properly +configured system, tell you exactly what DTD to use. The SYSTEM +identifier gives an absolute location for the DTD. In XML these are +supposed to be properly formatted URL's. + +SGML has these things called "catalogs" that are files that map FPI's +in to actual files. A "catalog" can also be used to remap a SYSTEM +identifier so you can say something like: "http://www.oasis.org/foo" +is actually "/usr/local/share/xml/foo.dtd" + +When you use various SGML/XML tools they need to be configured to look +at the same "catalog" files so that as you move from tool to tool they +all refer to the same DTD for the same document. + +We will be spending most of our configuration time making sure our +tools use the same "catalog" files and that we have the same DTD's +installed on our machines. XML's requirement of the SYSTEM identifier +over the FPI will probably lead to more problems as it does not +guarantee that everyone is using the same DTD. + +I did my initial work with the "sgmltools" the XML 4.0 DocBook DTD and +"jade" or "openjade." + +You can get the 4.0 XML DocBook DTD from: + + http://www.docbook.org/xml/4.0/ + +(download the .zip file.) NOTE: We will eventually be changing the +SYSTEM identifier to the recommended value of: + + http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd + +NOTE: Under FreeBSD this is the package: + + /usr/ports/textproc/docbook-xml + +NetBSD instructions are coming soon. + +With packages listed below installed under FreeBSD the "catalog" file +that all the tools refer to at least one is in: + + /usr/local/share/sgml/catalog + +In order for our SYSTEM identifier for the XML DocBook dtd to be found +I create a new catalog file at the top of the XML directory created on +FreeBSD: + + /usr/local/share/xml/catalog + +This file has one line: + + SYSTEM "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" "/usr/local/share/xml/dtd/docbook/docbookx.dtd" + +Then in the main "catalog" I have it include this XML catalog: + + CATALOG "/usr/local/share/xml/catalog" + + +On your systems you need to replace "/usr/local/share" with your +prefix root (probably /usr/pkg under NetBSD.) + +NOTE: The URL used above is supposed to the be the proper one for this +XML DocBook DTD... but there is nothing at that URL so you really do +need the "SYSTEM" identifier mapping in your catalog (or make the +SYSTEM identifier in your document refer to the real location of the +file on your local system.) + +HOW TO VALIDATE A DOCUMENT: + +I use the sgmltools "nsgmls" document validator. Since we are using +XML we need to use the XML declarations, which are installed as part +of the modular DSSL style sheets: + + nsgmls -sv /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \ + Bv9ARM-book.xml + +A convenient shell script "validate.sh" is now generated by configure +to invoke the above command with the correct system-dependent paths. + +The SGML tools can be found at: + + ftp://ftp.us.sgmltools.org/pub/SGMLtools/v2.0/source/ \ + ftp://ftp.nllgg.nl/pub/SGMLtools/v2.0/source/ + +FreeBSD package for these is: + + /usr/ports/textproc/sgmltools + +HOW TO RENDER A DOCUMENT AS HTML or TeX: + +o Generate html doc with: + + openjade -v -d ./nominum-docbook-html.dsl \ + -t sgml \ + /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \ + Bv9ARM-book.xml + +A convenient shell script "genhtml.sh" is now generated by configure to +invoke the above command with the correct system-dependent paths. + +On NetBSD there is no port for "openjade" however "jade" does still +work. However you need to specify the "catalog" file to use for style +sheets on the command line AND you need to have a default "catalog" +mapping where to find various DTDs. It seems that "jade" installed out +of the box on NetBSD does not use a globally defined "catalog" file +for mapping PUBLIC identifiers in to SYSTEM identifiers. + +So you need to have a "catalog" file in your current working directory +that has in it this: (these are probably more entries than you need!) + + CATALOG "/usr/pkg/share/sgml/iso8879/catalog" + CATALOG "/usr/pkg/share/sgml/docbook/2.4.1/catalog" + CATALOG "/usr/pkg/share/sgml/docbook/3.0/catalog" + CATALOG "/usr/pkg/share/sgml/docbook/3.1/catalog" + CATALOG "/usr/pkg/share/sgml/jade/catalog" + CATALOG "/usr/local/share/xml/catalog" + +(These would all be "/usr/local" on FreeBSD) + +So the command for jade on NetBSD will look like this: + +jade -v -c /usr/pkg/share/sgml/catalog -t sgml \ + -d ./nominum-docbook-html.dsl \ + /usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \ + ./Bv9ARM-book.xml + +Furthermore, since the style sheet subset we define has in it a hard +coded path to the style sheet is based, it is actually generated by +configure from a .in file so that it will contain the correct +system-dependent path: where on FreeBSD the second line reads: + + + +On NetBSD it needs to read: + + + +NOTE: This is usually solved by having this style sheet modification +be installed in a system directory and have it reference the style +sheet it is based on via a relative path. + +o Generate TeX documentation: + +openjade -d ./nominum-docbook-print.dsl -t tex -v \ + /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \ + Bv9ARM-book.xml + +If you have "jade" installed instead of "openjade" then use that as +the command. There is little difference, openjade has some bug fixes +and is in more active development. + +To convert the resulting TeX file in to a DVI file you need to do: + + tex "&jadetex" Bv9ARM-book.tex + +You can also directly generate the pdf file via: + + pdftex "&pdfjadetex" Bv9ARM-book.tex + +The scripts "genpdf.sh" and "gendvi." have been added to simply +generating the PDF and DVI output. These substitute the correct paths +of NetBSD & FreeBSD. You still need to have TeX, jadeTeX, and pdfTeX +installed and configured properly for these to work. + +You will need to up both the "pool_size" and "hash_extra" variables in +your texmf.cnf file and regenerate them. See below. + +You can see that I am using a DSSSL style sheet for DocBook. Actually +two different ones - one for rendering html, and one for 'print' +media. + +NOTE: For HTML we are using a Nominum DSSSL style instead of the +default one (all it does is change the chunking to the chapter level +and makes the files end with ".html" instead of ".htm" so far.) If you +want to use the plain jane DSSSL style sheet replace the: + + -d ./nominum-docbook-html.dsl + +with + + -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl + +This style sheet will attempt to reference the one above. + +I am currently working on fixing these up so that it works the same on +our various systems. The main trick is knowing which DTD's and DSSSL +stylesheets you have installed, installing the right ones, and +configuring a CATALOG that refers to them in the same way. We will +probably end up putting our CATALOG's in the same place and then we +should be able to generate and validate our documents with a minimal +number of command line arguments. + +When running these commands you will get a lot of messages about a +bunch of general entities not being defined and having no default +entity. You can ignore those for now. + +Also with the style sheets we have and jade as it is you will get +messages about "xref to title" being unsupported. You can ignore these +for now as well. + +=== Getting the various tools installed on FreeBSD +(NetBSD coming soon..) + +o On freebsd you need to install the following packages: + o print/teTeX + o textproc/openjade + o textproc/docbook + o textproc/docbook-xml + o textproc/dsssl-docbook-modular + o textproc/dtd-catalogs + +o on freebsd you need to make some entities visible to the docbook xml + dtd by making a symlink (can probably be done with a catalog too) + ln -s /usr/local/share/xml/entity /usr/local/share/xml/dtd/docbook/ent + +o you may need to edit /usr/local/share/sgml/catalog and add the line: + + CATALOG "/usr/local/share/sgml/openjade/catalog" + +o add "hugelatex," Enlarge pool sizes, install the jadetex TeX driver + file. + + cd /usr/local/share/texmf/web2c/ + sudo cp texmf.cnf texmf.cnf.bak + + o edit the lines in texmf.cnf with these keys to these values: + + main_memory = 1100000 + hash_extra = 15000 + pool_size = 500000 + string_vacancies = 45000 + max_strings = 55000 + pool_free = 47500 + nest_size = 500 + param_size = 1500 + save_size = 5000 + stack_size = 1500 + + sudo tex -ini -progname=hugelatex -fmt=hugelatex latex.ltx + sudo texconfig init + sudo texhash + + o For the jadetex macros you will need I recommend you get a more + current version than what is packaged with openjade or jade. + + Checkout http://www.tug.org/applications/jadetex/ + + Unzip the file you get from there (should be jadetex-2.20 or + newer.) + + In the directory you unzip: + + sudo make install + sudo texhash + + NOTE: In the most uptodate "ports" for FreeBSD, jadetext is 2.20+ + so on this platform you should be set as of 2001.01.08. diff --git a/contrib/bind9/doc/arm/isc.color.gif b/contrib/bind9/doc/arm/isc.color.gif new file mode 100644 index 000000000000..09c327cca65d Binary files /dev/null and b/contrib/bind9/doc/arm/isc.color.gif differ diff --git a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in new file mode 100644 index 000000000000..33fc938777a4 --- /dev/null +++ b/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in @@ -0,0 +1,148 @@ + +]> + + + + + + + +(define %html-prefix% + ;; Add the specified prefix to HTML output filenames + "Bv9ARM.") + +(define %use-id-as-filename% + ;; Use ID attributes as name for component HTML files? + #t) + +(define %root-filename% + ;; Name for the root HTML document + "Bv9ARM") + +(define %section-autolabel% + ;; REFENTRY section-autolabel + ;; PURP Are sections enumerated? + ;; DESC + ;; If true, unlabeled sections will be enumerated. + ;; /DESC + ;; AUTHOR N/A + ;; /REFENTRY + #t) + +(define %html-ext% + ;; REFENTRY html-ext + ;; PURP Default extension for HTML output files + ;; DESC + ;; The default extension for HTML output files. + ;; /DESC + ;; AUTHOR N/A + ;; /REFENTRY + ".html") + +(define nochunks + ;; REFENTRY nochunks + ;; PURP Suppress chunking of output pages + ;; DESC + ;; If true, the entire source document is formatted as a single HTML + ;; document and output on stdout. + ;; (This option can conveniently be set with '-V nochunks' on the + ;; Jade command line). + ;; /DESC + ;; AUTHOR N/A + ;; /REFENTRY + #f) + +(define rootchunk + ;; REFENTRY rootchunk + ;; PURP Make a chunk for the root element when nochunks is used + ;; DESC + ;; If true, a chunk will be created for the root element, even though + ;; nochunks is specified. This option has no effect if nochunks is not + ;; true. + ;; (This option can conveniently be set with '-V rootchunk' on the + ;; Jade command line). + ;; /DESC + ;; AUTHOR N/A + ;; /REFENTRY + #t) + +(define html-index + ;; REFENTRY html-index + ;; PURP HTML indexing? + ;; DESC + ;; Turns on HTML indexing. If true, then index data will be written + ;; to the file defined by 'html-index-filename'. This data can be + ;; collated and turned into a DocBook index with bin/collateindex.pl. + ;; /DESC + ;; AUTHOR N/A + ;; /REFENTRY + #t) + +(define html-manifest + ;; REFENTRY html-manifest + ;; PURP Write a manifest? + ;; DESC + ;; If not '#f' then the list of HTML files created by the stylesheet + ;; will be written to the file named by 'html-manifest-filename'. + ;; /DESC + ;; AUTHOR N/A + ;; /REFENTRY + #t) + +(define (chunk-element-list) + (list (normalize "preface") + (normalize "chapter") + (normalize "appendix") + (normalize "article") + (normalize "glossary") + (normalize "bibliography") + (normalize "index") + (normalize "colophon") + (normalize "setindex") + (normalize "reference") + (normalize "refentry") + (normalize "part") + (normalize "book") ;; just in case nothing else matches... + (normalize "set") ;; sets are definitely chunks... + )) + +; +; Add some cell padding to tables so that they don't look so cramped +; in Netscape. +; +; The following definition was cut-and-pasted from dbtable.dsl and the +; single line containing the word CELLPADDING was added. +; +(element tgroup + (let* ((wrapper (parent (current-node))) + (frameattr (attribute-string (normalize "frame") wrapper)) + (pgwide (attribute-string (normalize "pgwide") wrapper)) + (footnotes (select-elements (descendants (current-node)) + (normalize "footnote"))) + (border (if (equal? frameattr (normalize "none")) + '(("BORDER" "0")) + '(("BORDER" "1")))) + (width (if (equal? pgwide "1") + (list (list "WIDTH" ($table-width$))) + '())) + (head (select-elements (children (current-node)) (normalize "thead"))) + (body (select-elements (children (current-node)) (normalize "tbody"))) + (feet (select-elements (children (current-node)) (normalize "tfoot")))) + (make element gi: "TABLE" + attributes: (append + '(("CELLPADDING" "3")) + border + width + (if %cals-table-class% + (list (list "CLASS" %cals-table-class%)) + '())) + (process-node-list head) + (process-node-list body) + (process-node-list feet) + (make-table-endnotes)))) + + + + + diff --git a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in new file mode 100644 index 000000000000..511d6c48bc8c --- /dev/null +++ b/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in @@ -0,0 +1,42 @@ + +]> + + + + + + + + +(define %generate-book-titlepage% #t) + +(define %section-autolabel% + ;; REFENTRY section-autolabel + ;; PURP Are sections enumerated? + ;; DESC + ;; If true, unlabeled sections will be enumerated. + ;; /DESC + ;; AUTHOR N/A + ;; /REFENTRY + #t) + +;; Margins around cell contents +;; (define %cals-cell-before-row-margin% 20pt) +;; (define %cals-cell-after-row-margin% 20pt) + +;; seems to be a bug in JadeTeX -- we get a wierd indent on table +;; cells for the first line only. This is a workaround. +;; Adam Di Carlo, adam@onshore.com +(define %cals-cell-before-column-margin% 5pt) +(define %cals-cell-after-column-margin% 5pt) + +;; Inheritable start and end indent for cell contents +(define %cals-cell-content-start-indent% 5pt) +(define %cals-cell-content-end-indent% 5pt) + + + + + + diff --git a/contrib/bind9/doc/arm/validate.sh.in b/contrib/bind9/doc/arm/validate.sh.in new file mode 100644 index 000000000000..f50d8a09dbda --- /dev/null +++ b/contrib/bind9/doc/arm/validate.sh.in @@ -0,0 +1,21 @@ +#!/bin/sh +# +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000, 2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: validate.sh.in,v 1.2.206.1 2004/03/06 13:16:14 marka Exp $ + +nsgmls -sv @SGMLDIR@/docbook/dsssl/modular/dtds/decls/xml.dcl \ + Bv9ARM-book.xml diff --git a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt new file mode 100644 index 000000000000..1030e5782ef9 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt @@ -0,0 +1,336 @@ + + + + +Internet-Draft T. Baba +Expires: March 11, 2004 NTT Data + September 11, 2003 + + + Requirements for Access Control in Domain Name Systems + draft-baba-dnsext-acl-reqts-01.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Distribution of this memo is unlimited. + + This Internet-Draft will expire on March 11, 2004. + +Abstract + + This document describes the requirements for access control + mechanisms in the Domain Name System (DNS), which authenticate + clients and then allow or deny access to resource records in the + zone according to the access control list (ACL). + +1. Introduction + + The Domain Name System (DNS) is a hierarchical, distributed, highly + available database used for bi-directional mapping between domain + names and IP addresses, for email routing, and for other information + [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined + to authenticate the data in DNS and provide key distribution services + using SIG, KEY, and NXT resource records (RRs) [RFC2535]. + + + +Baba Expires March 11, 2004 [Page 1] + +Internet-Draft DNS Access Control Requirements September 2003 + + + At the 28th IETF Meeting in Houston in 1993, DNS security design team + started a discussion about DNSSEC and agreed to accept the assumption + that "DNS data is public". Accordingly, confidentiality for queries + or responses is not provided by DNSSEC, nor are any sort of access + control lists or other means to differentiate inquirers. However, + about ten years has passed, access control in DNS has been more + important than before. Currently, new RRs are proposed to add new + functionality to DNS such as ENUM [RFC2916]. Such new RRs may + contain private information. Thus, DNS access control will be + needed. + + Furthermore, with DNS access control mechanism, access from + unauthorized clients can be blocked when they perform DNS name + resolution. Thus, for example, Denial of Service (DoS) attacks + against a server used by a closed user group can be prevented using + this mechanism if IP address of the server is not revealed by other + sources. + + This document describes the requirements for access control + mechanisms in DNS. + +2. Terminology + + AC-aware client + This is the client that understands the DNS access control + extensions. This client may be an end host which has a stub + resolver, or a cashing/recursive name server which has a + full-service resolver. + + AC-aware server + This is the authoritative name server that understands the DNS + access control extensions. + + ACE + An Access Control Entry. This is the smallest unit of access + control policy. It grants or denies a given set of access + rights to a set of principals. An ACE is a component of an ACL, + which is associated with a resource. + + ACL + An Access Control List. This contains all of the access control + policies which are directly associated with a particular + resource. These policies are expressed as ACEs. + + Client + A program or host which issues DNS requests and accepts its + responses. A client may be an end host or a cashing/recursive name + server. + + + +Baba Expires March 11, 2004 [Page 2] + +Internet-Draft DNS Access Control Requirements September 2003 + + + RRset + All resource records (RRs) having the same NAME, CLASS and TYPE + are called a Resource Record Set (RRset). + +3. Requirements + + This section describes the requirements for access control in DNS. + +3.1 Authentication + +3.1.1 Client Authentication Mechanism + + The AC-aware server must identify AC-aware clients based on IP + address and/or domain name (user ID or host name), and must + authenticate them using strong authentication mechanism such as + digital signature or message authentication code (MAC). + + SIG(0) RR [RFC2931] contains a domain name associated with sender's + public key in its signer's name field, and TSIG RR [RFC2845] also + contains a domain name associated with shared secret key in its key + name field. Each of these domain names can be a host name or a user + name, and can be used as a sender's identifier for access control. + Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for + message authentication. These mechanisms can be used to authenticate + AC-aware clients. + + Server authentication may be also provided. + +3.1.2 End-to-End Authentication + + In current DNS model, caching/recursive name servers are deployed + between end hosts and authoritative name servers. Although + authoritative servers can authenticate caching/recursive name servers + using SIG(0) or TSIG, they cannot authenticate end hosts behind them. + For end-to-end authentication, the mechanism for an end host to + discover the target authoritative name server and directly access to + it bypassing caching/recursive name servers is needed. For example, + an end host can get the IP addresses of the authoritative name + servers by retrieving NS RRs for the zone via local caching/recursive + name server. + + In many enterprise networks, however, there are firewalls that block + all DNS packets other than those going to/from the particular + caching/recursive servers. To deal with this problem, one can + implement packet forwarding function on the caching/recursive servers + and enable end-to-end authentication via the caching/recursive + servers. + + + + +Baba Expires March 11, 2004 [Page 3] + +Internet-Draft DNS Access Control Requirements September 2003 + + +3.1.3 Authentication Key Retrieval + + Keys which are used to authenticate clients should be able to be + automatically retrieved. The KEY RR is used to store a public key + for a zone or a host that is associated with a domain name. SIG(0) + RR uses a public key in KEY RR for verifying the signature. If + DNSSEC is available, the KEY RR would be protected by the SIG RR. + KEY RR or newly defined RR can be used to automatic key retrieval. + +3.2 Confidentiality + +3.2.1 Data Encryption + + To avoid disclosure to eavesdroppers, the response containing the + RRsets which are restricted to access from particular users should be + encrypted. Currently, no encryption mechanism is specified in DNS. + Therefore, new RRs should be defined for DNS message encryption. + Instead, IPsec [RFC2401] can be used to provide confidentiality if + name server and resolver can set up security associations dynamically + using IPsec API [IPSECAPI] when encryption is required. + + In case encryption is applied, entire DNS message including DNS + header should be encrypted to hide information including error code. + + Query encryption may be also provided for hiding query information. + +3.2.2 Key Exchange + + If DNS message encryption is provided, automatic key exchange + mechanism should be also provided. [RFC2930] specifies a TKEY RR + that can be used to establish and delete shared secret keys used by + TSIG between a client and a server. With minor extensions, TKEY can + be used to establish shared secret keys used for message encryption. + +3.2.3 Caching + + The RRset that is restricted to access from particular users must not + be cached. To avoid caching, the TTL of the RR that is restricted to + access should be set to zero during transit. + +3.3 Access Control + +3.3.1 Granularity of Access Control + + Control of access on a per-user/per-host granularity must be + supported. Control of access to individual RRset (not just the + entire zone) must be also supported. However, SOA, NS, SIG, NXT, + KEY, and DS RRs must be publicly accessible to avoid unexpected + results. + + +Baba Expires March 11, 2004 [Page 4] + +Internet-Draft DNS Access Control Requirements September 2003 + + +3.3.2 ACL Representation + + Access Control List (ACL) format must be standardized so that both + the primary and secondary AC-aware servers can recognize the same + ACL. Although ACL may appear in or out of zone data, it must be + transferred to the secondary AC-aware server with associated zone + data. It is a good idea to contain ACL in zone data, because ACL can + be transferred with zone data using existing zone transfer mechanisms + automatically. However, ACL must not be published except for + authorized secondary master servers. + + In zone data master files, ACL should be specified using TXT RRs or + newly defined RRs. In each access control entry (ACE), authorized + entities (host or user) must be described using domain name (host + name, user name, or IP address in in-addr.arpa/ip6.arpa format). + There may be other access control attributes such as access time. + + It must be possible to create publicly readable entries, which may be + read even by unauthenticated clients. + +3.3.3 Zone/ACL Transfer + + As mentioned above, ACL should be transferred from a primary AC-aware + server to a secondary AC-aware server with associated zone data. + When an AC-aware server receives a zone/ACL transfer request, the + server must authenticate the client, and should encrypt the zone + data and associated ACL during transfer. + +3.4 Backward/co-existence Compatibility + + Any new protocols to be defined for access control in DNS must be + backward compatible with existing DNS protocol. AC-aware servers + must be able to process normal DNS query without authentication, and + must respond if retrieving RRset is publicly accessible. + + Modifications to root/gTLD/ccTLD name servers are not allowed. + +4. Security Considerations + + This document discusses the requirements for access control + mechanisms in DNS. + +5. Acknowledgements + + This work is funded by the Telecommunications Advancement + Organization of Japan (TAO). + + The author would like to thank the members of the NTT DATA network + security team for their important contribution to this work. + + +Baba Expires March 11, 2004 [Page 5] + +Internet-Draft DNS Access Control Requirements September 2003 + + +6. References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, + September 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", + RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API", + draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in + Progress. + + +Author's Address + + Tatsuya Baba + NTT Data Corporation + Research and Development Headquarters + Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku, + Tokyo 104-0033, Japan + + Tel: +81 3 3523 8081 + Fax: +81 3 3523 8090 + Email: babatt@nttdata.co.jp + + + + + + + + +Baba Expires March 11, 2004 [Page 6] diff --git a/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt b/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt new file mode 100644 index 000000000000..fffa8a5f20b3 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt @@ -0,0 +1,1232 @@ + + +Network Working Group L. Daigle +Internet-Draft A. Newton +Expires: August 15, 2004 VeriSign, Inc. + February 15, 2004 + + + Domain-based Application Service Location Using SRV RRs and the + Dynamic Delegation Discovery Service (DDDS) + draft-daigle-napstr-04.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This memo defines a generalized mechanism for application service + naming that allows service location without relying on rigid domain + naming conventions (so-called name hacks). The proposal defines a + Dynamic Delegation Discovery System (DDDS) Application to map domain + name, application service name, and application protocol to target + server and port, dynamically. + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 1] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4 + 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5 + 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5 + 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5 + 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5 + 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6 + 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6 + 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1 Guidelines for Application Protocol Developers . . . . . . . 7 + 3.1.1 Registration of application service and protocol tags . . . 7 + 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8 + 3.1.3 Server identification and handshake . . . . . . . . . . . . 8 + 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8 + 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9 + 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10 + 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10 + 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12 + 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12 + 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14 + 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15 + 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 16 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 + A. Application Service Location Application of DDDS . . . . . . 18 + A.1 Application Unique String . . . . . . . . . . . . . . . . . 18 + A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18 + A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18 + A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19 + A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19 + A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20 + A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20 + A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20 + B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20 + B.1 Finding the first (best) target . . . . . . . . . . . . . . 20 + B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 + + + + +Daigle & Newton Expires August 15, 2004 [Page 2] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +1. Introduction + + This memo defines a generalized mechanism for application service + naming that allows service location without relying on rigid domain + naming conventions (so-called name hacks). The proposal defines a + Dynamic Delegation Discovery System (DDDS -- see [6]) Application to + map domain name, application service name, and application protocol + to target server and port, dynamically. + + As discussed in Section 5, existing approaches to using DNS records + to dynamically determining the current host for a given application + service are limited in terms of the use cases supported. To address + some of the limitations, this document defines a DDDS Application to + map service+protocol+domain to specific server addresses using both + NAPTR [7] and SRV ([5]) DNS resource records. This can be viewed as + a more general version of the use of SRV and/or a very restricted + application of the use of NAPTR resource records. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC2119 ([2]). + +2. Straightforward-NAPTR (S-NAPTR) Specification + + The precise details of the specification of this DDDS application are + given in Appendix A. This section defines the usage of the DDDS + application. + +2.1 Key Terms + + An "application service" is a generic term for some type of + application, indpendent of the protocol that may be used to offer it. + Each application service will be associated with an IANA-registered + tag. For example, instant messaging is a type of application + service, which can be implemented by many different application-layer + protocols, and the tag "IM" (used as an illustration here) could be + registered for it. + + An "application protocol" is used to implement the application + service. These are also associated with IANA-registered tags. In + the case where multiple transports are available for the application, + separate tags should be defined for each transport. + + The intention is that the combination of application service and + protocol tags should be specific enough that finding a known pair + (e.g., "IM:ProtC") is sufficient for a client to identify a server + with which it can communicate. + + + + +Daigle & Newton Expires August 15, 2004 [Page 3] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + Some protocols support multiple application services. For example, + LDAP is an application protocol, and can be found supporting various + services (e.g., "whitepages", "directory enabled networking", etc). + +2.2 S-NAPTR DDDS Application Usage + + As outlined in Appendix A, NAPTR records are used to store + application service+protocol information for a given domain. + Following the DDDS standard, these records are looked up, and the + rewrite rules (contained in the NAPTR records) are used to determine + the successive DNS lookups, until a desirable target is found. + + For the rest of this section, refer to the set of NAPTR resource + records for example.com shown in the figure below. + + example.com. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example. + IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com. + IN NAPTR 200 10 "" "IM:protA" "" someisp.example. + IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com. + + +2.2.1 Ordering and Preference + + A client retrieves all of the NAPTR records associated with the + target domain name (example.com, above). These are to be sorted in + terms of increasing ORDER, and increasing PREF within each ORDER. + +2.2.2 Matching and non-Matching NAPTR Records + + Starting with the first sorted NAPTR record, the client examines the + SERVICE field to find a match. In the case of the S-NAPTR DDDS + application, that means a SERVICE field that includes the tags for + the desired application service and a supported application protocol. + + If more than one NAPTR record matches, they are processed in + increasing sort order. + +2.2.3 Terminal and Non-Terminal NAPTR Records + + A NAPTR record with an empty FLAG field is "non-terminal". That is, + more NAPTR RR lookups are to be performed. Thus, to process a NAPTR + record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is + used as the target of the next DNS lookup -- for NAPTR RRs. + + In S-NAPTR, the only terminal flags are "S" and "A". These are + called "terminal" NAPTR lookups because they denote the end of the + + + +Daigle & Newton Expires August 15, 2004 [Page 4] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + DDDS/NAPTR processing rules. In the case of an "S" flag, the + REPLACEMENT field is used as the target of a DNS query for SRV RRs, + and normal SRV processing is applied. In the case of an "A" flag, an + address record is sought for the REPLACEMENT field target (and the + default protocol port is assumed). + +2.2.4 S-NAPTR and Successive Resolution + + As shown in the example NAPTR RR set above, it is possible to have + multiple possible targets for a single application service+protocol + pair. These are to be pursued in order until a server is + successfully contacted or all possible matching NAPTR records have + been successively pursued to terminal lookups and servers contacted. + That is, a client must backtrack and attempt other resolution paths + in the case of failure. + + "Failure" is declared, and backtracking must be used when + + o the designated remote server (host and port) fail to provide + appropriate security credentials for the *originating* domain + + o connection to the designated remote server otherwise fails -- the + specifics terms of which are defined when an application protocol + is registered + + o the S-NAPTR-designated DNS lookup fails to yield expected results + -- e.g., no A RR for an "A" target, no SRV record for an "S" + target, or no NAPTR record with appropriate application service + and protocol for a NAPTR lookup. Except in the case of the very + first NAPTR lookup, this last is a configuration error: the fact + that example.com has a NAPTR record pointing to "bunyip.example" + for the "WP:Whois++" service and protocol means the administrator + of example.com believes that service exists. If bunyip.example + has no "WP:Whois++" NAPTR record, the application client MUST + backtrack and try the next available "WP:Whois++" option from + example.com. As there is none, the whole resolution fails. + + An application client first queries for the NAPTR RRs for the domain + of a named application service. The application client MUST select + one protocol to choose The PREF field of the NAPTR RRs may be used by + the domain administrator to The first DNS query is for the NAPTR RRs + in the original target domain (example.com, above). + +2.2.5 Clients Supporting Multiple Protocols + + In the case of an application client that supports more than one + protocol for a given application service, it MUST pursue S-NAPTR + resolution completely for one protocol before trying another.j It MAY + + + +Daigle & Newton Expires August 15, 2004 [Page 5] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + choose which protocol to try first based on its own preference, or + from the PREF ranking in the first set of NAPTR records (i.e., those + for the target named domain). However, the chosen protocol MUST be + listed in that first NAPTR RR set. + + That is, what the client MUST NOT do is start looking for one + protocol, observe that a successive NAPTR RR set supports another of + its preferred protocols, and continue the S-NAPTR resolution based on + that protocol. For example, even if someisp.example offers the "IM" + service with protocol "ProtB", there is no reason to believe it does + so on behalf of example.com (since there is no such pointer in + example.com's NAPTR RR set). + +3. Guidelines + +3.1 Guidelines for Application Protocol Developers + + The purpose of S-NAPTR is to provide application standards developers + with a more powerful framework (than SRV RRs alone) for naming + service targets, without requiring each application protocol (or + service) standard to define a separate DDDS application. + + Note that this approach is intended specifically for use when it + makes sense to associate services with particular domain names (e.g., + e-mail addresses, SIP addresses, etc). A non-goal is having all + manner of label mapped into domain names in order to use this. + + Specifically not addressed in this document is how to select the + domain for which the service+protocol is being sought. It is up to + other conventions to define how that might be used (e.g., instant + messaging standards can define what domain to use from IM URIs, how + to step down from foobar.example.com to example.com, and so on, if + that is applicable). + + Although this document proposes a DDDS application that does not use + all the features of NAPTR resource records, it does not mean to imply + that DNS resolvers should fail to implement all aspects of the NAPTR + RR standard. A DDDS application is a client use convention. + + The rest of this section outlines the specific elements that protocol + developers must determine and document in order to make use of S- + NAPTR. + +3.1.1 Registration of application service and protocol tags + + Application protocol developers that wish to make use of S-NAPTR must + make provision to register any relevant application service and + application protocol tags, as described in Section 6. + + + +Daigle & Newton Expires August 15, 2004 [Page 6] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +3.1.2 Definition of conditions for retry/failure + + One other important aspect that must be defined is the expected + behaviour for interacting with the servers that are reached via S- + NAPTR. Specifically, under what circumstances should the client + retry a target that was found via S-NAPTR? What should it consider a + failure that causes it to return to the S-NAPTR process to determine + the next serviceable target (a less preferred target)? + + For example, if the client gets a "connection refused" from a server, + should it retry for some (protocol-dependent) period of time? Or, + should it try the next-preferred target in the S-NAPTR chain of + resolution? Should it only try the next-preferred target if it + receives a protocol-specific permanent error message? + + The most important thing is to select one expected behaviour and + document it as part of the use of S-NAPTR. + + As noted earlier, failure to provide appropriate credentials to + identify the server as being authoritative for the original taret + domain is always considered a failure condition. + +3.1.3 Server identification and handshake + + As noted in Section 7, use of the DNS for server location increases + the importance of using protocol-specific handshakes to determine and + confirm the identity of the server that is eventually reached. + + Therefore, application protocol developers using S-NAPTR should + identify the mechanics of the expected identification handshake when + the client connects to a server found through S-NAPTR. + +3.2 Guidelines for Domain Administrators + + Although S-NAPTR aims to provide a "straightforward" application of + DDDS and use of NAPTR records, it is still possible to create very + complex chains and dependencies with the NAPTR and SRV records. + + Therefore, domain administrators are called upon to use S-NAPTR with + as much restraint as possible, while still achieving their service + design goals. + + The complete set of NAPTR, SRV and A RRs that are "reachable" through + the S-NAPTR process for a particular application service can be + thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR + or SRV records; each SRV record points to several A record lookups. + Even though a particular client can "prune" the tree to use only + those records referring to application protocols supported by the + + + +Daigle & Newton Expires August 15, 2004 [Page 7] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + client, the tree could be quite deep, and retracing the tree to retry + other targets can become expensive if the tree has many branches. + + Therefore, + + o Fewer branches is better: for both NAPTR and SRV records, provide + different targets with varying preferences where appropriate + (e.g., to provide backup services, etc), but don't look for + reasons to provide more. + + o Shallower is better: avoid using NAPTR records to "rename" + services within a zone. Use NAPTR records to identify services + hosted elsewhere (i.e., where you cannot reasonably provide the + SRV records in your own zone). + + +3.3 Guidelines for Client Software Writers + + To properly understand DDDS/NAPTR, an implementor must read [6]. + However, the most important aspect to keep in mind is that, if one + target fails to work for the application, it is expected that the + application will continue through the S-NAPTR tree to try the (less + preferred) alternatives. + +4. Illustrations + +4.1 Use Cases + + The basic intended use cases for which S-NAPTR has been developed + are: + + o Service discovery within a domain. For example, this can be used + to find the "authoritative" server for some type of service within + a domain (see the specific example in Section 4.2). + + o Multiple protocols. This is increasingly common as new + application services are defined. This includes the case of + instant messaging (a service) which can be offered with multiple + protocols (see Section 4.3). + + o Remote hosting. Each of the above use cases applies within the + administration of a single domain. However, one domain operator + may elect to engage another organization to provide an application + service. See Section 4.4 for an example that cannot be served by + SRV records alone. + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 8] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +4.2 Service Discovery within a Domain + + There are occasions when it is useful to be able to determine the + "authoritative" server for a given application service within a + domain. This is "discovery", because there is no a priori knowledge + as to whether or where the service is offered; it is therefore + important to determine the location and characteristics of the + offered service. + + For example, there is growing discussion of having a generic + mechanism for locating the keys or certificates associated with + particular application (servers) operated in (or for) a particular + domain. Here's a hypothetical case for storing application key or + certificate data for a given domain. The premise is that some + credentials registry (CredReg) service has been defined to be a leaf + node service holding the keys/certs for the servers operated by (or + for) the domain. Furthermore, it is assumed that more than one + protocol is available to provide the service for a particular domain. + This DDDS-based approach is used to find the CredReg server that + holds the information. + + Thus, the set of NAPTR records for thinkingcat.example might look + like this: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example. + + Note that another domain, offering the same application service, + might offer it using a different set of application protocols: + + anotherdomain.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example. + + +4.3 Multiple Protocols + + As it stands, there are several different protocols proposed for + offering "instant message" services. Assuming that "IM" was + registered as an application service, this DDDS application could be + used to determine the available services for delivering to a target. + + Two particular features of instant messaging should be noted: + + 1. gatewaying is expected to bridge communications across protocols + + 2. instant messaging servers are likely to be operated out of a + + + +Daigle & Newton Expires August 15, 2004 [Page 9] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + different domain than the instant messaging address, and servers + of different protocols may be offered by independent + organizations + + For example, "thinkingcat.example" may support its own servers for + the "ProtA" instant messaging protocol, but rely on outsourcing from + "example.com" for "ProtC" and "ProtB" servers. + + Using this DDDS-based approach, thinkingcat.example can indicate a + preference ranking for the different types of servers for the instant + messaging service, and yet the out-sourcer can independently rank the + preference and ordering of servers. This independence is not + achievable through the use of SRV records alone. + + Thus, to find the IM services for thinkingcat.example, the NAPTR + records for thinkingcat.example are retrieved: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. + IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com. + + and then the administrators at example.com can manage the preference + rankings of the servers they use to support the ProtB service: + + _ProtB._tcp.example.com. + ;; Pref Weight Port Target + IN SRV 10 0 10001 bigiron.example.com + IN SRV 20 0 10001 backup.im.example.com + IN SRV 30 0 10001 nuclearfallout.australia-isp.example + + +4.4 Remote Hosting + + In the Instant Message hosting example in Section 4.3, the service + owner (thinkingcat.example) had to host pointers to the hosting + service's SRV records in the thinkingcat.example domain. + + A better way to approach this is to have one NAPTR RR in the + thinkingcat.example domain pointing to all the hosted services, and + the hosting domain has NAPTR records for each service to map them to + whatever local hosts it chooses (and may change from time to time). + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 10] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com. + + + and then the administrators at example.com can break out the + individual application protocols and manage the preference rankings + of the servers they use to support the ProtB service (as before): + + thinkingcat.example.com. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com. + IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. + + + + _ProtC._tcp.example.com. + ;; Pref Weight Port Target + IN SRV 10 0 10001 bigiron.example.com + IN SRV 20 0 10001 backup.im.example.com + IN SRV 30 0 10001 nuclearfallout.australia-isp.example + + +4.5 Sets of NAPTR RRs + + Note that the above sections assumed that there was one service + available (via S-NAPTR) per domain. Often, that will not be the + case. Assuming thinkingcat.example had the CredReg service set up as + described in Section 4.2 and the instant messaging service set up as + described in Section 4.4, then a client querying for the NAPTR RR set + from thinkingcat.com would get the following answer: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com. + IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example. + + Sorting them by increasing "ORDER", the client would look through the + SERVICE strings to determine if there was a NAPTR RR that matched the + application service it was looking for, with an application protocol + it could use. The first (lowest PREF) record that so matched is the + one the client would use to continue. + +4.6 Sample sequence diagram + + Consider the example in Section 4.3. Visually, the sequence of steps + + + +Daigle & Newton Expires August 15, 2004 [Page 11] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + required for the client to reach the final server for a "ProtB" + service for IM for the thinkingcat.example domain is as follows: + + + Client NS for NS for + thinkingcat.example example.com backup.im.example.com + | | | + 1 -------->| | | + 2 <--------| | | + 3 ------------------------------>| | + 4 <------------------------------| | + 5 ------------------------------>| | + 6 <------------------------------| | + 7 ------------------------------>| | + 8 <------------------------------| | + 9 ------------------------------------------------->| + 10 <-------------------------------------------------| + 11 ------------------------------------------------->| + 12 <-------------------------------------------------| + (...) + + + + 1. the name server (NS) for thinkingcat.example is reached with a + request for all NAPTR records + + 2. the server responds with the NAPTR records shown in Section 4.3. + + 3. the second NAPTR record matches the desired criteria; that has an + "s" flag and a replacement fields of "_ProtB._tcp.example.com". + So, the client looks up SRV records for that target, ultimately + making the request of the NS for example.com. + + 4. the response includes the SRV records listed in Section 4.3. + + 5. the client attempts to reach the server with the lowest PREF in + the SRV list -- looking up the A record for the SRV record's + target (bigiron.example.com). + + 6. the example.com NS responds with an error message -- no such + machine! + + 7. the client attempts to reach the second server in the SRV list, + and looks up the A record for backup.im.example.com + + 8. the client gets the A record with the IP address for + backup.im.example.com from example.com's NS. + + + + +Daigle & Newton Expires August 15, 2004 [Page 12] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + 9. the client connects to that IP address, on port 10001 (from the + SRV record), using ProtB over tcp. + + 10. the server responds with an "OK" message. + + 11. the client uses ProtB to challenge that this server has + credentials to operate the service for the original domain + (thinkingcat.example) + + 12. the server responds, and the rest is IM. + + +5. Motivation and Discussion + + Increasingly, application protocol standards are using domain names + to identify server targets, and stipulating that clients should look + up SRV resource records to determine the host and port providing the + server. This enables a distinction between naming an application + service target and actually hosting the server. It also increases + flexibility in hosting the target service: + + o the server may be operated by a completely different organization + without having to list the details of that organization's DNS + setup (SRVs) + + o multiple instances can be set up (e.g., for load balancing or + secondaries) + + o it can be moved from time to time without disrupting clients' + access, etc. + + This is quite useful, but Section 5.1 outlines some of the + limitations inherent in the approach. + + That is, while SRV records can be used to map from a specific service + name and protocol for a specific domain to a specific server, SRV + records are limited to one layer of indirection, and are focused on + server administration rather than on application naming. And, while + the DDDS specification and use of NAPTR allows multiple levels of + redirection before locating the target server machine with an SRV + record, this proposal requires only a subset of NAPTR strictly bound + to domain names, without making use of the REGEXP field of NAPTR. + These restrictions make the client's resolution process much more + predictable and efficient than with some potential uses of NAPTR + records. This is dubbed "S-NAPTR" -- a "S"traightforward use of + NAPTR records. + + + + + +Daigle & Newton Expires August 15, 2004 [Page 13] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +5.1 So, why not just SRV records? + + An expected question at this point is: this is so similar in + structure to SRV records, why are we doing this with DDDS/NAPTR? + + Limitations of SRV include: + + o SRV provides a single layer of indirection -- the outcome of an + SRV lookup is a new domain name for which the A RR is to be found. + + o the purpose of SRV is focused on individual server administration, + not application naming: as stated in [5] "The SRV RR allows + administrators to use several servers for a single domain, to move + services from host to host with little fuss, and to designate some + hosts as primary servers for a service and others as backups." + + o target servers by "service" (e.g., "ldap") and "protocol" (e.g., + "tcp") in a given domain. The definition of these terms implies + specific things (e.g., that protocol should be one of UDP or TCP) + without being precise. Restriction to UDP and TCP is insufficient + for the uses described here. + + The basic answer is that SRV records provide mappings from protocol + names to host and port. The use cases described herein require an + additional layer -- from some service label to servers that may in + fact be hosted within different administrative domains. We could + tweak SRV to say that the next lookup could be something other than + an address record, but that is more complex than is necessary for + most applications of SRV. + +5.2 So, why not just NAPTR records? + + That's a trick question. NAPTR records cannot appear in the wild -- + see [6]. They must be part of a DDDS application. + + The purpose here is to define a single, common mechanism (the DDDS + application) to use NAPTR when all that is desired is simple DNS- + based location of services. This should be easy for applications to + use -- some simple IANA registrations and it's done. + + Also, NAPTR has very powerful tools for expressing "rewrite" rules. + That power (==complexity) makes some protocol designers and service + administrators nervous. The concern is that it can translate into + unintelligible, noodle-like rule sets that are difficult to test and + administer. + + This proposed DDDS application specifically uses a subset of NAPTR's + abilities. Only "replacement" expressions are allowed, not "regular + + + +Daigle & Newton Expires August 15, 2004 [Page 14] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + expressions". + +6. IANA Considerations + + This document calls for 2 IANA registries: one for application + service tags, and one for application protocol tags. + + Application service and protocol tags should be defined in an RFC + (unless the "x-" experimental form is used, in which case they are + unregistered). There are no restrictions placed on the tags other + than that they must conform with the syntax defined below (Appendix + A.5). The IANA registries should list the tags and the RFC that + defines their use. + +7. Security Considerations + + The security of this approach to application service location is only + as good as the security of the DNS servers along the way. If any of + them is compromised, bogus NAPTR and SRV records could be inserted to + redirect clients to unintended destinations. This problem is hardly + unique to S-NAPTR (or NAPTR in general). + + To protect against DNS-vectored attacks, applications should define + some form of end-to-end authentication to ensure that the correct + destination has been reached. Many application protocols such as + HTTPS, BEEP, IMAP, etc... define the necessary handshake mechansims + to accomplish this task. + + The basic mechanism works in the following way: + + 1. During some portion of the protocol handshake, the client sends + to the server the original name of the desired destination (i.e. + no transformations that may have resulted from NAPTR + replacements, SRV targets, or CNAME changes). In certain cases + where the application protocol does not have such a feature but + TLS may be used, it is possible to use the "server_name" TLS + extension. + + 2. The server sends back to the client a credential with the + appropriate name. For X.509 certificates, the name would either + be in the subjectDN or subjectAltName fields. For Kerberos, the + name would be a service principle name. + + 3. Using the matching semantics defined by the application protocol, + the client compares the name in the credential with the name sent + to the server. + + 4. If the names match, there is reasonable assurance that the + + + +Daigle & Newton Expires August 15, 2004 [Page 15] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + correct end point has been reached. + + It is important to note that this document does not define either the + handshake mechanism, the specific credenential naming fields, nor the + name matching semantics. Definitions of S-NAPTR for particular + application protocols MUST define these. + +8. Acknowledgements + + Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for + discussion and input that has (hopefully!) provoked clarifying + revisions of this document. + +References + + [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + One: The Comprehensive DDDS", RFC 3401, October 2002. + + [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Three: The Domain Name System (DNS) Database", RFC 3403, October + 2002. + + [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Four: The Uniform Resource Identifiers (URI)", RFC 3404, October + 2002. + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 16] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Authors' Addresses + + Leslie Daigle + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + EMail: leslie@verisignlabs.com; leslie@thinkingcat.com + + + Andrew Newton + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + EMail: anewton@verisignlabs.com + +Appendix A. Application Service Location Application of DDDS + + This section defines the DDDS application, as described in [6]. + +A.1 Application Unique String + + The Application Unique String is domain label for which an + authoritative server for a particular service is sought. + +A.2 First Well Known Rule + + The "First Well Known Rule" is identity -- that is, the output of the + rule is the Application Unique String, the domain label for which the + authoritative server for a particular service is sought. + +A.3 Expected Output + + The expected output of this Application is the information necessary + to connect to authoritative server(s) (host, port, protocol) for an + application service within a given a given domain. + +A.4 Flags + + This DDDS Application uses only 2 of the Flags defined for the + URI/URN Resolution Application ([8]): "S" and "A". No other Flags + are valid. + + Both are for terminal lookups. This means that the Rule is the last + one and that the flag determines what the next stage should be. The + + + +Daigle & Newton Expires August 15, 2004 [Page 17] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + "S" flag means that the output of this Rule is a domain label for + which one or more SRV [5] records exist. "A" means that the output + of the Rule is a domain name and should be used to lookup address + records for that domain. + + Consistent with the DDDS algorithm, if the Flag string is empty the + next lookup is for another NAPTR record (for the replacement target). + +A.5 Service Parameters + + Service Parameters for this Application take the form of a string of + characters that follow this ABNF ([3]): + + service-parms = [ [app-service] *(":" app-protocol)] + app-service = experimental-service / iana-registered-service + app-protocol = experimental-protocol / iana-registered-protocol + experimental-service = "x-" 1*30ALPHANUMSYM + experimental-protocol = "x-" 1*30ALPHANUMSYM + iana-registered-service = ALPHA *31ALPHANUMSYM + iana-registered-protocol = ALPHA *31ALPHANUM + ALPHA = %x41-5A / %x61-7A ; A-Z / a-z + DIGIT = %x30-39 ; 0-9 + SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." + ALPHANUMSYM = ALPHA / DIGIT / SYM + ; The app-service and app-protocol tags are limited to 32 + ; characters and must start with an alphabetic character. + ; The service-parms are considered case-insensitive. + + Thus, the Service Parameters may consist of an empty string, just an + app-service, or an app-service with one or more app-protocol + specifications separated by the ":" symbol. + + Note that this is similar to, but not the same as the syntax used in + the URI DDDS application ([8]). The DDDS DNS database requires each + DDDS application to define the syntax of allowable service strings. + The syntax here is expanded to allow the characters that are valid in + any URI scheme name (see [1]). Since "+" (the separator used in the + RFC3404 service parameter string) is an allowed character for URI + scheme names, ":" is chosen as the separator here. + +A.5.1 Application Services + + The "app-service" must be a registered service [this will be an IANA + registry; this is not the IANA port registry, because we want to + define services for which there is no single protocol, and we don't + want to use up port space for nothing]. + + + + + +Daigle & Newton Expires August 15, 2004 [Page 18] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +A.5.2 Application Protocols + + The protocol identifiers that are valid for the "app-protocol" + production are any standard, registered protocols [IANA registry + again -- is this the list of well known/registered ports?]. + +A.6 Valid Rules + + Only substitution Rules are permitted for this application. That is, + no regular expressions are allowed. + +A.7 Valid Databases + + At present only one DDDS Database is specified for this Application. + [7] specifies a DDDS Database that uses the NAPTR DNS resource record + to contain the rewrite rules. The Keys for this database are encoded + as domain-names. + + The First Well Known Rule produces a domain name, and this is the Key + that is used for the first lookup -- the NAPTR records for that + domain are requested. + + DNS servers MAY interpret Flag values and use that information to + include appropriate NAPTR, SRV or A records in the Additional + Information portion of the DNS packet. Clients are encouraged to + check for additional information but are not required to do so. See + the Additional Information Processing section of [7] for more + information on NAPTR records and the Additional Information section + of a DNS response packet. + +Appendix B. Pseudo pseudocode for S-NAPTR + +B.1 Finding the first (best) target + + Assuming the client supports 1 protocol for a particular application + service, the following pseudocode outlines the expected process to + find the first (best) target for the client, using S-NAPTR. + + + target = [initial domain] + naptr-done = false + + while (not naptr-done) + { + NAPTR-RRset = [DNSlookup of NAPTR RRs for target] + [sort NAPTR-RRset by ORDER, and PREF within each ORDER] + rr-done = false + cur-rr = [first NAPTR RR] + + + +Daigle & Newton Expires August 15, 2004 [Page 19] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + while (not rr-done) + if ([SERVICE field of cur-rr contains desired application + service and application protocol]) + rr-done = true + target= [REPLACEMENT target of NAPTR RR] + else + cur-rr = [next rr in list] + + if (not empty [FLAG in cur-rr]) + naptr-done = true + } + + port = -1 + + if ([FLAG in cur-rr is "S"]) + { + SRV-RRset = [DNSlookup of SRV RRs for target] + [sort SRV-RRset based on PREF] + target = [target of first RR of SRV-RRset] + port = [port in first RR of SRV-RRset] + } + + ; now, whether it was an "S" or an "A" in the NAPTR, we + ; have the target for an A record lookup + + host = [DNSlookup of target] + + return (host, port) + + + +B.2 Finding subsequent targets + + The pseudocode in Appendix B is crafted to find the first, most + preferred, host-port pair for a particular application service an + protocol. If, for any reason, that host-port pair did not work + (connection refused, application-level error), the client is expected + to try the next host-port in the S-NAPTR tree. + + The pseudocode above does not permit retries -- once complete, it + sheds all context of where in the S-NAPTR tree it finished. + Therefore, client software writers could + + o entwine the application-specific protocol with the DNS lookup and + RRset processing described in the pseudocode and continue the S- + NAPTR processing if the application code fails to connect to a + located host-port pair; + + + + +Daigle & Newton Expires August 15, 2004 [Page 20] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + o use callbacks for the S-NAPTR processing; + + o use an S-NAPTR resolution routine that finds *all* valid servers + for the required application service and protocol from the + originating domain, and provides them in sorted order for the + application to try in order. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 21] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 22] + diff --git a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt new file mode 100644 index 000000000000..4a01d91b9a8b --- /dev/null +++ b/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt @@ -0,0 +1,1960 @@ + + + +INTERNET-DRAFT Hadmut Danisch +Category: Experimental Oct 2003 +Expires: Apr 1, 2004 + + The RMX DNS RR and method for lightweight SMTP sender authorization + draft-danisch-dns-rr-smtp-03.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + +Abstract + + This memo introduces a new authorization scheme for SMTP e-mail + transport. It is designed to be a simple and robust protection + against e-mail fraud, spam and worms. It is based solely on + organisational security mechanisms and does not require but still + allow use of cryptography. This memo also focuses on security and + privacy problems and requirements in context of spam defense. In + contrast to prior versions of the draft a new RR type is not + required anymore. + + + + + + + + + + + + +Hadmut Danisch Experimental [Page 1] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + Table of Contents + + +1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 +2. Problem and threat description . . . . . . . . . . . . . . . . . 4 + 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4 + 2.1.1 Definition of sender forgery . . . . . . . . . . . 4 + 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5 + 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5 + 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6 + 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6 + 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7 +3. A DNS based sender address verification . . . . . . . . . . . . 7 + 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9 + 3.3. Domain part vs. full sender address . . . . . . . . . . . 9 +4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10 + 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10 + 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11 +5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11 + 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11 + 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12 + 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13 + 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14 + 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14 + 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15 + 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15 + 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16 +6. Optional and experimental entry types . . . . . . . . . . . . . 16 + 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16 + 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16 + 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17 + 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17 +7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17 + 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18 + 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18 + 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18 + 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18 + 7.2.5 Encoding of unused and full query . . . . . . . . . 19 + 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19 +8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19 + + + +Hadmut Danisch Experimental [Page 2] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20 +10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20 + 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20 + 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21 + 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21 +11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 + 11.1. Draft specific considerations . . . . . . . . . . . . . . 22 + 11.1.1 Authentication strength . . . . . . . . . . . . . 22 + 11.1.2 Where Authentication and Authorization end . . . . 22 + 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23 + 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25 + 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25 + 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25 + 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26 + 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26 + 11.2. General Considerations about spam defense . . . . . . . . 27 + 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27 + 11.2.2 Content based Denial of Service attacks . . . . . 27 +12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 + 12.1. Draft specific considerations . . . . . . . . . . . . . . 28 + 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28 + 12.1.2 Message reception and sender domain . . . . . . . 28 + 12.1.3 Network structure . . . . . . . . . . . . . . . . 29 + 12.1.4 Owner information distribution . . . . . . . . . . 29 + 12.2. General Considerations about spam defense . . . . . . . . 29 + 12.2.1 Content leaking of content filters . . . . . . . . 29 + 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30 +13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30 + 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30 + 13.1.1 Compatibility with old mail receivers . . . . . . 30 + 13.1.2 Compatibility with old mail senders . . . . . . . 30 + 13.1.3 Compatibility with old DNS clients . . . . . . . . 30 + 13.1.4 Compatibility with old DNS servers . . . . . . . . 30 + 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31 +14. General considerations about fighting spam . . . . . . . . . . 31 + 14.1. The economical problem . . . . . . . . . . . . . . . . . 31 + 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32 + 14.3. The network structure problem . . . . . . . . . . . . . . 33 + 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33 + 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33 + 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34 +Implementation and further Information . . . . . . . . . . . . . . . 34 +References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 +Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 +Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + + + + + + +Hadmut Danisch Experimental [Page 3] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +1. General Issues + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC 2119 [1]. + +2. Problem and threat description + +2.1. Mail sender forgery + + The amount of e-mails with forged sender addresses has dramatically + increased. As a consequence, damages and annoyances caused by such + e-mails increased as well. In the majority of examined e-mails the + domain name of the envelope sender address was forged, and the e- + mail was sent from an IP address which does not belong to a network + used by the actual owner of the domain. + +2.1.1. Definition of sender forgery + + As discussions, comments to prior versions of this draft, and + different approaches to stop forgery showed, different perceptions + of "mail forgery" exist. For example, there are mechanisms to + verify e-mail addresses for mailing lists, web servers, or to stop + spam, which do send a message with a random number to the given + address and expect the user to send a reply. Here, someone is + considered to be allowed to use a particular e-mail address, if and + only if he is able to receive informations sent to this address, + and is able to reply to such a message. While this definition + appears to be quite plausible and natural, it can't be used for a + simple technical solution. Sending back a challenge and expecting a + reply is simply too much overhead and time delay, and not every + authorized sender is able or willing to reply (e.g. because he went + offline or is not a human). + + Within the scope of this memo, sender forgery means that the + initiator of an e-mail transfer (which is the original sender in + contrast to relays) uses a sender address which he was not + authorized to use. Being authorized to use an address means that + the owner (administrator) of the internet domain has given + permission, i.e. agrees with the use of the address by that + particular sender. This memo will cover both the permission of the + full e-mail address and the domain part only for simplicity. + + Within context of Internet and SMTP, the sender address usually + occurs twice, once as the envelope sender address in SMTP, and once + as the address given in the RFC822 mail header. While the following + considerations apply to both addresses in principle, it is + important to stress that both addresses have distinct semantics and + + + +Hadmut Danisch Experimental [Page 4] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + are not neccessarily the same. The envelope address identifies the + initiator of the transport, while the header identifies the author + of the message content. Since this memo deals with the message + transport only and completely ignores the message content, the + method should naturally be applied to the envelope sender address. + +2.1.2. Spam + + A common and well known problem is the dramatic increase of + unsolicited e-mail, commonly called "spam". Again, the majority of + examined e-mails had forged sender addresses. The abused domains + were mainly those of common webmailers as hotmail or yahoo, or + well-known companies. + + Unfortunately, there is no accurate definition of spam availabe + yet, and neither are the concise technical criterions to filter or + block spam with technical mechanisms. There are efforts to design + content based filters, but these filters are expensive in + calculation time (and sometimes money), and they do not reliably + provide predictable results. Usually they give false positives + and/or require user interaction. Content filters in general suffer + from a design problem described later in this memo. Therefore, + this proposal does not use the content based approach to block + spam. + + As analysis of spam messages showed, most of spam messages were + sent with forged envelope sender addresses. This has mainly three + reasons. The first reason is, that spam senders usually do not + want to be contacted by e-mail. The second reason is, that they do + not want to be blacklisted easily. The third reason is, that spam + is or is going to be unlawful in many countries, and the sender + does not want to reveal his identity. Therefore, spam is considered + to be a special case of sender forgery. + +2.1.3. E-Mail Worms + + Another example of sender forgery is the reproduction of e-mail + worms. Most worms do choose random sender addresses, e.g. using + the addresses found in mailboxes on the infected system. In most + cases analyzed by the author, the e-mails sent by the reproduction + process can also be categorized as forged, since the infected + system would under normal circumstances not be authorized to send + e-mails with such e-mail addresses. So forgery does not require a + malicious human to be directly involved. This memo covers any kind + of e-mail sender address forgery, included those generated by + malicious software. + +2.1.4. E-Mail spoofing and fraud + + + +Hadmut Danisch Experimental [Page 5] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + Forging e-mail sender addresses for fraud or other kinds of + deception ("human engineering") has also dramatically increased. + There are many known cases where single or mass e-mails were sent + with wrong sender addresses, pretending to come from service + provider, software manufacturers etc., and asking the receiver to + install any software or patches, or to reply with any confidential + information. The Internet is becoming more and more a scene of + crime, and so are it's services, including e-mail. It is obvious + that crime based on e-mail is eased by the fact that SMTP allows + arbitrary sender address spoofing. + +2.2. Indirect damage caused by forgery + + As observed by the author, mass mails and worms with forged sender + addresses can cause a severe damage for the real owner of the + abused sender addresses. If a sender A is sending an e-mail to the + receiver B, pretending to be C by using a sender address of C's + domain, then C has currently no chance to prevent this, since C's + machines and software are not involved in any way in the delivery + process between A and B. B will nevertheless send any error + messages (virus/spam alert, "no such user", etc.) to C, erroneously + assuming that the message was sent by C. The author found several + cases where this flood of error messages caused a severe denial of + service or a dramatic increase of costs, e.g. when C was + downloading the e-mail through expensive or low bandwidth + connections (e.g. modem or mobile phones), or where disk space was + limited. The author examined mass mailings, where several tens or + hundreds of thousands of messages were sent to several addresses + around the world, where these messages caused only annoyance. But + since several thousands of these addresses were invalid or didn't + accept the message, the owner of the DNS domain which was abused by + the spammer to forge sender addresses was flooded for several + months with thousands of error messages, jamming the e-mail system + and causing severe costs and damages. + + As a consequence, when A sends a message to B, pretending to be C, + there must be any mechanism to allow C to inform B about the fact, + that A is not authorized to use C as a sender address. This is what + this memo is about. + +2.3. Technical problem analysis + + Why does e-mail forgery actually exist? Because of the lack of the + Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender + authentication, authorisation, or verification. This protocol was + designed at a time where security was not an issue. Efforts have + been made to block forged e-mails by requiring the sender address + domain part to be resolvable. This method provides protection from + + + +Hadmut Danisch Experimental [Page 6] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + e-mails with non-existing sender domains, and indeed, for some time + it blocked most spam e-mails. However, since attackers and spam + senders began to abuse existing domain names, this method was + rendered ineffective. + +2.4. Shortcomings of cryptographical approaches + + At a first glance, the problem of sender address forgery might + appear to be solvable with cryptographic methods such as challenge + response authentications or digital signatures. A deeper analysis + shows that only a small, closed user group could be covered with + cryptographical methods. Any method used to stop spam forgery must + be suitable to detect forgery not only for a small number of + particular addresses, but for all addresses on the world. An + attacker does not need to know the secrets belonging to a + particular address. It is sufficient to be able to forge any + address and thus to know any secret key. Since there are several + hundreds of millions of users, there will always be a large amount + of compromised keys, thus spoiling any common cryptographic method. + Furthermore, cryptography has proven to be far too complicated and + error prone to be commonly administered and reliably implemented. + Many e-mail and DNS administrators do not have the knowledge + required to deal with cryptographic mechanisms. Many legislations + do not allow the general deployment of cryptography and a directory + service with public keys. For these reasons, cryptography is + applicable only to a small and closed group of users, but not to + all participants of the e-mail service. + +3. A DNS based sender address verification + +3.1. Overview + + To gain improvement in e-mail authenticity while keeping as much + SMTP compatibility as possible, a method is suggested which doesn't + change SMTP at all. + + The idea is to store informations about how to verify who is + authorized to transmit e-mails through SMTP with a particular + sender address (either full address or - for simplicity - only the + domain part of the address) in a directory service, which is + currently the DNS. To be precise, the verification consists of two + steps, the classical pair of authentication and authorization: + + The first step is the authentication. While several methods are + possible to perform authentication (see below), the most important + and robust method is the verification of the sender's IP address. + This is done implicitely by TCP/IP and the TCP sequence number. The + authenticated identity is the IP address. It has to be stressed + + + +Hadmut Danisch Experimental [Page 7] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + that this TCP/IP "authentication" is a weak authentication and + vulnerable to several attacks. It is nevertheless sufficient for + this purpose, especially for blocking spam. It doesn't take any + implementation and it doesn't cost: It is already there, it is a + functionality of TCP/IP. An incoming SMTP connection based on + TCP/IP already carries the sender's IP address without any + modification of SMTP. See below (section Entry types) for more + details about authentication methods. + + The second step is the authorization. It is based on the identity + given by the previous authentication step, e.g. the IP address of + the originator of the incoming SMTP connection, and on the + envelope sender address. The mechanism proposed in this memo + answers the question "Is that particular sender (IP address,...) + allowed to send with that sender address" by querying and + processing informations stored in a directory service, which is + DNS. + + When the sender has issued the "MAIL FROM:" SMTP command, the + receiving mail transfer agent (MTA) can - and modern MTAs do - + perform some authorization checks, e.g. run a local rule database + or check whether the sender domain is resolvable. + + The suggested method is to let the DNS server for the sender domain + provide informations about who - this means for example which IP + address - is authorized to use an address or a domain as a part of + it. After receiving the "MAIL FROM:" SMTP command, the receiving + MTA can verify, whether e. g. the IP address of the sending MTA is + authorized to send mails with this domain name. Therefore, a list + of entries with authorized IP addresses or other informations is + provided by the authoritative DNS server of that domain. The entry + types are described in the subsequent chapters. Some of these + methods are + + - An IPv4 or IPv6 network address and mask + - A fully qualified domain name referring to an A record + - A fully qualified domain name referring to an APL record + + RMX records of these types would look like this: + + somedomain.de. IN RMX ipv4:10.0.0.0/8 + rmxtest.de. IN RMX host:relay.provider.com + danisch.de. IN RMX apl:relays.rackland.de + relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24 + + where the machine with the example address 213.133.101.23 and the + machines in the example subnet 1.2.3.0/24 are the only machines + allowed to send e-mails with an envelope sender address of domain + + + +Hadmut Danisch Experimental [Page 8] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + danisch.de. Since the APL records do not necessarily belong to the + same domain or zone table as the RMX records, this easily allows to + refer to APL records defined by someone else, e.g. the internet + access or server hosting provider, thus reducing administrative + overhead to a minimum. In the example given above, the domain + danisch.de and several other domains are hosted by the service + provider Rackland. So if the relay structure of Rackland is + modified, only the zone of rackland.de needs to be modified. The + domain owners don't need to care about such details. + +3.2. Envelope vs. header sender address + + Questions were raised why the proposed mechanism is based on the + envelope sender address, and not on the sender address given in the + message header. Technically, both can be used. Actually, it makes + sense to use the envelope address. + + In common, the header sender address identifies the author of the + content, while the envelope sender tells who caused the + transmission. The approach proposed in this memo is transmission + based, not content based. We can not authorize the author of a + message if we don't have contact with him, if the message does not + already contain a signature. In contrast, the sending MTA is linked + to an IP address which can be used for authentication. This + mechanism might not be very strong, but it is available and + sufficient to solve today's e-mail security problems. + + Some people argued that it is the header address and not the sender + address, which is displayed in common mail readers (MUAs), and + where the receiver believes the mail comes from. That's true, but + it doesn't help. There are many cases where the header sender + differs from the envelope sender for good reasons (see below in the + consequences chapter for the discussion about relaying). Relaying, + mailing lists etc. require to replace the sender address used for + RMX. If this were the header address, the message header would have + to be modified. This is undesirable. + +3.3. Domain part vs. full sender address + + Former versions of this draft were limited to the domain part of + the sender address. The first reason is that it is common and MX- + like, to lookup only the domain part of an e-mail address in DNS. + The second reason is, that it was left to the private business of + the domain administration to handle details of user verification. + The idea was that the domain administration takes care to verify + the left part of an e-mail address with an arbitrary method of + their individual taste. RMX was originally designed to ignore the + left part of the address and to expect the domain administration to + + + +Hadmut Danisch Experimental [Page 9] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + take over responsibility for enforcing their policy. If, e.g., a + spam message arrived and passed the RMX mechanism, it is known to + be authorized by the domain administration and they can be blamed, + no matter what is on the left side of the sender address - it's + their private problem what happens on the left side of the @. By + far the most of the comments to prior versions of this draft agreed + with that. A few comments asked for a finer granularity. + + And indeed, there is no technical reason against a finer + granularity. All it takes is a mapping from a given envelope + sender address to a DNS name, and the RMX lookup for that + particular e-mail address could be done instead of a lookup for the + domain part only. However, to my knowledge, most domain + administrators would not like to provide an RMX entry for every + single e-mail address. In many cases, this would also overload DNS + servers. + + It is to be discussed how to cover both views. One method could be + to query the full address, and if no RMX records were found to + query the domain part only. A different approach would be to query + the domain part only, and if it's RMX record contain a special + entry, then a new query for the full address is triggered. A third + way would be to always query the full address and to leave the + problem to the wildcard mechanism of DNS. This still has to be + discussed and will be described in future versions of this draft. + + + + + + + + + + + +4. Mapping of E-Mail addresses to DNS names + + To perform the RMX query, a mapping is needed from E-Mail addresses + to DNS fully qualified domain names. + + This chapter is under development and just a first approach. + +4.1. Domain part only + + Mapping of the domain part is trivial, since the domain part of an + e-mail address itself is a valid DNS name and does not need + translation. It might be nevertheless desirable to distinguish the + + + +Hadmut Danisch Experimental [Page 10] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + RMX entries from other entries, depending of the encoding of the + records. If the RMX entries are encoded in TXT record types, they + might collide with other uses of TXT records. It might be + necessary to prepend the domain part with a special prefix, e.g. + _rmx. So the e-mail address some.user@example.com could be mapped + to example.com or _rmx.example.com. + +4.2. Full address + + Mapping a full address is slightly more difficult. The @ sign must + be unambiguously translated, and therefore can not be simply + translated into a dot. The e-mail addresses some.user@example.com + and some@user.example.com must have different mappings. Therefore, + the @ sign could be translated into _rmx, implicitely assuming that + this is not an allowed domain name component of normal domain + names. Then the rightmost _rmx in the mapped DNS name always + corresponds to the @ sign. some.user@example.com would e translated + into some.user._rmx.example.com and can be covered by a wildcard + entry like *._rmx.example.com. + + Character encoding and character sets are still to be discussed. + +4.3. Empty address + + Unfortunately, SMTP allows empty envelope sender addresses to be + used for error messages. Empty sender addresses can therefore not + be prohibited. As observed, a significant amount of spam was sent + with such an empty sender address. To solve this problem, the host + name given in the HELO or EHLO command is taken to lookup the RMX + records instead. This makes sense, since such messages were + generated by the machine, not a human. + + + + +5. Mandatory entry types and their syntax + + The entry types described in this section MUST be supported by any + implementation of this draft. + +5.1. Overall structure + + Similar to APL, an RMX record is just a concatenation of zero or + more RMX entries. The entries within one record form an ordered + rule base as commonly usual in packet filtes and firewall rulesets, + i. e. they are processed one ofter another until the first entry + matches. This entry determines the result of the query. Once a + matching entry is found, the RMX processing is finished. + + + +Hadmut Danisch Experimental [Page 11] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + For any domain name there should not exist more than a single RMX + record. Due to the structure of DNS, it is nevertheless possible to + have more than a single RMX record. Multiple RMX records are + treated as a single record consisting of the concatenation of all + records. While the entries in a record are ordered, the records are + not ordered and may be processed in arbitrary order. If the order + of the entries matters, it is the zone maintainer's responsibility + to keep those entries in a single record. For example, there are + negative entries, which exclude IP addresses from authorization. + It is important that these entries are processed before positive + entries giving permission to a wider address range. Since order is + guaranteed only within a record, corresponding negative and + positive entries must be put in the same record. + + An RMX record may consist of one or more entries, where the entries + are separated by whitespace. An entry must not contain white space. + Each entry consists of an optional exclamation sign, a tag, a + colon, and the entry data: + + [!] TAG : ENTRY-SPECIFIC-DATA + + If the entry starts with an exclamation sign, the entry is negated. + See the entry type description below for details. + + The TAG is the mnemonic type identifier or the decimal number of + the entry. The TAG is case-insensitive. It is immediately followed + by a colon. + + The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the + entry type. See description below. + + Example: + + danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5 + ipv4:1.2.3.0/24 + +5.2. Unused + + This is a primitive entry which just says that this sender address + will never be used as a sender address under any circumstances. + Example: + + testdomain.danisch.de IN RMX unused: + +5.3. IPv4 and IPv6 address ranges + + These entry types contain a bit sequence representing a CIDR + address part. If that bit sequence matches the given IP address, + + + +Hadmut Danisch Experimental [Page 12] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + authorization is granted or denied, depending on the negation flag. + + The entry is prepended with the tag "IPv4" or "IPv6". The colon is + followed with an IPv4 or IPv6 address in standard notation, + optionally followed by a slash and a mask length. If the negation + flag is set, then the given address range is excluded. Examples: + + danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0 + IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16 + IN RMX !ipv4:1.2.3.4 + + (Please note that it does not make much sense to use + RFC1918-Addresses in RMX records, this is just to give a syntax + example.) + + +5.4. DNS Hostname + + This entry type simply contains a regular DNS name, which is to be + resolved as a host name (fetch the A record or IPv6 equivalent). If + the given IP address matches the result, authorization is granted + or denied, depending on the negation flag. It is still to be + defined how to treat unresolvable entries. + + The entry is prepended with the tag "host", followed by a colon and + the hostname. Examples: + + danisch.de IN RMX host:relay.provider.de + IN RMX !host:badmachine.domain.de apl:relays.domain.de + +5.4.1. Road warriors and DynDNS entries + + Several people argued against RMX that it would break their + existing installation which delivers e-mail from dynamically + assigned IP addresses, because their IP providers didn't assign a + static address, or because they are a road warrior, plugging their + notebook in any hotel room on the world. + + RMX provides a simple solution. If such a machine has a dynamically + updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of + the hostname type pointing to this dynamic DNS entry. + + The cleaner solution would be to deliver mail the same way as it is + received: If downloaded by POP from a central relay with a static + address, where the MX points to, then it would be a good idea to + deliver e-mail the same way in reverse direction. Unfortunately, + plain POP does not support uploading yet. + + + + +Hadmut Danisch Experimental [Page 13] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +5.5. APL Reference + + This entry type simply contains a regular DNS name, which is to be + resolved as an APL record index (fetch the APL record). If the + given IP address positively matches the APL, authorization is + granted. Details of the semantic (espially when the negation bit is + set) are still to be defined. It is still to be defined how to + treat unresolvable entries. + + The entry is prepended with the tag "host", followed by a colon and + the hostname. Example: + + danisch.de IN RMX apl:relays.rackland.de + +5.6. Domain Member + + In many cases it is desirable to cover all hosts of a given domain + with an RMX record without the need to duplicate the list of these + hosts. This entry type does it (thanks to Eric A. Hall for pointing + out this entry type). It contains a regular DNS name. + + If this entry type is given, a reverse DNS query for the IP address + of the sending MTA is performed to find its official fully + qualified domain name. To prevent spoofing, this domain name is + accepted only if a subsequent address query to the given domain + name points to exactly the IP address of the sending MTA (the usual + procedure to verify PTR records). + + The entry matches if the fully qualified domain name of the sending + MTA ends in the given domain. The negation flag works as usual. + + The tag for this entry type is "domain". After the colon the domain + name is given, but might be empty, thus pointing to itself. + Example: + + somedomain.org IN RMX domain:somedomain.org domain:provider.com + + would authorize all machines which's hostname can be verified + through an PTR and A query, and which ends in "somedomain.org" or + "provider.com". + + With such an entry, large companies with different networks can + easily be covered with just a single and simple RMX entry. + Obviously, it requires proper PTR records. + + As a special shortcut, the DNS name may be empty. In this case the + domain name of the zone itself is taken. Thus, with a very simple + entry of the type + + + +Hadmut Danisch Experimental [Page 14] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + somecompany.com IN RMX domain: + + a company could authorize all machines which's IP addresses map to + DNS names end in somecompany.com, which applies in the majority of + companies. + + + + +5.7. Full Address Query + + As described above, RMX records will in most cases apply to the + domain part of the sender address. In special cases it might be + desirable to query the RMX record for a particular address. An RMX + entry of the Full Address Query type may occur in a domain RMX + record only. It signals that the RMX record for the full address is + to be fetched and processed. + + This entry type does not take arguments. The negation flag is not + supported. The tag is "full". + + If such a full address query is to be performed, the mail address + must be mapped to a valid and non-ambiguos DNS name. This mapping + is still to be defined. It is not sufficient to simply replace the + @ with a dot, because of case sensitivity, character sets, etc. The + e-mail addresses + + john.doe@example.org + John.Doe@example.org + john@doe.example.org + + must all be mapped to different DNS entries. This entry type might + vanish in future versions of the draft, depending on the discussion + about whether to query the domain name part only or the full + address. + +5.8. DNS mapped authorization + + As I learned from comments to prior versions of the draft and from + alternative proposals, many users wish to have a DNS mapped + authorization table, i. e. the client queries a DNS entry of the + form a.b.c.d.domain, where a.b.c.d is the sender's IP address. + Since people wish to have this, RMX will now include such a mapping + entry. The entry has a parameter giving the DNS domain name where + to look at. If the parameter is empty, then the same domain is + taken as for the RMX lookup. + + As this is currently under construction and discussion in an IETF + + + +Hadmut Danisch Experimental [Page 15] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + group, details will be published in future versions of this draft. + +5.9. RMX reference + + This entry type has no parameters. It means that all those machines + are authorized, which are pointed to by an MX record. + +6. Optional and experimental entry types + + The following subsections roughly describe further entry types + which might not be supported by all implementations and might not + be allowed in all legislations. These methods might vanish in + future versions of the draft and are just considerations about what + to include in RMX and what to not include. The main purpose of this + section is to start discussion about such entry types. + + The disadvantage of the following methods is that they violate the + basic idea of RMX, i. e. to be simple, robust, easy to implement + and easy to administer. I personally do not believe that it is a + good idea or even feasible to implement cryptography for a world + wide e-mail transfer network. Keep in mind that cryptographic keys + can be copied. If only <0.1% of cryptographic keys were revealed, + this completely compromises and spoils RMX. Cryptography is simply + the wrong tool for the problem RMX is intended to solve. I + nevertheless like to discuss these methods. + +6.1. TLS fingerprint + + The sender is considered to be authorized if the message was + transmitted through SMTP and TLS, and the sender used a certificate + matching the fingerprint given in the RMX record. + +6.2. TLS and LDAP + + This means that the receiver should perform an LDAP query for the + sender address (through the LDAP SRV record or given in the RMX + record), fetch the X.509 certificate for the sender. The sender is + considered to be authorized when the message was transmitted + through SMTP and TLS using this certificate. + +6.3. PGP or S/MIME signature + + It would be possible to accept a message only if it was signed with + PGP or S/MIME with a key which's fingerprint is given in the RMX + record or to be fetched from LDAP or any PGP database. This is + just for discussion, since it violates the idea of RMX to focus on + the transport, not on the content. It would also allow replay + attacks and not cover the envelope sender address or message + + + +Hadmut Danisch Experimental [Page 16] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + header. + +6.4. Transparent Challenge/Response + + It would also be possible to implement a challenge-response + mechanism without modifying the syntax of SMTP. For example, the + receiving MTA could issue a challenge with it's very first greeting + message, the sending MTA could hide the response in the HELO + parameter and when the receiving MTA later learns the sender + envelope address, it could verify the response based on + informations in the RMX record. + +6.5. SASL Challenge/Response + + Modern SMTP implementations already include a SASL mechanisms, + which easily allows to plugin new authentication mechanisms. While + common SASL mechanisms require to use a previously shared password, + a new mechanism could perform a challenge response authentication + as a SASL method. + + + + + + +7. Encoding + +7.1. Alternative encoding as TXT records + + The main objection against the prior versions of this draft was + that it requires a new RR entry type and upgrading all DNS servers. + + Therefore and alternative encoding is proposed. Instead of using a + new RR type, the TXT record type is used to contain the RMX record. + The records would simply look as described in the entry type + chapters above, e.g. + + _rmx.danisch.de. IN TXT "apl:relays.rackland.de" + + To allow smooth introduction of RMX without the need to immediately + upgrade all DNS servers, all clients (which have to be newly + installed anyway) MUST support both the TXT and the RMX records. A + client has to perform an ANY or a TXT and a RMX query. Servers/zone + tables may currently use TXT entries but SHOULD use RMX entries in + future. + +7.2. RMX Records + + + + +Hadmut Danisch Experimental [Page 17] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +7.2.1. Overall structure + + Each entry starts with an octet containting the entry type and the + negation flag: + + +---+---+---+---+---+---+---+---+------ + | N | Entry Type Code | Parameters... + +---+---+---+---+---+---+---+---+------ + + N If this bit (MSB) is set, an IP address + matching this entry is not authorized, + but explicitely rejected. See entry + type descriptions for details. + + Entry Type A 7bit number simply determining the entry + type. + + + Currently, entries do not have an explicit length field, the entry + length is determined implicitely by the entry type. Applications + are required to abort if an unknown entry type is found, instead of + skipping unknown entries. + +7.2.2. Record encoding + + A RMX record is simply a concatenation of RMX entries. + +7.2.3. Encoding of IPv4 and IPv6 address ranges + + After the entry type tag as described above, one octet follows + giving the length L of the bit sequence. Then a sequence of exactly + as many octets follows as needed to carry L bits of information (= + trunc((L+7)/8) ). + + +---+---+---+---+---+---+---+---+ + | N | Entry Type Code (1 or 2) | + +---+---+---+---+---+---+---+---+ + | Length Field L | + +---+---+---+---+---+---+---+---+ + | Bit Field | + / ((L+7)/8) Octets / + +---+---+---+---+---+---+---+---+ + + +7.2.4. Encoding of DNS + + After the entry type tag immediately follows a DNS encoded and + compressed [3] domain name. + + + +Hadmut Danisch Experimental [Page 18] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + +---+---+---+---+---+---+---+---+ + | N | Entry Type Code (3..5) | + +---+---+---+---+---+---+---+---+ + | Length Field L | + +---+---+---+---+---+---+---+---+ + | Encoded DNS | + / Name as described in RFC1035 / + +---+---+---+---+---+---+---+---+ + + In contrast to earlier versions of this draft, the DNS name cannot + be compressed, since this would cause decompression errors when a + DNS server is part of the query chain which does not know this + particular RR type. + +7.2.5. Encoding of unused and full query + + These entries do not contain parameters and does not allow the + negation flag. So the encoding is quite simple: + + +---+---+---+---+---+---+---+---+ + | 0 | Entry Type Code (6 or 7)| + +---+---+---+---+---+---+---+---+ + + + +7.2.6. Additional Records + + In order to avoid the need of a second query to resolve the given + host name, a DNS server should enclose the A record for that domain + name in the additional section of the additional section of the DNS + reply, if the server happens to be authoritative. + + In order to avoid the need of a second query to resolve the given + host name, a DNS server should enclose the APL record for that + domain name in the additional section of the additional section of + the DNS reply, if the server happens to be authoritative. + + + +8. Message Headers + + An RMX query must be followed by any kind of action depending on + the RMX result. One action might be to reject the message. Another + action might be to add a header line to the message body, thus + allowing MUAs and delivery programs to filter or sort messages. + + In future, the RMX result might be melted into the Received: header + line. + + + +Hadmut Danisch Experimental [Page 19] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + The details of such entries are to be discussed. As a proposal the + following form is suggested: + + X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM + + where + + RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX", + "TempFail", "BadData", "Trusted". + + ADDRESS is the IP address of the sending machine + + HOST is the name of the machine performing the RMX query. + + DATE is the date of the query. + + MECHANISM is the RMX method used to authorize the sender. + + + +9. SMTP error messages + + If a message is rejected because of RMX records, an error message + should be issued which explains the details. It is to be discussed + whether new SMTP error codes are to be defined. + + +10. Message relaying and forwarding + +10.1. Problem description + + Message forwarding and relaying means that an MTA which received an + e-mail by SMTP does not deliver it locally, but resends the message + - usually unchanged except for an additional Received header line + and maybe the recipient's address rewritten - to the next SMTP MTA. + Message forwarding is an essential functionality of e-mail + transport services, for example: + + - Message transport from outer MX relay to the intranet + - Message forwarding and Cc-ing by .forward or .procmail-alike + mechanisms + - Mailing list processing + - Message reception by mail relays with low MX priority, + usually provided by third parties as a stand-by service + in case of relay failure or maintenance + - "Forwarding" and "Bouncing" as a MUA functionality + + In all these cases a message is sent by SMTP from a host which is + + + +Hadmut Danisch Experimental [Page 20] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + not covered by the original sender domain's RMX records. While the + RMX records would forbid accepting this message, it still must be + accepted. The following subsections explain how to cope with + relaying. + +10.2. Trusted relaying/forwarding + + In some cases the receiving MTA trusts the sending MTA to not fake + messages and to already have checked the RMX records at message + reception. As a typical example, a company might have an outer mail + relay which receives messages from the Internet and checks the RMX + records. This relay then forwards the messages to the different + department's mail servers. It does not make sense for these + department mail servers to check the RMX record, since the RMX + records have already been checked and - since the message was + relayed by the outer relay - always would deny the message. In this + case there is a trust relationship between the department relays + and the outer relay. So RMX checking is turned off for trusted + relays. In this example, the department relays would not check + messages from the outer relay (but for intranet security, they + could still check RMX records of the other departments sub-domains + to avoid internal forgery between departments). + + Another common example are the low-priority MX relays, which + receive and cache e-mails when the high-priority relays are down. + In this case, the high-priority relay would trust the low-priority + relay to have verified the sender authorization and would not + perform another RMX verification (which would obviously fail). + + When a relay forwards a message to a trusting machine, the envelope + sender address should remain unchanged. + +10.3. Untrusted relaying/forwarding + + If the receiving MTA does not trust the forwarding MTA, then there + is no chance to leave the sender envelope address unchanged. At a + first glance this might appear impracticable, but this is + absolutely necessary. If an untrusted MTA could claim to have + forwarded a message from a foreign sender address, it could have + forged the message as well. Spammers and forgers would just have to + act as such a relay. + + Therefore, it is required that, when performing untrusted + forwarding, the envelope sender address has to be replaced by the + sender address of someone responsible for the relaying mechanism, + e.g. the owner of the mailing list or the mail address of the user + who's .forward caused the transmission. It is important to stress + that untrusted relaying/forwarding means taking over responsibility + + + +Hadmut Danisch Experimental [Page 21] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + for the message. It is the idea of RMX records to tie + responsibility to message transmission. Untrusted relaying without + replacing the sender address would mean to transmit without taking + responsibility. + + The disadvantage is that the original sender address is lost. + Therefore, whenever a sender address replacement happens, the + Received-Line must contain the old address. Many of today's MTAs + already insert the envelope recipient address, but not the sender + address into the Received header line. It seems reasonable to + require every Received line to include both the sender and + recipient address of the incoming SMTP connection. + + +11. Security Considerations + +11.1. Draft specific considerations + +11.1.1. Authentication strength + + It is important to stress, that the suggested method does not + provide high level security and does not completely prevent forged + e-mails or spam under any circumstances. It is a robust, but not + highly reliable and completely secure security mechanism. Keep in + mind that it is based on DNS, and DNS is not secure today. + Authorization is based on the IP address. The very same machine + with the very same IP address could be authorized to send e-mail + with a given sender address and sending spam at the same time. + Maybe because several users are logged in. Or because several + customers use the same relay of the same ISP, where one customer + could use the sender address of a different customer. It is up to + the ISP to prevent this or not. Machines can still be hijacked. + Spammers are also domain owners. They can simply use their own + domain and authorize themselves. You will always find people on the + world who do not care about security and open their relays and RMX + records for others to abuse them. RMX is to be considered as a + very cheap and simple light weight mechanism, which can + nevertheless provide a significant improvement in mail security + against a certain class of attacks, until a successor of SMTP has + been defined and commonly accepted. + +11.1.2. Where Authentication and Authorization end + + Previous versions of RMX records did not cover the local part of + the e-mail address, i.e. what's on the left side of the @ sign. + This is still to be discussed. Authentication and authorization are + limited to the sending MTA's IP address. The authentication is + limited to the TCP functionality, which is sufficient for light + + + +Hadmut Danisch Experimental [Page 22] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + weight authentication. The RMX records authorize the IP address of + the sending host only, not the particular sender of the message. So + if a machine is authorized to use sender addresses of more than a + single domain, the authentication scheme does not prevent that any + user on this machine can send with any of these domains. RMX is not + a substitute for the host security of the involved machines. + + The proposed authentication scheme can be seen as a "half way + authentication": It does not track back an e-mail to the effective + sender. It tracks only half of the way, i. e. it tracks back to the + domain and it's DNS administrators who authorized that particular + sender IP address to use it for sending e-mail. How the party + responsible for that domain performs user authentication, whom it + grants access to, how it helds people responsible for abuse, is + completely left as the private business of those who are in charge + of that domain. So this draft does not interfere with the domain's + individual security policy or any legislation about such policies. + On the other hand, the proposed authentication scheme does not give + any statement about the nature and quality of the domain's security + policy. This is an essential feature of the proposal: E-mail + authentication must be deployed world wide, otherwise it won't do + the job. Any security scheme interfering with the local + legislations or the domain's security policy will not be accepted + and can't effectively deployed. Therefore, the security policy must + remain the domain's private business, no matter how lousy the + policy might be. + + In order to achieve this and to make use of the only existing world + wide Internet directory scheme (DNS), the approach of this proposal + is to just ignore the local part of the sender address (i.e. what's + left of the @ part) and limit view to the domain part. After all, + that's what we do anyway when delivering to a given address with + SMTP. + +11.1.3. Vulnerability of DNS + + DNS is an essential part of the proposed authentication scheme, + since it requires any directory service, and DNS is currently the + only one available. Unfortunately, DNS is vulnerable and can be + spoofed and poisoned. This flaw is commonly known and weakens many + network services, but for reasons beyond that draft DNS has not + been significantly improved yet. After the first version of this + draft, I received several comments who asked me not to use DNS + because of its lack of security. I took this into consideration, + but came to the conclusion that this is unfeasible: Any + authentication scheme linked to some kind of symbolic identity (in + this case the domain name) needs some kind of infrastructure and + trusted assignment. There are basically two ways to do it: Do it + + + +Hadmut Danisch Experimental [Page 23] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + yourself and trust nobody else, or let someone else do it. There + are methods to do it the former way, e.g. to give someone some kind + of authentication information after a first successful e-mail + exchange, e.g. some kind of cookie or special e-mail address. This + is certainly interesting and powerful, but it does not solve the + problem on a world wide scale and is far to complicated and error + prone for the average user, i. e. 99% of the users. + + The latter method to let someone else do the symbolic name + assignment and create the authentication framework is well known. + It context of public key cryptography, this is called a Public Key + Infrastructure (PKI). On of the best known facts about PKIs is + that, until now, we don't have any covering a significant part of + the Internet. And we won't have any in near future. The complexity + is far too high, it is too expensive, and it involves cooperation + of every single user, which is simply unrealistic and extremely + error prone. So what do we have we can use? All we have is the DNS + and the Whois database. And we have countries who don't allow + cryptography. So the proposal was designed to use DNS without + cryptography. It does not avoid DNS because of its vulnerability, + it asks for a better DNS, but accepts the DNS as it is for the + moment. Currently there are two main threats caused by the DNS + weakness: + + - A spammer/forger could spoof DNS in order to gain false + authorization to send fake e-mails. + + - An attacker could spoof DNS in order to block delivery from + authorized machines, i. e. perform a Denial of Service attack. + + The first one is rather unrealistic, because it would require an + average spammer to poison a significant part of the DNS servers of + its victims. A spammer sending messages to one million receipients + would need to poison at least 1-10% which is 10,000 to 100,000 + receipient's DNS servers. This should be unfeasible in most cases. + + In contrast, the second threat is a severe one. If an attacker + wanted to block messages from one company to another, he just needs + to poison the recipients DNS server with a wrong RMX record in + order to make the recipient's SMTP machine reject all messages. And + this is feasible since the attacker needs to poison only a single + DNS server. But does this make SMTP more vulnerable? No. Because + the attacker can already do even more without RMX. By poisoning the + sender's DNS server with wrong MX records, the attacker can also + block message delivery or even redirect the messages to the + attacker's machine, thus preventing any delivery error messages and + furthermore getting access to the messages. + + + + +Hadmut Danisch Experimental [Page 24] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + As a consequence, e-mail delivery by SMTP requires a better DNS + anyway. The requirements are not significantly expanded by RMX. + +11.1.4. Sneaking RMX attack? + + While writing a test implementation, a certain kind of attack came + into my mind. I'm still not sure, whether this attack is possible + on any DNS server, but I believe it should be mentioned: + + Imagine an unauthorized sender is sending a forged mail (e.g. + spam). At connection time, before querying the RMX record, the + receiving MTA usually performs a PTR query for the IP address of + the sending MTA. If the sender has control over the authoritative + name server for that particular IP address, the sender could give a + normal PTR answer, but could append a wrong RMX, APL, or A record + in the additional section of the query. A subsequent RMX query + could receive wrong DNS data if the DNS server used by the + receiving MTA accepted those forged records. + +11.1.5. Open SMTP relays + + Open SMTP relays (i.e. machines who accept any e-mail message from + anyone and deliver to the world) abused by spammers are a one of + the main problems of spam defense and sender backtracking. In most + cases this problem just vanishes because foreign open relay + machines will not be covered by the RMX records of the forged + sender address. But there are two special cases: + + If the spammer knows about a domain which authorizes this + particular machine, that domain can be used for forgery. But in + this case, the IP address of the relay machine and the RMX records + of the domain track back to the persons responsible. Both can be + demanded to fix the relay or remove the RMX record for this + machine. An open relay is a security flaw like leaving the machine + open for everybody to login and send random mails from inside. Once + the administrative persons refuse to solve the problem, they can be + identified as spammers and held responsible. + + The second special case is when a domain authorizes all IP + addresses by having the network 0.0.0.0/0 in the RMX/APL record. In + this case, open relays don't make things worse. It's up to the + recipient's MTA to reject mails from domains with loose security + policies. + +11.1.6. Unforged Spam + + This proposal does not prevent spam (which is, by the way, not yet + exactly defined), it prevents forgery. Since spam is against law + + + +Hadmut Danisch Experimental [Page 25] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + and violates the recipients rights, spam depends on untracability + of the sender. In practice the sender forges the sender address + (other cases see below). This proposal is designed to detect such + forgeries. + + However, the RMX approach is rendered ineffective, if the sender + doesn't forge. If the sender uses just a normal address of it's own + domain, this is just a plain, normal e-mail, which needs to be let + through. Since it is up to the human's taste whether this is spam + or not, there's no technical way to reliably identify this as spam. + But since the sender domain is known, this domain can be + blacklisted or legal steps can be gone into. + +11.1.7. Reliability of Whois Entries + + Once the RMX infrastructure gets deployed, what's the security + gain? It allows to determine the domain which's DNS zone + authorized the sending machine. What's that good for? There are + some immediate uses of the domain name, e.g. in black- and + whitelisting. But in most cases this is just the starting point of + further investigations, either performed automatically before + message acceptance, or manually after spam has been received and + complainted about. + + The next step after determining the domain is determining the + people responsible for this domain. This can sometimes be achieved + by querying the Whois databases. Unfortunately, many whois entries + are useless because they are incomplete, wrong, obsolete, or in + uncommon languages. Furthermore, there are several formats of + address informations which make it difficult to automatically + extract the address. Sometimes the whois entry identifies the + provider and not the owner of the domain. Whois servers are not + built for high availability and sometimes unreachable. + + Therefore, a mandatory standard is required about the contents and + the format of whois entries, and the availability of the servers. + After receiving the MAIL FROM SMTP command with the sender envelope + address, the receiving MTA could check the RMX record and Whois + entry. If it doesn't point to a real human, the message could be + rejected and an error message like "Ask your provider to fix your + Whois entry" could be issued. Obviously, domain providers must be + held responsible for wrong entries. It might still be acceptable to + allow anonymous domains, i. e. domains which don't point to a + responsible human. But it is the receivers choice to accept e-mails + from such domains or not. + +11.1.8. Hazards for Freedom of Speech + + + + +Hadmut Danisch Experimental [Page 26] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + Currently, some governments try to enforce limitations of internet + traffic in order to cut unwanted content providers from the + network. Some of these governments try to hide a whole country + behind firewalls, others try to force Internet providers to poison + DNS servers with wrong A records for web servers, e.g. one county + administration in Germany tries to do so. If message reception + depends on DNS entries, the same governments will try to block not + only HTTP, but SMTP also. + + However, since most MTAs already reject messages from unresolvable + domain names this is not a new threat. + +11.2. General Considerations about spam defense + + After discussing security requirements of the proposal, now the + security advantages of the RMX approach over content based filters + will be explained. Basically, there are three kinds of content + filters: + + - Those who upload the message or some digest to an external + third party and ask "Is this spam"? + + - Those who download a set of patterns and rules from a third + party and apply this set to incoming messages in order to + determine whether it is spam. + + - Those who are independent and don't contact any third party, + but try to learn themselves what is spam and what isn't. + + + The message filters provided by some e-mail service providers are + usually not a kind of their own, but a combination of the first two + kinds. + +11.2.1. Action vs. reaction + + Content filters suffer from a fundamental design problem: They are + late. They need to see some content of the same kind before in + order to learn and to block further distribution. + + This works for viruses and worms, which redistribute. This doesn't + work for spam, since spam is usually not redistributed after the + first delivery. When the filters have learned or downloaded new + pattern sets, it's too late. + + This proposal does not have this problem. + +11.2.2. Content based Denial of Service attacks + + + +Hadmut Danisch Experimental [Page 27] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + All three kinds of content filters, but especially the second and + the third kind are vulnerable to content based Denial of Service + attacks. + + If some kind of third party (e.g. non-democratic government, + intellectual property warriors, religious groups, military, secret + services, patriots, public relation agents, etc.) wants certain + contents not to be distributed, they could either poison the + pattern/rule databases or feed wrong sets to particular receivers. + + Such pattern/rule sets are the perfect tool for censoring e-mail + traffic and denial of service attacks by governments and other + parties, and a similar threat are virus filters. E. g. the content + industry could demand to teach all virus and spam filters to delete + all e-mails containing the URL of an MP3 web server outside the + legislations. Software manufacturers could try to block all e-mails + containing software license keys, thus trying to make unallowed + distribution more difficult. Governments could try to block + distribution of unwanted informations. + + This proposal does not have this problem. + + +12. Privacy Considerations + + (It was proposed on the 56th IETF meeting to have a privacy section + in drafts and RFCs.) + +12.1. Draft specific considerations + +12.1.1. No content leaking + + Since the RMX approach doesn't touch the contents of a message in + any way, there is obviously no way of leaking out any information + about the content of the message. RMX is based solely on the + envelope recipient address. However, methods to fix problems not + covered by RMX might allow content leaking, e.g. if the acceptance + of a message with an empty sender address requires the reference to + the message id of an e-mail recently sent, this allows an attacker + to verify whether a certain message was delivered from there. + +12.1.2. Message reception and sender domain + + Message delivery triggers RMX and APL requests by the recipient. + Thus, the admin of the DNS server or an eavesdropper could learn + that the given machine has just received a message with a sender + from this address, even if the SMTP traffic itself had been + encrypted. + + + +Hadmut Danisch Experimental [Page 28] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + However, most of today's MTAs do query the MX and A records of the + domain after the MAIL FROM command, so this is not a real new + threat. + +12.1.3. Network structure + + Since RMX and its associated APL records provide a complete list of + all IP addresses of hosts authorized to send messages from this + address, they do reveal informations about the network structure + and maybe the lifestyle of the domain owner, since a growing number + of domains are owned by single persons or families. E.g. the RMX + records could reveal where someone has his job or spends his time + at weekends. + + If such informations are to be kept secret, it is the user's job to + not sent e-mails from there and to relay them from non-compromising + IP addresses. + +12.1.4. Owner information distribution + + As described above, RMX depends partly on the reliability of the + whois database entries. It does not make anonymous domains + impossible, but it requires to keep the database entries "true", i. + e. if a whois entry does not contain informations about the + responsible person, this must be unambigously labeled as anonymous. + It must not contain fake names and addresses to pretend a non- + existing person. However, since most Internet users on the world + feel extremely annoyed by spam, they will urge their MTA admin to + reject messages from anonymous domains. The domain owner will have + the choice to either remain anonymous but be not able to send e- + mail to everyone in the world, or to be able but to reveal his + identity to everyone on the world. + + It would be possible to provide whois-like services only to + recipients of recent messages, but this would make things too + complicated to be commonly adopted. + +12.2. General Considerations about spam defense + +12.2.1. Content leaking of content filters + + As described above in the Security chapter, there are spam filters + which inherently allow leakage of the message body. Those filters + upload either the message body, or in most cases just some kind of + checksum to a third party, which replies whether this is to be seen + as spam or not. The idea is to keep a databases of all digests of + all messages. If a message is sent more often than some threshold, + it is to be considered as a mass mail and therefore tagged as spam. + + + +Hadmut Danisch Experimental [Page 29] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + While the digest itself does not reveal the content of the message, + it perfectly reveals where a particular message has been delivered + to. If a government finds just a single unwanted message, if a + software manufacturer finds a single message with a stolen product + license key, if someone finds a message with unpatriotic content, + it takes just a single database lookup to get a list of all people + who received this particular message. Content filters with digest + upload are the perfect "Big Brother". + +12.2.2. Black- and Whitelists + + Some proposals against spam are based on a central database of + white- or blacklisted IP addresses, Sender names, Message IDs or + whatever. Again, there is a central database which learns who has + received which e-mail or from which sender with every query. This + allows tracking relations between persons, which is also a breach + of privacy. + + + +13. Deployment Considerations + +13.1. Compatibility + +13.1.1. Compatibility with old mail receivers + + Since the suggested extension doesn't change the SMTP protocol at + all, it is fully compatible with old mail receivers. They simply + don't ask for the RMX records and don't perform the check. + +13.1.2. Compatibility with old mail senders + + Since the SMTP protocol is unchanged and the SMTP sender is not + involved in the check, the method is fully compatible with old mail + senders. + +13.1.3. Compatibility with old DNS clients + + Since the RMX is a new RR, the existing DNS protocol and zone + informations remain completely untouched. + + If RMX is provided as a TXT record instead, it must be ensured that + no other software is misinterpreting this entry. + +13.1.4. Compatibility with old DNS servers + + Full compatibility: If the server does not support RMX records, RMX + in TXT records can be used. + + + +Hadmut Danisch Experimental [Page 30] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +13.2. Enforcement policy + + Obviously, for reasons of backward compatibility and smooth + introduction of this scheme, RMX records can't be required + immediately. Domains without RMX records must temporarily be + treated the same way as they are treated right now, i.e. e-mail + must be accepted from anywhere. But once the scheme becomes + sufficiently widespread, mail relays can start to refuse e-mails + with sender addresses from domains without RMX records, thus + forcing the owner of the domain to include a statement of + authorization into the domain's zone table. Domain owners will + still be free to have an RMX record with a network and mask + 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere. + On the other hand, mail receivers will be free to refuse mails from + domains without RMX records or RMX records which are too loose. + Advanced MTAs might have a configuration option to set the maximum + number of IP addresses authorized to use a domain. E-mails from a + domain, which's RMX records exceed this limit, would be rejected. + For example, a relay could reject e-mails from domains which + authorize more than 8 IP addresses. That allows to accept e-mails + only from domains with a reasonable security policy. + + + +14. General considerations about fighting spam + + Is there a concise technical solution against spam? Yes. + + Will it be deployed? Certainly not. + + Why not? Because of the strong non-technical interests of several + parties against a solution to the problem, as described below. + Since these are non-technical reasons, they might be beyond the + scope of such a draft. But since they are the main problems that + prevent fighting spam, it is unavoidable to address them. This + chapter exists temporarily only and should support the discussion + of solutions. It is not supposed to be included in a later RFC. + +14.1. The economical problem + + As has been recently illustrated in the initial session of the + IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, + sending spam is a business with significant revenues. + + But a much bigger business is selling Anti-Spam software. This is a + billion dollar market, and it is rapidly growing. Any simple and + effective solution against spam would defeat revenues and drive + several companies into bankrupt, would make consultants jobless. + + + +Hadmut Danisch Experimental [Page 31] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + Therefore, spam is essential for the Anti-Spam business. If there + is no spam, then no Anti-Spam software can be sold, similar to the + Anti-Virus business. There are extremely strong efforts to keep + this market growing. Viruses, Worms, and now spam are just perfect + to keep this market alive: It is not sufficient to just buy a + software. Databases need to be updated continuously, thus making + the cash flow continuously. Have a single, simple, and permanent + solution to the problem and - boom - this billion dollar market is + dead. + + That's one of the reasons why people are expected to live with + spam. They have to live with it to make them buy Anti-Spam + software. Content filters are perfect products to keep this market + alive. + +14.2. The POP problem + + Another problem is the history of mail delivery. Once upon a time, + there used to be very few SMTP relays which handled the e-mail + traffic of all the world, and everybody was happy with that. Then + odd things like Personal Computers, which are sometimes switched + off, portable computers, dynamicly assigned IP addresses, IP access + from hotel rooms, etc. was invented, and people became unhappy, + because SMTP does not support delivery to such machines. To make + them happy again, the Post Office Protocol[4] was invented, which + turned the last part of message delivery from SMTP's push style + into a pull style, thus making virtually every computer on the + world with any random IP address a potential receiver of mails for + random domains. Unfortunately, only receiving e-mail was covered, + but sending e-mail was left to SMTP. + + The result is that today we have only very few SMTP relays pointed + to by MX records, but an extreme number of hosts sending e-mail + with SMTP from any IP address with sender addresses from any + domain. Mail delivery has become very asymmetric. Insecurity, + especially forgeability, has become an essential part of mail + transport. + + That problem could easily be fixed: Use protocols which allow + uploading of messages to be delivered. If a host doesn't receive + messages by SMTP, it shouldn't deliver by SMTP. Mail delivery + should go the same way back that incoming mail went in. This is + not a limitation to those people on the road who plug their + portable computer in any hotel room's phone plug and use any + provider. If there is a POP server granting download access from + anywhere, then the same server should be ready to accept uploading + of outgoing messages. + + + + +Hadmut Danisch Experimental [Page 32] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + But as I saw from the comments on the first version of this draft, + people religiously insist on sending e-mail with their domain from + any computer with any IP address in the world, e.g. when visiting a + friend using her computer. It appears to be impossible to convince + people that stopping mail forgery requires every one of them to + give up forging. + +14.3. The network structure problem + + A subsequent problem is that many organisations failed to implement + a proper mail delivery structure and heavily based their network on + this asymmetry. I received harsh comments from Universities who + were unable to give their network a good structure. While they do + have a central mail relay for incoming mail to the universities + domain, they developed a structure where every member of the + University randomly sends e-mails with that University's domain as + a sender address from home or everywhere in the world with any + dynamically assigned IP address from any provider. So this domain + is to be used from every possible IP address on earth, and they are + unable to operate any authentication scheme. Furthermore, they were + unable to understand that such a policy heavily supports spam and + that they have to expect that people don't accept such e-mails + anymore once they become blacklisted. + + As long as organisations insist on having such policies, spammers + will have a perfect playground. + +14.4. The mentality problem + + Another problem is the mentality of many internet users of certain + countries. I received harsh comments from people who strongly + insisted on the freedom to send any e-mail with any sender address + from anywhere, and who heavily refused any kind of authentication + step or any limitation, because they claimed that this would + infringe their constitutional "Freedom of speech". They are + undeviatingly convinced that "Freedom of speech" guarantees their + right to talk to everybody with any sender address, and that is has + to be kept the recipient's own problem to sort out what he doesn't + want to read - on the recipient's expense. + + It requires a clear statement that the constitutional "Freedom of + Speech" does not cover molesting people with unsolicited e-mail + with forged sender address. + +14.5. The identity problem + + How does one fight against mail forgery? With authentication. What + is authentication? In simple words: Making sure that the sender's + + + +Hadmut Danisch Experimental [Page 33] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + real identity meets the recipients idea of who is the sender, based + on the sender address which came with the message. + + What is identity? It is the main problem. Several countries have + different ideas of "identity", which turn out to be somehow + incompatible. In some countries people have identity cards and + never change their name and birthday. Identities are created by + human birth, not by identity changes. Other countries do not have + such a tight idea about identity. People's temporary identity is + based on nothing more than a driving license and a social security + number. With this background, it is virtually impossible to create + a trustworthy PKI covering all Internet users. I learned that it is + extremely difficult to convince some people to give up random e- + mail sending. + +14.6. The multi-legislation problem + + Many proposals about fighting spam are feasible under certain + legislations only, and are inacceptable under some of the + legislations. But a world wide applicable method is required. + That's why the approach to ask everone on the world to sign + messages with cryptographic keys is not feasible. + + +Implementation and further Information + + Further informations and a test implementation are available at + + http://www.danisch.de/work/security/antispam.html + http://www.danisch.de/software/rmx/ + + + Additional informations and a technology overview are also + available at + + http://www.mikerubel.org/computers/rmx_records/ + + +References + + + +1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- + els," RFC 2119 (March 1997). + +2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001). + + + + + +Hadmut Danisch Experimental [Page 34] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," + RFC 1035 (November 1987). + +4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939 + (May 1996). + + +Draft History + + 00 Dec 2002 + 01 Apr 2003 + 02 Jun 2003 + 03 Oct 2003 + +Author's Address + + Hadmut Danisch + + Tennesseeallee 58 + 76149 Karlsruhe + Germany + + Phone: ++49-721-843004 or ++49-351-4850477 + E-Mail: rfc@danisch.de + +Comments + + Please send comments to rfc@danisch.de. + +Expiry + + This drafts expires on Apr 1, 2004. + + + + + + + + + + + + + + + + + + + +Hadmut Danisch Experimental [Page 35] + diff --git a/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt b/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt new file mode 100644 index 000000000000..7b5e8cc4455b --- /dev/null +++ b/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt @@ -0,0 +1,241 @@ + +IETF DNSEXT WG Bill Manning +draft-dnsext-opcode-discover-02.txt ep.net + Paul Vixie + ISC + 13 Oct 2003 + + + The DISCOVER opcode + +This document is an Internet-Draft and is subject to all provisions of +Section 10 of RFC2026. + +Comments may be submitted to the group mailing list at "mdns@zocalo.net" +or the authors. + +Distribution of this memo is unlimited. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months and +may be updated, replaced, or obsoleted by other documents at any time. It +is inappropriate to use Internet-Drafts as reference material or to cite +them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this +document are to be interpreted as described in RFC 2119 + +0. Abstract: + + The QUERY opcode in the DNS is designed for unicast. With the + development of multicast capabilities in the DNS, it is desireable + to have a more robust opcode for server interactions since a single + request may generate replies from multiple responders. So DISCOVER + is defined to deal with replies from multiple responders. + + As such, this document extends the core DNS specifications to allow + clients to have a method for coping with replies from multiple + responders. Use of this new opcode may facilitate DNS operations in + modern networking topologies. A prototype of the DISCOVER opcode + was developed during the TBDS project (1999-2000), funded under DARPA + grant F30602-99-1-0523. + +1. Introduction: + + This document describes an experimental extension to the DNS to receive + multiple responses which is the likely result when using DNS that has + enabled multicast queries. This approach was developed as part of the + TBDS research project, funded under DARPA grant F30602-99-1-0523. The + full processing rules used by TBDS are documented here for possible + incorporation in a future revision of the DNS specification." + +2. Method: + + DISCOVER works like QUERY except: + + 1. it can be sent to a broadcast or multicast destination. QUERY + isn't defined for non-unicast, and arguably shouldn't be. + + 2. the Question section, if present, has + tuples. TBDS tried to augment this structure as follows: + . While this worked for our purposes in + TBDS, it is cleaner to place the SRV question in a separate pass. + + 3. if QDCOUNT equals 0 then only servers willing to do recursion should + answer. Other servers must silently discard the DISCOVER request. + + 4. if QDCOUNT is not equal to 0 then only servers who are authoritative + for the zones named by some QNAME should answer. + + 5. responses may echo the request's Question section or leave it blank, + just like QUERY. + + 6. responses have standard Answer, Authority, and Additional sections. + e.g. the response is the same as that to a QUERY. It is desireable + that zero content answers not be sent to avoid badly formed or + unfulfilled requests. Responses should be sent to the unicast + address of the requester and the source address should reflect + the unicast address of the responder. + + Example usage for gethostby{name,addr}-style requestors: + + Compute the zone name of the enclosing in-addr.arpa, ip6.int, or + ip6.arpa domain. + + DISCOVER whether anyone in-scope is authoritative for this zone. + + If so, query these authoritative servers for local + in-addr/ip6 names. + + If not, DISCOVER whether there are recursive servers available. + + If so, query these recursive servers for local + in-addr/ip6 names. + + So, a node will issue a multicast request with the DISCOVER opcode at + some particular multicast scope. Then determine, from the replies, + whether there are any DNS servers which are authoritative (or support + recursion) for the zone. Replies to DISCOVER requests MUST set the + Recursion Available (RA) flag in the DNS message header. + + It is important to recognize that a requester must be prepared to + receive multiple replies from multiple responders. We expect that + there will be a single response per responder. + + Once one learns a host's FQDN by the above means, repeat the process + for discovering the closest enclosing authoritative server of such + local name. + + Cache all NS and A data learned in this process, respecting TTL's. + + TBDS usage for SRV requestors: + + Do the gethostbyaddr() and gethostbyname() on one's own link-local + address, using the above process. + + Assume that the closest enclosing zone for which an authority server + answers an in-scope DISCOVER packet is "this host's parent domain". + + Compute the SRV name as _service._transport.*.parentdomain. + + This is a change to the definition as defined in RFC 1034. + A wildcard label ("*") in the QNAME used in a DNS message with + opcode DISCOVER SHOULD be evaluated with special rules. The + wildcard matches any label for which the DNS server data is + authoritative. For example 'x.*.example.com.' would match + 'x.y.example.com.' and 'x.yy.example.com.' provided that the + server was authoritative for 'example.com.' In this particular + case, we suggest the follwing considerations be made: + + getservbyname() can be satisfied by issuing a request with + this computed SRV name. This structure can be + populated by values returned from a request as follows: + + s_name The name of the service, "_service" without the + preceding underscore. + s_aliases The names returned in the SRV RRs in replies + to the query. + s_port The port number in the SRV RRs replies to the + query. If these port numbers disagree - one + of the port numbers is chosen, and only those + names which correspond are returned. + s_proto The transport protocol from named by the + "_transport" label, without the preceding + underscore. + + Send SRV query for this name to discovered local authoritative servers. + + Usage for disconnected networks with no authoritative servers: + + Hosts should run a "stub server" which acts as though its FQDN is a + zone name. Computed SOA gives the host's FQDN as MNAME, "." as the + ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE + and the other timers. Compute NS as the host's FQDN. Compute the + glue as the host's link-local address. Or Hosts may run a + "DNS stub server" which acts as though its FQDN is a zone name. The + rules governing the behavior of this stub server are given elsewhere + [1] [2]. + + Such stub servers should answer DISCOVER packets for its zone, and + will be found by the iterative "discover closest enclosing authority + server" by DISCOVER clients, either in the gethostbyname() or SRV + cases described above. Note that stub servers only answer with + zone names which exactly match QNAME's, not with zone names which + are owned by QNAME's. + + The main deviation from the DNS[3][4] model is that a host (like, say, a + printer offering LPD services) has a DNS server which answers authoritatively + for something which hasn't been delegated to it. However, the only way that + such DNS servers can be discovered is with a new opcode, DISCOVER, which + is explicitly defined to discover undelegated zones for tightly scoped + purposes. Therefore this isn't officially a violation of DNS's coherency + principles. In some cases a responder to DISCOVER may not be traditional + DNS software, it could be special purpose software. + +3. IANA Considerations + + As a new opcode, the IANA will need to assign a numeric value + for the memnonic. The last OPCODE assigned was "5", for UPDATE. + Test implementations have used OPCODE "6". + +4. Security Considerations + + No new security considerations are known to be introduced with any new + opcode, however using multicast for service discovery has the potential + for denial of service, primarly from flooding attacks. It may also be + possible to enable deliberate misconfiguration of clients simply by + running a malicious DNS resolver that claims to be authoritative for + things that it is not. One possible way to mitigate this effect is by + use of credentials, such as CERT resource records within an RR set. + The TBDS project took this approach. + +5. Attribution: + + This material was generated in discussions on the mdns mailing list +hosted by Zocalo in March 2000. Updated by discussion in September/October +2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, +Erik Guttman, Bill Manning and Paul Vixie were active contributors. + +6. Author's Address + + Bill Manning + PO 12317 + Marina del Rey, CA. 90295 + +1.310.322.8102 + bmanning@karoshi.com + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 7001 + + +7. References + +Informational References: + +[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS", + draft-ietf-dnsext-mdns-00.txt, November 2000. Expired + +[2] Woodcock, B., Manning, B., "Multicast Domain Name Service", + draft-manning-dnsext-mdns-00.txt, August 2000. Expired. + +Normative References: +[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", + RFC 1034, November 1987. +[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", + RFC 1035, November 1987 + + ----------------------------EOL----------------------- + diff --git a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt new file mode 100644 index 000000000000..224e7ad1697e --- /dev/null +++ b/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt @@ -0,0 +1,240 @@ +Internet Engineering Task Force Alain Durand +INTERNET-DRAFT SUN Microsystems +Feb 21, 2003 +Expires Aug 2, 2003 + + + + Dynamic reverse DNS for IPv6 + + + + +Status of this memo + + + This memo provides information to the Internet community. It does + not specify an Internet standard of any kind. This memo is in full + conformance with all provisions of Section 10 of RFC2026 [RFC2026]. + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + This document describes a method to dynamically generate PTR records + and corresponding A or AAAA records when the reverse path DNS tree is + not populated. + + A special domain dynrev.arpa. is reserved for that purpose. + + +1. Introduction + + In IPv4, the reverse path tree of the DNS under in-addr.arpa. + although not perfectly maintained, is still mostly usable and its + existence is important for a number of applications that relies on + its existence and decent status. Some applications performs some + (very) weak security checks based on it. Mail relays relies on it for + some anti-spams checks an some FTP server will not let you in unless + your IP address resolve properly with a PTR record. + + IPv6 addresses being much longer (and cumbersome) than IPv4 + addresses, it is to fear that the reverse path tree under ip6.arpa. + would not be as well maintained. Also, tools like 6to4, Isatap and + others have made creative use of the 128 bits of an IPv6 address to + automatically embed an IPv4 address to enable seamless connection to + the IPv6 Internet. However, no provision has been made to make sure + the reverse path tree gets automatically updated as well for those + new IPv6 addresses. One step furter, RFC3041 describes a mechanism + to basically use random bits in the bottom part of an IPv6 address to + preserver anonymity. If those addresses are to resolve in the reverse + path tree, it obviously has to be with anonymous data as well. + Another point to note is that home customer ISPs in IPv4 have a + current practice to pre-populate the reverse path tree with names + automatically derived from the IP addresses. This practice is no + longer possible in IPv6, where IP address allocation is not dense as + it is the case in IPv4. The mere size of typical customer allocation + (2^48 according to the recommendation of RFC3177) makes it + impossible. + + Applications that check the existence of PTR records usually follow + this by checking if the name pointed by the PTR resolve in a A (or + AAAA for IPv6) that match the original IP address. Thus the forward + path tree must also include the corresponding data. + + One simple approach of this problem is to simply declare the usage of + the reverse path DNS as described above obsolete. The author believe + this is too strong an approach for now. + + Similarly, a completely different approach would be to deprecate the + usage of DNS for the reverse tree altogether and replace it by + something inspired from ICMP name-info messages. The author believes + that this approached is an important departure from the current + practise and thus not very realistic. Also, there are some concerns + about the the security implications of this method as any node could + easily impersonate any name. This approach would fundamentally change + the underlying assumption of "I trust what has been put in the DNS by + the local administrators" to "I trust what has been configured on + each machine I query directly". + + + +2. Dynamic record generation + + If static pre-population of the tree is not possible anymore and data + still need to be returned to applications using getnameinfo(), the + alternative is dynamic record generation. This can be done is two + places: in the DNS servers responsible for the allocated space (/64 + or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the + sub resolver library or the recursive DNS server). + + 2.1. On the resolver side. + + The resolver, either in the recursive DNS server or in the stub + library could theoretically generate this data. + + In case DNSsec is in place, the recursive DNS server would have to + pretend these records are authentic. + + If the synthesis is done in the stub-resolver library, no record + needs to be actually generated, only the right information needs to + be passed to getnameinfo() and getaddrinfo(). If the synthesis is + done in the recursive DNS server, no modification is required to + existing stub resolvers. + + +2.2. On the server side. + + PTR records could be generated automatically by the server + responsible for the reverse path tree of an IPv6 prefix (a /64 or /48 + prefixes or basically anything in between) when static data is not + available. + + There could be impact on DNSsec as the zone or some parts of the zone + may need to be resigned each time a DNS query is made for an + unpopulated address. This can be seen as a DOS attack on a DNSsec + zone, so server side synthesis is not recommended if DNSsec is + deployed. + + + +3. Synthesis + + The algorithm is simple: Do the normal queries. If the query returns + No such domain, replace this answer by the synthetized one if + possible. + +3.1. PTR synthesis + + The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa. + where [X] is any valid DNS name. + + The fact that the synthetized PTR points to the dynrev.arpa. domain + is an indication to the applications that this record has been + dynamically generated. + + +3.2. A synthesis + + If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A + record for the string [X].dynrev.arpa. which value is d.c.b.a. with + a,b,c & d being integer [0..255] + + +3.3. AAAA synthesis + + If [X] is in the form + a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in- + addr.arpa, one can synthetized a AAAA record for the string + [X].dynrev.arpa. which value is + FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with + a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits. + + +3.4. Server side synthesis + + If synthesis is done on the server side, PTR could be set not to use + the dynrev.arpa domain but the local domain name instead. It culd be + for instance dynrev.mydomain.com. + + Note also that server side synthesis is not incompatible with + resolver side synthesis. + + + +4. IANA considerations + + The dynrev.arpa. domain is reserved for the purpose of this document. + + + +5. Security considerations + + Section 2. discusses the the interactions with DNSsec. + + + +6. Authors addresses + + Alain Durand + SUN Microsystems, Inc + 17, Network Circle + UMPK17-202 + Menlo Park, CA 94025 + USA + Mail: Alain.Durand@sun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt new file mode 100644 index 000000000000..f0ce70ab1c99 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt @@ -0,0 +1,393 @@ + + + +INTERNET-DRAFT Andreas Gustafsson +draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc. + November 2002 + + + DNS Zone Transfer Protocol Clarifications + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Abstract + + In the Domain Name System, zone data is replicated among + authoritative DNS servers by means of the "zone transfer" protocol, + also known as the "AXFR" protocol. This memo clarifies, updates, and + adds missing detail to the original AXFR protocol specification in + RFC1034. + +1. Introduction + + The original definition of the DNS zone transfer protocol consists of + a single paragraph in [RFC1034] section 4.3.5 and some additional + notes in [RFC1035] section 6.3. It is not sufficiently detailed to + serve as the sole basis for constructing interoperable + implementations. This document is an attempt to provide a more + complete definition of the protocol. Where the text in RFC1034 + conflicts with existing practice, the existing practice has been + codified in the interest of interoperability. + + + + +Expires May 2003 [Page 1] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + +2. The zone transfer request + + To initiate a zone transfer, the slave server sends a zone transfer + request to the master server over a reliable transport such as TCP. + The form of this request is specified in sufficient detail in RFC1034 + and needs no further clarification. + + Implementers are advised that one server implementation in widespread + use sends AXFR requests where the TCP message envelope size exceeds + the DNS request message size by two octets. + +3. The zone transfer response + + If the master server is unable or unwilling to provide a zone + transfer, it MUST respond with a single DNS message containing an + appropriate RCODE other than NOERROR. If the master is not + authoritative for the requested zone, the RCODE SHOULD be 9 + (NOTAUTH). + + Slave servers should note that some master server implementations + will simply close the connection when denying the slave access to the + zone. Therefore, slaves MAY interpret an immediate graceful close of + the TCP connection as equivalent to a "Refused" response (RCODE 5). + + If a zone transfer can be provided, the master server sends one or + more DNS messages containing the zone data as described below. + +3.1. Multiple answers per message + + The zone data in a zone transfer response is a sequence of answer + RRs. These RRs are transmitted in the answer section(s) of one or + more DNS response messages. + + The AXFR protocol definition in RFC1034 does not make a clear + distinction between response messages and answer RRs. Historically, + DNS servers always transmitted a single answer RR per message. This + encoding is wasteful due to the overhead of repeatedly sending DNS + message headers and the loss of domain name compression + opportunities. To improve efficiency, some newer servers support a + mode where multiple RRs are transmitted in a single DNS response + message. + + A master MAY transmit multiple answer RRs per response message up to + the largest number that will fit within the 65535 byte limit on TCP + + + +Expires May 2003 [Page 2] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + DNS message size. In the case of a small zone, this can cause the + entire transfer to be transmitted in a single response message. + + Slaves MUST accept messages containing any number of answer RRs. For + compatibility with old slaves, masters that support sending multiple + answers per message SHOULD be configurable to revert to the + historical mode of one answer per message, and the configuration + SHOULD be settable on a per-slave basis. + +3.2. DNS message header contents + + RFC1034 does not specify the contents of the DNS message header of + the zone transfer response messages. The header of each message MUST + be as follows: + + ID Copy from request + QR 1 + OPCODE QUERY + AA 1, but MAY be 0 when RCODE is not NOERROR + TC 0 + RD Copy from request, or 0 + RA Set according to availability of recursion, or 0 + Z 0 + AD 0 + CD 0 + RCODE NOERROR on success, error code otherwise + + The slave MUST check the RCODE in each message and abort the transfer + if it is not NOERROR. It SHOULD check the ID of the first message + received and abort the transfer if it does not match the ID of the + request. The ID SHOULD be ignored in subsequent messages, and fields + other than RCODE and ID SHOULD be ignored in all messages, to ensure + interoperability with certain older implementations which transmit + incorrect or arbitrary values in these fields. + +3.3. Additional section and SIG processing + + Zone transfer responses are not subject to any kind of additional + section processing or automatic inclusion of SIG records. SIG RRs in + the zone data are treated exactly the same as any other RR type. + +3.4. The question section + + RFC1034 does not specify whether zone transfer response messages have + a question section or not. The initial message of a zone transfer + response SHOULD have a question section identical to that in the + request. Subsequent messages SHOULD NOT have a question section, + though the final message MAY. The receiving slave server MUST accept + + + +Expires May 2003 [Page 3] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + any combination of messages with and without a question section. + +3.5. The authority section + + The master server MUST transmit messages with an empty authority + section. Slaves MUST ignore any authority section contents they may + receive from masters that do not comply with this requirement. + +3.6. The additional section + + The additional section MAY contain additional RRs such as transaction + signatures. The slave MUST ignore any unexpected RRs in the + additional section. It MUST NOT treat additional section RRs as zone + data. + +4. Zone data + + The purpose of the zone transfer mechanism is to exactly replicate at + each slave the set of RRs associated with a particular zone at its + primary master. An RR is associated with a zone by being loaded from + the master file of that zone at the primary master server, or by some + other, equivalent method for configuring zone data. + + This replication shall be complete and unaltered, regardless of how + many and which intermediate masters/slaves are involved, and + regardless of what other zones those intermediate masters/slaves do + or do not serve, and regardless of what data may be cached in + resolvers associated with the intermediate masters/slaves. + + Therefore, in a zone transfer the master MUST send exactly those + records that are associated with the zone, whether or not their owner + names would be considered to be "in" the zone for purposes of + resolution, and whether or not they would be eligible for use as glue + in responses. The transfer MUST NOT include any RRs that are not + associated with the zone, such as RRs associated with zones other + than the one being transferred or present in the cache of the local + resolver, even if their owner names are in the zone being transferred + or are pointed to by NS records in the zone being transferred. + + The slave MUST associate the RRs received in a zone transfer with the + specific zone being transferred, and maintain that association for + purposes of acting as a master in outgoing transfers. + +5. Transmission order + + RFC1034 states that "The first and last messages must contain the + data for the top authoritative node of the zone". This is not + consistent with existing practice. All known master implementations + + + +Expires May 2003 [Page 4] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + send, and slave implementations expect to receive, the zone's SOA RR + as the first and last record of the transfer. + + Therefore, the quoted sentence is hereby superseded by the sentence + "The first and last RR transmitted must be the SOA record of the + zone". + + The initial and final SOA record MUST be identical, with the possible + exception of case and compression. In particular, they MUST have the + same serial number. The slave MUST consider the transfer to be + complete when, and only when, it has received the message containing + the second SOA record. + + The transmission order of all other RRs in the zone is undefined. + Each of them SHOULD be transmitted only once, and slaves MUST ignore + any duplicate RRs received. + +6. Security Considerations + + The zone transfer protocol as defined in [RFC1034] and clarified by + this memo does not have any built-in mechanisms for the slave to + securely verify the identity of the master server and the integrity + of the transferred zone data. The use of a cryptographic mechanism + for ensuring authenticity and integrity, such as TSIG [RFC2845], + IPSEC, or TLS, is RECOMMENDED. + + The zone transfer protocol allows read-only public access to the + complete zone data. Since data in the DNS is public by definition, + this is generally acceptable. Sites that wish to avoid disclosing + their full zone data MAY restrict zone transfer access to authorized + slaves. + + These clarifications are not believed to themselves introduce any new + security problems, nor to solve any existing ones. + +Acknowledgements + + Many people have contributed input and commentary to earlier versions + of this document, including but not limited to Bob Halley, Dan + Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, + Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam + Trenholme, and Brian Wellington. + +References + + [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, + November 1987. + + + + +Expires May 2003 [Page 5] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + [RFC1035] - Domain Names - Implementation and Specifications, P. + Mockapetris, November 1987. + + [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels, + S. Bradner, BCP 14, March 1997. + + [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P. + Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. + +Author's Address + + Andreas Gustafsson + Nominum Inc. + 2385 Bay Rd + Redwood City, CA 94063 + USA + + Phone: +1 650 381 6004 + + Email: gson@nominum.com + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implmentation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + + + +Expires May 2003 [Page 6] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires May 2003 [Page 7] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt new file mode 100644 index 000000000000..09776618f2ae --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt @@ -0,0 +1,561 @@ + + +DNSEXT M. Stapp +Internet-Draft Cisco Systems, Inc. +Expires: January 14, 2005 T. Lemon + A. Gustafsson + Nominum, Inc. + July 16, 2004 + + + A DNS RR for Encoding DHCP Information (DHCID RR) + + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 14, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + It is possible for multiple DHCP clients to attempt to update the + same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or + the clients themselves perform the DNS updates, conflicts can arise. + To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] + proposes storing client identifiers in the DNS to unambiguously + + + +Stapp, et al. Expires January 14, 2005 [Page 1] + +Internet-Draft The DHCID RR July 2004 + + + associate domain names with the DHCP clients to which they refer. + This memo defines a distinct RR type for this purpose for use by DHCP + clients and servers, the "DHCID" RR. + +Table of Contents + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4 + 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4 + 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4 + 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4 + 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6 + 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires January 14, 2005 [Page 2] + +Internet-Draft The DHCID RR July 2004 + + +1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + +2. Introduction + + A set of procedures to allow DHCP [7] clients and servers to + automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed + in "Resolution of DNS Name Conflicts" [1]. + + Conflicts can arise if multiple DHCP clients wish to use the same DNS + name. To resolve such conflicts, "Resolution of DNS Name Conflicts" + [1] proposes storing client identifiers in the DNS to unambiguously + associate domain names with the DHCP clients using them. In the + interest of clarity, it is preferable for this DHCP information to + use a distinct RR type. This memo defines a distinct RR for this + purpose for use by DHCP clients or servers, the "DHCID" RR. + + In order to avoid exposing potentially sensitive identifying + information, the data stored is the result of a one-way MD5 [5] hash + computation. The hash includes information from the DHCP client's + REQUEST message as well as the domain name itself, so that the data + stored in the DHCID RR will be dependent on both the client + identification used in the DHCP protocol interaction and the domain + name. This means that the DHCID RDATA will vary if a single client + is associated over time with more than one name. This makes it + difficult to 'track' a client as it is associated with various domain + names. + + The MD5 hash algorithm has been shown to be weaker than the SHA-1 + algorithm; it could therefore be argued that SHA-1 is a better + choice. However, SHA-1 is significantly slower than MD5. A + successful attack of MD5's weakness does not reveal the original data + that was used to generate the signature, but rather provides a new + set of input data that will produce the same signature. Because we + are using the MD5 hash to conceal the original data, the fact that an + attacker could produce a different plaintext resulting in the same + MD5 output is not significant concern. + +3. The DHCID RR + + The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The + DHCID RR is only defined in the IN class. DHCID RRs cause no + additional section processing. The DHCID RR is not a singleton type. + + + + + +Stapp, et al. Expires January 14, 2005 [Page 3] + +Internet-Draft The DHCID RR July 2004 + + +3.1 DHCID RDATA format + + The RDATA section of a DHCID RR in transmission contains RDLENGTH + bytes of binary data. The format of this data and its interpretation + by DHCP servers and clients are described below. + + DNS software should consider the RDATA section to be opaque. DHCP + clients or servers use the DHCID RR to associate a DHCP client's + identity with a DNS name, so that multiple DHCP clients and servers + may deterministically perform dynamic DNS updates to the same zone. + From the updater's perspective, the DHCID resource record RDATA + consists of a 16-bit identifier type, in network byte order, followed + by one or more bytes representing the actual identifier: + + < 16 bits > DHCP identifier used + < n bytes > MD5 digest + + +3.2 DHCID Presentation Format + + In DNS master files, the RDATA is represented as a single block in + base 64 encoding identical to that used for representing binary data + in RFC 2535 [8]. The data may be divided up into any number of white + space separated substrings, down to single base 64 digits, which are + concatenated to form the complete RDATA. These substrings can span + lines using the standard parentheses. + +3.3 The DHCID RR Type Codes + + The DHCID RR Type Code specifies what data from the DHCP client's + request was used as input into the hash function. The type codes are + defined in a registry maintained by IANA, as specified in Section 7. + The initial list of assigned values for the type code is: + + 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7]. + 0x0001 = The data portion from a DHCPv4 client's Client Identifier + option [9]. + 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6 + client's Client Identifier option [10] or the DUID field from a + DHCPv4 client's Client Identifier option [12]). + + 0x0003 - 0xfffe = Available to be assigned by IANA. + + 0xffff = RESERVED + +3.4 Computation of the RDATA + + The DHCID RDATA is formed by concatenating the two type bytes with + + + +Stapp, et al. Expires January 14, 2005 [Page 4] + +Internet-Draft The DHCID RR July 2004 + + + some variable-length identifying data. + + < type > < data > + + The RDATA for all type codes other than 0xffff, which is reserved for + future expansion, is formed by concatenating the two type bytes and a + 16-byte MD5 hash value. The input to the hash function is defined to + be: + + data = MD5(< identifier > < FQDN >) + + The FQDN is represented in the buffer in unambiguous canonical form + as described in RFC 2535 [8], section 8.1. The type code and the + identifier are related as specified in Section 3.3: the type code + describes the source of the identifier. + + When the updater is using the client's link-layer address as the + identifier, the first two bytes of the DHCID RDATA MUST be zero. To + generate the rest of the resource record, the updater computes a + one-way hash using the MD5 algorithm across a buffer containing the + client's network hardware type, link-layer address, and the FQDN + data. Specifically, the first byte of the buffer contains the + network hardware type as it appeared in the DHCP 'htype' field of the + client's DHCPREQUEST message. All of the significant bytes of the + chaddr field in the client's DHCPREQUEST message follow, in the same + order in which the bytes appear in the DHCPREQUEST message. The + number of significant bytes in the 'chaddr' field is specified in the + 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified + above, follows. + + When the updater is using the DHCPv4 Client Identifier option sent by + the client in its DHCPREQUEST message, the first two bytes of the + DHCID RR MUST be 0x0001, in network byte order. The rest of the + DHCID RR MUST contain the results of computing an MD5 hash across the + payload of the option, followed by the FQDN. The payload of the + option consists of the bytes of the option following the option code + and length. + + When the updater is using the DHCPv6 DUID sent by the client in its + REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002, + in network byte order. The rest of the DHCID RR MUST contain the + results of computing an MD5 hash across the payload of the option, + followed by the FQDN. The payload of the option consists of the + bytes of the option following the option code and length. + +3.5 Examples + + + + + +Stapp, et al. Expires January 14, 2005 [Page 5] + +Internet-Draft The DHCID RR July 2004 + + +3.5.1 Example 1 + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client with + Ethernet MAC address 01:02:03:04:05:06 using domain name + "client.example.com" uses the client's link-layer address to identify + the client. The DHCID RDATA is composed by setting the two type + bytes to zero, and performing an MD5 hash computation across a buffer + containing the Ethernet MAC type byte, 0x01, the six bytes of MAC + address, and the domain name (represented as specified in Section + 3.4). + + client.example.com. A 10.0.0.1 + client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU + + +3.5.2 Example 2 + + A DHCP server allocates the IPv4 address 10.0.12.99 to a client which + included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c + in its DHCP request. The server updates the name "chi.example.com" + on the client's behalf, and uses the DHCP client identifier option + data as input in forming a DHCID RR. The DHCID RDATA is formed by + setting the two type bytes to the value 0x0001, and performing an MD5 + hash computation across a buffer containing the seven bytes from the + client-id option and the FQDN (represented as specified in Section + 3.4). + + chi.example.com. A 10.0.12.99 + chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 + + +4. Use of the DHCID RR + + This RR MUST NOT be used for any purpose other than that detailed in + "Resolution of DNS Name Conflicts" [1]. Although this RR contains + data that is opaque to DNS servers, the data must be consistent + across all entities that update and interpret this record. + Therefore, new data formats may only be defined through actions of + the DHC Working Group, as a result of revising [1]. + +5. Updater Behavior + + The data in the DHCID RR allows updaters to determine whether more + than one DHCP client desires to use a particular FQDN. This allows + site administrators to establish policy about DNS updates. The DHCID + RR does not establish any policy itself. + + Updaters use data from a DHCP client's request and the domain name + + + +Stapp, et al. Expires January 14, 2005 [Page 6] + +Internet-Draft The DHCID RR July 2004 + + + that the client desires to use to compute a client identity hash, and + then compare that hash to the data in any DHCID RRs on the name that + they wish to associate with the client's IP address. If an updater + discovers DHCID RRs whose RDATA does not match the client identity + that they have computed, the updater SHOULD conclude that a different + client is currently associated with the name in question. The + updater SHOULD then proceed according to the site's administrative + policy. That policy might dictate that a different name be selected, + or it might permit the updater to continue. + +6. Security Considerations + + The DHCID record as such does not introduce any new security problems + into the DNS. In order to avoid exposing private information about + DHCP clients to public scrutiny, a one-way hash is used to obscure + all client information. In order to make it difficult to 'track' a + client by examining the names associated with a particular hash + value, the FQDN is included in the hash computation. Thus, the RDATA + is dependent on both the DHCP client identification data and on each + FQDN associated with the client. + + Administrators should be wary of permitting unsecured DNS updates to + zones which are exposed to the global Internet. Both DHCP clients + and servers SHOULD use some form of update authentication (e.g., TSIG + [11]) when performing DNS updates. + +7. IANA Considerations + + IANA is requested to allocate an RR type number for the DHCID record + type. + + This specification defines a new number-space for the 16-bit type + codes associated with the DHCID RR. IANA is requested to establish a + registry of the values for this number-space. + + Three initial values are assigned in Section 3.3, and the value + 0xFFFF is reserved for future use. New DHCID RR type codes are + tentatively assigned after the specification for the associated type + code, published as an Internet Draft, has received expert review by a + designated expert. The final assignment of DHCID RR type codes is + through Standards Action, as defined in RFC 2434 [6]. + +8. Acknowledgements + + Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and + Ralph Droms for their review and suggestions. + + + + + +Stapp, et al. Expires January 14, 2005 [Page 7] + +Internet-Draft The DHCID RR July 2004 + + +9. References + +9.1 Normative References + + [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among + DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [4] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +9.2 Informative References + + [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [8] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers + for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004. + + + + + + + + +Stapp, et al. Expires January 14, 2005 [Page 8] + +Internet-Draft The DHCID RR July 2004 + + +Authors' Addresses + + Mark Stapp + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + USA + + Phone: 978.936.1535 + EMail: mjs@cisco.com + + + Ted Lemon + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: mellon@nominum.com + + + Andreas Gustafsson + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: gson@nominum.com + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires January 14, 2005 [Page 9] + +Internet-Draft The DHCID RR July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Stapp, et al. Expires January 14, 2005 [Page 10] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt new file mode 100644 index 000000000000..bcc2b4ec516e --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt @@ -0,0 +1,442 @@ + + +INTERNET-DRAFT Samuel Weiler +Expires: June 2004 December 15, 2003 +Updates: RFC 2535, [DS] + + Legacy Resolver Compatibility for Delegation Signer + draft-ietf-dnsext-dnssec-2535typecode-change-06.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Comments should be sent to the author or to the DNSEXT WG mailing + list: namedroppers@ops.ietf.org + +Abstract + + As the DNS Security (DNSSEC) specifications have evolved, the + syntax and semantics of the DNSSEC resource records (RRs) have + changed. Many deployed nameservers understand variants of these + semantics. Dangerous interactions can occur when a resolver that + understands an earlier version of these semantics queries an + authoritative server that understands the new delegation signer + semantics, including at least one failure scenario that will cause + an unsecured zone to be unresolvable. This document changes the + type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to + avoid those interactions. + +Changes between 05 and 06: + + Signifigantly reworked the IANA section -- went back to one + algorithm registry. + + Removed Diffie-Hellman from the list of zone-signing algorithms + (leaving only DSA, RSA/SHA-1, and private algorithms). + + Added a DNSKEY flags field registry. + +Changes between 04 and 05: + + IESG approved publication. + + Cleaned up an internal reference in the acknowledgements section. + + Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference. + + Changed the names of both new registries. Added algorithm + mnemonics to the new zone signing algorithm registry. Minor + rewording in the IANA section for clarity. + + Cleaned up formatting of references. Replaced unknown-rr draft + references with RFC3597. Bumped DS version number. + +Changes between 03 and 04: + + Clarified that RRSIG(0) may be defined by standards action. + + Created a new algorithm registry and renamed the old algorithm + registry for SIG(0) only. Added references to the appropriate + crypto algorithm and format specifications. + + Several minor rephrasings. + +Changes between 02 and 03: + + KEY (as well as SIG) retained for SIG(0) use only. + +Changes between 01 and 02: + + SIG(0) still uses SIG, not RRSIG. Added 2931 reference. + + Domain names embedded in NSECs and RRSIGs are not compressible and + are not downcased. Added unknown-rrs reference (as informative). + + Simplified the last paragraph of section 3 (NSEC doesn't always + signal a negative answer). + + Changed the suggested type code assignments. + + Added 2119 reference. + + Added definitions of "unsecure delegation" and "unsecure referral", + since they're not clearly defined elsewhere. + + Moved 2065 to informative references, not normative. + +1. Introduction + + The DNSSEC protocol has been through many iterations whose syntax + and semantics are not completely compatible. This has occurred as + part of the ordinary process of proposing a protocol, implementing + it, testing it in the increasingly complex and diverse environment + of the Internet, and refining the definitions of the initial + Proposed Standard. In the case of DNSSEC, the process has been + complicated by DNS's criticality and wide deployment and the need + to add security while minimizing daily operational complexity. + + A weak area for previous DNS specifications has been lack of detail + in specifying resolver behavior, leaving implementors largely on + their own to determine many details of resolver function. This, + combined with the number of iterations the DNSSEC spec has been + through, has resulted in fielded code with a wide variety of + behaviors. This variety makes it difficult to predict how a + protocol change will be handled by all deployed resolvers. The + risk that a change will cause unacceptable or even catastrophic + failures makes it difficult to design and deploy a protocol change. + One strategy for managing that risk is to structure protocol + changes so that existing resolvers can completely ignore input that + might confuse them or trigger undesirable failure modes. + + This document addresses a specific problem caused by Delegation + Signer's [DS] introduction of new semantics for the NXT RR that are + incompatible with the semantics in RFC 2535 [RFC2535]. Answers + provided by DS-aware servers can trigger an unacceptable failure + mode in some resolvers that implement RFC 2535, which provides a + great disincentive to sign zones with DS. The changes defined in + this document allow for the incremental deployment of DS. + +1.1 Terminology + + In this document, the term "unsecure delegation" means any + delegation for which no DS record appears at the parent. An + "unsecure referral" is an answer from the parent containing an NS + RRset and a proof that no DS record exists for that name. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2 The Problem + + Delegation Signer introduces new semantics for the NXT RR that are + incompatible with the semantics in RFC 2535. In RFC 2535, NXT + records were only required to be returned as part of a + non-existence proof. With DS, an unsecure referral returns, in + addition to the NS, a proof of non-existence of a DS RR in the form + of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was + to interpret a response with both an NS and an NXT in the authority + section, RCODE=0, and AA=0. Some widely deployed 2535-aware + resolvers interpret any answer with an NXT as a proof of + non-existence of the requested record. This results in unsecure + delegations being invisible to 2535-aware resolvers and violates + the basic architectural principle that DNSSEC must do no harm -- + the signing of zones must not prevent the resolution of unsecured + delegations. + +2. Possible Solutions + + This section presents several solutions that were considered. + Section 3 describes the one selected. + +2.1. Change SIG, KEY, and NXT type codes + + To avoid the problem described above, legacy (RFC2535-aware) + resolvers need to be kept from seeing unsecure referrals that + include NXT records in the authority section. The simplest way to + do that is to change the type codes for SIG, KEY, and NXT. + + The obvious drawback to this is that new resolvers will not be able + to validate zones signed with the old RRs. This problem already + exists, however, because of the changes made by DS, and resolvers + that understand the old RRs (and have compatibility issues with DS) + are far more prevalent than 2535-signed zones. + +2.2. Change a subset of type codes + + The observed problem with unsecure referrals could be addressed by + changing only the NXT type code or another subset of the type codes + that includes NXT. This has the virtue of apparent simplicity, but + it risks introducing new problems or not going far enough. It's + quite possible that more incompatibilities exist between DS and + earlier semantics. Legacy resolvers may also be confused by seeing + records they recognize (SIG and KEY) while being unable to find + NXTs. Although it may seem unnecessary to fix that which is not + obviously broken, it's far cleaner to change all of the type codes + at once. This will leave legacy resolvers and tools completely + blinded to DNSSEC -- they will see only unknown RRs. + +2.3. Replace the DO bit + + Another way to keep legacy resolvers from ever seeing DNSSEC + records with DS semantics is to have authoritative servers only + send that data to DS-aware resolvers. It's been proposed that + assigning a new EDNS0 flag bit to signal DS-awareness (tentatively + called "DA"), and having authoritative servers send DNSSEC data + only in response to queries with the DA bit set, would accomplish + this. This bit would presumably supplant the DO bit described in + RFC 3225. + + This solution is sufficient only if all 2535-aware resolvers zero + out EDNS0 flags that they don't understand. If one passed through + the DA bit unchanged, it would still see the new semantics, and it + would probably fail to see unsecure delegations. Since it's + impractical to know how every DNS implementation handles unknown + EDNS0 flags, this is not a universal solution. It could, though, + be considered in addition to changing the RR type codes. + +2.4. Increment the EDNS version + + Another possible solution is to increment the EDNS version number + as defined in RFC 2671 [RFC2671], on the assumption that all + existing implementations will reject higher versions than they + support, and retain the DO bit as the signal for DNSSEC awareness. + This approach has not been tested. + +2.5. Do nothing + + There is a large deployed base of DNS resolvers that understand + DNSSEC as defined by the standards track RFC 2535 and RFC 2065 + and, due to under specification in those documents, interpret any + answer with an NXT as a non-existence proof. So long as that is + the case, zone owners will have a strong incentive to not sign any + zones that contain unsecure delegations, lest those delegations be + invisible to such a large installed base. This will dramatically + slow DNSSEC adoption. + + Unfortunately, without signed zones there's no clear incentive for + operators of resolvers to upgrade their software to support the new + version of DNSSEC, as defined in [DS]. Historical data suggests + that resolvers are rarely upgraded, and that old nameserver code + never dies. + + Rather than wait years for resolvers to be upgraded through natural + processes before signing zones with unsecure delegations, + addressing this problem with a protocol change will immediately + remove the disincentive for signing zones and allow widespread + deployment of DNSSEC. + +3. Protocol changes + + This document changes the type codes of SIG, KEY, and NXT. This + approach is the cleanest and safest of those discussed above, + largely because the behavior of resolvers that receive unknown type + codes is well understood. This approach has also received the most + testing. + + To avoid operational confusion, it's also necessary to change the + mnemonics for these RRs. DNSKEY will be the replacement for KEY, + with the mnemonic indicating that these keys are not for + application use, per [RFC3445]. RRSIG (Resource Record SIGnature) + will replace SIG, and NSEC (Next SECure) will replace NXT. These + new types completely replace the old types, except that SIG(0) + [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY. + + The new types will have exactly the same syntax and semantics as + specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for + the following: + + 1) Consistent with [RFC3597], domain names embedded in + RRSIG and NSEC RRs MUST NOT be compressed, + + 2) Embedded domain names in RRSIG and NSEC RRs are not downcased + for purposes of DNSSEC canonical form and ordering nor for + equality comparison, and + + 3) An RRSIG with a type-covered field of zero has undefined + semantics. The meaning of such a resource record may only be + defined by IETF Standards Action. + + If a resolver receives the old types, it SHOULD treat them as + unknown RRs and SHOULD NOT assign any special meaning to them or + give them any special treatment. It MUST NOT use them for DNSSEC + validations or other DNS operational decision making. For example, + a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to + validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, + they MUST NOT receive special treatment. As an example, if a SIG + is included in a signed zone, there MUST be an RRSIG for it. + Authoritative servers may wish to give error messages when loading + zones containing SIG or NXT records (KEY records may be included + for SIG(0) or TKEY). + + As a clarification to previous documents, some positive responses, + particularly wildcard proofs and unsecure referrals, will contain + NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as + negative answers merely because they contain an NSEC. + +4. IANA Considerations + +4.1 DNS Resource Record Types + + This document updates the IANA registry for DNS Resource Record + Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and + DNSKEY RRs, respectively. + + Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and + TKEY [RFC2930] use only. + + Type 30 (NXT) should be marked as Obsolete. + +4.2 DNS Security Algorithm Numbers + + To allow zone signing (DNSSEC) and transaction security mechanisms + (SIG(0) and TKEY) to use different sets of algorithms, the existing + "DNS Security Algorithm Numbers" registry is modified to include + the applicability of each algorithm. Specifically, two new columns + are added to the registry, showing whether each algorithm may be + used for zone signing, transaction security mechanisms, or both. + Only algorithms usable for zone signing may be used in DNSKEY, + RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG + may be used in SIG and KEY RRs. + + All currently defined algorithms remain usable for transaction + security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private + algorithms (types 253 and 254) may be used for zone signing. Note + that the registry does not contain the requirement level of each + algorithm, only whether or not an algorithm may be used for the + given purposes. For example, RSA/MD5, while allowed for + transaction security mechanisms, is NOT RECOMMENDED, per RFC3110. + + Additionally, the presentation format algorithm mnemonics from + RFC2535 Section 7 are added to the registry. This document assigns + RSA/SHA-1 the mnemonic RSASHA1. + + As before, assignment of new algorithms in this registry requires + IETF Standards Action. Additionally, modification of algorithm + mnemonics or applicability requires IETF Standards Action. + Documents defining a new algorithm must address the applicability + of the algorithm and should assign a presentation mnemonic to the + algorithm. + +4.3 DNSKEY Flags + + Like the KEY resource record, DNSKEY contains a 16-bit flags field. + This document creates a new registry for the DNSKEY flags field. + + Initially, this registry only contains an assignment for bit 7 (the + ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF + Standards Action. + +4.4 DNSKEY Protocol Octet + + Like the KEY resource record, DNSKEY contains an eight bit protocol + field. The only defined value for this field is 3 (DNSSEC). No + other values are allowed, hence no IANA registry is needed for this + field. + +5. Security Considerations + + The changes introduced here do not materially affect security. + The implications of trying to use both new and legacy types + together are not well understood, and attempts to do so would + probably lead to unintended and dangerous results. + + Changing type codes will leave code paths in legacy resolvers that + are never exercised. Unexercised code paths are a frequent source + of security holes, largely because those code paths do not get + frequent scrutiny. + + Doing nothing, as described in section 2.5, will slow DNSSEC + deployment. While this does not decrease security, it also fails + to increase it. + +6. Normative references + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [DS] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15.txt, work in + progress, June 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2436, March 1999. + + [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)", RFC 3110, May 2001. + +7. Informative References + + [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, + RFC 2929, September 2000. + + [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource + Record (RR) Types", RFC 3597, September 2003. + +8. Acknowledgments + + The changes introduced here and the analysis of alternatives had + many contributors. With apologies to anyone overlooked, those + include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed + Lewis, Bill Manning, and Suzanne Woolf. + + Thanks to Jakob Schlyter and Mark Andrews for identifying the + incompatibility described in section 1.2. + + In addition to the above, the author would like to thank Scott + Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive + comments. + +9. Author's Address + + Samuel Weiler + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + weiler@tislabs.com + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt new file mode 100644 index 000000000000..0783e7b26e14 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt @@ -0,0 +1,1457 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: January 13, 2005 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + July 15, 2004 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-11 + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + The Domain Name System Security Extensions (DNSSEC) add data origin + authentication and data integrity to the Domain Name System. This + + + +Arends, et al. Expires January 13, 2005 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + document introduces these extensions, and describes their + capabilities and limitations. This document also discusses the + services that the DNS security extensions do and do not provide. + Last, this document describes the interrelationships between the + group of documents that collectively describe DNSSEC. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 + 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 + 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 + 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 + 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 + 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 + 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 + 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 + 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 + 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 + 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . . . . . 26 + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents + ([I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the + security extensions defined in RFC 2535 [RFC2535] and its + predecessors. These security extensions consist of a set of new + resource record types and modifications to the existing DNS protocol + [RFC1035]. The new records and protocol modifications are not fully + described in this document, but are described in a family of + documents outlined in Section 10. Section 3 and Section 4 describe + the capabilities and limitations of the security extensions in + greater detail. Section 5 discusses the scope of the document set. + Section 6, Section 7, Section 8, and Section 9 discuss the effect + that these security extensions will have on resolvers, stub + resolvers, zones and name servers. + + This document and its two companions update and obsolete RFCs 2535 + [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 + [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress + [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but + does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 + [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts + of 3226 [RFC3226] (dealing with DNSSEC). + + The DNS security extensions provide origin authentication and + integrity protection for DNS data, as well as a means of public key + distribution. These extensions do not provide confidentiality. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +2. Definitions of Important DNSSEC Terms + + This section defines a number of terms used in this document set. + Since this is intended to be useful as a reference while reading the + rest of the document set, first-time readers may wish to skim this + section quickly, read the rest of this document, then come back to + this section. + + Authentication Chain: An alternating sequence of DNSKEY RRsets and DS + RRsets forms a chain of signed data, with each link in the chain + vouching for the next. A DNSKEY RR is used to verify the + signature covering a DS RR and allows the DS RR to be + authenticated. The DS RR contains a hash of another DNSKEY RR and + this new DNSKEY RR is authenticated by matching the hash in the DS + RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset + and, in turn, some DNSKEY RR in this set may be used to + authenticate another DS RR and so forth until the chain finally + ends with a DNSKEY RR whose corresponding private key signs the + desired DNS data. For example, the root DNSKEY RRset can be used + to authenticate the DS RRset for "example." The "example." DS + RRset contains a hash that matches some "example." DNSKEY, and + this DNSKEY's corresponding private key signs the "example." + DNSKEY RRset. Private key counterparts of the "example." DNSKEY + RRset sign data records such as "www.example." as well as DS RRs + for delegations such as "subzone.example." + + Authentication Key: A public key that a security-aware resolver has + verified and can therefore use to authenticate data. A + security-aware resolver can obtain authentication keys in three + ways. First, the resolver is generally configured to know about + at least one public key; this configured data is usually either + the public key itself or a hash of the public key as found in the + DS RR (see "trust anchor"). Second, the resolver may use an + authenticated public key to verify a DS RR and the DNSKEY RR to + which the DS RR refers. Third, the resolver may be able to + determine that a new public key has been signed by the private key + corresponding to another public key which the resolver has + verified. Note that the resolver must always be guided by local + policy when deciding whether to authenticate a new public key, + even if the local policy is simply to authenticate any new public + key for which the resolver is able verify the signature. + + Delegation Point: Term used to describe the name at the parental side + of a zone cut. That is, the delegation point for "foo.example" + would be the foo.example node in the "example" zone (as opposed to + the zone apex of the "foo.example" zone). + + + + + +Arends, et al. Expires January 13, 2005 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + Island of Security: Term used to describe a signed, delegated zone + that does not have an authentication chain from its delegating + parent. That is, there is no DS RR containing a hash of a DNSKEY + RR for the island in its delegating parent zone (see + [I-D.ietf-dnsext-dnssec-records]). An island of security is + served by security-aware name servers and may provide + authentication chains to any delegated child zones. Responses + from an island of security or its descendents can only be + authenticated if its authentication keys can be authenticated by + some trusted means out of band from the DNS protocol. + + Key Signing Key (KSK): An authentication key that corresponds to a + private key used to sign one or more other authentication keys for + a given zone. Typically, the private key corresponding to a key + signing key will sign a zone signing key, which in turn has a + corresponding private key which will sign other zone data. Local + policy may require the zone signing key to be changed frequently, + while the key signing key may have a longer validity period in + order to provide a more stable secure entry point into the zone. + Designating an authentication key as a key signing key is purely + an operational issue: DNSSEC validation does not distinguish + between key signing keys and other DNSSEC authentication keys, and + it is possible to use a single key as both a key signing key and a + zone signing key. Key signing keys are discussed in more detail + in [RFC3757]. Also see: zone signing key. + + Non-Validating Security-Aware Stub Resolver: A security-aware stub + resolver which trusts one or more security-aware recursive name + servers to perform most of the tasks discussed in this document + set on its behalf. In particular, a non-validating security-aware + stub resolver is an entity which sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server which will + provide these services on behalf of the security-aware stub + resolver. See also: security-aware stub resolver, validating + security-aware stub resolver. + + Non-Validating Stub Resolver: A less tedious term for a + non-validating security-aware stub resolver. + + Security-Aware Name Server: An entity acting in the role of a name + server (defined in section 2.4 of [RFC1034]) that understands the + DNS security extensions defined in this document set. In + particular, a security-aware name server is an entity which + receives DNS queries, sends DNS responses, supports the EDNS0 + [RFC2671] message size extension and the DO bit [RFC3225], and + supports the RR types and message header bits defined in this + document set. + + + +Arends, et al. Expires January 13, 2005 [Page 5] + + + Security-Aware Recursive Name Server: An entity which acts in both + the security-aware name server and security-aware resolver roles. + A more cumbersome equivalent phrase would be "a security-aware + name server which offers recursive service". + + Security-Aware Resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [RFC1034]) which understands the DNS + security extensions defined in this document set. In particular, + a security-aware resolver is an entity which sends DNS queries, + receives DNS responses, supports the EDNS0 [RFC2671] message size + extension and the DO bit [RFC3225], and is capable of using the RR + types and message header bits defined in this document set to + provide DNSSEC services. + + Security-Aware Stub Resolver: An entity acting in the role of a stub + resolver (defined in section 5.3.1 of [RFC1034]) which has enough + of an understanding the DNS security extensions defined in this + document set to provide additional services not available from a + security-oblivious stub resolver. Security-aware stub resolvers + may be either "validating" or "non-validating" depending on + whether the stub resolver attempts to verify DNSSEC signatures on + its own or trusts a friendly security-aware name server to do so. + See also: validating stub resolver, non-validating stub resolver. + + Security-Oblivious : An that is not + "security-aware". + + Signed Zone: A zone whose RRsets are signed and which contains + properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS + records. + + Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A + validating security-aware resolver uses this public key or hash as + a starting point for building the authentication chain to a signed + DNS response. In general, a validating resolver will need to + obtain the initial values of its trust anchors via some secure or + trusted means outside the DNS protocol. Presence of a trust + anchor also implies that the resolver should expect the zone to + which the trust anchor points to be signed. + + Unsigned Zone: A zone that is not signed. + + Validating Security-Aware Stub Resolver: A security-aware resolver + that sends queries in recursive mode but which performs signature + validation on its own rather than just blindly trusting an + upstream security-aware recursive name server. See also: + security-aware stub resolver, non-validating security-aware stub + resolver. + + + + + +Arends, et al. Expires January 13, 2005 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + Validating Stub Resolver: A less tedious term for a validating + security-aware stub resolver. + + Zone Signing Key (ZSK): An authentication key that corresponds to a + private key used to sign a zone. Typically a zone signing key + will be part of the same DNSKEY RRset as the key signing key whose + corresponding private key signs this DNSKEY RRset, but the zone + signing key is used for a slightly different purpose, and may + differ from the key signing key in other ways, such as validity + lifetime. Designating an authentication key as a zone signing key + is purely an operational issue: DNSSEC validation does not + distinguish between zone signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. See also: key + signing key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +3. Services Provided by DNS Security + + The Domain Name System (DNS) security extensions provide origin + authentication and integrity assurance services for DNS data, + including mechanisms for authenticated denial of existence of DNS + data. These mechanisms are described below. + + These mechanisms require changes to the DNS protocol. DNSSEC adds + four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two + new message header bits (CD and AD). In order to support the larger + DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also + requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support + for the DO bit [RFC3225], so that a security-aware resolver can + indicate in its queries that it wishes to receive DNSSEC RRs in + response messages. + + These services protect against most of the threats to the Domain Name + System described in [I-D.ietf-dnsext-dns-threats]. + +3.1 Data Origin Authentication and Data Integrity + + DNSSEC provides authentication by associating cryptographically + generated digital signatures with DNS RRsets. These digital + signatures are stored in a new resource record, the RRSIG record. + Typically, there will be a single private key that signs a zone's + data, but multiple keys are possible: for example, there may be keys + for each of several different digital signature algorithms. If a + security-aware resolver reliably learns a zone's public key, it can + authenticate that zone's signed data. An important DNSSEC concept is + that the key that signs a zone's data is associated with the zone + itself and not with the zone's authoritative name servers (public + keys for DNS transaction authentication mechanisms may also appear in + zones, as described in [RFC2931], but DNSSEC itself is concerned with + object security of DNS data, not channel security of DNS + transactions. The keys associated with transaction security may be + stored in different RR types. See [RFC3755] for details.). + + A security-aware resolver can learn a zone's public key either by + having a trust anchor configured into the resolver or by normal DNS + resolution. To allow the latter, public keys are stored in a new + type of resource record, the DNSKEY RR. Note that the private keys + used to sign zone data must be kept secure, and should be stored + offline when practical to do so. To discover a public key reliably + via DNS resolution, the target key itself needs to be signed by + either a configured authentication key or another key that has been + authenticated previously. Security-aware resolvers authenticate zone + information by forming an authentication chain from a newly learned + public key back to a previously known authentication public key, + + + +Arends, et al. Expires January 13, 2005 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + which in turn either has been configured into the resolver or must + have been learned and verified previously. Therefore, the resolver + must be configured with at least one trust anchor. If the configured + key is a zone signing key, then it will authenticate the associated + zone; if the configured key is a key signing key, it will + authenticate a zone signing key. If the resolver has been configured + with the hash of a key rather than the key itself, the resolver may + need to obtain the key via a DNS query. To help security-aware + resolvers establish this authentication chain, security-aware name + servers attempt to send the signature(s) needed to authenticate a + zone's public key(s) in the DNS reply message along with the public + key itself, provided there is space available in the message. + + The Delegation Signer (DS) RR type simplifies some of the + administrative tasks involved in signing delegations across + organizational boundaries. The DS RRset resides at a delegation + point in a parent zone and indicates the public key(s) corresponding + to the private key(s) used to self-sign the DNSKEY RRset at the + delegated child zone's apex. The administrator of the child zone, in + turn, uses the private key(s) corresponding to one or more of the + public keys in this DNSKEY RRset to sign the child zone's data. The + typical authentication chain is therefore + DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more + DS->DNSKEY subchains. DNSSEC permits more complex authentication + chains, such as additional layers of DNSKEY RRs signing other DNSKEY + RRs within a zone. + + A security-aware resolver normally constructs this authentication + chain from the root of the DNS hierarchy down to the leaf zones based + on configured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to use one + or more configured public keys (or hashes of public keys) other than + the root public key, or may not provide configured knowledge of the + root public key, or may prevent the resolver from using particular + public keys for arbitrary reasons even if those public keys are + properly signed with verifiable signatures. DNSSEC provides + mechanisms by which a security-aware resolver can determine whether + an RRset's signature is "valid" within the meaning of DNSSEC. In the + final analysis however, authenticating both DNS keys and data is a + matter of local policy, which may extend or even override the + protocol extensions defined in this document set. See Section 5 for + further discussion. + +3.2 Authenticating Name and Type Non-Existence + + The security mechanism described in Section 3.1 only provides a way + to sign existing RRsets in a zone. The problem of providing negative + responses with the same level of authentication and integrity + + + +Arends, et al. Expires January 13, 2005 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + requires the use of another new resource record type, the NSEC + record. The NSEC record allows a security-aware resolver to + authenticate a negative reply for either name or type non-existence + via the same mechanisms used to authenticate other DNS replies. Use + of NSEC records requires a canonical representation and ordering for + domain names in zones. Chains of NSEC records explicitly describe + the gaps, or "empty space", between domain names in a zone, as well + as listing the types of RRsets present at existing names. Each NSEC + record is signed and authenticated using the mechanisms described in + Section 3.1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + on cryptographic operations. Please see Section 12 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above are not designed to + protect operations such as zone transfers and dynamic update + [RFC3007]. Message authentication schemes described in [RFC2845] and + [RFC2931] address security operations that pertain to these + transactions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +5. Scope of the DNSSEC Document Set and Last Hop Issues + + The specification in this document set defines the behavior for zone + signers and security-aware name servers and resolvers in such a way + that the validating entities can unambiguously determine the state of + the data. + + A validating resolver can determine these 4 states: + + Secure: The validating resolver has a trust anchor, a chain of trust + and is able to verify all the signatures in the response. + + Insecure: The validating resolver has a trust anchor, a chain of + trust, and, at some delegation point, signed proof of the + non-existence of a DS record. That indicates that subsequent + branches in the tree are provably insecure. A validating resolver + may have local policy to mark parts of the domain space as + insecure. + + Bogus: The validating resolver has a trust anchor and there is a + secure delegation which is indicating that subsidiary data will be + signed, but the response fails to validate due to one or more + reasons: missing signatures, expired signatures, signatures with + unsupported algorithms, data missing which the relevant NSEC RR + says should be present, and so forth. + + Indeterminate: There is no trust anchor which would indicate that a + specific portion of the tree is secure. This is the default + operation mode. + + This specification only defines how security aware name servers can + signal non-validating stub resolvers that data was found to be bogus + (using RCODE=2, "Server Failure" -- see + [I-D.ietf-dnsext-dnssec-protocol]). + + There is a mechanism for security aware name servers to signal + security-aware stub resolvers that data was found to be secure (using + the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). + + This specification does not define a format for communicating why + responses were found to be bogus or marked as insecure. The current + signaling mechanism does not distinguish between indeterminate and + insecure. + + A method for signaling advanced error codes and policy between a + security aware stub resolver and security aware recursive nameservers + is a topic for future work, as is the interface between a security + aware resolver and the applications that use it. Note, however, that + + + +Arends, et al. Expires January 13, 2005 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + the lack of the specification of such communication does not prohibit + deployment of signed zones or the deployment of security aware + recursive name servers that prohibit propagation of bogus data to the + applications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +6. Resolver Considerations + + A security-aware resolver needs to be able to perform cryptographic + functions necessary to verify digital signatures using at least the + mandatory-to-implement algorithm(s). Security-aware resolvers must + also be capable of forming an authentication chain from a newly + learned zone back to an authentication key, as described above. This + process might require additional queries to intermediate DNS zones to + obtain necessary DNSKEY, DS and RRSIG records. A security-aware + resolver should be configured with at least one trust anchor as the + starting point from which it will attempt to establish authentication + chains. + + If a security-aware resolver is separated from the relevant + authoritative name servers by a recursive name server or by any sort + of device which acts as a proxy for DNS, and if the recursive name + server or proxy is not security-aware, the security-aware resolver + may not be capable of operating in a secure mode. For example, if a + security-aware resolver's packets are routed through a network + address translation device that includes a DNS proxy which is not + security-aware, the security-aware resolver may find it difficult or + impossible to obtain or validate signed DNS data. + + If a security-aware resolver must rely on an unsigned zone or a name + server that is not security aware, the resolver may not be able to + validate DNS responses, and will need a local policy on whether to + accept unverified responses. + + A security-aware resolver should take a signature's validation period + into consideration when determining the TTL of data in its cache, to + avoid caching signed data beyond the validity period of the + signature, but should also allow for the possibility that the + security-aware resolver's own clock is wrong. Thus, a security-aware + resolver which is part of a security-aware recursive name server will + need to pay careful attention to the DNSSEC "checking disabled" (CD) + bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid + blocking valid signatures from getting through to other + security-aware resolvers which are clients of this recursive name + server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure + recursive server handles queries with the CD bit set. + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +7. Stub Resolver Considerations + + Although not strictly required to do so by the protocol, most DNS + queries originate from stub resolvers. Stub resolvers, by + definition, are minimal DNS resolvers which use recursive query mode + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + architecture has to take stub resolvers into account, but the + security features needed in a stub resolver differ in some respects + from those needed in a full security-aware resolver. + + Even a security-oblivious stub resolver may get some benefit from + DNSSEC if the recursive name servers it uses are security-aware, but + for the stub resolver to place any real reliance on DNSSEC services, + the stub resolver must trust both the recursive name servers in + question and the communication channels between itself and those name + servers. The first of these issues is a local policy issue: in + essence, a security-oblivious stub resolver has no real choice but to + place itself at the mercy of the recursive name servers that it uses, + since it does not perform DNSSEC validity checks on its own. The + second issue requires some kind of channel security mechanism; proper + use of DNS transaction authentication mechanisms such as SIG(0) or + TSIG would suffice, as would appropriate use of IPsec, and particular + implementations may have other choices available, such as operating + system specific interprocess communication mechanisms. + Confidentiality is not needed for this channel, but data integrity + and message authentication are. + + A security-aware stub resolver that does trust both its recursive + name servers and its communication channel to them may choose to + examine the setting of the AD bit in the message header of the + response messages it receives. The stub resolver can use this flag + bit as a hint to find out whether the recursive name server was able + to validate signatures for all of the data in the Answer and + Authority sections of the response. + + There is one more step that a security-aware stub resolver can take + if, for whatever reason, it is not able to establish a useful trust + relationship with the recursive name servers which it uses: it can + perform its own signature validation, by setting the Checking + Disabled (CD) bit in its query messages. A validating stub resolver + is thus able to treat the DNSSEC signatures as a trust relationship + between the zone administrator and the stub resolver itself. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +8. Zone Considerations + + There are several differences between signed and unsigned zones. A + signed zone will contain additional security-related records (RRSIG, + DNSKEY, DS and NSEC records). RRSIG and NSEC records may be + generated by a signing process prior to serving the zone. The RRSIG + records that accompany zone data have defined inception and + expiration times, which establish a validity period for the + signatures and the zone data the signatures cover. + +8.1 TTL values vs. RRSIG validity period + + It is important to note the distinction between a RRset's TTL value + and the signature validity period specified by the RRSIG RR covering + that RRset. DNSSEC does not change the definition or function of the + TTL value, which is intended to maintain database coherency in + caches. A caching resolver purges RRsets from its cache no later + than the end of the time period specified by the TTL fields of those + RRsets, regardless of whether or not the resolver is security-aware. + + The inception and expiration fields in the RRSIG RR + [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time + period during which the signature can be used to validate the covered + RRset. The signatures associated with signed zone data are only + valid for the time period specified by these fields in the RRSIG RRs + in question. TTL values cannot extend the validity period of signed + RRsets in a resolver's cache, but the resolver may use the time + remaining before expiration of the signature validity period of a + signed RRset as an upper bound for the TTL of the signed RRset and + its associated RRSIG RR in the resolver's cache. + +8.2 New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency which did not + exist in the original DNS protocol. A signed zone requires regular + maintenance to ensure that each RRset in the zone has a current valid + RRSIG RR. The signature validity period of an RRSIG RR is an + interval during which the signature for one particular signed RRset + can be considered valid, and the signatures of different RRsets in a + zone may expire at different times. Re-signing one or more RRsets in + a zone will change one or more RRSIG RRs, which in turn will require + incrementing the zone's SOA serial number to indicate that a zone + change has occurred and re-signing the SOA RRset itself. Thus, + re-signing any RRset in a zone may also trigger DNS NOTIFY messages + and zone transfers operations. + + + + + + +Arends, et al. Expires January 13, 2005 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +9. Name Server Considerations + + A security-aware name server should include the appropriate DNSSEC + records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from + resolvers which have signaled their willingness to receive such + records via use of the DO bit in the EDNS header, subject to message + size limitations. Since inclusion of these DNSSEC RRs could easily + cause UDP message truncation and fallback to TCP, a security-aware + name server must also support the EDNS "sender's UDP payload" + mechanism. + + If possible, the private half of each DNSSEC key pair should be kept + offline, but this will not be possible for a zone for which DNS + dynamic update has been enabled. In the dynamic update case, the + primary master server for the zone will have to re-sign the zone when + updated, so the private key corresponding to the zone signing key + will have to be kept online. This is an example of a situation where + the ability to separate the zone's DNSKEY RRset into zone signing + key(s) and key signing key(s) may be useful, since the key signing + key(s) in such a case can still be kept offline and may have a longer + useful lifetime than the zone signing key(s). + + DNSSEC, by itself, is not enough to protect the integrity of an + entire zone during zone transfer operations, since even a signed zone + contains some unsigned, nonauthoritative data if the zone has any + children. Therefore, zone maintenance operations will require some + additional mechanisms (most likely some form of channel security, + such as TSIG, SIG(0), or IPsec). + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +10. DNS Security Document Family + + The DNSSEC document set can be partitioned into several main groups, + under the larger umbrella of the DNS base protocol documents. + + The "DNSSEC protocol document set" refers to the three documents + which form the core of the DNS security extensions: + 1. DNS Security Introduction and Requirements (this document) + 2. Resource Records for DNS Security Extensions + [I-D.ietf-dnsext-dnssec-records] + 3. Protocol Modifications for the DNS Security Extensions + [I-D.ietf-dnsext-dnssec-protocol] + + Additionally, any document that would add to, or change the core DNS + Security extensions would fall into this category. This includes any + future work on the communication between security-aware stub + resolvers and upstream security-aware recursive name servers. + + The "Digital Signature Algorithm Specification" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + record format. Each document in this set deals with a specific + digital signature algorithm. + + The "Transaction Authentication Protocol" document set refers to the + group of documents that deal with DNS message authentication, + including secret key establishment and verification. While not + strictly part of the DNSSEC specification as defined in this set of + documents, this group is noted because of its relationship to DNSSEC. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. DNSSEC does not provide any direct security for + these new uses, but may be used to support them. Documents that fall + in this category include the use of DNS in the storage and + distribution of certificates [RFC2538]. + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +11. IANA Considerations + + This overview document introduces no new IANA considerations. Please + see [I-D.ietf-dnsext-dnssec-records] for a complete review of the + IANA considerations introduced by DNSSEC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +12. Security Considerations + + This document introduces the DNS security extensions and describes + the document set that contains the new security records and DNS + protocol modifications. The extensions provide data origin + authentication and data integrity using digital signatures over + resource record sets.This document discusses the capabilities and + limitations of these extensions. + + In order for a security-aware resolver to validate a DNS response, + all zones along the path from the trusted starting point to the zone + containing the response zones must be signed, and all name servers + and resolvers involved in the resolution process must be + security-aware, as defined in this document set. A security-aware + resolver cannot verify responses originating from an unsigned zone, + from a zone not served by a security-aware name server, or for any + DNS data which the resolver is only able to obtain through a + recursive name server which is not security-aware. If there is a + break in the authentication chain such that a security-aware resolver + cannot obtain and validate the authentication keys it needs, then the + security-aware resolver cannot validate the affected DNS data. + + This document briefly discusses other methods of adding security to a + DNS query, such as using a channel secured by IPsec or using a DNS + transaction authentication mechanism, but transaction security is not + part of DNSSEC per se. + + A non-validating security-aware stub resolver, by definition, does + not perform DNSSEC signature validation on its own, and thus is + vulnerable both to attacks on (and by) the security-aware recursive + name servers which perform these checks on its behalf and also to + attacks on its communication with those security-aware recursive name + servers. Non-validating security-aware stub resolvers should use + some form of channel security to defend against the latter threat. + The only known defense against the former threat would be for the + security-aware stub resolver to perform its own signature validation, + at which point, again by definition, it would no longer be a + non-validating security-aware stub resolver. + + DNSSEC does not protect against denial of service attacks. DNSSEC + makes DNS vulnerable to a new class of denial of service attacks + based on cryptographic operations against security-aware resolvers + and security-aware name servers, since an attacker can attempt to use + DNSSEC mechanisms to consume a victim's resources. This class of + attacks takes at least two forms. An attacker may be able to consume + resources in a security-aware resolver's signature validation code by + tampering with RRSIG RRs in response messages or by constructing + needlessly complex signature chains. An attacker may also be able to + + + +Arends, et al. Expires January 13, 2005 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + consume resources in a security-aware name server which supports DNS + dynamic update, by sending a stream of update messages that force the + security-aware name server to re-sign some RRsets in the zone more + frequently than would otherwise be necessary. + + DNSSEC does not provide confidentiality, due to a deliberate design + choice. + + DNSSEC introduces the ability for a hostile party to enumerate all + the names in a zone by following the NSEC chain. NSEC RRs assert + which names do not exist in a zone by linking from existing name to + existing name along a canonical ordering of all the names within a + zone. Thus, an attacker can query these NSEC RRs in sequence to + obtain all the names in a zone. While not an attack on the DNS + itself, this could allow an attacker to map network hosts or other + resources by enumerating the contents of a zone. + + DNSSEC introduces significant additional complexity to the DNS, and + thus introduces many new opportunities for implementation bugs and + misconfigured zones. In particular, enabling DNSSEC signature + validation in a resolver may cause entire legitimate zones to become + effectively unreachable due to DNSSEC configuration errors or bugs. + + DNSSEC does not protect against tampering with unsigned zone data. + Non-authoritative data at zone cuts (glue and NS RRs in the parent + zone) are not signed. This does not pose a problem when validating + the authentication chain, but does mean that the non-authoritative + data itself is vulnerable to tampering during zone transfer + operations. Thus, while DNSSEC can provide data origin + authentication and data integrity for RRsets, it cannot do so for + zones, and other mechanisms must be used to protect zone transfer + operations. + + Please see [I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations. + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +13. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group. While explicitly listing everyone + who has contributed during the decade during which DNSSEC has been + under development would be an impossible task, the editors would + particularly like to thank the following people for their + contributions to and comments on this document set: Jaap Akkerhuis, + Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, + David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald + Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, + Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip + Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, + Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon + Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, + Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, + Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ + Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, + Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob + Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and + Suzanne Woolf. + + No doubt the above list is incomplete. We apologize to anyone we + left out. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +14. References + +14.1 Normative References + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in + progress), May 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-08 (work in progress), + May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + +14.2 Informative References + + [I-D.ietf-dnsext-dns-threats] + Atkins, D. and R. Austein, "Threat Analysis Of The Domain + Name System", draft-ietf-dnsext-dns-threats-07 (work in + progress), April 2004. + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "DNSSEC NSEC RDATA Format", + draft-ietf-dnsext-nsec-rdata-06 (work in progress), May + 2004. + + + +Arends, et al. Expires January 13, 2005 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in + the Domain Name System (DNS)", RFC 2538, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 24] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + +Arends, et al. Expires January 13, 2005 [Page 25] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 13, 2005 [Page 26] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt new file mode 100644 index 000000000000..5728b35c9ba5 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt @@ -0,0 +1,3193 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: January 13, 2005 M. Larson + VeriSign + R. Austein + ISC + D. Massey + USC/ISI + S. Rose + NIST + July 15, 2004 + + + Protocol Modifications for the DNS Security Extensions + draft-ietf-dnsext-dnssec-protocol-07 + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents which describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + + + +Arends, et al. Expires January 13, 2005 [Page 1] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + collection of new resource records and protocol modifications which + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + defines the concept of a signed zone, along with the requirements for + serving and resolving using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5 + 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 + 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 + 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 + 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7 + 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 + 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10 + 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 + 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 + 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 + 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 + 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 + 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 + 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 + 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 + 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 + 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 + 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.2 Signature Verification Support . . . . . . . . . . . . . . 19 + 4.3 Determining Security Status of Data . . . . . . . . . . . 20 + 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20 + 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21 + 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 + 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 + 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 + 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 + 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23 + + + +Arends, et al. Expires January 13, 2005 [Page 2] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23 + 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 + 5.1 Special Considerations for Islands of Security . . . . . . 26 + 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 + 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 + 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 + 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 + 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 + 5.3.4 Authenticating A Wildcard Expanded RRset Positive + Response . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 + 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 + 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 + B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 + B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 + C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 + C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 + C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 + C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 + C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 + C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 + C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 + C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 + C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 + Intellectual Property and Copyright Statements . . . . . . . . 57 + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 3] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications which add data origin + authentication and data integrity to the DNS. This document defines + the DNSSEC protocol modifications. Section 2 of this document + defines the concept of a signed zone and lists the requirements for + zone signing. Section 3 describes the modifications to authoritative + name server behavior necessary to handle signed zones. Section 4 + describes the behavior of entities which include security-aware + resolver functions. Finally, Section 5 defines how to use DNSSEC RRs + to authenticate a response. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in [RFC1034] and [RFC1035]. + + This document is part of a family of documents that define DNSSEC. + An introduction to DNSSEC and definition of common terms can be found + in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be + familiar with this document. A definition of the DNSSEC resource + records can be found in [I-D.ietf-dnsext-dnssec-records]. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. [RFC2119]. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 4] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to + the rules specified in Section 2.1, Section 2.2, Section 2.3 and + Section 2.4, respectively. A zone that does not include these + records according to the rules in this section is an unsigned zone. + + DNSSEC requires a change to the definition of the CNAME resource + record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG + and NSEC RRs to appear at the same owner name as a CNAME RR. + + DNSSEC specifies the placement of two new RR types, NSEC and DS, + which can be placed at the parental side of a zone cut (that is, at a + delegation point). This is an exception to the general prohibition + against putting data in the parent zone at a zone cut. Section 2.6 + describes this change. + +2.1 Including DNSKEY RRs in a Zone + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR + containing the corresponding public key. A zone key DNSKEY RR MUST + have the Zone Key bit of the flags RDATA field set -- see Section + 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys associated + with other DNS operations MAY be stored in DNSKEY RRs that are not + marked as zone keys but MUST NOT be used to verify RRSIGs. + + If the zone administrator intends a signed zone to be usable other + than as an island of security, the zone apex MUST contain at least + one DNSKEY RR to act as a secure entry point into the zone. This + secure entry point could then be used as the target of a secure + delegation via a corresponding DS RR in the parent zone (see + [I-D.ietf-dnsext-dnssec-records]). + +2.2 Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone, there MUST be at least + one RRSIG record that meets all of the following requirements: + o The RRSIG owner name is equal to the RRset owner name; + o The RRSIG class is equal to the RRset class; + o The RRSIG Type Covered field is equal to the RRset type; + o The RRSIG Original TTL field is equal to the TTL of the RRset; + o The RRSIG RR's TTL is equal to the TTL of the RRset; + o The RRSIG Labels field is equal to the number of labels in the + RRset owner name, not counting the null root label and not + + + +Arends, et al. Expires January 13, 2005 [Page 5] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + counting the leftmost label if it is a wildcard; + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset; and + o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key DNSKEY record at the zone apex. + + The process for constructing the RRSIG RR for a given RRset is + described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have + multiple RRSIG RRs associated with it. + + An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR + would add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated + with delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset + itself MUST be signed by each algorithm appearing in the DS RRset + located at the delegating parent (if any). + +2.3 Including NSEC RRs in a Zone + + Each owner name in the zone which has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + format of NSEC RRs and the process for constructing the NSEC RR for a + given name is described in [I-D.ietf-dnsext-dnssec-records]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner names nodes which were + not the owner name of any RRset before the zone was signed. The main + reasons for this are a desire for namespace consistency between + signed and unsigned versions of the same zone and a desire to reduce + the risk of response inconsistency in security oblivious recursive + name servers. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + + + +Arends, et al. Expires January 13, 2005 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + The difference between the set of owner names that require RRSIG + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + signed zone to its children. Neither NSEC nor RRSIG records are + present (in the parent zone) at the owner names of glue address + RRsets. Note, however, that this distinction is for the most part is + only visible during the zone signing process, because NSEC RRsets are + authoritative data, and are therefore signed, thus any owner name + which has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + +2.4 Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR which is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (that is, the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5 Changes to the CNAME Resource Record. + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed. Other types + MUST NOT be present at that name. + + + + +Arends, et al. Expires January 13, 2005 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + +2.6 DNSSEC RR Types Appearing at Zone Cuts. + + DNSSEC introduced two new RR types that are unusual in that they can + appear at the parental side of a zone cut. At the parental side of a + zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at + the owner name. A DS RR could also be present if the zone being + delegated is signed and wishes to have a chain of authentication to + the parent zone. This is an exception to the original DNS + specification ([RFC1034]) which states that only NS RRsets could + appear at the parental side of a zone cut. + + This specification updates the original DNS specification to allow + NSEC and DS RR types at the parent side of a zone cut. These RRsets + are authoritative for the parent when they appear at the parent side + of a zone cut. + +2.7 Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 8] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +3. Serving + + This section describes the behavior of entities that include + security-aware name server functions. In many cases such functions + will be part of a security-aware recursive name server, but a + security-aware authoritative name server has some of the same + requirements. Functions specific to security-aware recursive name + servers are described in Section 3.2; functions specific to + authoritative servers are described in Section 3.1. + + The terms "SNAME", "SCLASS", and "STYPE" in the following discussion + are as used in [RFC1034]. + + A security-aware name server MUST support the EDNS0 [RFC2671] message + size extension, MUST support a message size of at least 1220 octets, + and SHOULD support a message size of 4000 octets [RFC3226]. + + A security-aware name server which receives a DNS query that does not + include the EDNS OPT pseudo-RR or that has the DO bit clear MUST + treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset, + and MUST NOT perform any of the additional processing described + below. Since the DS RR type has the peculiar property of only + existing in the parent zone at delegation points, DS RRs always + require some special processing, as described in Section 3.1.4.1. + + Security aware name servers that receive explicit queries for + security RR types which match the content of more than one zone that + it serves (for example, NSEC and RRSIG RRs above and below a + delegation point where the server is authoritative for both zones) + should behave self-consistently. The name server MAY return one of + the following: + o The above-delegation RRsets + o The below-delegation RRsets + o Both above and below-delegation RRsets + o Empty answer section (no records) + o Some other response + o An error + As long as the response is always consistent for each query to the + name server. + + DNSSEC allocates two new bits in the DNS message header: the CD + (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + is controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Section 3.1.6, + Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details + on the behavior of these bits. + + + +Arends, et al. Expires January 13, 2005 [Page 9] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + A security aware name server which synthesizes CNAME RRs from DNAME + RRs as described in [RFC2672] SHOULD NOT generate signatures for the + synthesized CNAME RRs. + +3.1 Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS [RFC2671] OPT + pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name + server for a signed zone MUST include additional RRSIG, NSEC, and DS + RRs according to the following rules: + o RRSIG RRs that can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1; + o NSEC RRs that can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.1.3; + o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST + be included in referrals automatically according to the rules in + Section 3.1.4. + + These rules only apply to responses the semantics of which convey + information about the presence or absence of resource records. That + is, these rules are not intended to rule out responses such as RCODE + 4 ("Not Implemented") or RCODE 5 ("Refused"). + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1 Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server SHOULD attempt to send RRSIG RRs that a + security-aware resolver can use to authenticate the RRsets in the + response. A name server SHOULD make every attempt to keep the RRset + and its associated RRSIG(s) together in a response. Inclusion of + RRSIG RRs in a response is subject to the following rules: + o When placing a signed RRset in the Answer section, the name server + MUST also place its RRSIG RRs in the Answer section. The RRSIG + RRs have a higher priority for inclusion than any other RRsets + that may need to be included. If space does not permit inclusion + of these RRSIG RRs, the name server MUST set the TC bit. + o When placing a signed RRset in the Authority section, the name + server MUST also place its RRSIG RRs in the Authority section. + The RRSIG RRs have a higher priority for inclusion than any other + RRsets that may need to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + o When placing a signed RRset in the Additional section, the name + server MUST also place its RRSIG RRs in the Additional section. + If space does not permit inclusion of both the RRset and its + + + +Arends, et al. Expires January 13, 2005 [Page 10] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If + this happens, the name server MUST NOT set the TC bit solely + because these RRSIG RRs didn't fit. + +3.1.2 Including DNSKEY RRs In a Response + + When responding to a query that has the DO bit set and that requests + the SOA or NS RRs at the apex of a signed zone, a security-aware + authoritative name server for that zone MAY return the zone apex + DNSKEY RRset in the Additional section. In this situation, the + DNSKEY RRset and associated RRSIG RRs have lower priority than any + other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + +3.1.3 Including NSEC RRs In a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server for a signed zone MUST include NSEC RRs in + each of the following cases: + + No Data: The zone contains RRsets that exactly match , + but does not contain any RRsets that exactly match . + + Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match but does contain an RRset that matches + via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match , does contain one or more RRsets that match + via wildcard name expansion, but does not contain + any RRsets that match via wildcard name + expansion. + + In each of these cases, the name server includes NSEC RRs in the + response to prove that an exact match for was + not present in the zone and that the response that the name server is + returning is correct given the data that are in the zone. + + + + + +Arends, et al. Expires January 13, 2005 [Page 11] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +3.1.3.1 Including NSEC RRs: No Data Response + + If the zone contains RRsets matching but contains no + RRset matching , then the name server MUST + include the NSEC RR for along with its associated + RRSIG RR(s) in the Authority section of the response (see Section + 3.1.1). If space does not permit inclusion of the NSEC RR or its + associated RRSIG RR(s), the name server MUST set the TC bit (see + Section 3.1.1). + + Since the search name exists, wildcard name expansion does not apply + to this query, and a single signed NSEC RR suffices to prove the + requested RR type does not exist. + +3.1.3.2 Including NSEC RRs: Name Error Response + + If the zone does not contain any RRsets matching + either exactly or via wildcard name expansion, then the name server + MUST include the following NSEC RRs in the Authority section, along + with their associated RRSIG RRs: + o An NSEC RR proving that there is no exact match for ; and + o An NSEC RR proving that the zone contains no RRsets that would + match via wildcard name expansion. + + In some cases a single NSEC RR may prove both of these points, in + that case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + Note that this form of response includes cases in which SNAME + corresponds to an empty non-terminal name within the zone (a name + which is not the owner name for any RRset but which is the parent + name of one or more RRsets). + +3.1.3.3 Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets which exactly match but does contain an RRset which matches via wildcard name expansion, the name server MUST include the + wildcard-expanded answer and the corresponding wildcard-expanded + RRSIG RRs in the Answer section, and MUST include in the Authority + + + +Arends, et al. Expires January 13, 2005 [Page 12] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + section an NSEC RR and associated RRSIG RR(s) proving that the zone + does not contain a closer match for . If space does + not permit inclusion of the answer, NSEC and RRSIG RRs, the name + server MUST set the TC bit (see Section 3.1.1). + +3.1.3.4 Including NSEC RRs: Wildcard No Data Response + + This case is a combination of the previous cases. The zone does not + contain an exact match for , and while the zone does + contain RRsets which match via wildcard expansion, + none of those RRsets match STYPE. The name server MUST include the + following NSEC RRs in the Authority section, along with their + associated RRSIG RRs: + o An NSEC RR proving that there are no RRsets matching STYPE at the + wildcard owner name which matched via wildcard + expansion; and + o An NSEC RR proving that there are no RRsets in the zone which + would have been a closer match for . + + In some cases a single NSEC RR may prove both of these points, in + which case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5 Finding The Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server needs to locate an NSEC RR + which proves that no RRsets matching a particular SNAME exist. + Locating such an NSEC RR within an authoritative zone is relatively + simple, at least in concept. The following discussion assumes that + the name server is authoritative for the zone which would have held + the nonexistent RRsets matching SNAME. The algorithm below is + written for clarity, not efficiency. + + To find the NSEC which proves that no RRsets matching name N exist in + the zone Z which would have held them, construct sequence S + consisting of the owner names of every RRset in Z, sorted into + canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate + names. Find the name M which would have immediately preceded N in S + if any RRsets with owner name N had existed. M is the owner name of + the NSEC RR which proves that no RRsets exist with owner name N. + + + +Arends, et al. Expires January 13, 2005 [Page 13] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + The algorithm for finding the NSEC RR which proves that a given name + is not covered by any applicable wildcard is similar, but requires an + extra step. More precisely, the algorithm for finding the NSEC + proving that no RRsets exist with the applicable wildcard name is + precisely the same as the algorithm for finding the NSEC RR which + proves that RRsets with any other owner name do not exist: the part + that's missing is how to determine the name of the nonexistent + applicable wildcard. In practice, this is easy, because the + authoritative name server has already checked for the presence of + precisely this wildcard name as part of step (1)(c) of the normal + lookup algorithm described in Section 4.3.2 of [RFC1034]. + +3.1.4 Including DS RRs In a Response + + When responding to a query which has the DO bit set, a security-aware + authoritative name server returning a referral includes DNSSEC data + along with the NS RRset. + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. The name server MUST + place the NS RRset before the DS RRset and its associated RRSIG + RR(s). + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR which proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages, and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1 Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, since the name server for + the child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + + + +Arends, et al. Expires January 13, 2005 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + o the name server has received a query for the DS RRset at a zone + cut; and + o the name server is authoritative for the child zone; and + o the name server is not authoritative for the parent zone; and + o the name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all of the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5 Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation. + + An authoritative name server is not required to verify that a zone is + properly signed before sending or accepting a zone transfer. + However, an authoritative name server MAY choose to reject the entire + zone transfer if the zone fails meets any of the signing requirements + described in Section 2. The primary objective of a zone transfer is + to ensure that all authoritative name servers have identical copies + of the zone. An authoritative name server that chooses to perform + its own zone validation MUST NOT selectively reject some RRs and + accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + + + +Arends, et al. Expires January 13, 2005 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + of the zone in which the RRset is authoritative data: in the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut, and + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, since the NSEC RR in the child zone's apex will always + indicate the presence of the child zone's SOA RR while the parental + NSEC RR at the zone cut will never indicate the presence of an SOA + RR. As with any other authoritative RRs, NSEC RRs MUST be included + in zone transfers of the zone in which they are authoritative data: + the parental NSEC RR at a zone cut MUST be included zone transfers of + the parent zone, while the NSEC at the zone apex of the child zone + MUST be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut, + and are authoritative in whichever zone contains the authoritative + RRset for which the RRSIG RR provides the signature. That is, the + RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, while the RRSIG for any RRset in + the child zone's apex will be authoritative in the child zone. + Parental and child RRSIG RRs at a zone cut will never be identical to + each other, since the Signer's Name field of an RRSIG RR in the child + zone's apex will indicate a DNSKEY RR in the child zone's apex while + the same field of a parental RRSIG RR at the zone cut will indicate a + DNSKEY RR in the parent zone's apex. As with any other authoritative + RRs, RRSIG RRs MUST be included in zone transfers of the zone in + which they are authoritative data. + +3.1.6 The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed for use in communication between + security-aware resolvers and security-aware recursive name servers. + These bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + A security-aware name server does not perform signature validation + for authoritative data during query processing even when the CD bit + is clear. A security-aware name server SHOULD clear the CD bit when + composing an authoritative response. + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation, but the name server + MUST NOT do so unless the name server obtained the authoritative zone + via secure means (such as a secure zone transfer mechanism), and MUST + + + +Arends, et al. Expires January 13, 2005 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + NOT do so unless this behavior has been configured explicitly. + + A security-aware name server which supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2 Recursive Name Servers + + As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware + recursive name server is an entity which acts in both the + security-aware name server and security-aware resolver roles. This + section uses the terms "name server side" and "resolver side" to + refer to the code within a security-aware recursive name server which + implements the security-aware name server role and the code which + implements the security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching which would apply to any security-aware resolver. + +3.2.1 The DO bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response, but MUST + NOT strip any DNSSEC RR types that the initiating query explicitly + requested. + +3.2.2 The CD bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + The name server side of a security-aware recursive name server MUST + pass the sense of the CD bit to the resolver side along with the rest + of an initiating query, so that the resolver side will know whether + or not it is required to verify the response data it returns to the + name server side. If the CD bit is set, it indicates that the + originating resolver is willing to perform whatever authentication + its local policy requires, thus the resolver side of the recursive + name server need not perform authentication on the RRsets in the + response. When the CD bit is set the recursive name server SHOULD, + if possible, return the requested data to the originating resolver + + + +Arends, et al. Expires January 13, 2005 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + even if the recursive name server's local authentication policy would + reject the records in question. That is, by setting the CD bit, the + originating resolver has indicated that it takes responsibility for + performing its own authentication, and the recursive name server + should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query which matches an entry in the + resolver side's BAD cache, the name server side's response depends on + the sense of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + + The intent of the above rule is to provide the raw data to clients + which are capable of performing their own signature verification + checks while protecting clients which depend on the resolver side of + a security-aware recursive name server to perform such checks. + Several of the possible reasons why signature validation might fail + involve conditions which may not apply equally to the recursive name + server and the client which invoked it: for example, the recursive + name server's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security which the recursive name + server does not share. In such cases, "protecting" a client which is + capable of performing its own signature validation from ever seeing + the "bad" data does not help the client. + +3.2.3 The AD bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + authentic. The name server side SHOULD set the AD bit if and only if + the resolver side considers all RRsets in the Answer section and any + relevant negative response RRs in the Authority section to be + authentic. The resolver side MUST follow the procedure described in + Section 5 to determine whether the RRs in question are authentic. + However, for backwards compatibility, a recursive name server MAY set + the AD bit when a response includes unsigned CNAME RRs if those CNAME + RRs demonstrably could have been synthesized from an authentic DNAME + RR which is also included in the response according to the synthesis + rules described in [RFC2672]. + +3.3 Example DNSSEC Responses + + See Appendix B for example response packets. + + + + + +Arends, et al. Expires January 13, 2005 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +4. Resolving + + This section describes the behavior of entities that include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1 EDNS Support + + A security-aware resolver MUST include an EDNS [RFC2671] OPT + pseudo-RR with the DO [RFC3225] bit set when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + advertise the supported message size using the "sender's UDP payload + size" field in the EDNS OPT pseudo-RR. A security-aware resolver + MUST handle fragmented UDP packets correctly regardless of whether + any such fragmented packets were received via IPv4 or IPv6. Please + see [RFC3226] for discussion of these requirements. + +4.2 Signature Verification Support + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5, and SHOULD apply them to every + received response except when: + o The security-aware resolver is part of a security-aware recursive + name server, and the response is the result of recursion on behalf + of a query received with the CD bit set; + o The response is the result of a query generated directly via some + form of application interface which instructed the security-aware + resolver not to perform validation for this query; or + o Validation for this query has been disabled by local policy. + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + Security aware resolvers MAY query for missing security RRs in an + attempt to perform validation; implementations that choose to do so + must be aware that the answers received may not be sufficient to + validate the original response. + + When attempting to retrieve missing NSEC RRs which reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + + + +Arends, et al. Expires January 13, 2005 [Page 19] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name; if no NS RRset is present at that name, the + resolver then strips of the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + +4.3 Determining Security Status of Data + + A security-aware resolver MUST be able to determine whether or not it + should expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between four + cases: + + Secure: An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted security anchor to the + RRset. In this case, the RRset should be signed, and is subject + to signature validation as described above. + + Insecure: An RRset for which the resolver knows that it has no chain + of signed DNSKEY and DS RRs from any trusted starting point to the + RRset. This can occur when the target RRset lies in an unsigned + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + Bogus: An RRset for which the resolver believes that it ought to be + able to establish a chain of trust but is unable to do so, either + due to signatures that for some reason fail to validate or due to + missing data which the relevant DNSSEC RRs indicate should be + present. This case may indicate an attack, but may also indicate + a configuration error or some form of data corruption. + + Indeterminate: An RRset for which the resolver is not able to + determine whether or not the RRset should be signed, because the + resolver is not able to obtain the necessary DNSSEC RRs. This can + occur when the security-aware resolver is not able to contact + security-aware name servers for the relevant zones. + +4.4 Configured Trust Anchors + + A security-aware resolver MUST be capable of being configured with at + + + +Arends, et al. Expires January 13, 2005 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + least one trusted public key or DS RR, and SHOULD be capable of being + configured with multiple trusted public keys or DS RRs. Since a + security-aware resolver will not be able to validate signatures + without such a configured trust anchor, the resolver SHOULD have some + reasonably robust mechanism for obtaining such keys when it boots; + examples of such a mechanism would be some form of non-volatile + storage (such as a disk drive) or some form of trusted local network + configuration mechanism. + + Note that trust anchors also covers key material that is updated in a + secure manner. This secure manner could be through physical media, a + key exchange protocol, or some other out of band means. + +4.5 Response Caching + + A security-aware resolver SHOULD cache each response as a single + atomic entry containing the entire answer, including the named RRset + and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. In + most cases the appropriate cache index for the atomic entry will be + the triple , but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double . + + The reason for these recommendations is that, between the initial + query and the expiration of the data from the cache, the + authoritative data might have been changed (for example, via dynamic + update). + + There are two situations for which this is relevant: + 1. By using the RRSIG record, it is possible to deduce that an + answer was synthesized from a wildcard. A security aware + recursive name server could store this wildcard data and use it + to generate positive responses to queries other than the name for + which the original answer was first received. + 2. NSEC RRs received to prove the non-existence of a name could be + reused by a security aware resolver to prove the non-existence of + any name in the name range it spans. + + In theory, a resolver could use wildcards or NSEC RRs to generate + positive and negative responses (respectively) until the TTL or + signatures on the records in question expire. However, it seems + prudent for resolvers to avoid blocking new authoritative data or + synthesizing new data on their own. Resolvers which follow this + recommendation will have a more consistent view of the namespace. + + + + + + +Arends, et al. Expires January 13, 2005 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +4.6 Handling of the CD and AD bits + + A security-aware resolver MAY set a query's CD bit in order to + indicate that the resolver takes responsibility for performing + whatever authentication its local policy requires on the RRsets in + the response. See Section 3.2 for the effect this bit has on the + behavior of security-aware recursive name servers. + + A security-aware resolver MUST clear the AD bit when composing query + messages to protect against buggy name servers which blindly copy + header bits which they do not understand from the query message to + the response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained using a secure channel or + the resolver was specifically configured to regard the message header + bits without using a secure channel. + +4.7 Caching BAD Data + + While many validation errors will be transient, some are likely to be + more persistent, such as those caused by administrative error + (failure to re-sign a zone, clock skew, and so forth). Since + requerying will not help in these cases, validating resolvers might + generate a significant amount of unnecessary DNS traffic as a result + of repeated queries for RRsets with persistent validation failures. + + To prevent such unnecessary DNS traffic, security-aware resolvers MAY + cache data with invalid signatures, with some restrictions. + Conceptually, caching such data is similar to negative caching + [RFC2308], except that instead of caching a valid negative response, + the resolver is caching the fact that a particular answer failed to + validate. This document refers to a cache of data with invalid + signatures as a "BAD cache". + + Resolvers which implement a BAD cache MUST take steps to prevent the + cache from being useful as a denial-of-service attack amplifier. In + particular: + o Since RRsets which fail to validate do not have trustworthy TTLs, + the implementation MUST assign a TTL. This TTL SHOULD be small, + in order to mitigate the effect of caching the results of an + attack. + o In order to prevent caching of a transient validation failure + (which might be the result of an attack), resolvers SHOULD track + queries that result in validation failures, and SHOULD only answer + from the BAD cache after the number of times that responses to + queries for that particular have failed to + validate exceeds a threshold value. + + + +Arends, et al. Expires January 13, 2005 [Page 22] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + Resolvers MUST NOT return RRsets from the BAD cache unless the + resolver is not required to validate the signatures of the RRsets in + question under the rules given in Section 4.2 of this document. See + Section 3.2.2 for discussion of how the responses returned by a + security-aware recursive name server interact with a BAD cache. + +4.8 Synthesized CNAMEs + + A validating security-aware resolver MUST treat the signature of a + valid signed DNAME RR as also covering unsigned CNAME RRs which could + have been synthesized from the DNAME RR as described in [RFC2672], at + least to the extent of not rejecting a response message solely + because it contains such CNAME RRs. The resolver MAY retain such + CNAME RRs in its cache or in the answers it hands back, but is not + required to do so. + +4.9 Stub resolvers + + A security-aware stub resolver MUST support the DNSSEC RR types, at + least to the extent of not mishandling responses just because they + contain DNSSEC RRs. + +4.9.1 Handling of the DO Bit + + A non-validating security-aware stub resolver MAY include the DNSSEC + RRs returned by a security-aware recursive name server as part of the + data that the stub resolver hands back to the application which + invoked it but is not required to do so. A non-validating stub + resolver that wishes to do this will need to set the DO bit in + receive DNSSEC RRs from the recursive name server. + + A validating security-aware stub resolver MUST set the DO bit, since + otherwise it will not receive the DNSSEC RRs it needs to perform + signature validation. + +4.9.2 Handling of the CD Bit + + A non-validating security-aware stub resolver SHOULD NOT set the CD + bit when sending queries unless requested by the application layer, + since by definition, a non-validating stub resolver depends on the + security-aware recursive name server to perform validation on its + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + since otherwise the security-aware recursive name server will answer + the query using the name server's local policy, which may prevent the + stub resolver from receiving data which would be acceptable to the + stub resolver's local policy. + + + +Arends, et al. Expires January 13, 2005 [Page 23] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +4.9.3 Handling of the AD Bit + + A non-validating security-aware stub resolver MAY chose to examine + the setting of the AD bit in response messages that it receives in + order to determine whether the security-aware recursive name server + which sent the response claims to have cryptographically verified the + data in the Answer and Authority sections of the response message. + Note, however, that the responses received by a security-aware stub + resolver are heavily dependent on the local policy of the + security-aware recursive name server, so as a practical matter there + may be little practical value to checking the status of the AD bit + except perhaps as a debugging aid. In any case, a security-aware + stub resolver MUST NOT place any reliance on signature validation + allegedly performed on its behalf except when the security-aware stub + resolver obtained the data in question from a trusted security-aware + recursive name server via a secure channel. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, since, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 24] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +5. Authenticating DNS Responses + + In order to use DNSSEC RRs for authentication, a security-aware + resolver requires configured knowledge of at least one authenticated + DNSKEY or DS RR. The process for obtaining and authenticating this + initial trust anchors is achieved via some external mechanism. For + example, a resolver could use some off-line authenticated exchange to + obtain a zone's DNSKEY RR or obtain a DS RR that identifies and + authenticates a zone's DNSKEY RR. The remainder of this section + assumes that the resolver has somehow obtained an initial set of + trust anchors. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset using an initial key, + the resolver MUST: + 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag + (DNSKEY RDATA bit 7) set. + 2. Verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset using an + initial DNSKEY RR, delegations from that zone can be authenticated + using DS RRs. This allows a resolver to start from an initial key, + and use DS RRsets to proceed recursively down the DNS tree obtaining + other apex DNSKEY RRsets. If the resolver were configured with a + root DNSKEY RR, and if every delegation had a DS RR associated with + it, then the resolver could obtain and validate any apex DNSKEY + RRset. The process of using DS RRs to authenticate referrals is + described in Section 5.2. + + Once the resolver has authenticated a zone's apex DNSKEY RRset, + Section 5.3 shows how the resolver can use DNSKEY RRs in the apex + DNSKEY RRset and RRSIG RRs from the zone to authenticate any other + RRsets in the zone. Section 5.4 shows how the resolver can use + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + that lacks the appropriate DNSSEC RRs, whether due to configuration + issues such as an upstream security-oblivious recursive name server + that accidentally interferes with DNSSEC RRs or due to a deliberate + attack in which an adversary forges a response, strips DNSSEC RRs + + + +Arends, et al. Expires January 13, 2005 [Page 25] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + from a response, or modifies a query so that DNSSEC RRs appear not to + be requested. The absence of DNSSEC data in a response MUST NOT by + itself be taken as an indication that no authentication information + exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1 Special Considerations for Islands of Security + + Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed + zones for which it is not possible to construct an authentication + chain to the zone from its parent. Validating signatures within an + island of security requires the validator to have some other means of + obtaining an initial authenticated zone key for the island. If a + validator cannot obtain such a key, it SHOULD switch to operating as + if the zones in the island of security are unsigned. + + All the normal processes for validating responses apply to islands of + security. The only difference between normal validation and + validation within an island of security is in how the validator + obtains a trust anchor for the authentication chain. + +5.2 Authenticating Referrals + + Once the apex DNSKEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a DNSKEY RR in the child + zone's apex DNSKEY RRset, and contains a cryptographic digest of the + child zone's DNSKEY RR. A strong cryptographic digest algorithm + ensures that an adversary can not easily generate a DNSKEY RR that + matches the digest. Thus, authenticating the digest allows a + resolver to authenticate the matching DNSKEY RR. The resolver can + then use this child DNSKEY RR to authenticate the entire child apex + DNSKEY RRset. + + Given a DS RR for a delegation, the child zone's apex DNSKEY RRset + can be authenticated if all of the following hold: + o The DS RR has been authenticated using some DNSKEY RR in the + parent's apex DNSKEY RRset (see Section 5.3); + o The Algorithm and Key Tag in the DS RR match the Algorithm field + and the key tag of a DNSKEY RR in the child zone's apex DNSKEY + RRset and, when hashed using the digest algorithm specified in the + DS RR's Digest Type field, results in a digest value that matches + the Digest field of the DS RR; and + + + +Arends, et al. Expires January 13, 2005 [Page 26] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + o The matching DNSKEY RR in the child zone has the Zone Flag bit + set, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the validator authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the validator can not authenticate RRsets in or below the + child zone. + + If the validator does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + Note that, for a signed delegation, there are two NSEC RRs associated + with the delegated name. One NSEC RR resides in the parent zone, and + can be used to prove whether a DS RRset exists for the delegated + name. The second NSEC RR resides in the child zone, and identifies + which RRsets are present at the apex of the child zone. The parent + NSEC RR and child NSEC RR can always be distinguished, since the SOA + bit will be set in the child NSEC RR and clear in the parent NSEC RR. + A security-aware resolver MUST use the parent NSEC RR when attempting + to prove that a DS RRset does not exist. + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3 Authenticating an RRset Using an RRSIG RR + + A validator can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The validator first checks the RRSIG + + + +Arends, et al. Expires January 13, 2005 [Page 27] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The validator then constructs the + canonical form of the signed data by appending the RRSIG RDATA + (excluding the Signature Field) with the canonical form of the + covered RRset. Finally, the validator uses the public key and + signature to authenticate the signed data. Section 5.3.1, Section + 5.3.2, and Section 5.3.3 describe each step in detail. + +5.3.1 Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + o The RRSIG RR and the RRset MUST have the same owner name and the + same class; + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset; + o The RRSIG RR's Type Covered field MUST equal the RRset's type; + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field; + o The validator's notion of the current time MUST be less than or + equal to the time listed in the RRSIG RR's Expiration field; + o The validator's notion of the current time MUST be greater than or + equal to the time listed in the RRSIG RR's Inception field; + o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some DNSKEY RR in + the zone's apex DNSKEY RRset; + o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY + RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) + set. + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the validator cannot predetermine which DNSKEY + RR to use to authenticate the signature, MUST try each matching + DNSKEY RR until either the signature is validated or the validator + has run out of matching public keys to try. + + Note that this authentication process is only meaningful if the + validator authenticates the DNSKEY RR before using it to validate + signatures. The matching DNSKEY RR is considered to be authentic if: + o The apex DNSKEY RRset containing the DNSKEY RR is considered + authentic; or + o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + and the DNSKEY RR either matches an authenticated DS RR from the + parent zone or matches a trust anchor. + +5.3.2 Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + + + +Arends, et al. Expires January 13, 2005 [Page 28] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + Section 5.3.1, the validator needs to reconstruct the original signed + data. The original signed data includes RRSIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The validator should use the following to + reconstruct the original signed data: + + signed_data = RRSIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signature field excluded and the Signer's Name + in canonical form. + + RR(i) = name | type | class | OrigTTL | RDATA length | RDATA + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the RRSIG Original TTL field + + All names in the RDATA field are in canonical form + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + + + +Arends, et al. Expires January 13, 2005 [Page 29] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + RRset. + + The canonical forms for names and RRsets are defined in + [I-D.ietf-dnsext-dnssec-records]. + + NSEC RRsets at a delegation boundary require special processing. + There are two distinct NSEC RRsets associated with a signed delegated + name. One NSEC RRset resides in the parent zone, and specifies which + RRset are present at the parent zone. The second NSEC RRset resides + at the child zone, and identifies which RRsets are present at the + apex in the child zone. The parent NSEC RRset and child NSEC RRset + can always be distinguished since only the child NSEC RRs will + specify an SOA RRset exists at the name. When reconstructing the + original NSEC RRset for the delegation from the parent zone, the NSEC + RRs MUST NOT be combined with NSEC RRs from the child zone, and when + reconstructing the original NSEC RRset for the apex of the child + zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent + zone. + + Note also that each of the two NSEC RRsets at a delegation point has + a corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + +5.3.3 Checking the Signature + + Once the resolver has validated the RRSIG RR as described in Section + 5.3.1 and reconstructed the original signed data as described in + Section 5.3.2, the validator can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). + [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types + and provides pointers to the documents that define each algorithm's + use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the validator can only + determine which DNSKEY RR by trying each matching public key until + the validator either succeeds in validating the signature or runs out + of keys to try. + + + +Arends, et al. Expires January 13, 2005 [Page 30] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also needs to test these RRSIG + RRs, and determines how to resolve conflicts if these RRSIG RRs lead + to differing results. + + If the resolver accepts the RRset as authentic, the validator MUST + set the TTL of the RRSIG RR and each RR in the authenticated RRset to + a value no greater than the minimum of: + o The RRset's TTL as received in the response; + o The RRSIG RR's TTL as received in the response; + o The value in the RRSIG RR's Original TTL field; and + o The difference of the RRSIG RR's Signature Expiration time and the + current time. + +5.3.4 Authenticating A Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the validator has verified the signature as described in Section + 5.3, it must take additional steps to verify the non-existence of an + exact match or closer wildcard match for the query. Section 5.4 + discusses these steps. + + Note that the response received by the resolver should include all + NSEC RRs needed to authenticate the response (see Section 3.1.3). + +5.4 Authenticated Denial of Existence + + A resolver can use authenticated NSEC RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NSEC RRs for signed zones in + their responses to security-aware resolvers. + + Denial of existence is determined by the following rules: + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + + + +Arends, et al. Expires January 13, 2005 [Page 31] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. + o If the requested RR name would appear after an authenticated NSEC + RR's owner name and before the name listed in that NSEC RR's Next + Domain Name field according to the canonical DNS name order + defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with + the requested name exist in the zone. However, it is possible + that a wildcard could be used to match the requested RR owner name + and type, so proving that the requested RRset does not exist also + requires proving that no possible wildcard RRset exists that could + have been used to generate a positive response. + + In addition, security-aware resolvers MUST authenticate the NSEC + RRsets that comprise the non-existence proof as described in Section + 5.3. + + To prove non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify non-existence of the requested RRset. As with all DNS + operations, however, the resolver MUST bound the work it puts into + answering any particular query. + + Since a validated NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a validator MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + +5.5 Resolver Behavior When Signatures Do Not Validate + + If for whatever reason none of the RRSIGs can be validated, the + response SHOULD be considered BAD. If the validation was being done + to service a recursive query, the name server MUST return RCODE 2 to + the originating client. However, it MUST return the full response if + and only if the original query had the CD bit set. See also Section + 4.7 on caching responses that do not validate. + +5.6 Authentication Example + + Appendix C shows an example the authentication process. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 32] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +6. IANA Considerations + + [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA + considerations introduced by DNSSEC. The additional IANA + considerations discussed in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655] and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 33] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general + security considerations related to DNSSEC; see + [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the + DNSSEC resource record types. + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection which DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Section 3.2.2 and Section 4.9 for further discussion. + + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, + since recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will need to pay close attention to the + behavior of the applications which use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidentally denying service to the clients it + is intended to support. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 34] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +8. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 35] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +9. References + +9.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-10 (work in progress), May + 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-08 (work in progress), + May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + +9.2 Informative References + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "DNSSEC NSEC RDATA Format", + draft-ietf-dnsext-nsec-rdata-06 (work in progress), May + + + +Arends, et al. Expires January 13, 2005 [Page 36] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + 2004. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + +Arends, et al. Expires January 13, 2005 [Page 37] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 38] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB + 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE + VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO + 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM + W6OISukd1EQt7a0kygkg+PEDxdI= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + 3600 DNSKEY 256 3 5 ( + AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV + rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e + k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo + vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI + + + +Arends, et al. Expires January 13, 2005 [Page 39] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== + ) + 3600 DNSKEY 257 3 5 ( + AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl + LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ + syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP + RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT + Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 9465 example. + ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ + xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ + XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 + hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY + NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z + DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri + bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp + eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk + 7z5OXogYVaFzHKillDt3HRxHIZM= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba + U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 + 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I + BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g + sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + + + +Arends, et al. Expires January 13, 2005 [Page 40] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l + e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh + ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 + AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw + FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG + CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p + P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN + 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL + AhS+JOVfDI/79QtyTI0SaDWcg8U= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + + + +Arends, et al. Expires January 13, 2005 [Page 41] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE + VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb + 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH + l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw + Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + + + +Arends, et al. Expires January 13, 2005 [Page 42] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK + vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E + mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI + NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e + IjgiM8PXkBQtxPq37wDKALkyn7Q= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia + t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj + q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq + GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb + +gLcMZBnHJ326nb/TOOmrqNmQQE= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 + t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq + BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 + 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ + RgNvuwbioFSEuv2pNlkq0goYxNY= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + + + +Arends, et al. Expires January 13, 2005 [Page 43] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY + 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k + mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi + asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W + GghLahumFIpg4MO3LS/prgzVVWo= ) + + The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA + Flags indicate that each of these DNSKEY RRs is a zone key. One of + these DNSKEY RRs also has the SEP flag set and has been used to sign + the apex DNSKEY RRset; this is the key which should be hashed to + generate a DS record to be inserted into the parent zone. The other + DNSKEY is used to sign all the other RRsets in the zone. + + The zone includes a wildcard entry "*.w.example". Note that the name + "*.w.example" is used in constructing NSEC chains, and that the RRSIG + covering the "*.w.example" MX RRset has a label count of 2. + + The zone also includes two delegations. The delegation to + "b.example" includes an NS RRset, glue address records, and an NSEC + RR; note that only the NSEC RRset is signed. The delegation to + "a.example" provides a DS RR; note that only the NSEC and DS RRsets + are signed. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 44] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1 Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + + + +Arends, et al. Expires January 13, 2005 [Page 45] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + + +B.2 Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + + + +Arends, et al. Expires January 13, 2005 [Page 46] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + +B.3 No Data Error + + A "no data" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 47] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + + ;; Additional + ;; (empty) + + +B.4 Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 48] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + + +B.5 Referral to Unsigned Zone + + Referral to an unsigned zone. The NSEC RR proves that no DS RR for + this delegation exists in the parent zone. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 49] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + + +B.6 Wildcard Expansion + + A successful query which was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + + ;; Authority + + + +Arends, et al. Expires January 13, 2005 [Page 50] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + + +B.7 Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + + + +Arends, et al. Expires January 13, 2005 [Page 51] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + + ;; Additional + ;; (empty) + + +B.8 DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query which was mistakenly sent + to a name server for the child zone. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 52] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 53] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1 Authenticating An Answer + + The query in section Appendix B.1 returned an MX RRset for + "x.w.example.com". The corresponding RRSIG indicates the MX RRset + was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The resolver needs the corresponding DNSKEY RR in order to + authenticate this answer. The discussion below describes how a + resolver might obtain this DNSKEY RR. + + The RRSIG indicates the original TTL of the MX RRset was 3600 and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates the answer was not + the result of wildcard expansion. The "x.w.example.com" MX RRset is + placed in canonical form and, assuming the current time falls between + the signature inception and expiration dates, the signature is + authenticated. + +C.1.1 Authenticating the example DNSKEY RR + + This example shows the logical authentication process that starts + from the a configured root DNSKEY (or DS RR) and moves down the tree + to authenticate the desired "example" DNSKEY RR. Note the logical + order is presented for clarity and an implementation may choose to + construct the authentication as referrals are received or may choose + to construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with an configured DNSKEY RR for the + root zone (or a configured DS RR for the root zone). The resolver + checks this configured DNSKEY RR is present in the root DNSKEY RRset + (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this + DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the DNSKEY + RRset are considered authenticated. The resolver then uses one (or + more) of the root DNSKEY RRs to authenticate the "example" DS RRset. + Note the resolver may need to query the root zone to obtain the root + DNSKEY RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + + + +Arends, et al. Expires January 13, 2005 [Page 54] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + matching "example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the "example" + DNSKEY RRset are considered authenticated. + + Finally the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This + DNSKEY is used to authenticated the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried and the answer is authenticated if any + of the matching DNSKEY RRs validates the signature as described + above. + +C.2 Name Error + + The query in section Appendix B.2 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3 No Data Error + + The query in section Appendix B.3 returned an NSEC RR that proves the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4 Referral to Signed Zone + + The query in section Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "a.example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the + "a.example" DNSKEY RRset are considered authenticated. + +C.5 Referral to Unsigned Zone + + The query in section Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + + + +Arends, et al. Expires January 13, 2005 [Page 55] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + "example" to "b.example" and the NSEC RR is authenticated in a manner + identical to that of the MX RRset discussed above. + +C.6 Wildcard Expansion + + The query in section Appendix B.6 returned an answer that was + produced as a result of wildcard expansion. The RRset expanded as + the similar to The corresponding RRSIG indicates the MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The RRSIG indicates the original TTL of the MX RRset was 3600 and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 2 indicates the answer the + result of wildcard expansion since the "a.z.w.example" name contains + 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", + the MX RRset is placed in canonical form and, assuming the current + time falls between the signature inception and expiration dates, the + signature is authenticated. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7 Wildcard No Data Error + + The query in section Appendix B.7 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8 DS Child Zone No Data Error + + The query in section Appendix B.8 returned NSEC RRs that shows the + requested was answered by a child server ("example" server). The + NSEC RR indicates the presence of an SOA RR, showing the answer is + from the child . Queries for the "example" DS RRset should be sent + to the parent servers ("root" servers). + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 56] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 13, 2005 [Page 57] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt new file mode 100644 index 000000000000..79a17284357c --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt @@ -0,0 +1,1849 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: January 13, 2005 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + July 15, 2004 + + + Resource Records for the DNS Security Extensions + draft-ietf-dnsext-dnssec-records-09 + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents that describes the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + + + +Arends, et al. Expires January 13, 2005 [Page 1] + +Internet-Draft DNSSEC Resource Records July 2004 + + + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + public key (DNSKEY), delegation signer (DS), resource record digital + signature (RRSIG), and authenticated denial of existence (NSEC) + resource records. The purpose and format of each resource record is + described in detail, and an example of each resource record is given. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5 + 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6 + 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6 + 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6 + 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6 + 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6 + 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8 + 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10 + 3.1.5 Signature Expiration and Inception Fields . . . . . . 10 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11 + 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12 + 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14 + 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14 + 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15 + 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 16 + 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 16 + 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 16 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19 + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19 + + + +Arends, et al. Expires January 13, 2005 [Page 2] + +Internet-Draft DNSSEC Resource Records July 2004 + + + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19 + 5.2 Processing of DS RRs When Validating Responses . . . . . . 19 + 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20 + 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Canonical Form and Order of Resource Records . . . . . . . . . 21 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 21 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 22 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 + 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32 + Intellectual Property and Copyright Statements . . . . . . . . 33 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 3] + +Internet-Draft DNSSEC Resource Records July 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the + purpose of each resource record (RR), the RR's RDATA format, and its + presentation format (ASCII representation). + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035] and subsequent RFCs that update + them: [RFC2136], [RFC2181] and [RFC2308]. + + This document is part of a family of documents that define the DNS + security extensions. The DNS security extensions (DNSSEC) are a + collection of resource records and DNS protocol modifications that + add source authentication and data integrity to the Domain Name + System (DNS). An introduction to DNSSEC and definitions of common + terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is + assumed to be familiar with this document. A description of DNS + protocol modifications can be found in + [I-D.ietf-dnsext-dnssec-protocol]. + + This document defines the DNSSEC resource records. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 4] + +Internet-Draft DNSSEC Resource Records July 2004 + + +2. The DNSKEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in DNSKEY + resource records and are used in the DNSSEC authentication process + described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its + authoritative RRsets using a private key and stores the corresponding + public key in a DNSKEY RR. A resolver can then use the public key to + authenticate signatures covering the RRsets in the zone. + + The DNSKEY RR is not intended as a record for storing arbitrary + public keys and MUST NOT be used to store certificates or public keys + that do not directly relate to the DNS infrastructure. + + The Type value for the DNSKEY RR type is 48. + + The DNSKEY RR is class independent. + + The DNSKEY RR has no special TTL requirements. + +2.1 DNSKEY RDATA Wire Format + + The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 + octet Protocol Field, a 1 octet Algorithm Field, and the Public Key + Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner + name MUST be the name of a zone. If bit 7 has value 0, then the + DNSKEY record holds some other type of DNS public key and MUST NOT be + used to verify RRSIGs that cover RRsets. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a + key intended for use as a secure entry point. This flag is only + + + +Arends, et al. Expires January 13, 2005 [Page 5] + +Internet-Draft DNSSEC Resource Records July 2004 + + + intended to be to a hint to zone signing or debugging software as to + the intended use of this DNSKEY record; validators MUST NOT alter + their behavior during the signature validation process in any way + based on the setting of this bit. This also means a DNSKEY RR with + the SEP bit set would also need the Zone Key flag set in order to + legally be able to generate signatures. A DNSKEY RR with the SEP set + and the Zone Key flag not set MUST NOT be used to verify RRSIGs that + cover RRsets. + + Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon + creation of the DNSKEY RR, and MUST be ignored upon reception. + +2.1.2 The Protocol Field + + The Protocol Field MUST have value 3 and the DNSKEY RR MUST be + treated as invalid during signature verification if found to be some + value other than 3. + +2.1.3 The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4 The Public Key Field + + The Public Key Field holds the public key material. The format + depends on the algorithm of the key being stored and are described in + separate documents. + +2.1.5 Notes on DNSKEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with early versions of the KEY record. + +2.2 The DNSKEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field MUST be represented as an unsigned decimal integer. + Given the currently defined flags, the possible values are: 0, 256, + or 257. + + The Protocol Field MUST be represented as an unsigned decimal integer + with a value of 3. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + + +Arends, et al. Expires January 13, 2005 [Page 6] + +Internet-Draft DNSSEC Resource Records July 2004 + + + The Public Key field MUST be represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see [RFC3548]. + +2.3 DNSKEY RR Example + + The following DNSKEY RR stores a DNS zone key for example.com. + + example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 + Cbl+BBZH4b/0PY1kxkmvHjcZc8no + kfzj31GajIQKY+5CptLr3buXA10h + WqTkF7H6RfoRqXQeogmMHfpftf6z + Mv1LyBUgia7za6ZEzOJBOztyvhjL + 742iU/TpPSEDhm2SNKLijfUppn1U + aNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in + the Flags field has value 1. Value 3 is the fixed Protocol value. + Value 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [RFC3110]. The remaining + text is a Base64 encoding of the public key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 7] + +Internet-Draft DNSSEC Resource Records July 2004 + + +3. The RRSIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Digital signatures are stored in + RRSIG resource records and are used in the DNSSEC authentication + process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator + can use these RRSIG RRs to authenticate RRsets from the zone. The + RRSIG RR MUST only be used to carry verification material (digital + signatures) used to secure DNS operations. + + An RRSIG record contains the signature for an RRset with a particular + name, class, and type. The RRSIG RR specifies a validity interval + for the signature and uses the Algorithm, the Signer's Name, and the + Key Tag to identify the DNSKEY RR containing the public key that a + validator can use to verify the signature. + + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034] that stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a signed + zone. + + The Type value for the RRSIG RR type is 46. + + The RRSIG RR is class independent. + + An RRSIG RR MUST have the same class as the RRset it covers. + + The TTL value of an RRSIG RR MUST match the TTL value of the RRset it + covers. This is an exception to the [RFC2181] rules for TTL values + of individual RRs within a RRset: individual RRSIG with the same + owner name will have different TTL values if the RRsets they cover + have different TTL values. + +3.1 RRSIG RDATA Wire Format + + The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a + 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original + TTL field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 8] + +Internet-Draft DNSSEC Resource Records July 2004 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 The Type Covered Field + + The Type Covered field identifies the type of the RRset that is + covered by this RRSIG record. + +3.1.2 The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3 The Labels Field + + The Labels field specifies the number of labels in the original RRSIG + RR owner name. The significance of this field is that a validator + uses it to determine if the answer was synthesized from a wildcard. + If so, it can be used to determine what owner name was used in + generating the signature. + + To validate a signature, the validator needs the original owner name + that was used to create the signature. If the original owner name + contains a wildcard label ("*"), the owner name may have been + expanded by the server during the response process, in which case the + validator will need to reconstruct the original owner name in order + to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] + describes how to use the Labels field to reconstruct the original + owner name. + + + +Arends, et al. Expires January 13, 2005 [Page 9] + +Internet-Draft DNSSEC Resource Records July 2004 + + + The value of the Labels field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Labels field MUST be less than or equal + to the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Labels field value of 3, and + "*.example.com." has a Labels field value of 2. Root (".") has a + Labels field value of 0. + + Although the wildcard label is not included in the count stored in + the Labels field of the RRSIG RR, the wildcard label is part of the + RRset's owner name when generating or verifying the signature. + +3.1.4 Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a validator requires the original TTL. + [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original + TTL field value to reconstruct the original TTL. + +3.1.5 Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The RRSIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + Signature Expiration and Inception field values are in POSIX.1 time + format: a 32-bit unsigned number of seconds elapsed since 1 January + 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The + longest interval which can be expressed by this format without + wrapping is approximately 136 years. An RRSIG RR can have an + Expiration field value which is numerically smaller than the + Inception field value if the expiration field value is near the + 32-bit wrap-around point or if the signature is long lived. Because + of this, all comparisons involving these fields MUST use "Serial + number arithmetic" as defined in [RFC1982]. As a direct consequence, + the values contained in these fields cannot refer to dates more than + 68 years in either the past or the future. + +3.1.6 The Key Tag Field + + The Key Tag field contains the key tag value of the DNSKEY RR that + validates this signature, in network byte order. Appendix B explains + how to calculate Key Tag values. + + + +Arends, et al. Expires January 13, 2005 [Page 10] + +Internet-Draft DNSSEC Resource Records July 2004 + + +3.1.7 The Signer's Name Field + + The Signer's Name field value identifies the owner name of the DNSKEY + RR which a validator is supposed to use to validate this signature. + The Signer's Name field MUST contain the name of the zone of the + covered RRset. A sender MUST NOT use DNS name compression on the + Signer's Name field when transmitting a RRSIG RR. + +3.1.8 The Signature Field + + The Signature field contains the cryptographic signature that covers + the RRSIG RDATA (excluding the Signature field) and the RRset + specified by the RRSIG owner name, RRSIG class, and RRSIG Type + Covered field. The format of this field depends on the algorithm in + use and these formats are described in separate companion documents. + +3.1.8.1 Signature Calculation + + A signature covers the RRSIG RDATA (excluding the Signature Field) + and covers the data RRset specified by the RRSIG owner name, RRSIG + class, and RRSIG Type Covered fields. The RRset is in canonical form + (see Section 6) and the set RR(1),...RR(n) is signed as follows: + + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | type | class | TTL | RDATA length | RDATA + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the RRSIG RR; + + Each RR MUST have the same class as the RRSIG RR; + + Each RR in the RRset MUST have the RR type listed in the + RRSIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the + RRSIG Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + + + +Arends, et al. Expires January 13, 2005 [Page 11] + +Internet-Draft DNSSEC Resource Records July 2004 + + + canonical form; and + + The RRset MUST be sorted in canonical order. + + See Section 6.2 and Section 6.3 for details on canonical form and + ordering of RRsets. + +3.2 The RRSIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field is represented as a RR type mnemonic. When + the mnemonic is not known, the TYPE representation as described in + [RFC3597] (section 5) MUST be used. + + The Algorithm field value MUST be represented either as an unsigned + decimal integer or as an algorithm mnemonic as specified in Appendix + A.1. + + The Labels field value MUST be represented as an unsigned decimal + integer. + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Expiration Time and Inception Time field values MUST be + represented either as seconds since 1 January 1970 00:00:00 UTC or in + the form YYYYMMDDHHmmSS in UTC, where: + YYYY is the year (0001-9999, but see Section 3.1.5); + MM is the month number (01-12); + DD is the day of the month (01-31); + HH is the hour in 24 hours notation (00-23); + mm is the minute (00-59); and + SS is the second (00-59). + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Signer's Name field value MUST be represented as a domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. See + Section 2.2. + +3.3 RRSIG RR Example + + The following RRSIG RR stores the signature for the A RRset of + host.example.com: + + + + +Arends, et al. Expires January 13, 2005 [Page 12] + +Internet-Draft DNSSEC Resource Records July 2004 + + + host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + The first four fields specify the owner name, TTL, Class, and RR type + (RRSIG). The "A" represents the Type Covered field. The value 5 + identifies the algorithm used (RSA/SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the RRSIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of RRSIG RR owner name, class, and Type Covered + indicate that this RRSIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate this signature can be + authenticated using an example.com zone DNSKEY RR whose algorithm is + 5 and key tag is 2642. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 13] + +Internet-Draft DNSSEC Resource Records July 2004 + + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the next owner + name (in the canonical ordering of the zone) which contains + authoritative data or a delegation point NS RRset, and the set of RR + types present at the NSEC RR's owner name. The complete set of NSEC + RRs in a zone both indicate which authoritative RRsets exist in a + zone and also form a chain of authoritative owner names in the zone. + This information is used to provide authenticated denial of existence + for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol]. + + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034] that + stated that if a CNAME is present for a name, it is the only type + allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist + for the same name as a CNAME resource record in a signed zone. + + See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone + signer determines precisely which NSEC RRs it needs to include in a + zone. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +4.1 NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The Next Domain field contains the next owner name (in the canonical + ordering of the zone) which has authoritative data or contains a + delegation point NS RRset; see Section 6.1 for an explanation of + canonical ordering. The value of the Next Domain Name field in the + + + +Arends, et al. Expires January 13, 2005 [Page 14] + +Internet-Draft DNSSEC Resource Records July 2004 + + + last NSEC record in the zone is the name of the zone apex (the owner + name of the zone's SOA RR). This indicates that the owner name of + the NSEC RR is the last name in the canonical ordering of the zone. + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets not authoritative for the given zone (such as + glue records) MUST NOT be listed in the Next Domain Name unless at + least one authoritative RRset exists at the same owner name. + +4.1.2 The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC RR's owner name. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set, + it indicates that an RRset of that type is present for the NSEC RR's + owner name. If a bit is clear, it indicates that no RRset of that + type is present for the NSEC RR's owner name. + + Bits representing pseudo-types MUST be clear, since they do not + appear in zone data. If encountered, they MUST be ignored upon + reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + + + +Arends, et al. Expires January 13, 2005 [Page 15] + +Internet-Draft DNSSEC Resource Records July 2004 + + + interpreted as zero octets. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + + A zone MUST NOT include an NSEC RR for any domain name that only + holds glue records. + +4.1.3 Inclusion of Wildcard Names in NSEC RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for purposes of generating NSEC RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards + on authenticated denial of existence. + +4.2 The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + as described in [RFC3597] (section 5) MUST be used. + +4.3 NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, + and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and + TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + + + + +Arends, et al. Expires January 13, 2005 [Page 16] + +Internet-Draft DNSSEC Resource Records July 2004 + + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 + + Assuming that the validator can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or could + be used to prove there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + [I-D.ietf-dnsext-dnssec-protocol]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 17] + +Internet-Draft DNSSEC Resource Records July 2004 + + +5. The DS Resource Record + + The DS Resource Record refers to a DNSKEY RR and is used in the DNS + DNSKEY authentication process. A DS RR refers to a DNSKEY RR by + storing the key tag, algorithm number, and a digest of the DNSKEY RR. + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The DS RR and its corresponding DNSKEY RR have the same owner name, + but they are stored in different locations. The DS RR appears only + on the upper (parental) side of a delegation, and is authoritative + data in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + "example.com" zone (the child zone). The corresponding DNSKEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing, but introduces special response + processing requirements for the DS RR; these are described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + The DS RR has no special TTL requirements. + +5.1 DS RDATA Wire Format + + The RDATA for a DS RR consists of a 2 octet Key Tag field, a one + octet Algorithm field, a one octet Digest Type field, and a Digest + field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 18] + +Internet-Draft DNSSEC Resource Records July 2004 + + +5.1.1 The Key Tag Field + + The Key Tag field lists the key tag of the DNSKEY RR referred to by + the DS record, in network byte order. + + The Key Tag used by the DS RR is identical to the Key Tag used by + RRSIG RRs. Appendix B describes how to compute a Key Tag. + +5.1.2 The Algorithm Field + + The Algorithm field lists the algorithm number of the DNSKEY RR + referred to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the + algorithm number types. + +5.1.3 The Digest Type Field + + The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY + RR. The Digest Type field identifies the algorithm used to construct + the digest. Appendix A.2 lists the possible digest algorithm types. + +5.1.4 The Digest Field + + The DS record refers to a DNSKEY RR by including a digest of that + DNSKEY RR. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, + and then applying the digest algorithm. + + digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); + + "|" denotes concatenation + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. + + + The size of the digest may vary depending on the digest algorithm and + DNSKEY RR size. As of the time of writing, the only defined digest + algorithm is SHA-1, which produces a 20 octet digest. + +5.2 Processing of DS RRs When Validating Responses + + The DS RR links the authentication chain across zone boundaries, so + the DS RR requires extra care in processing. The DNSKEY RR referred + to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST + + + +Arends, et al. Expires January 13, 2005 [Page 19] + +Internet-Draft DNSSEC Resource Records July 2004 + + + have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC + zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in + the validation process. + +5.3 The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field MUST be represented as an unsigned decimal + integer. + + The Digest MUST be represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.4 DS RR Example + + The following example shows a DNSKEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm + used by this "dskey.example.com." DNSKEY RR. The value 1 is the + algorithm used to construct the digest, and the rest of the RDATA + text is the digest in hexadecimal. + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 20] + +Internet-Draft DNSSEC Resource Records July 2004 + + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NSEC name chain. A canonical RR form and ordering + within an RRset are required to construct and verify RRSIG RRs. + +6.1 Canonical DNS Name Order + + For purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and upper case + US-ASCII letters are treated as if they were lower case US-ASCII + letters. + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + names ending "z.example". The names within each level are sorted in + the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + + +6.2 Canonical RR Form + + For purposes of DNS security, the canonical form of an RR is the wire + format of the RR where: + 1. Every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + 2. All uppercase US-ASCII letters in the owner name of the RR are + replaced by the corresponding lowercase US-ASCII letters; + + + + +Arends, et al. Expires January 13, 2005 [Page 21] + +Internet-Draft DNSSEC Resource Records July 2004 + + + 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in + the DNS names contained within the RDATA are replaced by the + corresponding lowercase US-ASCII letters; + 4. If the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + 5. The RR's TTL is set to its original value as it appears in the + originating authoritative zone or the Original TTL field of the + covering RRSIG RR. + +6.3 Canonical RR Ordering Within An RRset + + For purposes of DNS security, RRs with the same owner name, class, + and type are sorted by treating the RDATA portion of the canonical + form of each RR as a left-justified unsigned octet sequence where the + absence of an octet sorts before a zero octet. + + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs when + putting the RRset in canonical form, the implementation MUST treat + this as a protocol error. If the implementation chooses to handle + this protocol error in the spirit of the robustness principle (being + liberal in what it accepts), the implementation MUST remove all but + one of the duplicate RR(s) for purposes of calculating the canonical + form of the RRset. + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 22] + +Internet-Draft DNSSEC Resource Records July 2004 + + +7. IANA Considerations + + This document introduces no new IANA considerations, because all of + the protocol parameters used in this document have already been + assigned by previous specifications. However, since the evolution of + DNSSEC has been long and somewhat convoluted, this section attempts + to describe the current state of the IANA registries and other + protocol parameters which are (or once were) related to DNSSEC. + + Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA + considerations. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS + Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, + and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. + [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted + use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction + security protocol described in [RFC2931] and the transaction KEY + Resource Record described in [RFC2930]. + + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers, and assigned + values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] + altered this registry to include flags for each entry regarding + its use with the DNS security extensions. Each algorithm entry + could refer to an algorithm that can be used for zone signing, + transaction security (see [RFC2931]) or both. Values 6-251 are + available for assignment by IETF standards action. See Appendix A + for a full listing of the DNS Security Algorithm Numbers entries + at the time of writing and their status of use in DNSSEC. + + [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and + assigned value 0 to reserved and value 1 to SHA-1. + + KEY Protocol Values: [RFC2535] created an IANA Registry for KEY + Protocol Values, but [RFC3445] re-assigned all values other than 3 + to reserved and closed this IANA registry. The registry remains + closed, and all KEY and DNSKEY records are required to have + Protocol Octet value of 3. + + Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains an assignment for bit 7 (the ZONE bit) + and a reservation for bit 15 for the Secure Entry Point flag (SEP + bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by + IETF Standards Action. + + + + +Arends, et al. Expires January 13, 2005 [Page 23] + +Internet-Draft DNSSEC Resource Records July 2004 + + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions, and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] + and [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations related to the use of these records. + + The DS record points to a DNSKEY RR using a cryptographic digest, the + key algorithm type and a key tag. The DS record is intended to + identify an existing DNSKEY RR, but it is theoretically possible for + an attacker to generate a DNSKEY that matches all the DS fields. The + probability of constructing such a matching DNSKEY depends on the + type of digest algorithm in use. The only currently defined digest + algorithm is SHA-1, and the working group believes that constructing + a public key which would match the algorithm, key tag, and SHA-1 + digest given in a DS record would be a sufficiently difficult problem + that such an attack is not a serious threat at this time. + + The key tag is used to help select DNSKEY resource records + efficiently, but it does not uniquely identify a single DNSKEY + resource record. It is possible for two distinct DNSKEY RRs to have + the same owner name, the same algorithm type, and the same key tag. + An implementation which uses only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. + + The table of algorithms in Appendix A and the key tag calculation + algorithms in Appendix B include the RSA/MD5 algorithm for + completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as + explained in [RFC3110]. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 24] + +Internet-Draft DNSSEC Resource Records July 2004 + + +9. Acknowledgments + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 25] + +Internet-Draft DNSSEC Resource Records July 2004 + + +10. References + +10.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-10 (work in progress), May + 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in + progress), May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + + + +Arends, et al. Expires January 13, 2005 [Page 26] + +Internet-Draft DNSSEC Resource Records July 2004 + + + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 3548, July 2003. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + +10.2 Informative References + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "DNSSEC NSEC RDATA Format", + draft-ietf-dnsext-nsec-rdata-06 (work in progress), May + 2004. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 27] + +Internet-Draft DNSSEC Resource Records July 2004 + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 28] + +Internet-Draft DNSSEC Resource Records July 2004 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS + resource records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1 DNSSEC Algorithm Types + + The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify + the security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. + + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs as described in [RFC2931] + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman [DH] n RFC 2539 - + 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. + +A.1.1 Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with a wire encoded + + + +Arends, et al. Expires January 13, 2005 [Page 29] + +Internet-Draft DNSSEC Resource Records July 2004 + + + domain name, which MUST NOT be compressed. The domain name indicates + the private algorithm to use and the remainder of the public key area + is determined by that algorithm. Entities should only use domain + names they control to designate their private algorithms. + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with an unsigned + length byte followed by a BER encoded Object Identifier (ISO OID) of + that length. The OID indicates the private algorithm in use and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2 DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 30] + +Internet-Draft DNSSEC Resource Records July 2004 + + +Appendix B. Key Tag Calculation + + The Key Tag field in the RRSIG and DS resource record types provides + a mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a DNSKEY record. Both the RRSIG and DS resource records + have corresponding DNSKEY records. The Key Tag field in the RRSIG + and DS records can be used to help select the corresponding DNSKEY RR + efficiently when more than one candidate DNSKEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct DNSKEY RRs + to have the same owner name, the same algorithm, and the same key + tag. The key tag is used to limit the possible candidate keys, but + it does not uniquely identify a DNSKEY record. Implementations MUST + NOT assume that the key tag uniquely identifies a DNSKEY RR. + + The key tag is the same for all DNSKEY algorithm types except + algorithm 1 (please see Appendix B.1 for the definition of the key + tag for algorithm 1). The key tag algorithm is the sum of the wire + format of the DNSKEY RDATA broken into 2 octet groups. First the + RDATA (in wire format) is treated as a series of 2 octet groups, + these groups are then added together ignoring any carry bits. + + A reference implementation of the key tag algorithm is as an ANSI C + function is given below with the RDATA portion of the DNSKEY RR is + used as input. It is not necessary to use the following reference + code verbatim, but the numerical value of the Key Tag MUST be + identical to what the reference implementation would generate for the + same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described here rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the DNSKEY RR. The code is written + for clarity, not efficiency. + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 31] + +Internet-Draft DNSSEC Resource Records July 2004 + + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the DNSKEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + +B.1 Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently than the + key tag for all other algorithms, for historical reasons. For a + DNSKEY RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 32] + +Internet-Draft DNSSEC Resource Records July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 13, 2005 [Page 33] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt new file mode 100644 index 000000000000..4cfd417804d3 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt @@ -0,0 +1,639 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Clarifies STD0013 Motorola Laboratories +Expires December 2004 July 2004 + + + + Domain Name System (DNS) Case Insensitivity Clarification + ------ ---- ------ ----- ---- ------------- ------------- + + + Donald E. Eastlake 3rd + + + +Status of This Document + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group at namedroppers@ops.ietf.org. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- + Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + Domain Name System (DNS) names are "case insensitive". This document + explains exactly what that means and provides a clear specification + of the rules. This clarification should not have any interoperability + consequences. + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Acknowledgements + + The contributions to this document of Rob Austein, Olafur + Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, + Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully + acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Case Insensitivity of DNS Labels........................3 + 2.1 Escaping Unusual DNS Label Octets......................3 + 2.2 Example Labels with Escapes............................4 + 3. Name Lookup, Label Types, and CLASS.....................4 + 3.1 Original DNS Label Types...............................5 + 3.2 Extended Label Type Case Insensitivity Considerations..5 + 3.3 CLASS Case Insensitivity Considerations................5 + 4. Case on Input and Output................................6 + 4.1 DNS Output Case Preservation...........................6 + 4.2 DNS Input Case Preservation............................6 + 5. Internationalized Domain Names..........................7 + 6. Security Considerations.................................7 + + Copyright and Disclaimer...................................9 + Normative References.......................................9 + Informative References....................................10 + -02 to -03 Changes........................................10 + -03 to -04 Changes........................................11 + Author's Address..........................................11 + Expiration and File Name..................................11 + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS Case Insensitivity + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. Each node in the DNS tree has a name consisting of + zero or more labels [STD 13][RFC 1591, 2606] that are treated in a + case insensitive fashion. This document clarifies the meaning of + "case insensitive" for the DNS. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + + +2. Case Insensitivity of DNS Labels + + DNS was specified in the era of [ASCII]. DNS names were expected to + look like most host names or Internet email address right halves (the + part after the at-sign, "@") or be numeric as in the in-addr.arpa + part of the DNS name space. For example, + + foo.example.net. + aol.com. + www.gnu.ai.mit.edu. + or 69.2.0.192.in-addr.arpa. + + Case varied alternatives to the above would be DNS names like + + Foo.ExamplE.net. + AOL.COM. + WWW.gnu.AI.mit.EDU. + or 69.2.0.192.in-ADDR.ARPA. + + However, the individual octets of which DNS names consist are not + limited to valid ASCII character codes. They are 8-bit bytes and all + values are allowed. Many applications, however, interpret them as + ASCII characters. + + + +2.1 Escaping Unusual DNS Label Octets + + In Master Files [STD 13] and other human readable and writable ASCII + contexts, an escape is needed for the byte value for period (0x2E, + ".") and all octet values outside of the inclusive range of 0x21 + ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in + the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. + + One typographic convention for octets that do not correspond to an + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS Case Insensitivity + + + ASCII printing graphic is to use a back-slash followed by the value + of the octet as an unsigned integer represented by exactly three + decimal digits. + + The same convention can be used for printing ASCII characters so that + they will be treated as a normal label character. This includes the + back-slash character used in this convention itself which can be + expressed as \092 or \\ and the special label separator period (".") + which can be expressed as and \046 or \. respectively. It is + advisable to avoid using a backslash to quote an immediately + following non-printing ASCII character code to avoid implementation + difficulties. + + A back-slash followed by only one or two decimal digits is undefined. + A back-slash followed by four decimal digits produces two octets, the + first octet having the value of the first three digits considered as + a decimal number and the second octet being the character code for + the fourth decimal digit. + + + +2.2 Example Labels with Escapes + + The first example below shows embedded spaces and a period (".") + within a label. The second one show a 5 octet label where the second + octet has all bits zero, the third is a backslash, and the fourth + octet has all bits one. + + Donald\032E\.\032Eastlake\0323rd.example. + and a\000\\\255z.example. + + + +3. Name Lookup, Label Types, and CLASS + + The design decision was made that comparisons on name lookup for DNS + queries should be case insensitive [STD 13]. That is to say, a lookup + string octet with a value in the inclusive range of 0x41 to 0x5A, the + upper case ASCII letters, MUST match the identical value and also + match the corresponding value in the inclusive range 0x61 to 0x7A, + the lower case ASCII letters. And a lookup string octet with a lower + case ASCII letter value MUST similarly match the identical value and + also match the corresponding value in the upper case ASCII letter + range. + + (Historical Note: the terms "upper case" and "lower case" were + invented after movable type. The terms originally referred to the + two font trays for storing, in partitioned areas, the different + physical type elements. Before movable type, the nearest equivalent + terms were "majuscule" and "minuscule".) + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + One way to implement this rule would be, when comparing octets, to + subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A + before the comparison. Such an operation is commonly known as "case + folding" but implementation via case folding is not required. Note + that the DNS case insensitivity does NOT correspond to the case + folding specified in iso-8859-1 or iso-8859-2. For example, the + octets 0xDD (\221) and 0xFD (\253) do NOT match although in other + contexts, where they are interpreted as the upper and lower case + version of "Y" with an acute accent, they might. + + + +3.1 Original DNS Label Types + + DNS labels in wire encoded names have a type associated with them. + The original DNS standard [RFC 1035] had only two types. ASCII + labels, with a length of from zero to 63 octets, and indirect labels + which consist of an offset pointer to a name location elsewhere in + the wire encoding on a DNS message. (The ASCII label of length zero + is reserved for use as the name of the root node of the name tree.) + ASCII labels follow the ASCII case conventions described herein and, + as stated above, can actually contain arbitrary byte values. Indirect + labels are, in effect, replaced by the name to which they point which + is then treated with the case insensitivity rules in this document. + + + +3.2 Extended Label Type Case Insensitivity Considerations + + DNS was extended by [RFC 2671] to have additional label type numbers + available. (The only such type defined so far is the BINARY type [RFC + 2673].) + + The ASCII case insensitivity conventions only apply to ASCII labels, + that is to say, label type 0x0, whether appearing directly or invoked + by indirect labels. + + + +3.3 CLASS Case Insensitivity Considerations + + As described in [STD 13] and [RFC 2929], DNS has an additional axis + for data location called CLASS. The only CLASS in global use at this + time is the "IN" or Internet CLASS. + + The handling of DNS label case is not CLASS dependent. + + + + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS Case Insensitivity + + +4. Case on Input and Output + + While ASCII label comparisons are case insensitive, [STD 13] says + case MUST be preserved on output, and preserved when convenient on + input. However, this means less than it would appear since the + preservation of case on output is NOT required when output is + optimized by the use of indirect labels, as explained below. + + + +4.1 DNS Output Case Preservation + + [STD 13] views the DNS namespace as a node tree. ASCII output is as + if a name was marshaled by taking the label on the node whose name is + to be output, converting it to a typographically encoded ASCII + string, walking up the tree outputting each label encountered, and + preceding all labels but the first with a period ("."). Wire output + follows the same sequence but each label is wire encoded and no + periods inserted. No "case conversion" or "case folding" is done + during such output operations, thus "preserving" case. However, to + optimize output, indirect labels may be used to point to names + elsewhere in the DNS answer. In determining whether the name to be + pointed to, for example the QNAME, is the "same" as the remainder of + the name being optimized, the case insensitive comparison specified + above is done. Thus such optimization MAY easily destroy the output + preservation of case. This type of optimization is commonly called + "name compression". + + + +4.2 DNS Input Case Preservation + + Originally, DNS input came from an ASCII Master File as defined in + [STD 13] or a zone transfer. DNS Dynamic update and incremental zone + transfers [RFC 1995] have been added as a source of DNS data [RFC + 2136, 3007]. When a node in the DNS name tree is created by any of + such inputs, no case conversion is done. Thus the case of ASCII + labels is preserved if they are for nodes being created. However, + when a name label is input for a node that already exist in DNS data + being held, the situation is more complex. Implementations may retain + the case first input for such a label or allow new input to override + the old case or even maintain separate copies preserving the input + case. + + For example, if data with owner name "foo.bar.example" is input and + then later data with owner name "xyz.BAR.example" is input, the name + of the label on the "bar.example" node, i.e. "bar", might or might + not be changed to "BAR" or the actual input case could be preserved. + Thus later retrieval of data stored under "xyz.bar.example" in this + case can easily return data with "xyz.BAR.example". The same + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS Case Insensitivity + + + considerations apply when inputting multiple data records with owner + names differing only in case. For example, if an "A" record is stored + as the first resourced record under owner name "xyz.BAR.example" and + then a second "A" record is stored under "XYZ.BAR.example", the + second MAY be stored with the first (lower case initial label) name + or the second MAY override the first so that only an upper case + initial label is retained or both capitalizations MAY be kept. + + Note that the order of insertion into a server database of the DNS + name tree nodes that appear in a Master File is not defined so that + the results of inconsistent capitalization in a Master File are + unpredictable output capitalization. + + + +5. Internationalized Domain Names + + A scheme has been adopted for "internationalized domain names" and + "internationalized labels" as described in [RFC 3490, 3454, 3491, and + 3492]. It makes most of [UNICODE] available through a separate + application level transformation from internationalized domain name + to DNS domain name and from DNS domain name to internationalized + domain name. Any case insensitivity that internationalized domain + names and labels have varies depending on the script and is handled + entirely as part of the transformation described in [RFC 3454] and + [RFC 3491] which should be seen for further details. This is not a + part of the DNS as standardized in STD 13. + + + +6. Security Considerations + + The equivalence of certain DNS label types with case differences, as + clarified in this document, can lead to security problems. For + example, a user could be confused by believing two domain names + differing only in case were actually different names. + + Furthermore, a domain name may be used in contexts other than the + DNS. It could be used as a case sensitive index into some data base + system. Or it could be interpreted as binary data by some integrity + or authentication code system. These problems can usually be handled + by using a standardized or "canonical" form of the DNS ASCII type + labels, that is, always mapping the ASCII letter value octets in + ASCII labels to some specific pre-chosen case, either upper case or + lower case. An example of a canonical form for domain names (and also + a canonical ordering for them) appears in Section 8 of [RFC 2535]. + See also [RFC 3597]. + + Finally, a non-DNS name may be stored into DNS with the false + expectation that case will always be preserved. For example, although + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS Case Insensitivity + + + this would be quite rare, on a system with case sensitive email + address local parts, an attempt to store two "RP" records that + differed only in case would probably produce unexpected results that + might have security implications. That is because the entire email + address, including the possibly case sensitive local or left hand + part, is encoded into a DNS name in a readable fashion where the case + of some letters might be changed on output as described above. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Copyright and Disclaimer + + Copyright (C) The Internet Society 2004. This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Normative References + + [ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + [RFC 1034, 1035] - See [STD 13]. + + [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August + 1996. + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. + + [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", November 2000. + + [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", + draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. + + [STD 13] + - P. Mockapetris, "Domain names - concepts and facilities", RFC + 1034, November 1987. + - P. Mockapetris, "Domain names - implementation and + specification", RFC 1035, November 1987. + + + + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Informative References + + [RFC 1591] - J. Postel, "Domain Name System Structure and + Delegation", March 1994. + + [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", + June 1999. + + [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain + Name System (DNS) IANA Considerations", September 2000. + + [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August + 1999. + + [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", + August 1999. + + [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of + Foo", 1 April 2001. + + [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of + Internationalized String ("stringprep")", December 2002. + + [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", March 2003. + + [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile + for Internationalized Domain Names (IDN)", March 2003. + + [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications (IDNA)", March + 2003. + + [UNICODE] - The Unicode Consortium, "The Unicode Standard", + . + + + +-02 to -03 Changes + + The following changes were made between draft version -02 and -03: + + 1. Add internationalized domain name section and references. + + 2. Change to indicate that later input of a label for an existing DNS + name tree node may or may not be normalized to the earlier input or + override it or both may be preserved. + + 3. Numerous minor wording changes. + + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS Case Insensitivity + + +-03 to -04 Changes + + The following changes were made between draft version -03 and -04: + + 1. Change to conform to the new IPR, Copyright, etc., notice + requirements. + + 2. Change in some section headers for clarity. + + 3. Drop section on wildcards. + + 4. Add emphasis on loss of case preservation due to name compression. + + 5. Add references to RFCs 1995 and 3092. + + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-786-7554 (w) + +1 508-634-2066 (h) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires December 2004. + + Its file name is draft-ietf-dnsext-insensitive-04.txt. + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 11] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt new file mode 100644 index 000000000000..123d3cc09611 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt @@ -0,0 +1,335 @@ + +DNS Extensions Working Group J. Schlyter +Internet-Draft August 24, 2004 +Expires: February 22, 2005 + + + RFC 3597 Interoperability Report + draft-ietf-dnsext-interop3597-01.txt + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3667. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on February 22, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This memo documents the result from the RFC 3597 (Handling of Unknown + DNS Resource Record Types) interoperability testing. + + + + + + + + + + + + +Schlyter Expires February 22, 2005 [Page 1] + +Internet-Draft RFC 3597 Interoperability Report August 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3 + 3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3 + 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3 + 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + Normative References . . . . . . . . . . . . . . . . . . . . . 4 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 + A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 + Intellectual Property and Copyright Statements . . . . . . . . 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires February 22, 2005 [Page 2] + +Internet-Draft RFC 3597 Interoperability Report August 2004 + + +1. Introduction + + This memo documents the result from the RFC 3597 (Handling of Unknown + DNS Resource Record Types) interoperability testing. The test was + performed during June and July 2004 by request of the IETF DNS + Extensions Working Group. + +2. Implementations + + The following is a list, in alphabetic order, of implementations for + compliance of RFC 3597: + + DNSJava 1.6.4 + ISC BIND 8.4.5rc4 + ISC BIND 9.3.0rc2 + NSD 2.1.1 + Net::DNS 0.47 patchlevel 1 + Nominum ANS 2.2.1.0.d + + These implementations covers the following functions (number of + implementations tested for each function in paranthesis): + + Authoritative Name Servers (4) + Full Recursive Resolver (2) + Stub Resolver (4) + DNSSEC Zone Signers (2) + +3. Tests + +3.1 Authoritative Primary Name Server + + The test zone data (Appendix A) was loaded into the name server + implementation and the server was queried for the loaded information. + +3.2 Authoritative Secondary Name Server + + The test zone data (Appendix A) was transferred using AXFR from + another name server implementation and the server was queried for the + transferred information. + +3.3 Full Recursive Resolver + + A recursive resolver was queried for resource records from a domain + with the test zone data (Appendix A). + +3.4 Stub Resolver + + A stub resolver was used to query resource records from a domain with + + + +Schlyter Expires February 22, 2005 [Page 3] + +Internet-Draft RFC 3597 Interoperability Report August 2004 + + + the test zone data (Appendix A). + +3.5 DNSSEC Signer + + A DNSSEC signer was used to sign a zone with test zone data (Appendix + A). + +4. Problems found + + Two implementations had problems with text presentation of zero + length RDATA. + + One implementation had problems with text presentation of RR type + code and classes >= 4096. + + Bug reports were filed for problems found. + +5. Summary + + Unknown type codes works in the tested authoritative servers, + recursive resolvers and stub clients. + + No changes are needed to advance RFC 3597 to draft standard. + +Normative References + + [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + +Author's Address + + Jakob Schlyter + + EMail: jakob@rfc.se + + + + + + + + + + + + + + + + +Schlyter Expires February 22, 2005 [Page 4] + +Internet-Draft RFC 3597 Interoperability Report August 2004 + + +Appendix A. Test zone data + + ; A-record encoded as TYPE1 + a TYPE1 \# 4 7f000001 + a TYPE1 192.0.2.1 + a A \# 4 7f000002 + + ; draft-ietf-secsh-dns-05.txt + sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e + + ; bogus test record (from RFC 3597) + type731 TYPE731 \# 6 abcd ( + ef 01 23 45 ) + + ; zero length RDATA (from RFC 3597) + type62347 TYPE62347 \# 0 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires February 22, 2005 [Page 5] + +Internet-Draft RFC 3597 Interoperability Report August 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Schlyter Expires February 22, 2005 [Page 6] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt new file mode 100644 index 000000000000..6bffb70423f4 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt @@ -0,0 +1,560 @@ + +DNS Extensions O. Kolkman +Internet-Draft RIPE NCC +Expires: June 17, 2004 J. Schlyter + + E. Lewis + ARIN + December 18, 2003 + + + DNSKEY RR Secure Entry Point Flag + draft-ietf-dnsext-keyrr-key-signing-flag-12 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 17, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + With the Delegation Signer (DS) resource record the concept of a + public key acting as a secure entry point has been introduced. During + exchanges of public keys with the parent there is a need to + differentiate secure entry point keys from other public keys in the + DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is + defined to indicate that DNSKEY is to be used as a secure entry + point. The flag bit is intended to assist in operational procedures + to correctly generate DS resource records, or to indicate what + DNSKEYs are intended for static configuration. The flag bit is not to + + + +Kolkman, et al. Expires June 17, 2004 [Page 1] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + be used in the DNS verification protocol. This document updates RFC + 2535 and RFC 3445. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4 + 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 + 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Internationalization Considerations . . . . . . . . . . . . . . 6 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . . . 7 + Informative References . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 2] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + +1. Introduction + + "All keys are equal but some keys are more equal than others" [6] + + With the definition of the Delegation Signer Resource Record (DS RR) + [5] it has become important to differentiate between the keys in the + DNSKEY RR set that are (to be) pointed to by parental DS RRs and the + other keys in the DNSKEY RR set. We refer to these public keys as + Secure Entry Point (SEP) keys. A SEP key either used to generate a + DS RR or is distributed to resolvers that use the key as the root of + a trusted subtree[3]. + + In early deployment tests, the use of two (kinds of) key pairs for + each zone has been prevalent. For one kind of key pair the private + key is used to sign just the zone's DNSKEY resource record (RR) set. + Its public key is intended to be referenced by a DS RR at the parent + or configured statically in a resolver. The private key of the other + kind of key pair is used to sign the rest of the zone's data sets. + The former key pair is called a key-signing key (KSK) and the latter + is called a zone-signing key (ZSK). In practice there have been + usually one of each kind of key pair, but there will be multiples of + each at times. + + It should be noted that division of keys pairs into KSK's and ZSK's + is not mandatory in any definition of DNSSEC, not even with the + introduction of the DS RR. But, in testing, this distinction has + been helpful when designing key roll over (key super-cession) + schemes. Given that the distinction has proven helpful, the labels + KSK and ZSK have begun to stick. + + There is a need to differentiate the public keys for the key pairs + that are used for key signing from keys that are not used key signing + (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to + be sent for generating DS RRs, which DNSKEYs are to be distributed to + resolvers, and which keys are fed to the signer application at the + appropriate time. + + In other words, the SEP bit provides an in-band method to communicate + a DNSKEY RR's intended use to third parties. As an example we present + 3 use cases in which the bit is useful: + + The parent is a registry, the parent and the child use secured DNS + queries and responses, with a preexisting trust-relation, or plain + DNS over a secured channel to exchange the child's DNSKEY RR + sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset + the SEP bit can be used to isolate the DNSKEYs for which a DS RR + needs to be created. + + + + +Kolkman, et al. Expires June 17, 2004 [Page 3] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + An administrator has configured a DNSKEY as root for a trusted + subtree into security aware resolver. Using a special purpose tool + that queries for the KEY RRs from that domain's apex, the + administrator will be able to notice the roll over of the trusted + anchor by a change of the subset of KEY RRs with the DS flag set. + + A signer might use the SEP bit on the public key to determine + which private key to use to exclusively sign the DNSKEY RRset and + which private key to use to sign the other RRsets in the zone. + + As demonstrated in the above examples it is important to be able to + differentiate the SEP keys from the other keys in a DNSKEY RR set in + the flow between signer and (parental) key-collector and in the flow + between the signer and the resolver configuration. The SEP flag is to + be of no interest to the flow between the verifier and the + authoritative data store. + + The reason for the term "SEP" is a result of the observation that the + distinction between KSK and ZSK key pairs is made by the signer, a + key pair could be used as both a KSK and a ZSK at the same time. To + be clear, the term SEP was coined to lessen the confusion caused by + the overlap. ( Once this label was applied, it had the side effect of + removing the temptation to have both a KSK flag bit and a ZSK flag + bit.) + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119 [1]. + +2. The Secure Entry Point (SEP) Flag + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags |S| protocol | algorithm | + | |E| | | + | |P| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + DNSKEY RR Format + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 4] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + This document assigns the 15'th bit in the flags field as the secure + entry point (SEP) bit. If the the bit is set to 1 the key is + intended to be used as secure entry point key. One SHOULD NOT assign + special meaning to the key if the bit is set to 0. Operators can + recognize the secure entry point key by the even or odd-ness of the + decimal representation of the flag field. + +3. DNSSEC Protocol Changes + + The bit MUST NOT be used during the resolving and verification + process. The SEP flag is only used to provide a hint about the + different administrative properties of the key and therefore the use + of the SEP flag does not change the DNS resolution protocol or the + resolution process. + +4. Operational Guidelines + + The SEP bit is set by the key-pair-generator and MAY be used by the + zone signer to decide whether the public part of the key pair is to + be prepared for input to a DS RR generation function. The SEP bit is + recommended to be set (to 1) whenever the public key of the key pair + will be distributed to the parent zone to build the authentication + chain or if the public key is to be distributed for static + configuration in verifiers. + + When a key pair is created, the operator needs to indicate whether + the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within + the data that is used to compute the 'key tag field' in the SIG RR, + changing the SEP bit will change the identity of the key within DNS. + In other words, once a key is used to generate signatures, the + setting of the SEP bit is to remain constant. If not, a verifier will + not be able to find the relevant KEY RR. + + When signing a zone, it is intended that the key(s) with the SEP bit + set (if such keys exist) are used to sign the KEY RR set of the zone. + The same key can be used to sign the rest of the zone data too. It + is conceivable that not all keys with a SEP bit set will sign the + DNSKEY RR set, such keys might be pending retirement or not yet in + use. + + When verifying a RR set, the SEP bit is not intended to play a role. + How the key is used by the verifier is not intended to be a + consideration at key creation time. + + Although the SEP flag provides a hint on which public key is to be + used as trusted root, administrators can choose to ignore the fact + that a DNSKEY has its SEP bit set or not when configuring a trusted + root for their resolvers. + + + +Kolkman, et al. Expires June 17, 2004 [Page 5] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + Using the SEP flag a key roll over can be automated. The parent can + use an existing trust relation to verify DNSKEY RR sets in which a + new DNSKEY RR with the SEP flag appears. + +5. Security Considerations + + As stated in Section 3 the flag is not to be used in the resolution + protocol or to determine the security status of a key. The flag is to + be used for administrative purposes only. + + No trust in a key should be inferred from this flag - trust MUST be + inferred from an existing chain of trust or an out-of-band exchange. + + Since this flag might be used for automating public key exchanges, we + think the following consideration is in place. + + Automated mechanisms for roll over of the DS RR might be vulnerable + to a class of replay attacks. This might happen after a public key + exchange where a DNSKEY RR set, containing two DNSKEY RRs with the + SEP flag set, is sent to the parent. The parent verifies the DNSKEY + RR set with the existing trust relation and creates the new DS RR + from the DNSKEY RR that the current DS RR is not pointing to. This + key exchange might be replayed. Parents are encouraged to implement a + replay defense. A simple defense can be based on a registry of keys + that have been used to generate DS RRs during the most recent roll + over. These same considerations apply to entities that configure keys + in resolvers. + +6. IANA Considerations + + The flag bits in the DNSKEY RR are assigned by IETF consensus and + registered in the DNSKEY Flags registry (created by [4]). This + document assigns the 15th bit in the DNSKEY RR as the Secure Entry + Point (SEP) bit. + +7. Internationalization Considerations + + Although SEP is a popular acronym in many different languages, there + are no internationalization considerations. + +8. Acknowledgments + + The ideas documented in this document are inspired by communications + we had with numerous people and ideas published by other folk. Among + others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, + Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler + have contributed ideas and provided feedback. + + + + +Kolkman, et al. Expires June 17, 2004 [Page 6] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + This document saw the light during a workshop on DNSSEC operations + hosted by USC/ISI in August 2002. + +Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [4] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work + in progress), October 2003. + +Informative References + + [5] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15 (work in progress), June + 2003. + + [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy + Story", ISBN 0151002177 (50th anniversary edition), April 1996. + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Jakob Schlyter + Karl Gustavsgatan 15 + Goteborg SE-411 25 + Sweden + + EMail: jakob@schlyter.se + + + + +Kolkman, et al. Expires June 17, 2004 [Page 7] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + Edward P. Lewis + ARIN + 3635 Concorde Parkway Suite 200 + Chantilly, VA 20151 + US + + Phone: +1 703 227 9854 + EMail: edlewis@arin.net + URI: http://www.arin.net/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 8] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Kolkman, et al. Expires June 17, 2004 [Page 9] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 10] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt new file mode 100644 index 000000000000..8dcacc8bb9ec --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt @@ -0,0 +1,1559 @@ + + + + + + +DNSEXT Working Group Levon Esibov +INTERNET-DRAFT Bernard Aboba +Category: Standards Track Dave Thaler + Microsoft +18 July 2004 + + + Linklocal Multicast Name Resolution (LLMNR) + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 2, 2005. + +Copyright Notice + + Copyright (C) The Internet Society 2004. All rights reserved. + +Abstract + + Today, with the rise of home networking, there are an increasing + number of ad-hoc networks operating without a Domain Name System + (DNS) server. The goal of Link-Local Multicast Name Resolution + (LLMNR) is to enable name resolution in scenarios in which + conventional DNS name resolution is not possible. LLMNR supports all + current and future DNS formats, types and classes, while operating on + a separate port from DNS, and with a distinct resolver cache. Since + LLMNR only operates on the local link, it cannot be considered a + substitute for DNS. + + + + +Esibov, Aboba & Thaler Standards Track [Page 1] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +Table of Contents + +1. Introduction .......................................... 3 + 1.1 Requirements .................................... 4 + 1.2 Terminology ..................................... 4 +2. Name resolution using LLMNR ........................... 4 + 2.1 LLMNR packet format ............................. 6 + 2.2 Sender behavior ................................. 8 + 2.3 Responder behavior .............................. 8 + 2.4 Unicast queries ................................. 11 + 2.5 Off-link detection .............................. 11 + 2.6 Responder responsibilities ...................... 12 + 2.7 Retransmission and jitter ....................... 13 + 2.8 DNS TTL ......................................... 13 + 2.9 Use of the authority and additional sections .... 14 +3. Usage model ........................................... 14 + 3.1 LLMNR configuration ............................. 15 +4. Conflict resolution ................................... 16 + 4.1 Considerations for multiple interfaces .......... 18 + 4.2 API issues ...................................... 19 +5. Security considerations ............................... 20 + 5.1 Scope restriction ............................... 20 + 5.2 Usage restriction ............................... 21 + 5.3 Cache and port separation ....................... 22 + 5.4 Authentication .................................. 22 +6. IANA considerations ................................... 22 +7. References ............................................ 22 + 7.1 Normative References ............................ 22 + 7.2 Informative References .......................... 23 +Acknowledgments .............................................. 24 +Authors' Addresses ........................................... 25 +Intellectual Property Statement .............................. 25 +Disclaimer of Validity ....................................... 26 +Full Copyright Statement ..................................... 26 + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 2] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +1. Introduction + + This document discusses Link Local Multicast Name Resolution (LLMNR), + which utilizes the DNS packet format and supports all current and + future DNS formats, types and classes. LLMNR operates on a separate + port from the Domain Name System (DNS), with a distinct resolver + cache. + + The goal of LLMNR is to enable name resolution in scenarios in which + conventional DNS name resolution is not possible. These include + scenarios in which hosts are not configured with the address of a DNS + server, where configured DNS servers do not reply to a query, or + where they respond with errors, as described in Section 2. Since + LLMNR only operates on the local link, it cannot be considered a + substitute for DNS. + + Link-scope multicast addresses are used to prevent propagation of + LLMNR traffic across routers, potentially flooding the network. + LLMNR queries can also be sent to a unicast address, as described in + Section 2.4. + + Propagation of LLMNR packets on the local link is considered + sufficient to enable name resolution in small networks. The + assumption is that if a network has a gateway, then the network is + able to provide DNS server configuration. Configuration issues are + discussed in Section 3.1. + + In the future, it may be desirable to consider use of multicast name + resolution with multicast scopes beyond the link-scope. This could + occur if LLMNR deployment is successful, the need arises for + multicast name resolution beyond the link-scope, or multicast routing + becomes ubiquitous. For example, expanded support for multicast name + resolution might be required for mobile ad-hoc networking scenarios, + or where no DNS server is available that is authoritative for the + names of local hosts, and can support dynamic DNS, such as in + wireless hotspots. + + Once we have experience in LLMNR deployment in terms of + administrative issues, usability and impact on the network, it will + be possible to reevaluate which multicast scopes are appropriate for + use with multicast name resolution. + + Service discovery in general, as well as discovery of DNS servers + using LLMNR in particular, is outside of the scope of this document, + as is name resolution over non-multicast capable media. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 3] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +1.1. Requirements + + In this document, several words are used to signify the requirements + of the specification. The key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +1.2. Terminology + + This document assumes familiarity with DNS terminology defined in + [RFC1035]. Other terminology used in this document includes: + +Positively Resolved + Responses with RCODE set to zero are referred to in this document + as "positively resolved". + +Routable Address + An address other than a Link-Local address. This includes globally + routable addresses, as well as private addresses. + +Reachable + An address is considered reachable over a link if either an ARP or + neighbor discovery cache entry exists for the address on the link. + +Responder + A host that listens to LLMNR queries, and responds to those for + which it is authoritative. + +Sender + A host that sends an LLMNR query. + +2. Name resolution using LLMNR + + LLMNR is a peer-to-peer name resolution protocol that is not intended + as a replacement for DNS. LLMNR queries are sent to and received on + port 5355. IPv4 administratively scoped multicast usage is specified + in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link- + scope multicast address a given responder listens to, and to which a + sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast + address a given responder listens to, and to which a sender sends all + queries, is FF02:0:0:0:0:0:1:3. + + Typically a host is configured as both an LLMNR sender and a + responder. A host MAY be configured as a sender, but not a + responder. However, a host configured as a responder MUST act as a + sender to verify the uniqueness of names as described in Section 4. + This document does not specify how names are chosen or configured. + + + +Esibov, Aboba & Thaler Standards Track [Page 4] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + This may occur via any mechanism, including DHCPv4 [RFC2131] or + DHCPv6 [RFC3315]. + + LLMNR usage MAY be configured manually or automatically on a per + interface basis. By default, LLMNR responders SHOULD be enabled on + all interfaces, at all times. Enabling LLMNR for use in situations + where a DNS server has been configured will result in a change in + default behavior without a simultaneous update to configuration + information. Where this is considered undesirable, LLMNR SHOULD NOT + be enabled by default, so that hosts will neither listen on the link- + scope multicast address, nor will they send queries to that address. + + An LLMNR sender may send a request for any name. However, by + default, LLMNR requests SHOULD be sent only when one of the following + conditions are met: + + [1] No manual or automatic DNS configuration has been + performed. If an interface has been configured with DNS + server address(es), then LLMNR SHOULD NOT be used as the + primary name resolution mechanism on that interface, although + it MAY be used as a name resolution mechanism of last resort. + + [2] DNS servers do not respond. + + [3] DNS servers respond to a DNS query with RCODE=3 + (Authoritative Name Error) or RCODE=0, and an empty + answer section. + + A typical sequence of events for LLMNR usage is as follows: + + [a] DNS servers are not configured or do not respond to a + DNS query, or respond with RCODE=3, or RCODE=0 and an + empty answer section. + + [b] An LLMNR sender sends an LLMNR query to the link-scope + multicast address(es) defined in Section 2, unless a + unicast query is indicated. A sender SHOULD send LLMNR + queries for PTR RRs via unicast, as specified in Section 2.4. + + [c] A responder responds to this query only if it is authoritative + for the domain name in the query. A responder responds to a + multicast query by sending a unicast UDP response to the sender. + Unicast queries are responded to as indicated in Section 2.4. + + [d] Upon reception of the response, the sender processes it. + + Further details of sender and responder behavior are provided in the + sections that follow. + + + +Esibov, Aboba & Thaler Standards Track [Page 5] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +2.1. LLMNR packet format + + LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 + for both queries and responses. LLMNR implementations SHOULD send + UDP queries and responses only as large as are known to be + permissible without causing fragmentation. When in doubt a maximum + packet size of 512 octets SHOULD be used. LLMNR implementations MUST + accept UDP queries and responses as large as permitted by the link + MTU. + +2.1.1. LLMNR header format + + LLMNR queries and responses utilize the DNS header format defined in + [RFC1035] with exceptions noted below: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + +ID A 16 bit identifier assigned by the program that generates any kind + of query. This identifier is copied from the query to the response + and can be used by the sender to match responses to outstanding + queries. The ID field in a query SHOULD be set to a pseudo-random + value. + +QR A one bit field that specifies whether this message is an LLMNR + query (0), or an LLMNR response (1). + +OPCODE + A four bit field that specifies the kind of query in this message. + This value is set by the originator of a query and copied into the + response. This specification defines the behavior of standard + queries and responses (opcode value of zero). Future + specifications may define the use of other opcodes with LLMNR. + + + +Esibov, Aboba & Thaler Standards Track [Page 6] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + LLMNR senders and responders MUST support standard queries (opcode + value of zero). LLMNR queries with unsupported OPCODE values MUST + be silently discarded by responders. + +TC TrunCation - specifies that this message was truncated due to + length greater than that permitted on the transmission channel. + The TC bit MUST NOT be set in an LLMNR query and if set is ignored + by an LLMNR responder. If the TC bit is set an LLMNR response, + then the sender MAY use the response if it contains all necessary + information, or the sender MAY discard the response and resend the + LLMNR query over TCP using the unicast address of the responder as + the destination address. See [RFC2181] and Section 2.4 of this + specification for further discussion of the TC bit. + +Z Reserved for future use. Implementations of this specification + MUST set these bits to zero in both queries and responses. If + these bits are set in a LLMNR query or response, implementations of + this specification MUST ignore them. Since reserved bits could + conceivably be used for different purposes than in DNS, + implementors are advised not to enable processing of these bits in + an LLMNR implementation starting from a DNS code base. + +RCODE + Response code -- this 4 bit field is set as part of LLMNR + responses. In an LLMNR query, the RCODE MUST be zero, and is + ignored by the responder. The response to a multicast LLMNR query + MUST have RCODE set to zero. A sender MUST silently discard an + LLMNR response with a non-zero RCODE sent in response to a + multicast query. + + If an LLMNR responder is authoritative for the name in a multicast + query, but an error is encountered, the responder SHOULD send an + LLMNR response with an RCODE of zero, no RRs in the answer section, + and the TC bit set. This will cause the query to be resent using + TCP, and allow the inclusion of a non-zero RCODE in the response to + the TCP query. Responding with the TC bit set is preferrable to + not sending a response, since it enables errors to be diagnosed. + + Since LLMNR responders only respond to LLMNR queries for names for + which they are authoritative, LLMNR responders MUST NOT respond + with an RCODE of 3; instead, they should not respond at all. + + LLMNR implementations MUST support EDNS0 [RFC2671] and extended + RCODE values. + +QDCOUNT + An unsigned 16 bit integer specifying the number of entries in the + question section. A sender MUST place only one question into the + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + question section of an LLMNR query. LLMNR responders MUST silently + discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders + MUST silently discard LLMNR responses with QDCOUNT not equal to + one. + +ANCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the answer section. LLMNR responders MUST silently + discard LLMNR queries with ANCOUNT not equal to zero. + +NSCOUNT + An unsigned 16 bit integer specifying the number of name server + resource records in the authority records section. Authority + record section processing is described in Section 2.9. + +ARCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the additional records section. Additional record + section processing is described in Section 2.9. + +2.2. Sender behavior + + A sender may send an LLMNR query for any legal resource record type + (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. + + As described in Section 2.4, a sender may also send a unicast query. + Sections 2 and 3 describe the circumstances in which LLMNR queries + may be sent. + + The sender MUST anticipate receiving no replies to some LLMNR + queries, in the event that no responders are available within the + link-scope or in the event no positive non-null responses exist for + the transmitted query. If no positive response is received, a + resolver treats it as a response that no records of the specified + type and class exist for the specified name (it is treated the same + as a response with RCODE=0 and an empty answer section). + + Since the responder may order the RRs in the response so as to + indicate preference, the sender SHOULD preserve ordering in the + response to the querying application. + +2.3. Responder behavior + + An LLMNR response MUST be sent to the sender via unicast. + + Upon configuring an IP address responders typically will synthesize + corresponding A, AAAA and PTR RRs so as to be able to respond to + LLMNR queries for these RRs. An SOA RR is synthesized only when a + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + responder has another RR as well; the SOA RR MUST NOT be the only RR + that a responder has. However, in general whether RRs are manually + or automatically created is an implementation decision. + + For example, a host configured to have computer name "host1" and to + be a member of the "example.com" domain, and with IPv4 address + 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be + authoritative for the following records: + + host1. IN A 10.1.1.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + host1.example.com. IN A 10.1.1.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + 1.1.1.10.in-addr.arpa. IN PTR host1. + IN PTR host1.example.com. + + 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa + IN PTR host1. + IN PTR host1.example.com + + An LLMNR responder might be further manually configured with the name + of a local mail server with an MX RR included in the "host1." and + "host1.example.com." records. + + In responding to queries: + +[a] Responders MUST listen on UDP port 5355 on the link-scope multicast + address(es) defined in Section 2, and on UDP and TCP port 5355 on + the unicast address(es) that could be set as the source address(es) + when the responder responds to the LLMNR query. + +[b] Responders MUST direct responses to the port from which the query + was sent. When queries are received via TCP this is an inherent + part of the transport protocol. For queries received by UDP the + responder MUST take note of the source port and use that as the + destination port in the response. Responses SHOULD always be sent + from the port to which they were directed. + +[c] Responders MUST respond to LLMNR queries for names and addresses + they are authoritative for. This applies to both forward and + reverse lookups. + +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +[e] Responders MUST NOT respond using cached data. + +[f] If a DNS server is running on a host that supports LLMNR, the DNS + server MUST respond to LLMNR queries only for the RRSets relating + to the host on which the server is running, but MUST NOT respond + for other records for which the server is authoritative. DNS + servers also MUST NOT send LLMNR queries in order to resolve DNS + queries. + +[g] If a responder is authoritative for a name, it MAY respond with + RCODE=0 and an empty answer section, if the type of query does not + match a RR that the responder has. + + As an example, a host configured to respond to LLMNR queries for the + name "foo.example.com." is authoritative for the name + "foo.example.com.". On receiving an LLMNR query for an A RR with the + name "foo.example.com." the host authoritatively responds with A + RR(s) that contain IP address(es) in the RDATA of the resource + record. If the responder has a AAAA RR, but no A RR, and an A RR + query is received, the responder would respond with RCODE=0 and an + empty answer section. + + In conventional DNS terminology a DNS server authoritative for a zone + is authoritative for all the domain names under the zone apex except + for the branches delegated into separate zones. Contrary to + conventional DNS terminology, an LLMNR responder is authoritative + only for the zone apex. + + For example the host "foo.example.com." is not authoritative for the + name "child.foo.example.com." unless the host is configured with + multiple names, including "foo.example.com." and + "child.foo.example.com.". As a result, "foo.example.com." cannot + reply to an LLMNR query for "child.foo.example.com." with RCODE=3 + (authoritative name error). The purpose of limiting the name + authority scope of a responder is to prevent complications that could + be caused by coexistence of two or more hosts with the names + representing child and parent (or grandparent) nodes in the DNS tree, + for example, "foo.example.com." and "child.foo.example.com.". + + In this example (unless this limitation is introduced) an LLMNR query + for an A resource record for the name "child.foo.example.com." would + result in two authoritative responses: RCODE=3 (authoritative name + error) received from "foo.example.com.", and a requested A record - + from "child.foo.example.com.". To prevent this ambiguity, LLMNR + enabled hosts could perform a dynamic update of the parent (or + grandparent) zone with a delegation to a child zone. In this example + a host "child.foo.example.com." would send a dynamic update for the + NS and glue A record to "foo.example.com.", but this approach + + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + significantly complicates implementation of LLMNR and would not be + acceptable for lightweight hosts. + +2.4. Unicast queries and responses + + Unicast queries SHOULD be sent when: + + [a] A sender repeats a query after it received a response + with the TC bit set to the previous LLMNR multicast query, or + + [b] The sender queries for a PTR RR of a fully formed IP address + within the "in-addr.arpa" or "ip6.arpa" zones. + + Unicast LLMNR queries MUST be done using TCP and the responses MUST + be sent using the same TCP connection as the query. Senders MUST + support sending TCP queries, and responders MUST support listening + for TCP queries. If the sender of a TCP query receives a response to + that query not using TCP, the response MUST be silently discarded. + + Unicast UDP queries MUST be silently discarded. + + If TCP connection setup cannot be completed in order to send a + unicast TCP query, this is treated as a response that no records of + the specified type and class exist for the specified name (it is + treated the same as a response with RCODE=0 and an empty answer + section). + +2.5. "Off link" detection + + For IPv4, an "on link" address is defined as a link-local address + [IPv4Link] or an address whose prefix belongs to a subnet on the + local link. For IPv6 [RFC2460] an "on link" address is either a + link-local address, defined in [RFC2373], or an address whose prefix + belongs to a subnet on the local link. + + A sender MUST select a source address for LLMNR queries that is "on + link". The destination address of an LLMNR query MUST be a link- + scope multicast address or an "on link" unicast address. + + A responder MUST select a source address for responses that is "on + link". The destination address of an LLMNR response MUST be an "on + link" unicast address. + + On receiving an LLMNR query, the responder MUST check whether it was + sent to a LLMNR multicast addresses defined in Section 2. If it was + sent to another multicast address, then the query MUST be silently + discarded. + + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + Section 2.4 discusses use of TCP for LLMNR queries and responses. In + composing an LLMNR query using TCP, the sender MUST set the Hop Limit + field in the IPv6 header and the TTL field in the IPv4 header of the + response to one (1). The responder SHOULD set the TTL or Hop Limit + settings on the TCP listen socket to one (1) so that SYN-ACK packets + will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This + prevents an incoming connection from off-link since the sender will + not receive a SYN-ACK from the responder. + + For UDP queries and responses the Hop Limit field in the IPv6 header, + and the TTL field in the IPV4 header MAY be set to any value. + However, it is RECOMMENDED that the value 255 be used for + compatibility with Apple Rendezvous. + + Implementation note: + + In the sockets API for IPv4 [POSIX], the IP_TTL and + IP_MULTICAST_TTL socket options are used to set the TTL of + outgoing unicast and multicast packets. The IP_RECVTTL socket + option is available on some platforms to retrieve the IPv4 TTL of + received packets with recvmsg(). [RFC2292] specifies similar + options for setting and retrieving the IPv6 Hop Limit. + +2.6. Responder responsibilities + + It is the responsibility of the responder to ensure that RRs returned + in LLMNR responses MUST only include values that are valid on the + local interface, such as IPv4 or IPv6 addresses valid on the local + link or names defended using the mechanism described in Section 4. + In particular: + + [a] If a link-scope IPv6 address is returned in a AAAA RR, + that address MUST be valid on the local link over which + LLMNR is used. + + [b] If an IPv4 address is returned, it MUST be reachable + through the link over which LLMNR is used. + + [c] If a name is returned (for example in a CNAME, MX + or SRV RR), the name MUST be resolvable on the local + link over which LLMNR is used. + + Routable addresses MUST be included first in the response, if + available. This encourages use of routable address(es) for + establishment of new connections. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +2.7. Retransmission and jitter + + An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine + when to retransmit an LLMNR query and how long to collect responses + to an LLMNR query. + + If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, + then a sender MAY repeat the transmission of the query in order to + assure that it was received by a host capable of responding to it. + Retransmission of UDP queries SHOULD NOT be attempted more than 3 + times. Where LLMNR queries are sent using TCP, retransmission is + handled by the transport layer. + + Because an LLMNR sender cannot know in advance if a query sent using + multicast will receive no response, one response, or more than one + response, the sender SHOULD wait for LLMNR_TIMEOUT in order to + collect all possible responses, rather than considering the multicast + query answered after the first response is received. A unicast query + sender considers the query answered after the first response is + received, so that it only waits for LLMNR_TIMEOUT if no response has + been received. + + An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT + for each transmission. It is suggested that the computation of + LLMNR_TIMEOUT be based on the response times for earlier LLMNR + queries sent on the same interface. + + For example, the algorithms described in RFC 2988 [RFC2988] + (including exponential backoff) compute an RTO, which is used as the + value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial + RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum + RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the + maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). + + Recommended values are an initial RTO of 1 second, a minimum RTO of + 200ms, and a maximum RTO of 5 seconds. In order to avoid + synchronization, the transmission of each LLMNR query and response + SHOULD delayed by a time randomly selected from the interval 0 to 100 + ms. This delay MAY be avoided by responders responding with RRs + which they have previously determined to be UNIQUE (see Section 4 for + details). + +2.8. DNS TTL + + The responder should use a pre-configured TTL value in the records + returned an LLMNR response. A default value of 30 seconds is + RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc + networks), the TTL value may need to be reduced. + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + Due to the TTL minimalization necessary when caching an RRset, all + TTLs in an RRset MUST be set to the same value. + +2.9. Use of the authority and additional sections + + Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a + concept of delegation. In LLMNR, the NS resource record type may be + stored and queried for like any other type, but it has no special + delegation semantics as it does in the DNS. Responders MAY have NS + records associated with the names for which they are authoritative, + but they SHOULD NOT include these NS records in the authority + sections of responses. + + Responders SHOULD insert an SOA record into the authority section of + a negative response, to facilitate negative caching as specified in + [RFC2308]. The owner name of this SOA record MUST be equal to the + query name. + + Responders SHOULD NOT perform DNS additional section processing, + except as required for EDNS0 and DNSSEC. + + Senders MUST NOT cache RRs from the authority or additional section + of a response as answers, though they may be used for other purposes + such as negative caching. + +3. Usage model + + Since LLMNR is a secondary name resolution mechanism, its usage is in + part determined by the behavior of DNS implementations. This + document does not specify any changes to DNS resolver behavior, such + as searchlist processing or retransmission/failover policy. However, + robust DNS resolver implementations are more likely to avoid + unnecessary LLMNR queries. + + As noted in [DNSPerf], even when DNS servers are configured, a + significant fraction of DNS queries do not receive a response, or + result in negative responses due to missing inverse mappings or NS + records that point to nonexistent or inappropriate hosts. This has + the potential to result in a large number of unnecessary LLMNR + queries. + + [RFC1536] describes common DNS implementation errors and fixes. If + the proposed fixes are implemented, unnecessary LLMNR queries will be + reduced substantially, and so implementation of [RFC1536] is + recommended. + + For example, [RFC1536] Section 1 describes issues with retransmission + and recommends implementation of a retransmission policy based on + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + round trip estimates, with exponential backoff. [RFC1536] Section 4 + describes issues with failover, and recommends that resolvers try + another server when they don't receive a response to a query. These + policies are likely to avoid unnecessary LLMNR queries. + + [RFC1536] Section 3 describes zero answer bugs, which if addressed + will also reduce unnecessary LLMNR queries. + + [RFC1536] Section 6 describes name error bugs and recommended + searchlist processing that will reduce unnecessary RCODE=3 + (authoritative name) errors, thereby also reducing unnecessary LLMNR + queries. + +3.1. LLMNR configuration + + Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is + possible for a dual stack host to be configured with the address of a + DNS server over IPv4, while remaining unconfigured with a DNS server + suitable for use over IPv6. + + In these situations, a dual stack host will send AAAA queries to the + configured DNS server over IPv4. However, an IPv6-only host + unconfigured with a DNS server suitable for use over IPv6 will be + unable to resolve names using DNS. Automatic IPv6 DNS configuration + mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely + deployed, and not all DNS servers support IPv6. Therefore lack of + IPv6 DNS configuration may be a common problem in the short term, and + LLMNR may prove useful in enabling linklocal name resolution over + IPv6. + + Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], + IPv6-only hosts may not be configured with a DNS server. Where there + is no DNS server authoritative for the name of a host or the + authoritative DNS server does not support dynamic client update over + IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not + be able to do DNS dynamic update, and other hosts will not be able to + resolve its name. + + For example, if the configured DNS server responds to AAAA RR queries + sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), + then it will not be possible to resolve the names of IPv6-only hosts. + In this situation, LLMNR over IPv6 can be used for local name + resolution. + + Similarly, if a DHCPv4 server is available providing DNS server + configuration, and DNS server(s) exist which are authoritative for + the A RRs of local hosts and support either dynamic client update + over IPv4 or DHCPv4-based dynamic update, then the names of local + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no + DNS server is authoritative for the names of local hosts, or the + authoritative DNS server(s) do not support dynamic update, then LLMNR + enables linklocal name resolution over IPv4. + + Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to + configure LLMNR on an interface. The LLMNR Enable Option, described + in [LLMNREnable], can be used to explicitly enable or disable use of + LLMNR on an interface. The LLMNR Enable Option does not determine + whether or in which order DNS itself is used for name resolution. + The order in which various name resolution mechanisms should be used + can be specified using the Name Service Search Option (NSSO) for DHCP + [RFC2937], using the LLMNR Enable Option code carried in the NSSO + data. + + It is possible that DNS configuration mechanisms will go in and out + of service. In these circumstances, it is possible for hosts within + an administrative domain to be inconsistent in their DNS + configuration. + + For example, where DHCP is used for configuring DNS servers, one or + more DHCP servers can fail. As a result, hosts configured prior to + the outage will be configured with a DNS server, while hosts + configured after the outage will not. Alternatively, it is possible + for the DNS configuration mechanism to continue functioning while + configured DNS servers fail. + + Unless unconfigured hosts periodically retry configuration, an outage + in the DNS configuration mechanism will result in hosts continuing to + use LLMNR even once the outage is repaired. Since LLMNR only enables + linklocal name resolution, this represents an unnecessary degradation + in capabilities. As a result, it is recommended that hosts without a + configured DNS server periodically attempt to obtain DNS + configuration. For example, where DHCP is used for DNS + configuration, [RFC2131] recommends a maximum retry interval of 64 + seconds. In the absence of other guidance, a default retry interval + of one (1) minute is RECOMMENDED. + +4. Conflict resolution + + The sender MUST anticipate receiving multiple replies to the same + LLMNR query, in the event that several LLMNR enabled computers + receive the query and respond with valid answers. When this occurs, + the responses may first be concatenated, and then treated in the same + manner that multiple RRs received from the same DNS server would; the + sender perceives no inherent conflict in the receipt of multiple + responses. + + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + There are some scenarios when multiple responders MAY respond to the + same query. There are other scenarios when only one responder MAY + respond to a query. Resource records for which the latter queries + are submitted are referred as UNIQUE throughout this document. The + uniqueness of a resource record depends on a nature of the name in + the query and type of the query. For example it is expected that: + + - multiple hosts may respond to a query for an SRV type record + - multiple hosts may respond to a query for an A or AAAA type + record for a cluster name (assigned to multiple hosts in + the cluster) + - only a single host may respond to a query for an A or AAAA + type record for a name. + + Every responder that responds to an LLMNR query AND includes a UNIQUE + record in the response: + + [1] MUST verify that there is no other host within the + scope of the LLMNR query propagation that can return + a resource record for the same name, type and class. + + [2] MUST NOT include a UNIQUE resource record in the + response without having verified its uniqueness. + + Where a host is configured to issue LLMNR queries on more than one + interface, each interface should have its own independent LLMNR + cache. For each UNIQUE resource record in a given interface's + configuration, the host MUST verify resource record uniqueness on + that interface. To accomplish this, the host MUST send an LLMNR + query for each UNIQUE resource record. + + By default, a host SHOULD be configured to behave as though all RRs + are UNIQUE. Uniqueness verification is carried out when the host: + + - starts up or is rebooted + - wakes from sleep (if the network interface was inactive during sleep) + - is configured to respond to the LLMNR queries on an interface + enabled for transmission and reception of IP traffic + - is configured to respond to the LLMNR queries using additional + UNIQUE resource records + - detects that an interface is connected and is usable + (e.g. an IEEE 802 hardware link-state change indicating + that a cable was attached or completion of authentication + (and if needed, association) with a wireless base station + or adhoc network + + When a host that has a UNIQUE record receives an LLMNR query for that + record, the host MUST respond. After the client receives a response, + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + it MUST check whether the response arrived on an interface different + from the one on which the query was sent. If the response arrives on + a different interface, the client can use the UNIQUE resource record + in response to LLMNR queries. If not, then it MUST NOT use the + UNIQUE resource record in response to LLMNR queries. + + The name conflict detection mechanism doesn't prevent name conflicts + when previously partitioned segments are connected by a bridge. In + order to minimize the chance of conflicts in such a situation, it is + recommended that steps be taken to ensure name uniqueness. For + example, the name could be chosen randomly from a large pool of + potential names, or the name could be assigned via a process designed + to guarantee uniqueness. + + When name conflicts are detected, they SHOULD be logged. To detect + duplicate use of a name, an administrator can use a name resolution + utility which employs LLMNR and lists both responses and responders. + This would allow an administrator to diagnose behavior and + potentially to intervene and reconfigure LLMNR responders who should + not be configured to respond to the same name. + +4.1. Considerations for Multiple Interfaces + + A multi-homed host may elect to configure LLMNR on only one of its + active interfaces. In many situations this will be adequate. + However, should a host need to configure LLMNR on more than one of + its active interfaces, there are some additional precautions it MUST + take. Implementers who are not planning to support LLMNR on multiple + interfaces simultaneously may skip this section. + + A multi-homed host checks the uniqueness of UNIQUE records as + described in Section 4. The situation is illustrated in figure 1. + + ---------- ---------- + | | | | + [A] [myhost] [myhost] + + Figure 1. Link-scope name conflict + + In this situation, the multi-homed myhost will probe for, and defend, + its host name on both interfaces. A conflict will be detected on one + interface, but not the other. The multi-homed myhost will not be + able to respond with a host RR for "myhost" on the interface on the + right (see Figure 1). The multi-homed host may, however, be + configured to use the "myhost" name on the interface on the left. + + Since names are only unique per-link, hosts on different links could + be using the same name. If an LLMNR client sends requests over + + + +Esibov, Aboba & Thaler Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + multiple interfaces, and receives replies from more than one, the + result returned to the client is defined by the implementation. The + situation is illustrated in figure 2. + + ---------- ---------- + | | | | + [A] [myhost] [A] + + + Figure 2. Off-segment name conflict + + If host myhost is configured to use LLMNR on both interfaces, it will + send LLMNR queries on both interfaces. When host myhost sends a + query for the host RR for name "A" it will receive a response from + hosts on both interfaces. + + Host myhost cannot distinguish between the situation shown in Figure + 2, and that shown in Figure 3 where no conflict exists. + + [A] + | | + ----- ----- + | | + [myhost] + + Figure 3. Multiple paths to same host + + This illustrates that the proposed name conflict resolution mechanism + does not support detection or resolution of conflicts between hosts + on different links. This problem can also occur with unicast DNS + when a multi-homed host is connected to two different networks with + separated name spaces. It is not the intent of this document to + address the issue of uniqueness of names within DNS. + +4.2. API issues + + [RFC2553] provides an API which can partially solve the name + ambiguity problem for applications written to use this API, since the + sockaddr_in6 structure exposes the scope within which each scoped + address exists, and this structure can be used for both IPv4 (using + v4-mapped IPv6 addresses) and IPv6 addresses. + + Following the example in Figure 2, an application on 'myhost' issues + the request getaddrinfo("A", ...) with ai_family=AF_INET6 and + ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both + interfaces and the resolver library will return a list containing + multiple addrinfo structures, each with an associated sockaddr_in6 + structure. This list will thus contain the IPv4 and IPv6 addresses + + + +Esibov, Aboba & Thaler Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + of both hosts responding to the name 'A'. Link-local addresses will + have a sin6_scope_id value that disambiguates which interface is used + to reach the address. Of course, to the application, Figures 2 and 3 + are still indistinguishable, but this API allows the application to + communicate successfully with any address in the list. + +5. Security Considerations + + LLMNR is by nature a peer-to-peer name resolution protocol. It is + therefore inherently more vulnerable than DNS, since existing DNS + security mechanisms are difficult to apply to LLMNR. While tools + exist to alllow an attacker to spoof a response to a DNS query, + spoofing a response to an LLMNR query is easier since the query is + sent to a link-scope multicast address, where every host on the + logical link will be made aware of it. + + In order to address the security vulnerabilities, the following + mechanisms are contemplated: + + [1] Scope restrictions. + [2] Usage restrictions. + [3] Cache and port separation. + [4] Authentication. + + These techniques are described in the following sections. + +5.1. Scope restriction + + With LLMNR it is possible that hosts will allocate conflicting names + for a period of time, or that attackers will attempt to deny service + to other hosts by allocating the same name. Such attacks also allow + hosts to receive packets destined for other hosts. + + Since LLMNR is typically deployed in situations where no trust model + can be assumed, it is likely that LLMNR queries and responses will be + unauthenticated. In the absence of authentication, LLMNR reduces the + exposure to such threats by utilizing UDP queries sent to a link- + scope multicast address, as well as setting the TTL (IPv4) or Hop + Limit (IPv6) fields to one (1) on TCP queries and responses. + + Using a TTL of one (1) to set up a TCP connection in order to send a + unicast LLMNR query reduces the likelihood of both denial of service + attacks and spoofed responses. Checking that an LLMNR query is sent + to a link-scope multicast address should prevent spoofing of + multicast queries by off-link attackers. + + While this limits the ability of off-link attackers to spoof LLMNR + queries and responses, it does not eliminate it. For example, it is + + + +Esibov, Aboba & Thaler Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + possible for an attacker to spoof a response to a frequent query + (such as an A or AAAA query for a popular Internet host), and by + using a TTL or Hop Limit field larger than one (1), for the forged + response to reach the LLMNR sender. + + When LLMNR queries are sent to a link-scope multicast address, it is + possible that some routers may not properly implement link-scope + multicast, or that link-scope multicast addresses may leak into the + multicast routing system. + + Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than + one in an LLMNR UDP response may enable denial of service attacks + across the Internet. However, since LLMNR responders only respond to + queries for which they are authoritative, and LLMNR does not provide + wildcard query support, it is believed that this threat is minimal. + + There also are scenarios such as public "hotspots" where attackers + can be present on the same link. These threats are most serious in + wireless networks such as 802.11, since attackers on a wired network + will require physical access to the home network, while wireless + attackers may reside outside the home. Link-layer security can be of + assistance against these threats if it is available. + +5.2. Usage restriction + + As noted in Sections 2 and 3, LLMNR is intended for usage in a + limited set of scenarios. + + If an LLMNR query is sent whenever a DNS server does not respond in a + timely way, then an attacker can poison the LLMNR cache by responding + to the query with incorrect information. To some extent, these + vulnerabilities exist today, since DNS response spoofing tools are + available that can allow an attacker to respond to a query more + quickly than a distant DNS server. + + Since LLMNR queries are sent and responded to on the local-link, an + attacker will need to respond more quickly to provide its own + response prior to arrival of the response from a legitimate + responder. If an LLMNR query is sent for an off-link host, spoofing a + response in a timely way is not difficult, since a legitimate + response will never be received. + + The vulnerability is more serious if LLMNR is given higher priority + than DNS among the enabled name resolution mechanisms. In such a + configuration, a denial of service attack on the DNS server would not + be necessary in order to poison the LLMNR cache, since LLMNR queries + would be sent even when the DNS server is available. In addition, the + LLMNR cache, once poisoned, would take precedence over the DNS cache, + + + +Esibov, Aboba & Thaler Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + + eliminating the benefits of cache separation. As a result, LLMNR is + only used as a name resolution mechanism of last resort. + +5.3. Cache and port separation + + In order to prevent responses to LLMNR queries from polluting the DNS + cache, LLMNR implementations MUST use a distinct, isolated cache for + LLMNR on each interface. The use of separate caches is most effective + when LLMNR is used as a name resolution mechanism of last resort, + since this minimizes the opportunities for poisoning the LLMNR cache, + and decreases reliance on it. + + LLMNR operates on a separate port from DNS, reducing the likelihood + that a DNS server will unintentionally respond to an LLMNR query. + +5.4. Authentication + + LLMNR implementations may not support DNSSEC or TSIG, and as a + result, responses to LLMNR queries may be unauthenticated. If + authentication is desired, and a pre-arranged security configuration + is possible, then IPsec ESP with a null-transform MAY be used to + authenticate LLMNR responses. In a small network without a + certificate authority, this can be most easily accomplished through + configuration of a group pre-shared key for trusted hosts. + +6. IANA Considerations + + This specification creates one new name space: the reserved bits in + the LLMNR header. These are allocated by IETF Consensus, in + accordance with BCP 26 [RFC2434]. + + LLMNR requires allocation of port 5355 for both TCP and UDP. + + LLMNR requires allocation of link-scope multicast IPv4 address + 224.0.0.252, as well as link-scope multicast IPv6 address + FF02:0:0:0:0:0:1:3. + +7. References + +7.1. Normative References + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + +[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + +[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + +[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + +[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + +[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + +[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + +[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + +7.2. Informative References + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested + Fixes", RFC 1536, October 1993. + +[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + +[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + +[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + +[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic + Socket Interface Extensions for IPv6", RFC 2553, March 1999. + + + +Esibov, Aboba & Thaler Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + +[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + +[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of + Caching", IEEE/ACM Transactions on Networking, Volume 10, + Number 5, pp. 589, October 2002. + +[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local + unicast addresses to communicate with recursive DNS servers", + Internet draft (work in progress), draft-ietf-ipv6-dns- + discovery-07.txt, October 2002. + +[IPV4Link] + Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of IPv4 Link-Local Addresses", Internet draft (work in + progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May + 2004. + +[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX). Open Group + Technical Standard: Base Specifications, Issue 6, December + 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin + +[LLMNREnable] + Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work + in progress), draft-guttman-mdns-enable-02.txt, April 2002. + +[NodeInfo] + Crawford, M., "IPv6 Node Information Queries", Internet draft + (work in progress), draft-ietf-ipn-gwg-icmp-name- + lookups-09.txt, May 2002. + +Acknowledgments + + This work builds upon original work done on multicast DNS by Bill + Manning and Bill Woodcock. Bill Manning's work was funded under DARPA + grant #F30602-99-1-0523. The authors gratefully acknowledge their + contribution to the current specification. Constructive input has + also been received from Mark Andrews, Stuart Cheshire, Randy Bush, + Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik + Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik + Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill, + Keith Moore and Markku Savela. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +Authors' Addresses + + Levon Esibov + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: levone@microsoft.com + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 706 6605 + EMail: bernarda@microsoft.com + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 18 July 2004 + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + +Open Issues + + Open issues with this specification are tracked on the following web + site: + + http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 26] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt new file mode 100644 index 000000000000..c5c3b84ba3d5 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt @@ -0,0 +1,1235 @@ + + + + + + +DNSEXT Working Group Yuji Kamite +INTERNET-DRAFT NTT Communications + Masaya Nakayama +Expires: Aug. 2004 The University of Tokyo + Feb. 2004 + + + + + TKEY Secret Key Renewal Mode + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + This document defines a new mode in TKEY and proposes an atomic + method for changing secret keys used for TSIG periodically. + Originally, TKEY provides methods of setting up shared secrets other + than manual exchange, but it cannot control timing of key renewal + very well though it can add or delete shared keys separately. This + proposal is a systematical key renewal procedure intended for + preventing signing DNS messages with old and non-safe keys + permanently. + + + + + + + + +Kamite, et. al. [Page 1] + +INTERNET-DRAFT Feb. 2004 + + + Table of Contents + + +1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4 + 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4 +2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5 + 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5 + 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6 + 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 7 + 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . . . 7 + 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . . 7 + 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . . . 8 + 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . . . 8 + 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 10 + 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 + 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 + 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11 + 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12 + 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13 + 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14 +3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 15 +4 Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . . 15 + 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . . . 15 + 4.2 Authentication Methods Considerations . . . . . . . . . . . . 15 +5 Special Considerations for Two Servers' Case . . . . . . . . . . 16 + 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16 +6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17 +7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17 +8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20 +9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20 +10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 21 +11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 +Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22 + + + + + + + + + + + + + + + +Kamite, et. al. [Page 2] + +INTERNET-DRAFT Feb. 2004 + + +1. Introduction + + TSIG [RFC2845] provides DNS message integrity and the + request/transaction authentication by means of message authentication + codes (MAC). TSIG is a practical solution in view of calculation + speed and availability. However, TSIG does not have exchanging + mechanism of shared secret keys between server and resolver, and + administrators might have to exchange secret keys manually. TKEY + [RFC2930] is introduced to solve such problem and it can exchange + secrets for TSIG via networks. + + In various modes of TKEY, a server and a resolver can add or delete a + secret key be means of TKEY message exchange. However, the existing + TKEY does not care fully about the management of keys which became + too old, or dangerous after long time usage. + + It is ideal that the number of secret which a pair of hosts share + should be limited only one, because having too many keys for the same + purpose might not only be a burden to resolvers for managing and + distinguishing according to servers to query, but also does not seem + to be safe in terms of storage and protection against attackers. + Moreover, perhaps holding old keys long time might give attackers + chances to compromise by scrupulous calculation. + + Therefore, when a new shared secret is established by TKEY, the + previous old secret should be revoked immediately. To accomplish + this, DNS servers must support a protocol for key renewal. This + document specifies procedure to refresh secret keys between two hosts + which is defined within the framework of TKEY, and it is called "TKEY + Secret Key Renewal Mode". + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + +1.1. Defined Words + + * Inception Time: Beginning of the shared secret key lifetime. This + value is determined when the key is generated. + + * Expiry Limit: Time limit of the key's validity. This value is + determined when a new key is generated. After Expiry Limit, server + and client (resolver) must not authenticate TSIG signed with the key. + Therefore, Renewal to the next key should be carried out before + Expiry Limit. + + * Partial Revocation Time: Time when server judges the key is too old + + + +Kamite, et. al. [Page 3] + +INTERNET-DRAFT Feb. 2004 + + + and must be updated. It must be between Inception Time and Expiry + Limit. This value is determined by server freely following its + security policy. e.g., If the time from Inception to Partial + Revocation is short, renewal will be carried out more often, which + might be safer. + + * Revocation Time: Time when the key becomes invalid and can be + removed. This value is not determined in advance because it is the + actual time when revocation is completed. + + * Adoption Time: Time when the new key is adopted as the next key + formally. After Adoption, the key is valid and server and client can + generate or verify TSIG making use of it. Adoption Time also means + the time when it becomes possible to remove the previous key, so + Revocation and Adoption are usually done at the same time. + + + Partial + Inception Revocation Revocation Expiry Limit + | | | | + |----------------|- - - - - - >>|- (revoked) -| + | | | | + previous key | | | + |- - - -|-------------------->> time + | | new key + Inception Adoption + + +1.2. New Format and Assigned Numbers + + TSIG + ERROR = (PartialRevoke), TBD + + TKEY + Mode = (server assignment for key renewal), TBD + Mode = (Diffie-Hellman exchange for key renewal), TBD + Mode = (resolver assignment for key renewal), TBD + Mode = (key adoption), TBD + + +1.3. Overview of Secret Key Renewal Mode + + When a server receives a query from a client signed with a TSIG key, + It always checks if the present time is within the range of usage + duration it considers safe. If it is judged that the key is too old, + i.e., after Partial Revocation Time, the server comes to be in + Partial Revocation state about the key, and this key is called + partially revoked. + + + +Kamite, et. al. [Page 4] + +INTERNET-DRAFT Feb. 2004 + + + In this state, if a client sends a normal query (e.g., question about + A RR) other than TKEY Renewal request with TSIG signed with the old + key, the server returns an error message to notify that the time to + renew has come. This is called "PartialRevoke" error message. It is + server's choice whether it returns PartialRevoke or not. If and only + if the server is ready for changing its own key, it decides to return + PartialRevoke. + + The client which got this error is able to notice that it is + necessary to refresh the secret. To make a new shared secret, it + sends a TKEY Renewal request, in which several keying methods are + available. It can make use of TSIG authentication signed with the + partially revoked key mentioned above. + + After new secret establishment, the client sends a TKEY Adoption + request for renewal confirmation. This can also be authenticated with + the partially revoked key. If this is admitted by the server, the new + key is formally adopted, and at the same time the corresponding old + secret is invalidated. Then the client can send the first query again + signed with the new key. + + Key renewal procedure is executed based on two-phase commit + mechanism. The first phase is the TKEY Renewal request and its + response, which means preparatory confirmation for key update. The + second phase is Adoption request and its response. If the server gets + request and client receives the response successfully, they can + finish renewal process. If any error happens and renewal process + fails during these phases, client should roll back to the beginning + of the first phase, and send TKEY Renewal request again. This + rollback can be done until the Expiry Limit of the key. + + +2. Shared Secret Key Renewal + + Suppose a server and a client agree to change their TSIG keys + periodically. Key renewal procedure is defined between two hosts. + +2.1. Key Usage Time Check + + Whenever a server receives a query with TSIG and can find a key that + is used for signing it, the server checks its Inception Time, Partial + Revocation Time and Expiry Limit (this information is usually + memorized by the server). + + When the present time is before Inception Time, the server MUST NOT + verify TSIG with the key, and server acts the same way as when the + key used by the client is not recognized. It follows [RFC2845] 4.5.1. + + + + +Kamite, et. al. [Page 5] + +INTERNET-DRAFT Feb. 2004 + + + When the present time is equal to Inception Time, or between + Inception Time and Partial Revocation Time, the behavior of the + server is the same as when a valid key is found. It follows [RFC2845] + 4.5.2 and 4.5.3. + + When the present time is the same as the Partial Revocation Time, or + between the Partial Revocation Time and Expiry Limit, the server + comes to be in Partial Revocation state about the TSIG key and + behaves according to the next section. + + When the present time is the same as the Expiry Time or after it, the + server MUST NOT verify TSIG with the key, and returns error messages + in the same way as when the key used by the client is not recognized. + It follows [RFC2845] 4.5.1. + + +2.2. Partial Revocation + + In Partial Revocation state, we say the server has partially revoked + the key and the key has become a "partially revoked key". + + If server has received a query signed with the partially revoked key + for TKEY Renewal request (See section 2.3.) or Key Adoption request + (See section 2.4.), then server does proper process following each + specification. If it is for TKEY key deletion request ([RFC2930] + 4.2), server MAY process usual deletion operation defined therein. + + If server receives other types of query signed with the partially + revoked key, and both the corresponding MAC and signed TIME are + verified, then server begins returning answer whose TSIG error code + is "PartialRevoke" (See section 9.). Server MUST randomly but with + increasing frequency return PartialRevoke when in the Partial + Revocation state. + + Server can decide when it actually sends PartialRevoke, checking if + it is appropriate time for renewal. Server MUST NOT return + PartialRevoke if this is apart long lived TSIG transaction (such as + AXFR) that started before the Partial Revocation Time. + + If the client receives PartialRevoke and understands it, then it MUST + retry the query with the old key unless a new key has been adopted. + Client SHOULD start the process to renew the TSIG key. For key + renewal procedure, see details in Section 2.3 and 2.4. + + PartialRevoke period (i.e., time while server returns PartialRevoke + randomely) SHOULD be small, say 2-5% of key lifetime. This is + server's choice. + + + + +Kamite, et. al. [Page 6] + +INTERNET-DRAFT Feb. 2004 + + + Server MUST keep track of clients ignoring PartialRevoke, thus + indicating ignorance of this TKEY mode. + + PartialRevoke error messages have the role to inform clients of the + keys' partial revocation and urge them to send TKEY Renewal requests. + These error responses MUST be signed with those partial revoked keys + if the queries are signed with them. They are sent only when the + signing keys are found to be partially revoked. If the MAC of TSIG + cannot be verified with the partially revoked keys, servers MUST NOT + return PartialRevoke error with MAC, but MUST return another error + such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other + words, a server informs its key's partial revocation only when the + MAC in the received query is valid. + + +2.3. Key Renewal Message Exchange + +2.3.1. Query for Key Renewal + + If a client has received a PartialRevoke error and authenticated the + response based on TSIG MAC, it sends a TKEY query for Key Renewal (in + this document, we call it Renewal request, too.) to the server. The + request MUST be signed with TSIG or SIG(0) [RFC2931] for + authentication. If TSIG is selected, the client can sign it with the + partial revoked key. + + Key Renewal can use one of several keying methods which is indicated + in "Mode" field of TKEY RR, and its message structure is dependent on + that method. + + +2.3.2. Response for Key Renewal + + The server which has received Key Renewal request first tries to + verify TSIG or SIG(0) accompanying it. If the TSIG is signed and + verified with the partially revoked key, the request MUST be + authenticated. + + After authentication, server must check existing old key's validity. + If the partially revoked key indicated in the request TKEY's OldName + and OldAlgorithm field (See section 2.3.4.) does not exist at the + server, "BADKEY" [RFC2845] is given in Error field for response. If + any other error happens, server returns appropriate error messages + following the specification described in section 2.5. If there are no + errors, server returns a Key Renewal answer. This answer MUST be + signed with TSIG or SIG(0) for authentication. + + When this answer is successfully returned and no error is detected by + + + +Kamite, et. al. [Page 7] + +INTERNET-DRAFT Feb. 2004 + + + client, a new shared secret can be established. The details of + concrete keying procedure are given in the section 2.5. + + Note: + Sometimes Adoption message and new Renewal request will cross on + the wire. In this case the newly generated key Adoption message is + resent. + + +2.3.3. Attributes of Generated Key + + As a result of this message exchange, client comes to know the newly + generated key's attributes such as key's name, Inception Time and + Expiry Limit. They are decided by the server and told to the client; + in particular, however, once the server has decided Expiry Limit and + returned a response, it should obey the decision as far as it can. In + other words, they SHOULD NOT change time values for checking Expiry + Limit in the future without any special reason, such as security + issue like "Emergency Compulsory Revocation" described in section 8. + + On the other hand, Partial Revocation Time of this generated key is + not decided based on the request, and not informed to the client. The + server can determine any value as long as it is between Inception + Time and Expiry Limit. However, the period from Inception to Partial + Revocation SHOULD be fixed as the server side's configuration or be + set the same as the corresponding old key's one. + + Note: + Even if client sends Key Renewal request though the key described + in OldName has not been partially revoked yet, server does renewal + processes. At the moment when the server accepts such requests + with valid authentication, it MUST forcibly consider the key is + already partially revoked, that is, the key's Partial Revocation + Time must be changed into the present time (i.e., the time when + the server receives the request). + + +2.3.4. TKEY RR structure + + TKEY RR for Key Renewal message has the structure given below. In + principle, format and definition for each field follows [RFC2930]. + Note that each keying scheme sometimes needs different interpretation + of RDATA field; for detail, see section 2.5. + + Field Type Comment + ------- ------ ------- + NAME domain used for a new key, see below + TYPE u_int16_t (defined in [RFC2930]) + + + +Kamite, et. al. [Page 8] + +INTERNET-DRAFT Feb. 2004 + + + CLASS u_int16_t (defined in [RFC2930]) + TTL u_int32_t (defined in [RFC2930]) + RDLEN u_int16_t (defined in [RFC2930]) + RDATA: + Algorithm: domain algorithm for a new key + Inception: u_int32_t about the keying material + Expiration: u_int32_t about the keying material + Mode: u_int16_t scheme for key agreement + see section 9. + Error: u_int16_t see description below + Key Size: u_int16_t see description below + Key Data: octet-stream + Other Size: u_int16_t (defined in [RFC2930]) + size of other data + Other Data: newly defined: see description below + + + For "NAME" field, both non-root and root name are allowed. It may + be used for a new key's name in the same manner as [RFC2930] 2.1. + + "Algorithm" specifies which algorithm is used for agreed keying + material, which is used for identification of the next key. + + "Inception" and "Expiration" are used for the valid period of + keying material. The meanings differ somewhat according to whether + the message is request or answer, and its keying scheme. + + "Key Data" has different meanings according to keying schemes. + + "Mode" field stores the value in accordance with the keying method, + and see section 2.5. Servers and clients supporting TKEY Renewal + method MUST implement "Diffie-Hellman exchange for key renewal" + scheme. All other modes are OPTIONAL. + + "Error" is an extended RCODE which includes "PartialRevoke" value + too. See section 9. + + "Other Data" field has the structure given below. They describe + attributes of the key to be renewed. + + in Other Data filed: + + Field Type Comment + ------- ------ ------- + OldNAME domain name of the old key + OldAlgorithm domain algorithm of the old key + + + + + +Kamite, et. al. [Page 9] + +INTERNET-DRAFT Feb. 2004 + + + "OldName" indicates the name of the previous key (usually, + this is partially revoked key's name that client noticed by + PartialRevoke answer from server), and "OldAlogirthm" + indicates its algorithm. + + +2.4. Key Adoption + +2.4.1. Query for Key Adoption + + After receiving a TKEY Renewal answer, the client gets the same + secret as the server. Then, it sends a TKEY Adoption request. The + request's question section's QNAME field is the same as the NAME + filed of TKEY written below. In additional section, there is one TKEY + RR that has the structure and values described below. + + "NAME" field is the new key's name to be adopted which was already + generated by Renewal message exchange. "Algorithm" is its + algorithm. "Inception" means the key's Inception Time, and + "Expiration" means Expiry Limit. + + "Mode" field is the value of "key adoption". See section 9. + + "Other Data" field in Adoption has the same structure as that of + Renewal request message. "OldName" means the previous old key, and + "OldAlogirthm" means its algorithm. + + Key Adoption request MUST be signed with TSIG or SIG(0) for + authentication. The client can sign TSIG with the previous key. Note + that until Adoption is finished, the new key is treated as invalid, + thus it cannot be used for authentication immediately. + + +2.4.2. Response for Key Adoption + + The server which has received Adoption request, it verifies TSIG or + SIG(0) accompanying it. If the TSIG is signed with the partially + revoked key and can be verified, the message MUST be authenticated. + + If the next new key indicated by the request TKEY's "NAME" is not + present at the server, BADNAME [RFC2845] is given in Error field and + the error message is returned. + + If the next key exists but it has not been adopted formally yet, the + server confirms the previous key's existence indicated by the + "OldName" and "OldAlgorithm" field. If it succeeds, the server + executes Adoption of the next key and Revocation of the previous key. + Response message duplicates the request's TKEY RR with NOERROR, + + + +Kamite, et. al. [Page 10] + +INTERNET-DRAFT Feb. 2004 + + + including "OldName" and "OldAlgorithm" that indicate the revoked key. + + If the next key exists but it is already adopted, the server returns + a response message regardless of the substance of the request TKEY's + "OldName". In this response, Response TKEY RR has the same data as + the request's one except as to its "Other Data" that is changed into + null (i.e., "Other Size" is zero), which is intended for telling the + client that the previous key name was ignored, and the new key is + already available. + + Client sometimes has to retry Adoption request. Suppose the client + sent request signed with the partially revoked key, but its response + did not return successfully (e.g., due to the drop of UDP packet). + Client will probably retry Adoption request; however, the request + will be refused in the form of TSIG "BADKEY" error because the + previous key was already revoked. In this case, client will + retransmit Adoption request signed with the next key, and expect a + response which has null "Other Data" for confirming the completion of + renewal. + + +2.5. Keying Schemes + + In Renewal message exchanges, there are no limitations as to which + keying method is actually used. The specification of keying + algorithms is independent of the general procedure of Renewal that is + described in section 2.3. + + Now this document specifies three algorithms in this section, but + other future documents can make extensions defining other methods. + + +2.5.1. DH Exchange for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.1. This + specification only describes the difference from it and special + notice; assume that all other points, such as keying material + computation, are the exactly same as the specification of [RFC2930] + 4.1. + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. KEY RR is + the client's Diffie-Hellman public key [RFC2539]. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + + + +Kamite, et. al. [Page 11] + +INTERNET-DRAFT Feb. 2004 + + + TKEY "Mode" field stores the value of "DH exchange for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is used as a random, following [RFC2930] 4.1. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. If + any incompatible DH key is found in the request, "BADKEY" + [RFC2845] is given in Error field for response. "FORMERR" is given + if the query included no DH KEY. + + If there are no errors, the server processes a response according + to Diffie-Hellman algorithm and returns the answer. In this + answer, there is one TKEY RR in answer section and KEY RR(s) in + additional section. + + As long as no error has occurred, all values of TKEY are equal to + that of the request message except TKEY NAME, TKEY RDLEN, RDATA's + Inception, Expiration, Key Size and Key Data. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + TKEY "Key Data" is used as an additional nonce, following + [RFC2930] 4.1. + + The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in + the additional section and a server Diffie-Hellman KEY RR will + also be present in the answer section, following [RFC2930] 4.1. + + +2.5.2. Server Assigned Keying for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.4. This + specification only describes the difference from it and special + notice; assume that all other points, such as secret encrypting + method, are the exactly same as the specification of [RFC2930] 4.4. + + + +Kamite, et. al. [Page 12] + +INTERNET-DRAFT Feb. 2004 + + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. KEY RR is + used in encrypting the response. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "server assignment for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is provided following the specification of + [RFC2930] 4.4. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. + "FORMERR" is given if the query specified no encryption key. + + If there are no errors, the server response contains one TKEY RR + in the answer section, and echoes the KEY RR provided in the query + in the additional information section. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + TKEY "Key Data" is the assigned keying data encrypted under the + public key in the resolver provided KEY RR, which is the same as + [RFC2930] 4.4. + + +2.5.3. Resolver Assigned Keying for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.5. This + specification only describes the difference from it and special + notice; assume that all other points, such as secret encrypting + method, are the exactly same as the specification of [RFC2930] 4.5. + + + + +Kamite, et. al. [Page 13] + +INTERNET-DRAFT Feb. 2004 + + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. TKEY RR + has the encrypted keying material and KEY RR is the server public + key used to encrypt the data. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "resolver assignment for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is the encrypted keying material. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. + "FORMERR" is given if the server does not have the corresponding + private key for the KEY RR that was shown sin the request. + + If there are no errors, the server returns a response. The + response contains a TKEY RR in the answer section to tell the + shared key's name and its usage time values. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + +2.6. Considerations about Non-compliant Hosts + + Key Renewal requests and responses must be exchanged between hosts + which can understand them and do proper processes. PartialRevoke + error messages will be only ignored if they should be returned to + non-compliant hosts. + + Note that server does not inform actively the necessity of renewal to + clients, but inform it as responses invoked by client's query. + Server needs not care whether the PartialRevoke errors has reached + + + +Kamite, et. al. [Page 14] + +INTERNET-DRAFT Feb. 2004 + + + client or not. If client has not received yet because of any reasons + such as packet drops, it will resend the queries, and finally will be + able to get PartialRevoke information. + + +3. Secret Storage + + Every server keeps all secrets and attached information, e.g., + Inception Time, Expiry Limit, etc. safely to be able to recover from + unexpected stop. To accomplish this, formally adopted keys SHOULD be + memorized not only on memory, but also be stored in the form of some + files. It will become more secure if they are stored in ecrypted + form. + + +4. Compulsory Key Revocation + +4.1. Compulsory Key Revocation by Server + + There is a rare but possible case that although servers have already + partially revoked keys, clients do not try to send any Renewal + requests. If this state continues, in the future it will become the + time of Expiry Limit. After Expiry Limit, the keys will be expired + and completely removed, so this is called Compulsory Key Revocation + by server. + + If Expiry Limit is too distant from the Partial Revocation Time, then + even though very long time passes, clients will be able to refresh + secrets only if they add TSIG signed with those old partially revoked + keys into requests, which is not safe. + + On the other hand, if Expiry Limit is too close to Partial Revocation + Time, perhaps clients might not be able to notice their keys' Partial + Revocation by getting "PartialRevoke" errors. + + Therefore, servers should set proper Expiry Limit to their keys, + considering both their keys' safety, and enough time for clients to + send requests and process renewal. + + +4.2. Authentication Methods Considerations + + It might be ideal to provide both SIG(0) and TSIG as authentication + methods. For example: + + A client and a server start SIG(0) authentication at first, to + establish TSIG shared keys by means of "Query for Diffie-Hellman + Exchanged Keying" as described in [RFC2930] 4.1. Once they get + + + +Kamite, et. al. [Page 15] + +INTERNET-DRAFT Feb. 2004 + + + shared secret, they keep using TSIG for queries and responses. + After a while the server returns a "ParitalRevoke" error and they + begin a key renewal process. Both TSIG signed with partially + revoked keys and SIG(0) are okay for authentication, but TSIG would + be easier to use considering calculation efficiency. + + Suppose now client is halted for long time with some reason. + Because server does not execute any renewal process, it will + finally do Compulsory Revocation. Even if client restarts and sends + a key Renewal request, it will fail because old key is already + deleted at server. + + At this moment, however, if client also uses SIG(0) as another + authentication method, it can make a new shared key again and + recover successfully by sending "Query for Diffie-Hellman Exchanged + Keying" with SIG(0). + + +5. Special Considerations for Two servers' Case + + This section refers to the case where both hosts are DNS servers + which can act as full resolvers as well and using one shared key + only. If one server (called Server A) wants to refresh a shared key + (called "Key A-B"), it will await a TKEY Renewal request from the + other server (called Server B). However, perhaps Server A wants to + refresh the key right now. + + In this case, Server A is allowed to send a Renewal request to Server + B, if Server A knows the Key A-B is too old and wants to renew it + immediately. + + Note that the initiative in key renewal belongs to Server A because + it can notice the Partial Revocation Time and decide key renewal. If + Server B has information about Partial Revocation Time as well, it + can also decide for itself to send Renewal request to Server A. + However, it is not essential for both two servers have information + about key renewal timing. + +5.1. To Cope with Collisions of Renewal Requests + + At least one of two hosts which use Key Renewal must know their key + renewal information such as Partial Revocation Time. It is okay that + both hosts have it. + + Provided that both two servers know key renewal timing information, + there is possibility for them to begin partial revocation and sending + Renewal requests to each other at the same time. Such collisions will + not happen so often because Renewal requests are usually invoked when + + + +Kamite, et. al. [Page 16] + +INTERNET-DRAFT Feb. 2004 + + + hosts want to send queries, but it is possible. + + When one of two servers tries to send Renewal requests, it MUST + protect old secrets that it has partially revoked and prevent it from + being refreshed by any requests from the other server (i.e., it must + lock the old secret during the process of renewal). While the server + is sending Renewal requests and waiting responses, it ignores the + other server's Renewal requests. + + Therefore, servers might fail to change secrets by means of their own + requests to others. After failure they will try to resend, but they + should wait for random delays by the next retries. If they get any + Renewal requests from others while they are waiting, their shared + keys may be refreshed, then they do not need to send any Renewal + requests now for themselves. + + +6. Key Name Considerations + + Since both servers and clients have only to distinguish new secrets + and old ones, keys' names do not need to be specified strictly. + However, it is recommended that some serial number or key generation + time be added to the name and that the names of keys between the same + pair of hosts should have some common labels among their keys. For + example, suppose A.example.com. and B.example.com. share the key + ".A.example.com.B.example.com." such as + "10010.A.example.com.B.example.com.". After key renewal, they change + their secret and name into "10011.A.example.com.B.example.com." + + Servers and clients must be able to use keys properly for each query. + Because TSIG secret keys themselves do not have any particular IDs to + be distinguished and would be identified by their names and + algorithm, it must be understood correctly what keys are refreshed. + + +7. Example Usage of Secret Key Renewal Mode + + This is an example of Renewal mode usage where a Server, + server.example.com, and a Client, client.exmple.com have an initial + shared secret key named "00.client.example.com.server.example.com". + + (1) The time values for key + "00.client.example.com.server.example.com" was set as follows: + Inception Time is at 1:00, Expiry Limit is at 21:00. + + (2) At Server, renewal time has been set: Partial Revocation Time + is at 20:00. + + + + +Kamite, et. al. [Page 17] + +INTERNET-DRAFT Feb. 2004 + + + (3) Suppose the present time is 19:55. If Client sends a query + signed with key "00.client.example.com.server.example.com" to ask + the IP address of "www.example.com", finally it will get a proper + answer from Server with valid TSIG (NOERROR). + + (4) At 20:05. Client sends a query to ask the IP address of + "www2.example.com". It is signed with key + "00.client.example.com.server.example.com". Server returns an + answer for the IP address. However, server has begun retuning + PartialRevoke Error randomely. This answer includes valid TSIG MAC + signed with "00.client.example.com.server.example.com", and its + Error Code indicates PartialRevoke. Client understands that the + current key is partially revoked. + + (5) At 20:06. Client sends a Renewal request to Server. This + request is signed with key + "00.client.example.com.server.example.com". It includes data such + as: + + Question Section: + QNAME = 01.client.example.com. (Client can set this freely) + TYPE = TKEY + + Additional Section: + 01.client.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (DH exchange for key renewal) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + Additional Section also contains a KEY RR for DH and a TSIG RR. + + (6) As soon as Server receives this request, it verifies TSIG. It + is signed with the partially revoked key + "00.client.example.com.server.example.com". and Server accepts the + request. It creates a new key by Diffie-Hellman calculation and + returns an answer which includes data such as: + + Answer Section: + 01.client.example.com.server.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (DH exchange for key renewal) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + + +Kamite, et. al. [Page 18] + +INTERNET-DRAFT Feb. 2004 + + + Answer Section also contains KEY RRs for DH. + + Additional Section also contains a TSIG RR. + This response is signed with key + "00.client.example.com.server.example.com" without error. + + At the same time, Server decides to set the Partial Revocation Time + of this new key "01.client.example.com.server.example.com." as next + day's 15:00. + + (7) Client gets the response and checks TSIG MAC, and calculates + Diffie-Hellman. It will get a new key, and it has been named + "01.client.example.com.server.example.com" by Server. + + (8) At 20:07. Client sends an Adoption request to Server. This + request is signed with the previous key + "00.client.example.com.server.example.com". It includes: + + Question Section: + QNAME = 01.client.example.com.server.example.com. + TYPE = TKEY + + Additional Section: + 01.client.example.com.server.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (key adoption) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + Additional Section also contains a TSIG RR. + + (9) Server verifies the query's TSIG. It is signed with the + previous key and authenticated. It returns a response whose TKEY RR + is the same as the request's one. The response is signed with key + "00.client.example.com.server.example.com.". As soon as the + response is sent, Server revokes and removes the previous key. At + the same time, key "01.client.example.com.server.example.com." is + validated. + + (10) Client acknowledges the success of Adoption by receiving the + response. Then, it retries to send an original question about + "www2.example.com". It is signed with the adopted key + "01.client.example.com.server.example.com", so Server authenticates + it and returns an answer. + + + + + +Kamite, et. al. [Page 19] + +INTERNET-DRAFT Feb. 2004 + + + (11) This key is used until next day's 15:00. After that, it will + be partially revoked again. + + +8. Security Considerations + + This document considers about how to refresh shared secret. Secret + changed by this method is used at servers in support of TSIG + [RFC2845]. + + [RFC2104] says that current attacks to HMAC do not indicate a + specific recommended frequency for key changes but periodic key + refreshment is a fundamental security practice that helps against + potential weaknesses of the function and keys, and limits the damage + of an exposed key. TKEY Secret Key Renewal provides the method of + periodical key refreshment. + + In TKEY Secret Key Renewal, clients need to send two requests + (Renewal and Adoption) and spend time to finish their key renewal + processes. Thus the usage period of secrets should be considered + carefully based on both TKEY processing performance and security. + + This document specifies the procedure of periodical key renewal, but + actually there is possibility for servers to have no choice other + than revoking their secret keys immediately especially when the keys + are found to be compromised by attackers. This is called "Emergency + Compulsory Revocation". For example, suppose the original Expiry + Limit was set at 21:00, Partial Revocation Time at 20:00 and + Inception Time at 1:00. if at 11:00 the key is found to be + compromised, the server sets Expiry Limit forcibly to be 11:00 or + before it. + + Consequently, once Compulsory Revocation (See section 4.) is carried + out, normal renewal process described in this document cannot be done + any more as far as the key is concerned. However, after such + accidents happened, the two hosts are able to establish secret keys + and begin renewal procedure only if they have other (non-compromised) + shared TSIG keys or safe SIG(0) keys for the authentication of + initial secret establishment such as Diffie-Hellman Exchanged Keying. + + +9. IANA Considerations + + IANA needs to allocate a value for "DH exchange for key renewal", + "server assignment for key renewal", "resolver assignment for key + renewal" and "key adoption" in the mode filed of TKEY. It also needs + to allocate a value for "PartialRevoke" from the extended RCODE + space. + + + +Kamite, et. al. [Page 20] + +INTERNET-DRAFT Feb. 2004 + + +10. Acknowledgement + + The authors would like to thank Olafur Gudmundsson, whose helpful + input and comments contributed greatly to this document. + + +11. References + +[RFC2104] + H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message + Authentication", RFC2104, February 1997. + +[RFC2119] + Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + +[RFC2539] + D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name + System (DNS)", RFC 2539, March 1999. + +[RFC2845] + Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, + May 2000. + +[RFC2930] + D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', + RFC 2930, September 2000. + +[RFC2931] + D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s + )", RFC 2931, September 2000. + + + + + + + + + + + + + + + + + + + +Kamite, et. al. [Page 21] + +INTERNET-DRAFT Feb. 2004 + + +Authors' Addresses + + Yuji Kamite + NTT Communications Corporation + Tokyo Opera City Tower + 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo + 163-1421, Japan + EMail: y.kamite@ntt.com + + + Masaya Nakayama + Information Technology Center, The University of Tokyo + 2-11-16 Yayoi, Bunkyo-ku, Tokyo + 113-8658, Japan + EMail: nakayama@nc.u-tokyo.ac.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kamite, et. al. [Page 22] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt new file mode 100644 index 000000000000..1133b0c87d49 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt @@ -0,0 +1,466 @@ + + +INTERNET-DRAFT Donald E. Eastlake 3rd +UPDATES RFC 2845 Motorola Laboratories +Expires: February 2005 August 2004 + + + HMAC SHA TSIG Algorithm Identifiers + ---- --- ---- --------- ----------- + + + +Status of This Document + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group mailing list . + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + Use of the TSIG DNS resource record requires specification of a + cryptographic message authentication code. Currently identifiers + have been specified only for the HMAC-MD5 and GSS TSIG algorithms. + This document standardizes identifiers for additional HMAC SHA TSIG + algorithms and standardizes how to specify the truncation of HMAC + values. + + +Copyright Notice + + Copyright (C) The Internet Society 2004. All Rights Reserved. + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + + 2. Algorithms and Identifiers..............................4 + + 3. Specifying Truncation...................................5 + + 4. IANA Considerations.....................................6 + 5. Security Considerations.................................6 + 6. Copyright and Disclaimer................................6 + + 7. Normative References....................................7 + 8. Informative References..................................7 + + Authors Address............................................8 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +1. Introduction + + [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to + authenticate DNS queries and responses. This RR contains a domain + name syntax data item which names the authentication algorithm used. + [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for + authentication codes using the HMAC [RFC 2104] algorithm with the MD5 + [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an + identifier for TSIG authentication where the cryptographic operations + are delegated to GSS [RFC 3645]. + + In section 2, this document specifies additional names for TSIG + authentication algorithms based on US NIST SHA algorithms and HMAC. + + In section 3, this document specifies the meaning of inequality + between the normal output size of the specified hash function and the + length of MAC (message authentication code) data given in the TSIG + RR. In particular, it specifies that a shorter length field value + specifies truncation and a longer length field is an error. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +2. Algorithms and Identifiers + + TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS + queries and responses. They are intended to be efficient symmetric + authentication codes based on a shared secret. (Asymmetric signatures + can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) + can be used for transaction signatures.) Used with a strong hash + function, HMAC [RFC 2104] provides a way to calculate such symmetric + authentication codes. The only specified HMAC based TSIG algorithm + identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. + + The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as + compared with the 128 bits for MD5, and additional hash algorithms in + the SHA family [FIPS 180-2, RFC sha224] with 224, 256, 384, and 512 + bits, may be preferred in some case. Use of TSIG between a DNS + resolver and server is by mutual agreement. That agreement can + include the support of additional algorithms. + + For completeness in relation to HMAC based algorithms, the current + HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below. + Implementations which support TSIG MUST implement HMAC MD5, SHOULD + implement HMAC SHA-1, and MAY implement gss-tsig and the other + algorithms listed below. + + Mandatory HMAC-MD5.SIG-ALG.REG.INT + Recommended hmac-sha1 + Optional hmac-sha224 + Optional hmac-sha256 + Optional hamc-sha384 + Optional hmac-sha512 + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +3. Specifying Truncation + + In some cases, it is reasonable to truncate the output of HMAC and + use the truncated value for authentication. HMAC SHA-1 truncated to + 96 bits is an optional available in several IETF protocols including + IPSEC and TLS. + + The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the + size of the MAC field in octets. But [RFC 2845] does not specify what + to do if this MAC size differs from the length of the output of HMAC + for a particular hash function. + + The specification for TSIG handling is changed as follows: + + 1. If The "MAC size" field is larger than the HMAC output length or + is zero: This case MUST NOT be generated and if received MUST + cause the packet to be dropped and RCODE 1 (FORMERR) to be + returned. + + 2. If the "MAC size" field equals the HMAC output length: Operation + is as described in [RFC 2845]. + + 3. If the "MAC size" field is less than the HMAC output length but is + not zero: This is sent when the signer has truncated the HMAC + output as described in RFC 2104, taking initial octets and + discarding trailing octets. TSIG truncation can only be to an + integral number of octets. On receipt of a packet with truncation + thus indicated, the locally calculated MAC is similarly truncated + and only the truncated values compared for authentication. + + TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12 + octets) and MAY implement any or all other truncations valid under + case 3 above. + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +4. IANA Considerations + + This document, on approval for publication as a standards track RFC, + registers the new TSIG algorithm identifiers listed in Section 2 with + IANA. + + + +5. Security Considerations + + For all of the message authentication code algorithms listed herein, + those producing longer values are believed to be stronger; however, + while there are some arguments that mild truncation can strengthen a + MAC by reducing the information available to an attacker, excessive + truncation clearly weakens authentication by reducing the number of + bits an attacker has to try to force. See [RFC 2104] which recommends + that ah HMAC never be truncated to less than half its length nor to + less than 80 bits (10 octets). + + See also the Security Considerations section of [RFC 2845]. + + + +6. Copyright and Disclaimer + + Copyright (C) The Internet Society 2004. This document is subject to + the rights, licenses and restrictions contained in BCP 78 and except + as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +7. Normative References + + [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal + Information Processing Standard, Draft, 1 August 2002. + + [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC + 1321, April 1992. + + [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February 1997. + + [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + [RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R. + Housley, December 2003, work in progress, draft-ietf-pkix- + sha224-*.txt. + + + +8. Informative References. + + [FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information + Processing Standard, 17 April 1995. + + [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction + Signatures ( SIG(0)s )", RFC 2931, September 2000. + + [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm + 1 (SHA1)", RFC 3174, September 2001. + + [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, + J., and R. Hall, "Generic Security Service Algorithm for Secret Key + Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October + 2003. + + + + + + + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +Authors Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 (w) + +1-508-634-2066 (h) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in February 2005. + + Its file name is draft-ietf-dnsext-tsig-sha-00.txt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt new file mode 100644 index 000000000000..d65fa7104251 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt @@ -0,0 +1,1010 @@ + + + + + + +dnsext Working Group B. Halley +Internet Draft Nominum +Expiration Date: March 2004 + E. Lewis + ARIN + + September 2003 + + + Clarifying the Role of Wild Card Domains + in the Domain Name System + + + draft-ietf-dnsext-wcard-clarify-02.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. + +Abstract + + The definition of wild cards is recast from the original in RFC 1034, + in words that are more specific and in line with RFC 2119. This + document is meant to supplement the definition in RFC 1034 and to + alter neither the spirit nor intent of that definition. + + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 1] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + +Table of Contents + + Abstract ................................................ 1 + 1 Introduction ............................................ 2 + 1.1 Document Limits ......................................... 3 + 1.2 Existence ............................................... 4 + 1.3 An Example .............................................. 4 + 1.4 Empty Non-terminals ..................................... 5 + 1.5 Terminology ............................................. 6 + 2 Defining the Wild Card Domain Name ...................... 7 + 3 Defining Existence ...................................... 8 + 4 Impact of a Wild Card In a Query or in RDATA ............ 8 + 5 Impact of a Wild Card Domain On a Response .............. 9 + 6 Considerations with Special Types ....................... 12 + 6.1 SOA RR's at a Wild Card Domain Name ..................... 12 + 6.2 NS RR's at a Wild Card Domain Name ...................... 12 + 6.3 CNAME RR's at a Wild Card Domain Name ................... 13 + 6.4 DNAME RR's at a Wild Card Domain Name ................... 13 + 7 Security Considerations ................................. 14 + 8 References .............................................. 14 + 9 Others Contributing to This Document .................... 14 + 10 Editors ................................................. 15 + Appendix A: Subdomains of Wild Card Domain Names ........ 16 + Full Copyright Statement ................................ 18 + Acknowledgement ......................................... 18 + + + + +1. Introduction + + The first section of this document will give a crisp overview of what + is begin defined, as well as the motivation rewording of an original + document and making a change to bring the specification in line with + implementations. Examples are included to help orient the reader. + + Wild card domain names are defined in Section 4.3.3. of RFC 1034 as + "instructions for synthesizing RRs." [RFC1034]. The meaning of this + is that a specific, special domain name is used to construct + responses in instances in which the query name is not otherwise + represented in a zone. + + A wild card domain name has a specific range of influence on query + names (QNAMEs) within a given class, which is rooted at the domain + name containing the wild card label, and is limited by explicit + entries, zone cuts and empty non-terminal domains (see section 1.3 of + this document). + + + + +Halley & Lewis [Expires March 2004] [Page 2] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + Note that a wild card domain name has no special impact on the search + for a query type (QTYPE). If a domain name is found that matches the + QNAME (exact or a wild card) but the QTYPE is not found at that + point, the proper response is that there is no data available. The + search does not continue on to seek other wild cards that might match + the QTYPE. To illustrate, a wild card owning an MX RR does not + 'cover' other names in the zone that own an A RR. There are certain + special case RR types that will be singled out for discussion, the + SOA RR, NS RR, CNAME RR, and DNAME RR. + + Why is this document needed? Empirical evidence suggests that the + words in RFC 1034 are not clear enough. There exist a number of + implementations that have strayed (each differently) from that + definition. There also exists a misconception of operators that the + wild card can be used to add a specific RR type to all names, such as + the MX RR example cited above. This document is also needed as input + to efforts to extend DNS, such as the DNS Security Extensions [RFC + 2535]. Lack of a clear base specification has proven to result in + extension documents that have unpredictable consequences. (This is + true in general, not just for DNS.) + + Another reason this clarification is needed is to answer questions + regarding authenticated denial of existence, a service introduced in + the DNS Security Extensions [RFC 2535]. Prior to the work leading up + to this document, it had been feared that a large number of proof + records (NXTs) might be needed in each reply because of the unknown + number of potential wild card domains that were thought to be + applicable. One outcome of this fear is a now discontinued document + solving a problem that is now known not to exist. I.e., this + clarification has the impact of defending against unwarranted + protocol surgery. It is not "yet another" effort to just rewrite the + early specifications for the sake of purity. + + Although the effort to define the DNS Security Extensions has + prompted this document, the clarifications herein relate to basic DNS + only. No DNS Security Extensions considerations are mentioned in the + document. + +1.1. Document Limits + + This document limits itself to reinforcing the concepts in RFC 1034. + In the effort to do this, a few issues have been discussed that + change parts of what is in RFC 1034. The discussions have been held + within the DNS Extensions Working Group. + + + + + + + +Halley & Lewis [Expires March 2004] [Page 3] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + Briefly, the issues raised include: + - The lack of clarity in the definition of domain name existence + - Implications of a wild card domain name owning any of the + following resource record sets: DNAME [RFC 2672], CNAME, NS, and + SOA + - Whether RFC 1034 meant to allow special processing of CNAME RR's + owned by wild card domain names + +1.2. Existence + + The notion that a domain name 'exists' will arise numerous times in + this discussion. RFC 1034 raises the issue of existence in a number + of places, usually in reference to non-existence and often in + reference to processing involving wild card domain names. RFC 1034 + contains algorithms that describe how domain names impact the + preparation of an answer and does define wild cards as a means of + synthesizing answers. Because of this a discussion on wild card + domain names has to start with the issue of existence. + + To help clarify the topic of wild cards, a positive definition of + existence is needed. Complicating matters, though, is the + realization that existence is relative. To an authoritative server, + a domain name exists if the domain name plays a role following the + algorithms of preparing a response. To a resolver, a domain name + exists if there is any data available corresponding to the name. The + difference between the two is the synthesis of records according to a + wild card. + + For the purposes of this document, the point of view of an + authoritative server is adopted. A domain name is said to exist if + it plays a role in the execution of the algorithms in RFC 1034. + +1.3. An Example + + For example, consider this wild card domain name: *.example. Any + query name under example. is a candidate to be matched (answered) by + this wild card, i.e., to have an response returned that is + synthesized from the wild card's RR sets. Although any name is a + candidate, not all queries will match. + + + + + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 4] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + To further illustrate this, consider this zone: + + $ORIGIN example. + @ IN SOA + NS + NS + * TXT "this is a wild card" + MX 10 mailhost.example. + host1 A 10.0.0.1 + _ssh._tcp.host1 SRV + _ssh._tcp.host2 SRV + subdel NS + + + The following queries would be synthesized from the wild card: + + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host3.example. IN MX ..." + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will reflect "no error, but no data" + because there is no A RR set at '*' + + The following queries would not be synthesized from the wild card: + + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN + because host2.example. exists (without data) + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists and is a zone cut + + To the server, the following domains are considered to exist in the + zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, + _ssh._tcp.host2, and subdel. To a resolver, many more domains appear + to exist via the synthesis of the wild card. + +1.4. Empty Non-terminals + + Empty non-terminals are domain names that own no data but have + subdomains. This is defined in section 3.1 of RFC 1034: + +# The domain name space is a tree structure. Each node and leaf on the +# tree corresponds to a resource set (which may be empty). The domain +# system makes no distinctions between the uses of the interior nodes and +# leaves, and this memo uses the term "node" to refer to both. + + + + +Halley & Lewis [Expires March 2004] [Page 5] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + The parenthesized "which may be empty" specifies that empty non- + terminals are explicitly recognized. According to the definition of + existence in this document, empty non-terminals do exist at the + server. + + Carefully reading the above paragraph can lead to an interpretation + that all possible domains exist - up to the suggested limit of 255 + octets for a domain name [RFC 1035]. For example, www.example. may + have an A RR, and as far as is practically concerned, is a leaf of + the domain tree. But the definition can be taken to mean that + sub.www.example. also exists, albeit with no data. By extension, all + possible domains exist, from the root on down. As RFC 1034 also + defines "an authoritative name error indicating that the name does + not exist" in section 4.3.1, this is not the intent of the original + document. + + RFC1034's wording is to be clarified by adding the following + paragraph: + + A node is considered to have an impact on the algorithms of + 4.3.2 if it is a leaf node with any resource sets or an interior + node, with or without a resource set, that has a subdomain that + is a leaf node with a resource set. A QNAME and QCLASS matching + an existing node never results in a response return code of + authoritative name error. + + The terminology in the above paragraph is chosen to remain as close + to that in the original document. The term "with" is a alternate + form for "owning" in this case, hence "a leaf node owning resources + sets, or an interior node, owning or not owning any resource set, + that has a leaf node owning a resource set as a subdomain," is the + proper interpretation of the middle sentence. + + As an aside, an "authoritative name error" has been called NXDOMAIN + in some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic + assigned to such an error by at least one implementation of DNS. As + this mnemonic is specific to implementations, it is avoided in the + remainder of this document. + +1.5. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in the document entitled + "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] + + Requirements are denoted by paragraphs that begin with with the + following convention: 'R'.. + + + +Halley & Lewis [Expires March 2004] [Page 6] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + Quotations of RFC 1034 (as has already been done once above) are + denoted by a '#' in the leftmost column. + +2. Defining the Wild Card Domain Name + + A wild card domain name is defined by having the initial label be: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + + This defines domain names that may play a role in being a wild card, + that is, being a source for synthesized answers. Domain names + conforming to this definition that appear in queries and RDATA + sections do not have any special role. These cases will be described + in more detail in following sections. + + R2.1 A domain name that is to be interpreted as a wild card MUST + begin with a label of '0000 0001 0010 1010' in binary. + + The first octet is the normal label type and length for a 1 octet + long label, the second octet is the ASCII representation [RFC 20] for + the '*' character. In RFC 1034, ASCII encoding is assumed to be the + character encoding. + + In the master file formats used in RFCs, a "*" is a legal + representation for the wild card label. Even if the "*" is escaped, + it is still interpreted as the wild card when it is the only + character in the label. + + R2.2 A server MUST treat a wild card domain name as the basis of + synthesized answers regardless of any "escape" sequences in the + input format. + + RFC 1034 and RFC 1035 ignore the case in which a domain name might be + "the*.example.com." The interpretation is that this domain name in a + zone would only match queries for "the*.example.com" and not have any + other role. + + Note: By virtue of this definition, a wild card domain name may have + a subdomain. The subdomain (or sub-subdomain) itself may also be a + wild card. E.g., *.*.example. is a wild card, so is *.sub.*.example. + More discussion on this is given in Appendix A. + + + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 7] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + +3. Defining Existence + + As described in the Introduction, a precise definition of existence + is needed. + + R3.1 An authoritative server MUST treat a domain name as existing + during the execution of the algorithms in RFC 1034 when the + domain name conforms to the following definition. A domain name + is defined to exist if the domain name owns data and/or has a + subdomain that exists. + + Note that at a zone boundary, the domain name owns data, including + the NS RR set. At the delegating server, the NS RR set is not + authoritative, but that is of no consequence here. The domain name + owns data, therefore, it exists. + + R3.2 An authoritative server MUST treat a domain name that has + neither a resource record set nor an existing subdomain as non- + existent when executing the algorithm in section 4.3.2. of RFC + 1034. + + A note on terminology. A domain transcends zones, i.e., all DNS data + is in the root domain but segmented into zones of control. In this + document, there are references to a "domain name" in the context of + existing "in a zone." In this usage, a domain name is the root of a + domain, not the entire domain. The domain's root point is said to + "exist in a zone" if the zone is authoritative for the name. RR sets + existing in a domain need not be owned by the domain's root domain + name, but are owned by other domain names in the domain. + +4. Impact of a Wild Card In a Query or in RDATA + + When a wild card domain name appears in a question, e.g., the query + name is "*.example.", the response in no way differs from any other + query. In other words, the wild card label in a QNAME has no special + meaning, and query processing will proceed using '*' as a literal + query name. + + R4.1 A wild card domain name acting as a QNAME MUST be treated as any + other QNAME, there MUST be no special processing accorded it. + + If a wild card domain name appears in the RDATA of a CNAME RR or any + other RR that has a domain name in it, the same rule applies. In the + instance of a CNAME RR, the wild card domain name is used in the same + manner of as being the original QNAME. For other RR's, rules vary + regarding what is done with the domain name(s) appearing in them, in + no case does the wild card hold special meaning. + + + + +Halley & Lewis [Expires March 2004] [Page 8] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + R4.2 A wild card domain name appearing in any RR's RDATA MUST be + treated as any other domain name in that situation, there MUST + be no special processing accorded it. + +5. Impact of a Wild Card Domain On a Response + + The description of how wild cards impact response generation is in + RFC 1034, section 4.3.2. That passage contains the algorithm + followed by a server in constructing a response. Within that + algorithm, step 3, part 'c' defines the behavior of the wild card. + The algorithm is directly quoted in lines that begin with a '#' sign. + Commentary is interleaved. + + There is a documentation issue deserving some explanation. The + algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo + code, i.e., it's steps are not intended to be followed in strict + order. The "algorithm" is a suggestion. As such, in step 3, parts + a, b, and c, do not have to be implemented in that order. + + Another issue needing explanation is that RFC 1034 is a full + standard. There is another RFC, RFC 2672, which makes, or proposes + an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME + RR. RFC 2672 is a proposed standard. The dilemma in writing these + clarifications is knowing which document is the one being clarified. + Fortunately, the difference between RFC 1034 and RFC 2672 is not + significant with respect to wild card synthesis, so this document + will continue to state that it is clarifying RFC 1034. If RFC 2672 + progresses along the standards track, it will need to refer to + modifying RFC 1034's algorithm as amended here. + + The context of part 'c' is that the search is progressing label by + label through the QNAME. (Note that the data being searched is the + authoritative data in the server, the cache is searched in step 4.) + Step 3's part 'a' covers the case that the QNAME has been matched in + full, regardless of the presence of a CNAME RR. Step 'b' covers + crossing a cut point, resulting in a referral. All that is left is + to look for the wild card. + + Step 3 of the algorithm also assumes that the search is looking in + the zone closest to the answer, i.e., in the same class as QCLASS and + as close to the authority as possible on this server. If the zone is + not the authority, then a referral is given, possibly one indicating + lameness. + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 9] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if a +# the "*" label exists. + + The above paragraph refers to finding the domain name that exists in + the zone and that most encloses the QNAME. Such a domain name will + mark the boundary of candidate wild card domain names that might be + used to synthesize an answer. (Remember that at this point, if the + most enclosing name is the same as the QNAME, part 'a' would have + recorded an exact match.) The existence of the enclosing name means + that no wild card name higher in the tree is a candidate to answer + the query. + + Once the closest enclosing node is identified, there's the matter of + what exists below it. It may have subdomains, but none will be + closer to the QNAME. One of the subdomains just might be a wild + card. If it exists, this is the only wild card eligible to be used + to synthesize an answer for the query. Even if the closest enclosing + node conforms to the syntax rule in section 2 for being a wild card + domain name, the closest enclosing node is not eligible to be a + source of a synthesized answer. + + The only wild card domain name that is a candidate to synthesize an + answer will be the "*" subdomain of the closest enclosing domain + name. Three possibilities can happen. The "*" subdomain does not + exist, the "*" subdomain does but does not have an RR set of the same + type as the QTYPE, or it exists and has the desired RR set. + + For the sake of brevity, the closest enclosing node can be referred + to as the "closest encloser." The closest encloser is the most + important concept in this clarification. Describing the closest + encloser is a bit tricky, but it is an easy concept. + + To find the closest encloser, you have to first locate the zone that + is the authority for the query name. This eliminates the need to be + concerned that the closest encloser is a cut point. In addition, we + can assume too that the query name does not exist, hence the closest + encloser is not equal to the query name. We can assume away these + two cases because they are handled in steps 2, 3a and 3b of section + 4.3.2.'s algorithm. + + What is left is to identify the existing domain name that would have + been up the tree (closer to the root) from the query name. Knowing + that an exact match is impossible, if there is a "*" label descending + from the unique closest encloser, this is the one and only wild card + from which an answer can be synthesized for the query. + + + + + +Halley & Lewis [Expires March 2004] [Page 10] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + To illustrate, using the example in section 1.2 of this document, the + following chart shows QNAMEs and the closest enclosers. In + Appendix A there is another chart showing unusual cases. + + QNAME Closest Encloser Wild Card Source + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no wild card + _telnet._tcp.host2.example. host2.example. no wild card + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + + Note that host1.subdel.example. is in a subzone, so the search for it + ends in a referral in part 'b', thus does not enter into finding a + closest encloser. + + The fact that a closest encloser will be the only superdomain that + can have a candidate wild card will have an impact when it comes to + designing authenticated denial of existence proofs. + +# If the "*" label does not exist, check whether the name +# we are looking for is the original QNAME in the query +# or a name we have followed due to a CNAME. If the name +# is original, set an authoritative name error in the +# response and exit. Otherwise just exit. + + The above passage says that if there is not even a wild card domain + name to match at this point (failing to find an explicit answer + elsewhere), we are to return an authoritative name error at this + point. If we were following a CNAME, the specification is unclear, + but seems to imply that a no error return code is appropriate, with + just the CNAME RR (or sequence of CNAME RRs) in the answer section. + +# If the "*" label does exist, match RRs at that node +# against QTYPE. If any match, copy them into the answer +# section, but set the owner of the RR to be QNAME, and +# not the node with the "*" label. Go to step 6. + + This final paragraph covers the role of the QTYPE in the process. + Note that if no resource record set matches the QTYPE the result is + that no data is copied, but the search still ceases ("Go to step + 6."). In the following section, a suggested change is made to this, + under the heading "CNAME RRs at a Wild Card Domain Name." + + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 11] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + +6. Considerations with Special Types + + For the purposes of this section, "special" means that a record + induces processing at the server beyond simple lookup. The special + types in this section are SOA, NS, CNAME, and DNAME. SOA is special + because it is used as a zone marker and has an impact on step 2 of + the algorithm in 4.3.2. NS denotes a cut point and has an impact on + step 3b. CNAME redirects the query and is mentioned in steps 3a and + 3b. DNAME is a "CNAME generator." + +6.1. SOA RR's at a Wild Card Domain Name + + If the owner of an SOA record conforms to the basic rules of owning + an SOA RR (meaning it is the apex of a zone) the impact on the search + algorithm is not in section 3c (where records are synthesized) as + would be expected. The impact is really in step 2 of the algorithm, + the choice of zone. + + We are no longer talking about whether or not an SOA RR can be + synthesized in a response because we are shifting attention to step + 2. We are now talking about what it means for a name server to + synthesize a zone for a response. To date, no implementation has + done this. Thinking ahead though, anyone choosing to pursue this + would have to be aware that a server would have to be able to + distinguish between queries for data it will have to synthesize and + queries that ought to be treated as if they were prompted by a lame + delegation. + + It is not a protocol error to have an SOA RR owned by a wild card + domain name, just as it is not an error to have zone name be + syntactically equivalent to a domain name. However, this situation + requires careful consideration of how a server chooses the + appropriate zone for an answer. And an SOA RR is not able to be + synthesized as in step 3c. + +6.2. NS RR's at a Wild Card Domain Name + + Complimentary to the issue of an SOA RR owned by a wild card domain + name is the issue of NS RR's owned by a wild card domain name. In + this instance, each machine being referred to in the RDATA of the NS + RR has to be able to understand the impact of this on step 2, the + choosing of the authoritative zone. + + Referring to the same machine in such a NS RR will probably not work + well. This is because the server may become confused as to whether + the query name ought to be answered by the zone owning the NS RR in + question or a synthesized zone. (It isn't known in advance that the + query name will invoke the wild card synthesis.) + + + +Halley & Lewis [Expires March 2004] [Page 12] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + The status of other RR's owned by a wild card domain name is the same + as if the owner name was not a wild card domain name. I.e., when + there is a NS RR at a wild card domain name, other records are + treated as being below the zone cut. + + Is it not a protocol error to have a NS RR owned by a wild card + domian name, complimentary to the case of a SOA RR. However, for + this to work, an implementation has to know how to synthesize a zone. + +6.3. CNAME RR's at a Wild Card Domain Name + + The issue of CNAME RR's owned by wild card domain names has prompted + a suggested change to the last paragraph of step 3c of the algorithm + in 4.3.2. The changed text is this: + + If the "*" label does exist and if the data at the node is a + CNAME and QTYPE doesn't match CNAME, copy the CNAME RR into the + answer section of the response, set the owner of the CNAME RR to + be QNAME, and then change QNAME to the canonical name in the + CNAME RR, and go back to step 1. + + If the "*" label does exist and either QTYPE is CNAME or the + data at the node is not a CNAME, then match RRs at that node + against QTYPE. If any match, copy them into the answer section, + but set the owner of the RR to be QNAME, and not the node with + the "*" label. Go to step 6. + + Apologies if the above isn't clear, but an attempt was made to stitch + together the passage using just the phrases in section 3a and 3c of + the algorithm so as to preserve the original flavor. + + In case the passage as suggested isn't clear enough, the intent is to + make "landing" at a wild card name and finding a CNAME the same as if + this happened as a result of a direct match. I.e., Finding a CNAME + at the name matched in step 3c is supposed to have the same impact as + finding the CNAME in step 3a. + +6.4. DNAME RR's at a Wild Card Domain Name + + The specification of the DNAME RR, which is at the proposed level of + standardization, is not as mature as the full standard in RFC 1034. + Because of this, or the reason for this is, there appears to be a + host of issues with that definition and it's rewrite of the algorithm + in 4.3.2. For the time being, when it comes to wild card processing + issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME + at a wild card domain name is effectively the same as a CNAME at a + wild card domain name. + + + + +Halley & Lewis [Expires March 2004] [Page 13] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + +7. Security Considerations + + This document is refining the specifications to make it more likely + that security can be added to DNS. No functional additions are being + made, just refining what is considered proper to allow the DNS, + security of the DNS, and extending the DNS to be more predictable. + +8. References + + Normative References + + [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 + + [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, + Nov-01-1987 + + [RFC 1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 + + [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S + Bradner, March 1997 + + Informative References + + [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, + Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 + + [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 + + [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 + +9. Others Contributing to This Document + + Others who have directly caused text to appear in the document: Paul + Vixie and Olaf Kolkman. Many others have indirect influences on the + content. + + + + + + + + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 14] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + +10. Editors + + Name: Bob Halley + Affiliation: Nominum, Inc. + Address: 2385 Bay Road, Redwood City, CA 94063 USA + Phone: +1-650-381-6016 + EMail: Bob.Halley@nominum.com + + Name: Edward Lewis + Affiliation: ARIN + Address: 3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA + Phone: +1-703-227-9854 + Email: edlewis@arin.net + + Comments on this document can be sent to the editors or the mailing + list for the DNSEXT WG, namedroppers@ops.ietf.org. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 15] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + +Appendix A: Subdomains of Wild Card Domain Names + + In reading the definition of section 2 carefully, it is possible to + rationalize unusual names as legal. In the example given, + *.example. could have subdomains of *.sub.*.example. and even the + more direct *.*.example. (The implication here is that these domain + names own explicit resource records sets.) Although defining these + names is not easy to justify, it is important that implementions + account for the possibility. This section will give some further + guidence on handling these names. + + The first thing to realize is that by all definitions, subdomains of + wild card domain names are legal. In analyzing them, one realizes + that they cause no harm by their existence. Because of this, they + are allowed to exist, i.e., there are no special case rules made to + disallow them. The reason for not preventing these names is that the + prevention would just introduce more code paths to put into + implementations. + + The concept of "closest enclosing" existing names is important to + keep in mind. It is also important to realize that a wild card + domain name can be a closest encloser of a query name. For example, + if *.*.example. is defined in a zone, and the query name is + a.*.example., then the closest enclosing domain name is *.example. + Keep in mind that the closest encloser is not eligible to be a source + of synthesized answers, just the subdomain of it that has the first + label "*". + + To illustrate this, the following chart shows some matches. Assume + that the names *.example., *.*.example., and *.sub.*.example. are + defined in the zone. + + QNAME Closest Encloser Wild Card Source + a.example. example. *.example. + b.a.example. example. *.example. + a.*.example. *.example. *.*.example. + b.a.*.example. *.example. *.*.example. + b.a.*.*.example. *.*.example. no wild card + a.sub.*.example. sub.*.example. *.sub.*.example. + b.a.sub.*.example. sub.*.example. *.sub.*.example. + a.*.sub.*.example. *.sub.*.example. no wild card + *.a.example. example. *.example. + a.sub.b.example. example. *.example. + + Recall that the closest encloser itself cannot be the wild card. + Therefore the match for b.a.*.*.example. has no applicable wild card. + + + + + +Halley & Lewis [Expires March 2004] [Page 16] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + + Finally, if a query name is sub.*.example., any answer available will + come from an exact name match for sub.*.example. No wild card + synthesis is performed in this case. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 17] + +Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society 2003. All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Halley & Lewis [Expires March 2004] [Page 18] diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt new file mode 100644 index 000000000000..e9943015e4e9 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt @@ -0,0 +1,1120 @@ + + +DNS Operations M. Larson +Internet-Draft P. Barber +Expires: August 16, 2004 VeriSign + February 16, 2004 + + + Observed DNS Resolution Misbehavior + draft-ietf-dnsop-bad-dns-res-02 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 16, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This Internet-Draft describes DNS name server and resolver behavior + that results in a significant query volume sent to the root and + top-level domain (TLD) name servers. In some cases we recommend + minor additions to the DNS protocol specification and corresponding + changes in name server implementations to alleviate these unnecessary + queries. The recommendations made in this document are a direct + byproduct of observation and analysis of abnormal query traffic + patterns seen at two of the thirteen root name servers and all + thirteen com/net TLD name servers. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + + + +Larson & Barber Expires August 16, 2004 [Page 1] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + document are to be interpreted as described in RFC 2119 [1]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Observed name server misbehavior . . . . . . . . . . . . . 4 + 2.1 Aggressive requerying for delegation information . . . . . 4 + 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 5 + 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 6 + 2.3 Inability to follow multiple levels of out-of-zone glue . 6 + 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4 Aggressive retransmission when fetching glue . . . . . . . 7 + 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 + 2.5 Aggressive retransmission behind firewalls . . . . . . . . 8 + 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 + 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 9 + 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 10 + 2.7 Name server records with zero TTL . . . . . . . . . . . . 10 + 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 + 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 11 + 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 + 2.9 Queries for domain names resembling IP addresses . . . . . 12 + 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 12 + 2.10 Misdirected recursive queries . . . . . . . . . . . . . . 12 + 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 + 2.11 Suboptimal name server selection algorithm . . . . . . . . 13 + 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 + 3. IANA considerations . . . . . . . . . . . . . . . . . . . 15 + 4. Security considerations . . . . . . . . . . . . . . . . . 16 + 5. Internationalization considerations . . . . . . . . . . . 17 + Normative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . 19 + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 2] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net TLD name servers has revealed that a large + proportion of the total traffic often consists of "requeries". A + requery is the same question () asked + repeatedly at an unexpectedly high rate. We have observed requeries + from both a single IP address and multiple IP addresses. + + By analyzing requery events we have found that the cause of the + duplicate traffic is almost always a deficient name server, stub + resolver and/or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of glue records must be followed, and aggressive retry by stub + resolvers and/or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (DoS attacks, crashes, maintenance, routing failures, + congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. Some of the changes recommended affect the core DNS protocol + specification, described principally in RFC 1034 [2], RFC 1035 [3] + and RFC 2181 [4]. + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 3] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +2. Observed name server misbehavior + +2.1 Aggressive requerying for delegation information + + There can be times when every name server in a zone's NS RRset is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host) or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider a recursive name server + that attempts to resolve a query for a domain name in such a zone and + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation that then + verifies the zone's NS RRset in its cache by querying for the zone's + delegation information: it sends a query for the zone's NS RRset to + one of the parent zone's name servers. + + For example, suppose that "example.com" has the following NS RRset: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this recursive name server implementation immediately queries + a "com" zone name server for the "example.com" NS RRset to verify it + has the proper delegation information. This name server + implementation performs this query to a zone's parent zone for each + recursive query it receives that fails because of a completely + unresponsive set of name servers for the target zone. Consider the + effect when a popular zone experiences a catastrophic failure of all + its name servers: now every recursive query for domain names in that + zone sent to this name server implementation results in a query to + the failed zone's parent name servers. On one occasion when several + dozen popular zones became unreachable, the query load on the com/net + name servers increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: When a recursive name server is resolving a query for + a domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent is pointless: this query to the parent would come so quickly + on the heels of the referral that it would be almost certain to + contain the same list of name servers. The chance of discovering any + new information is slim. + + The other possibility is that the recursive name server successfully + + + +Larson & Barber Expires August 16, 2004 [Page 4] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + contacts one of the target zone's name servers and then caches the NS + RRset from the authority section of a response, the proper behavior + according to section 5.4.1 of RFC 2181 [4], because the NS RRset from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the recursing name server discovers that none of the name servers + specified in the cached NS RRset is available or authoritative, + querying the parent would be wrong. An NS RRset from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured and/or decommissioned AND + the delegation information in the parent zone would have to be + updated with the new set of name servers, all within the TTL of the + target zone's NS RRset. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually, with servers that are removed from the + NS RRset left authoritative for the zone as long as possible. The + scenarios that we can envision that would benefit from the parent + requery behavior do not outweigh its damaging effects. + +2.1.1 Recommendation + + Name servers offering recursion MUST NOT send a query for the NS + RRset of a non-responsive zone to any of the name servers for that + zone's parent zone. For the purposes of this injunction, a + non-responsive zone is defined as a zone for which every name server + listed in the zone's NS RRset: + + 1. is not authoritative for the zone (i.e., lame), or, + + 2. returns a server failure response (RCODE=2), or, + + 3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. + + +2.2 Repeated queries to lame servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is a subset of a zone's name servers being + unavailable or misconfigured. Different failure modes have different + expected durations. Some symptoms indicate problems that are + potentially transient: various types of ICMP unreachable messages + because a name server process is not running or a host or network is + unreachable, or a complete lack of a response to a query. Such + responses could be the result of a host rebooting or temporary + + + +Larson & Barber Expires August 16, 2004 [Page 5] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + outages; these events don't necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + +2.2.1 Recommendation + + Recursive name servers SHOULD cache name servers that they discover + are not authoritative for zones delegated to them (i.e. lame + servers). Lame servers MUST be cached against the specific query + tuple . Zone name can be + derived from the owner name of the NS record that was referenced to + query the name server that was discovered to be lame. + Implementations that perform lame server caching MUST refrain from + sending queries to known lame servers based on a time interval from + when the server is discovered to be lame. A minimum interval of + thirty minutes is RECOMMENDED. + +2.3 Inability to follow multiple levels of out-of-zone glue + + Some recursive name server implementations are unable to follow more + than one level of out-of-zone glue. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + A name server processing a recursive query for "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" and/or "ns2.test.example.net" in order to + obtain address records for "ns1.example.com" and/or "ns2.example.com" + in order to query those name servers for the address records of + "www.foo.example". While this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + + + +Larson & Barber Expires August 16, 2004 [Page 6] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + top-level domains (gTLDs) become active. We anticipate many zones in + the new gTLDs will use name servers in other gTLDs, increasing the + amount of inter-zone glue. + +2.3.1 Recommendation + + Clearly constructing a delegation that relies on multiple levels of + out-of-zone glue is not a good administrative practice. This issue + could be mitigated with an operational injunction in an RFC to + refrain from construction of such delegations. In our opinion the + practice is widespread enough to merit clarifications to the DNS + protocol specification to permit it on a limited basis. + + Name servers offering recursion SHOULD be able to handle at least + three levels of indirection resulting from out-of-zone glue. + +2.4 Aggressive retransmission when fetching glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include A records for every NS record in the + authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing A records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such a server will not + generate any queries of its own. Instead it answers non-recursive + queries from resolvers looking for information in zones it serves. + With glue fetching enabled, however, an authoritative server will + generate queries whenever it needs to look up an unknown address + record to complete the additional section of a response. + + We have observed situations where a glue-fetching name server can + send queries that reach other name servers, but apparently is + prevented from receiving the responses. For example, perhaps the + name server is authoritative-only and therefore its administrators + expect it to receive only queries. Perhaps unaware of glue fetching + and presuming that the name server will generate no queries, its + administrators place the name server behind a network device that + prevents it from receiving responses. If this is the case, all + glue-fetching queries will go answered. + + + +Larson & Barber Expires August 16, 2004 [Page 7] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + We have observed name server implementations that retry excessively + when glue-fetching queries are unanswered. A single com/net name + server has received hundreds of queries per second from a single name + server. Judging from the specific queries received and based on + additional analysis, we believe these queries result from overly + aggressive glue fetching. + +2.4.1 Recommendation + + Implementers whose name servers support glue fetching should take + care to avoid sending queries at excessive rates. Implementations + should support throttling logic to detect when queries are sent but + no responses are received. + +2.5 Aggressive retransmission behind firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, a + recursive name server is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose traffic is improperly + filtered in this manner. Stub resolvers in the organization could be + configured to query multiple name servers. Consider the case where a + stub resolver queries a filtered name server first. This name server + sends one or more queries whose replies are filtered, so it can't + respond to the stub resolver, which times out. The resolver + retransmits to a name server that is able to provide an answer. + Since resolution ultimately succeeds the underlying problem might not + be recognized or corrected. A popular stub resolver has a very + aggressive retransmission schedule, including simultaneous queries to + multiple name servers, which could explain how such a situation could + persist without being detected. + +2.5.1 Recommendation + + + + +Larson & Barber Expires August 16, 2004 [Page 8] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + The most obvious recommendation is that administrators should take + care not to place recursive name servers behind a firewall that + prohibits queries to pass through but not the resulting replies. + + Name servers should take care to avoid sending queries at excessive + rates. Implementations should support throttling logic to detect + when queries are sent but no responses are received. + +2.6 Misconfigured NS records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. A recursive name server + attempting to resolve A records for "www.example.com" with no cached + information for this zone will query a "com" authoritative server. + The "com" server responds with a referral to the "example.com" zone, + consisting of NS records with valid RDATA and associated glue + records. (This example assumes that the "example.com" zone + information is correct in the "com" zone.) The recursive name server + caches the NS RRset from the "com" server and follows the referral by + querying one of the "example.com" authoritative servers. This server + responds with the "www.example.com" A record in the answer section + and, typically, the "example.com" NS records in the authority section + and, if space in the message remains, glue A records in the + additional section. According to Section 5.4 of RFC 2181 [4], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a + non-authoritative answer. Thus the "example.com" NS RRset just + received from the "example.com" authoritative server displaces the + "example.com" NS RRset received moments ago from the "com" + authoritative server. + + But the "example.com" zone contains the erroneous NS RRset as shown + in the example above. Subsequent queries for names in "example.com" + will cause the server to attempt to use the incorrect NS records and + so the server will try to resolve the nonexistent names + + + +Larson & Barber Expires August 16, 2004 [Page 9] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the recursive server cannot reach any "example.com" name + servers. Therefore attempts to resolve these names result in A + record queries to the "com' authoritative servers. Queries for such + obviously bogus glue A records occur frequently at the com/net name + servers. + +2.6.1 Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that is in the zone. But any in-zone name server + should have a corresponding glue A record also in the zone. An + authoritative name server should report an error when a zone's NS + record references an in-zone name server without a corresponding glue + A record. + +2.7 Name server records with zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRset, however, carries + additional consequences beyond the zone itself: if a recursive name + server cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRset expected to change frequently is extreme but + permissible. A zone's NS RRset is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + zone parent/child relationships we are aware of, there is typically + some delay involved in effecting changes. Further, changes to the + set of a zone's authoritative name servers (and therefore to the + zone's NS RRset) are typically relatively rare: providing reliable + authoritative service requires a reasonably stable set of servers. + Therefore an extremely low or zero TTL on a zone's NS RRset rarely + makes sense, except in anticipation of an upcoming change. In this + case, when the zone's administrator has planned a change and does not + want recursive name servers throughout the Internet to cache the NS + RRset for a long period of time, a low TTL is reasonable. + + + +Larson & Barber Expires August 16, 2004 [Page 10] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +2.7.1 Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers imposed by a zero TTL on a zone's NS RRset, + under such circumstances authoritative name servers should issue a + warning when loading a zone or refuse to load the zone altogether. + +2.8 Unnecessary dynamic update messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's SOA MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + is the lowest zone in the name space. The closest enclosing zone + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone involves working up the name + space tree and sending repeated UPDATE messages until success. For + example, consider an agent attempting to add an A record with the + name "foo.bar.example.com". The agent could first attempt to update + the "foo.bar.example.com" zone. If the attempt failed, the update + could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A reasonable question is why the algorithm proceeds with + sending updates all the way to TLD and root name servers. In + enterprise DNS architectures with an "internal root" design, there + could conceivably be private, non-public TLD or root zones that would + be the appropriate target for a dynamic update. However, we question + if designing an algorithm to accommodate these limited cases is worth + the load it places on the public DNS in the form of unnecessary + UPDATE messages. + +2.8.1 Recommendation + + Dynamic update agents should not attempt to send UPDATE messages to + authoritative servers for TLD zones or the root zone by default. If + this functionality is supported, it should be require specific action + + + +Larson & Barber Expires August 16, 2004 [Page 11] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + by a user to be enabled. + +2.9 Queries for domain names resembling IP addresses + + The root name servers receive a significant number of A record + queries where the qname is an IP address. The source of these + queries is unknown. It could be attributed to situations where a + user believes an application will accept either a domain name or an + IP address in a given configuration option. The user enters an IP + address, but the application assumes any input is a domain name and + attempts to resolve it, resulting in an A record lookup. There could + also be applications that produce such queries in a misguided attempt + to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. A recursive + name server can negatively cache such responses, but each response + requires a separate cache entry, i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + +2.9.1 Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + bandwidth. One possibility is for recursive name server + implementations to produce the Name Error response directly. We + suggest that implementors consider the option of synthesizing Name + Error responses at the recursive name server. The server could claim + authority for synthesized TLD zones corresponding to the first octet + of every possible IP address, e.g. 1., 2., through 255. This + behavior could be configurable in the (probably unlikely) event that + numeric TLDs are ever put into use. + + Another option is to delegate these numeric TLDs from the root zone + to a separate set of servers to absorb the traffic. The "blackhole + servers" used by the the AS 112 Project [8], which are currently + delegated the in-addr.arpa zones corresponding to RFC 1918 [7] + private use address space, would be a possible choice to receive + these delegations. + +2.10 Misdirected recursive queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the RD bit set in the header). Since + none of the root servers offer recursion, the servers' response in + such a situation ignores the request for recursion and the response + probably does not contain the data the querier anticipated. Some of + these queries result from users configuring stub resolvers to query a + + + +Larson & Barber Expires August 16, 2004 [Page 12] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + root server. (This situation is not hypothetical: we have received + complaints from users when this configuration does not work as + hoped.) Of course, users should not direct stub resolvers to use name + servers that do not offer recursion, but we are not aware of any stub + resolver implementation that offers any feedback to the user when so + configured, aside from simply "not working". + +2.10.1 Recommendation + + When the IP address of a (supposedly) recursive name server is + configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server + supports recursion (i.e., the response has the RA bit set in the + header). The user could be immediately notified if the server is + non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting should be throttled to avoid a + notification or log message for every response from a non-recursive + server. + +2.11 Suboptimal name server selection algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully underspecified, requiring + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by a recursive name server. When a recursive name server + wants to contact one of a zone's authoritative name servers, how does + it choose from the NS records listed in the zone's NS RRset? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1 Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. I.e., these changes would + help spread the query load evenly. + + + + +Larson & Barber Expires August 16, 2004 [Page 13] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + o Do not make assumptions based on NS RRset order: all NS RRs should + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for + "a.gtld-servers.net" first in the authority section of referrals. + As a result, this server receives disproportionately more traffic + than the other 12 authoritative servers for "com".) + + o Use all NS records in an RRset. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + + o Do not lock onto the best-performing of a zone's name servers. A + recursive name server should periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 14] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +3. IANA considerations + + There are no new IANA considerations introduced by this + Internet-Draft. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 15] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +4. Security considerations + + Name server and resolver misbehaviors identical or similar to those + discussed in this document expose the root and TLD name servers to + increased risk of both intentional and unintentional denial of + service. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 16] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +5. Internationalization considerations + + We do not believe this document introduces any new + internationalization considerations to the DNS protocol + specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 17] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April + 1997. + + [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + + [8] + + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: pbarber@verisign.com + + + + + +Larson & Barber Expires August 16, 2004 [Page 18] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Larson & Barber Expires August 16, 2004 [Page 19] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 20] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt new file mode 100644 index 000000000000..04815175fdba --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt @@ -0,0 +1,1344 @@ + +DNSOP O. Kolkman +Internet-Draft RIPE NCC +Expires: August 30, 2004 R. Gieben + NLnet Labs + March 2004 + + + DNSSEC Operational Practices + draft-ietf-dnsop-dnssec-operational-practices-01.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 30, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes a set of practices for operating a DNSSEC + aware environment. The target audience is zone administrators + deploying DNSSEC that need a guide to help them chose appropriate + values for DNSSEC parameters. It also discusses operational matters + such as key rollovers, KSK and ZSK considerations and related + matters. + + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 1] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3 + 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3 + 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5 + 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1 Motivations for the KSK and ZSK Functions . . . . . . . . 7 + 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8 + 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8 + 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8 + 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10 + 3.3.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 13 + 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 14 + 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15 + 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16 + 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1 Initial Key Exchanges and Parental Policies + Considerations . . . . . . . . . . . . . . . . . . . . . . 16 + 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 16 + 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 17 + 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 17 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 + 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 + A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 + B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 20 + C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 20 + D. Document Details and Changes . . . . . . . . . . . . . . . . . 22 + D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22 + D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22 + Intellectual Property and Copyright Statements . . . . . . . . 23 + + + + + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 2] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +1. Introduction + + During workshops and early operational deployment tests, operators + and system administrators gained experience about operating DNSSEC + aware DNS services. This document translates these experiences into + a set of practices for zone administrators. At the time of writing, + there exists very little experience with DNSSEC in production + environments, this document should therefore explicitly not be seen + as represented 'Best Current Practices'. + + The procedures herein are focused on the maintenance of signed zones + (i.e. signing and publishing zones on authoritative servers). It is + intended that maintenance of zones such as resigning or key rollovers + be transparent to any verifying clients on the Internet. + + The structure of this document is as follows: It begins with + discussing some of the considerations with respect to timing + parameters of DNS in relation to DNSSEC (Section 2). Aspects of key + management such as key rollover schemes are described in Section 3. + Emergency rollover considerations are addressed in Section 4. The + typographic conventions used in this document are explained in + Appendix C. + + Since this is a document with operational suggestions and there are + no protocol specifications, the RFC2119 [5] language does not apply. + +1.1 The Use of the Term 'key' + + It is assumed that the reader is familiar with the concept of + asymmetric keys on which DNSSEC is based (Public Key Cryptography + [Ref to Schneider?]). Therefore, this document will use the term + 'key' rather loosely. Where it is written that 'a key is used to sign + data' it is assumed that the reader understands that it is the + private part of the key-pair that is used for signing. It is also + assumed that the reader understands that the public part of the + key-pair is published in the DNSKEY resource record and that it is + used in key-exchanges. + +1.2 Keeping the Chain of Trust Intact + + Maintaining a valid chain of trust is important because broken chains + of trust will result in data being marked as bogus, which may cause + entire (sub)domains to become invisible to verifying clients. The + administrators of secured zones have to realise that their zone is, + to their clients, part of a chain of trust. + + As mentioned in the introduction, the procedures herein are intended + to ensure maintenance of zones, such as resigning or key rollovers, + + + +Kolkman & Gieben Expires August 30, 2004 [Page 3] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + be transparent to the verifying clients on the Internet. + Administrators of secured zones will have to keep in mind that data + published on an authoritative primary server will not be immediately + seen by verifying clients; it may take some time for the data to be + transfered to other secondary authoritative nameservers, during which + period clients may be fetching data from caching non-authoritative + servers. For the verifying clients it is important that data from + secured zones can be used to build chains of trust regardless of + whether the data came directly from an authoritative server, a + caching nameserver or some middle box. Only by carefully using the + available timing parameters can a zone administrator assure that the + data necessary for verification can be obtained. + + The responsibility for maintaining the chain of trust is shared by + administrators of secured zones in the chain of trust. This is most + obvious in the case of a 'key compromise' when a trade off between + maintaining a valid chain of trust and the fact that the key has been + stolen, must be made. + + The zone administrator will have to make a tradeoff between keeping + the chain of trust intact -thereby allowing for attacks with the + compromised key- or to deliberately break the chain of trust thereby + making secured subdomains invisible to security aware resolvers. Also + see Section 4. + +2. Time in DNSSEC + + Without DNSSEC all times in DNS are relative. The SOA's refresh, + retry and expiration timers are counters that are used to determine + the time elapsed after a slave server syncronised (or tried to + syncronise) with a master server. The Time to Live (TTL) value and + the SOA minimum TTL parameter [6] are used to determine how long a + forwarder should cache data after it has been fetched from an + authoritative server. DNSSEC introduces the notion of an absolute + time in the DNS. Signatures in DNSSEC have an expiration date after + which the signature is marked as invalid and the signed data is to be + considered bogus. + +2.1 Time Definitions + + In this document we will be using a number of time related terms. + Within the context of this document the following definitions apply: + o "Signature validity period" + The period that a signature is valid. It starts at the time + specified in the signature inception field of the RRSIG RR and + ends at the time specified in the expiration field of the RRSIG + RR. + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 4] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + o "Signature publication period" + Time after which a signature (made with a specific key) is + replaced with a new signature (made with the same key). This + replacement takes place by publishing the relevant RRSIG in the + master zone file. If a signature is published at time T0 and a + new signature is published at time T1, the signature + publication period is T1 - T0. + If all signatures are refreshed at zone (re)signing then the + signature publication period is equal signature validity + period. + o "Maximum/Minimum Zone TTL" + The maximum or minimum value of all the TTLs in a zone. + +2.2 Time Considerations + + Because of the expiration of signatures, one should consider the + following. + o The Maximum Zone TTL of your zone data should be a fraction of + your signature validity period. + If the TTL would be of similar order as the signature validity + period, then all RRsets fetched during the validity period + would be cached until the signature expiration time. As a + result query load on authoritative servers would peak at + signature expiration time. + To avoid query load peaks we suggest the TTL on all the RRs in + your zone to be at least a few times smaller than your + signature validity period. + o The signature publication period should be at least one maximum + TTL smaller than the signature validity period. + Resigning a zone shortly before the end of the signature + validity period may cause simultaneous expiration of data from + caches. This in turn may lead to peaks in the load on + authoritative servers. + o The Minimum zone TTL should be long enough to both fetch and + verify all the RRs in the authentication chain. + 1. During validation, some data may expire before the + validation is complete. The validator should be able to keep + all data, until is completed. This applies to all RRs needed + to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and + the final answers i.e. the RR that is returned for the + initial query. + 2. Frequent verification causes load on recursive + nameservers. Data at delegation points, DSs, DNSKEYs and + RRSIGs benefit from caching. The TTL on those should be + relatively long. + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 5] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + We have seen events where data needed for verification of an + authentication chain had expired from caches. + We suggest the TTL on DNSKEY and DSs to be between ten minutes + and one hour. We recommend zone administrators to chose TTLs + longer than half a minute. + [Editor's Note: this observation could be implementation + specific. We are not sure if we should leave this item] + o Slave servers will need to be able to fetch newly signed zones + well before the data expires from your zone. + 'Better no answers than bad answers.' + If a properly implemented slave server is not able to contact a + master server for an extended period the data will at some + point expire and the slave server will not hand out any data. + If the server serves a DNSSEC zone than it may well happen that + the signatures expire well before the SOA expiration timer + counts down to zero. It is not possible to completely prevent + this from happening by tweaking the SOA parameters. However, + the effects can be minimized where the SOA expiration time is + equal or smaller than the signature validity period. + The consequence of an authoritative server not being able to + update a zone, whilst that zone includes expired signaturs, is + that non-secure resolvers will continue to be able to resolve + data served by the particular slave servers. Security aware + resolvers will experience problems. + We suggest the SOA expiration timer being approximately one + third or one fourth of the signature validity period. It will + allow problems with transfers from the master server to be + noticed before the actual signature time out. + We suggest that operators of nameservers with slave zones + develop 'watch dogs' to spot upcoming signature expirations in + slave zones, and take appropriate action. + When determining the value for the expiration parameter one has + to take the following into account: What are the chances that + all my secondary zones expire; How quickly can I reach an + administrator and load a valid zone? All these arguments are + not DNSSEC specific. + +3. Keys + + In the DNSSEC protocol there is only one type of key, the zone key. + With this key, the data in a zone is signed. + + To make zone re-signing and key rollovers procedures easier to + implement, it is possible to use one or more keys as Key Signing Keys + (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other + keys can be used to sign all the RRsets in a zone and are referred to + as Zone Signing Keys (ZSK). In this document we assume that KSKs are + the subset of keys that are used for key exchanges with the parents + + + +Kolkman & Gieben Expires August 30, 2004 [Page 6] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + and potentially for configuration as trusted anchors - the so called + Secure Entry Point keys (SEP). In this document we assume a + one-to-one mapping between KSK and SEP keys and we assume the SEP + flag [4] to be set on KSKs. + +3.1 Motivations for the KSK and ZSK Functions + + Differentiating between the KSK to ZSK functions has several + advantages: + + o Making the KSK stronger (i.e. using more bits in the key material) + has little operational impact since it is only used to sign a + small fraction of the zone data. + o As the KSK is only used to sign a keyset, which is most probably + updated less frequently than other data in the zone, it can be + stored separately from (and thus in a safer location than) the + ZSK. + o A KSK can be used for longer periods. + o No parent/child interaction is required when ZSKs are updated. + + The KSK is used less than ZSK, once a keyset is signed with the KSK + all the keys in the keyset can be used as ZSK. If a ZSK is + compromised, it can be simply dropped from the keyset. The new keyset + is then resigned with the KSK. + + Given the assumption that for KSKs the SEP flag is set, the KSK can + be distinguished from a ZSK by examining the flag field in the DNSKEY + RR. If the flag field is an odd number it is a KSK if it is an even + number it is a ZSK e.g. a value of 256 and a key signing key has 257. + + The zone-signing key can be used to sign all the data in a zone on a + regular basis. When a zone-signing key is to be rolled, no + interaction with the parent is needed. This allows for relatively + short "Signature Validity Periods". That is, Signature Validity + Periods of the order of days. + + The key-signing key is only to be used to sign the Key RR set from + the zone apex. If a key-signing key is to be rolled over, there will + be interactions with parties other than the zone administrator such + as the registry of the parent zone or administrators of verifying + resolvers that have the particular key configured as trusted entry + points. Hence, the "Key Usage Time" of these keys can and should be + made much longer. Although, given a long enough key, the "Key Usage + Time" can be on the order of years we suggest to plan for a "Key + Usage Time" of the order of a few months so that a key rollover + remains an operational routine. + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 7] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +3.2 Key Security Considerations + + Keys in DNSSEC have a number of parameters which should all be chosen + with care, the most important once are: size, algorithm and the key + validity period (its lifetime). + +3.2.1 Key Validity Period + + RFC2541 [2] describes a number of considerations with respect to the + security of keys. The document deals with the generation, lifetime, + size and storage of private keys. + + In Section 3 of RFC2541 [2] there are some suggestions for a key + validity period: 13 months for long-lived keys and 36 days for + transaction keys but suggestions for key sizes are not made. + + If we say long-lived keys are key-signing keys and transactions keys + are zone-signing keys, these recommendations will lead to rollovers + occurring frequently enough to become part of 'operational habits'; + the procedure does not have to be reinvented every time a key is + replaced. + +3.2.2 Key Algorithm + + We recommend you choose RSA/SHA-1 as the preferred algorithm for the + key. RSA has been developed in an open and transparent manner. As the + patent on RSA expired in 2001, its use is now also free. The current + known attacks on RSA can be defeated by making your key longer. As + the MD5 hashing algorithm is showing (theoretical) cracks, we + recommend the usage of SHA1. + +3.2.3 Key Sizes + + When choosing key sizes, zone administrators will need to take into + account how long a key will be used and how much data will be signed + during the key publication period. It is hard to give precise + recommendations but Lenstra and Verheul [9] supplied the following + table with lower bound estimates for cryptographic key sizes. Their + recommendations are based on a set of explicitly formulated parameter + settings, combined with existing data points about cryptosystems. For + details we refer to the original paper. + + [Editor's Note: DSA???] + + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 8] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + Year RSA Key Sizes Elliptic Curve Key Size + 2000 952 132 + 2001 990 135 + 2002 1028 139 + 2003 1068 140 + 2004 1108 143 + + 2005 1149 147 + 2006 1191 148 + 2007 1235 152 + 2008 1279 155 + 2009 1323 157 + + + 2010 1369 160 + 2011 1416 163 + 2012 1464 165 + 2013 1513 168 + 2014 1562 172 + + 2015 1613 173 + 2016 1664 177 + 2017 1717 180 + 2018 1771 181 + 2019 1825 185 + + + 2020 1881 188 + 2021 1937 190 + 2022 1995 193 + 2023 2054 197 + 2024 2113 198 + + 2025 2174 202 + 2026 2236 205 + 2027 2299 207 + 2028 2362 210 + 2029 2427 213 + + For example, should you wish your key to last three years from 2003, + check the RSA keysize values for 2006 in this table. In this case + 1191. + +3.3 Key Rollovers + + Key rollovers are a fact of life when using DNSSEC. A DNSSEC key + cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone + administrators who are in the process of rolling their keys have to + + + +Kolkman & Gieben Expires August 30, 2004 [Page 9] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + take into account that data published in previous versions of their + zone still lives in caches. When deploying DNSSEC, this becomes an + important consideration; ignoring data that may be in caches may lead + to loss of service for clients. + + The most pressing example of this is when zone material signed with + an old key is being validated by a resolver which does not have the + old zone key cached. If the old key is no longer present in the + current zone, this validation fails, marking the data bogus. + Alternatively, an attempt could be made to validate data which is + signed with a new key against an old key that lives in a local cache, + also resulting in data being marked bogus. + + To appreciate the situation one could think of a number of + authoritative servers that may not be instantaneously running the + same version of a zone and a security aware non-recursive resolver + that sits behind security aware caching forwarders. + + Note that KSK rollovers and ZSK rollovers are different. A zone-key + rollover can be handled in two different ways: pre-publish (Section + Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The + pre-publish technique works because the key-signing key stays the + same during this ZSK rollover. With this KSK a cache is able to + validate the new keyset of a zone. With a KSK rollover a cache can + not validate the new keyset, because it does not trust the new KSK. + + [Editors note: This needs more verbose explanation, nobody will + appreciate the situation just yet. Help with text and examples is + appreciated] + +3.3.1 Zone-signing Key Rollovers + + For zone-signing key rollovers there are two ways to make sure that + during the rollover data still cached can be verified with the new + keysets or newly generated signatures can be verified with the keys + still in caches. One schema uses double signatures, it is described + in Section 3.3.1.2, the other uses key pre-publication (Section + 3.3.1.1). The pros, cons and recommendations are described in Section + 3.3.1.3. + +3.3.1.1 Pre-publish Keyset Rollover + + This section shows how to perform a ZSK rollover without the need to + sign all the data in a zone twice - the so called "prepublish + rollover". We recommend this method because it has advantages in the + case of key compromise. If the old key is compromised, the new key + has already been distributed in the DNS. The zone administrator is + then able to quickly switch to the new key and remove the compromised + + + +Kolkman & Gieben Expires August 30, 2004 [Page 10] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + key from the zone. Another major advantage is that the zone size does + not double, as is the case with the double signature ZSK rollover. A + small "HOWTO" for this kind of rollover can be found in Appendix B. + + normal pre-roll roll after + + SOA0 SOA1 SOA2 SOA3 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) + + DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 DNSKEY11 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) + + + normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. + DNSKEY 10 is used to sign all the data of the zone, the + zone-signing key. + pre-roll: DNSKEY 11 is introduced into the keyset. Note that no + signatures are generated with this key yet, but this does not + secure against brute force attacks on the public key. The minimum + duration of this pre-roll phase is the time it takes for the data + to propagate to the authoritative servers plus TTL value of the + keyset. This equates to two times the Maximum Zone TTL. + roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign + the data in the zone exclusively (i.e. all the signatures from + DNSKEY 10 are removed from the zone). DNSKEY 10 remains published + in the keyset. This way data that was loaded into caches from + version 1 of the zone can still be verified with key sets fetched + from version 2 of the zone. + The minimum time that the keyset including DNSKEY 10 is to be + published is the time that it takes for zone data from the + previous version of the zone to expire from old caches i.e. the + time it takes for this zone to propagate to all authoritative + servers plus the Maximum Zone TTL value of any of the data in the + previous version of the zone. + after: DNSKEY 10 is removed from the zone. The keyset, now only + containing DNSKEY 11 is resigned with the DNSKEY 1. + + The above scheme can be simplified by always publishing the "future" + key immediately after the rollover. The scheme would look as follows + (we show two rollovers); the future key is introduced in "after" as + DNSKEY 12 and again a newer one, numbered 13, in "2nd after": + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 11] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + normal roll after 2nd roll 2nd after + + SOA0 SOA2 SOA3 SOA4 SOA5 + RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5) + + DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12 + DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13 + RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY) + + + Note that the key introduced after the rollover is not used for + production yet; the private key can thus be stored in a physically + secure manner and does not need to be 'fetched' every time a zone + needs to be signed. + + This scheme has the benefit that the key that is intended for future + use: immediately during an emergency rollover assuming that the + private key was stored in a physically secure manner. + +3.3.1.2 Double Signature Zone-signing Key Rollover + + This section shows how to perform a ZSK key rollover using the double + zone data signature scheme, aptly named "double sig rollover". + + During the rollover stage the new version of the zone file will need + to propagate to all authoritative servers and the data that exists in + (distant) caches will need to expire, this will take at least the + maximum Zone TTL . + + normal roll after + + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) + RRSIG11(SOA1) + + DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 + RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) + RRSIG11(DNSKEY) + + normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. + DNSKEY 10 is used to sign all the data of the zone, the + zone-signing key. + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 12] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced + into the keyset and all the data in the zone is signed with DNSKEY + 10 and DNSKEY 11. The rollover period will need to exist until all + data from version 0 of the zone has expired from remote caches. + This will take at least the maximum Zone TTL of version 0 of the + zone. + after: DNSKEY 10 is removed from the zone. All the signatures from + DNSKEY 10 are removed from the zone. The keyset, now only + containing DNSKEY 11, is resigned with DNSKEY 1. + + At every instance the data from the previous version of the zone can + be verified with the key from the current version and vice verse. The + data from the current version can be verified with the data from the + previous version of the zone. The duration of the rollover phase and + the period between rollovers should be at least the "Maximum Zone + TTL". + + Making sure that the rollover phase lasts until the signature + expiration time of the data in version 0 of the zone is recommended. + However, this date could be considerably longer than the Maximum Zone + TTL, making the rollover a lengthy procedure. + + Note that in this example we assumed that the zone was not modified + during the rollover. New data can be introduced in the zone as long + as it is signed with both keys. + +3.3.1.3 Pros and Cons of the Schemes + + Prepublish-keyset rollover: This rollover does not involve signing + the zone data twice. Instead, just before the actual rollover, the + new key is published in the keyset and thus available for + cryptanalysis attacks. A small disavantage is that this process + requires four steps. Also the prepublish scheme will not work for + KSKs as explained in Section 3.3. + Double signature rollover: The drawback of this signing scheme is + that during the rollover the number of signatures in your zone + doubles, this may be prohibitive if you have very big zones. An + advantage is that it only requires three steps. + +3.3.2 Key-signing Key Rollovers + + For the rollover of a key-signing key the same considerations as for + the rollover of a zone-signing key apply. However we can use a double + signature scheme to guarantee that old data (only the apex keyset) in + caches can be verified with a new keyset and vice versa. + + Since only the keyset is signed with a KSK, zone size considerations + do not apply. + + + +Kolkman & Gieben Expires August 30, 2004 [Page 13] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + normal roll after + + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) + + DNSKEY1 DNSKEY1 DNSKEY2 + DNSKEY2 + DNSKEY10 DNSKEY10 DNSKEY10 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) + RRSIG2 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) + + normal: Version 0 of the zone. The parental DS points to DNSKEY1. + Before the rollover starts the child will have to verify what the + TTL is of the DS RR that points to DNSKEY1 - it is needed during + the rollover and we refer to the value as TTL_DS. + roll: During the rollover phase the zone administrator generates a + second KSK, DNSKEY2. The key is provided to the parent and the + child will have to wait until a new DS RR has been generated that + points to DNSKEY2. After that DS RR has been published on _all_ + servers authoritative for the parents zone, the zone administrator + has to wait at least TTL_DS to make sure that the old DS RR has + expired from distant caches. + after: DNSKEY1 has been removed. + + The scenario above puts the responsibility for maintaining a valid + chain of trust with the child. It also is based on the premises that + the parent only has one DS RR (per algorithm) per zone. St John [The + draft has expired] proposed a mechanism where using an established + trust relation, the interaction can be performed in-band. In this + mechanism there are periods where there are two DS RRs at the parent. + + [Editors note: We probably need to mention more] + +4. Planning for Emergency Key Rollover + + This section deals with preparation for a possible key compromise. + Our advice is to have a documented procedure ready for when a key + compromise is suspected or confirmed. + + [Editors note: We are much in favor of a rollover tactic that keeps + the authentication chain intact as long as possible. This means that + one has to take all the regular rollover properties into account.] + + When the private material of one of your keys is compromised it can + be used for as long as a valid authentication chain exists. An + authentication chain remains intact for: + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 14] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + o as long as a signature over the compromised key in the + authentication chain is valid, + o as long as a parental DS RR (and signature) points to the + compromised key, + o as long as the key is anchored in a resolver and is used as a + starting point for validation. (This is the hardest to update.) + While an authentication chain to your compromised key exists, your + name-space is vulnerable to abuse by the malicious key holder (i.e. + the owner of the compromised key). Zone operators have to make a + trade off if the abuse of the compromised key is worse than having + data in caches that cannot be validated. If the zone operator chooses + to break the authentication chain to the compromised key, data in + caches signed with this key cannot be validated. However, if the zone + administrator chooses to take the path of a regular roll-over, the + malicious key holder can spoof data so that it appears to be valid, + note that this kind of attack will usually be localised in the + Internet topology. + + +4.1 KSK Compromise + + When the KSK has been compromised the parent must be notified as soon + as possible using secure means. The keyset of the zone should be + resigned as soon as possible. Care must be taken to not break the + authentication chain. The local zone can only be resigned with the + new KSK after the parent's zone has been updated with the new KSK. + Before this update takes place it would be best to drop the security + status of a zone all together: the parent removes the DS of the child + at the next zone update. After that the child can be made secure + again. + + An additional danger of a key compromise is that the compromised key + can be used to facilitate a legitimate DNSKEY/DS and/or nameserver + rollover at the parent. When that happens the domain can be in + dispute. An out of band and secure notify mechanism to contact a + parent is needed in this case. + +4.2 ZSK Compromise + + Primarily because there is no parental interaction required when a + ZSK is compromised, the situation is less severe than with with a KSK + compromise. The zone must still be resigned with a new ZSK as soon + as possible. As this is a local operation and requires no + communication between the parent and child this can be achieved + fairly quickly. However, one has to take into account that just as + with a normal rollover the immediate disappearance from the old + compromised key may lead to verification problems. The + pre-publication scheme as discussed above minimises such problems. + + + +Kolkman & Gieben Expires August 30, 2004 [Page 15] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +4.3 Compromises of Keys Anchored in Resolvers + + A key can also be pre-configured in resolvers. If DNSSEC is rolled + out as planned the root key should be pre-configured in every secure + aware resolver on the planet. [Editors Note: add more about + authentication of a newly received resolver key] + + If trust-anchor keys are compromised, the resolvers using these keys + should be notified of this fact. Zone administrators may consider + setting up a mailing list to communicate the fact that a SEP key is + about to be rolled over. This communication will of course need to be + authenticated e.g. by using digital signatures. + +5. Parental Policies + +5.1 Initial Key Exchanges and Parental Policies Considerations + + The initial key exchange is always subject to the policies set by the + parent (or its registry). When designing a key exchange policy one + should take into account that the authentication and authorisation + mechanisms used during a key exchange should be as strong as the + authentication and authorisation mechanisms used for the exchange of + delegation information between parent and child. + + Using the DNS itself as the source for the actual DNSKEY material, + with an off-band check on the validity of the DNSKEY, has the benefit + that it reduces the chances of user error. A parental DNSKEY download + tool can make use of the SEP bit [4] to select the proper key from a + DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is + sent. It can validate the self-signature over a key; thereby + verifying the ownership of the private key material. Fetching the + DNSKEY from the DNS ensures that the child will not become bogus once + the parent publishes the DS RR indicating the child is secure. + + Note: the off-band verification is still needed when the key-material + is fetched by a tool. The parent can not be sure whether the DNSKEY + RRs have been spoofed. + +5.2 Storing Keys So Hashes Can Be Regenerated + + When designing a registry system one should consider if the DNSKEYs + and/or the corresponding DSs are stored. Storing DNSKEYs will help + during troubleshooting while the overhead of calculating DS records + from them is minimal. + + Having an out-of-band mechanism, such as a Whois database, to find + out which keys are used to generate DS Resource Records for specific + owners may also help with troubleshooting. + + + +Kolkman & Gieben Expires August 30, 2004 [Page 16] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +5.3 Security Lameness Checks + + Security Lameness is defined as what happens when a parent has a DS + Resource Record pointing to a non-existing DNSKEY RR. During key + exchange a parent should make sure that the child's key is actually + configured in the DNS before publishing a DS RR in its zone. Failure + to do so would render the child's zone being marked as bogus. + + Child zones should be very careful removing DNSKEY material, + specifically SEP keys, for which a DS RR exists. + + Once a zone is "security lame" a fix (e.g. by removing a DS RR) will + take time to propagate through the DNS. + +5.4 DS Signature Validity Period + + Since the DS can be replayed as long as it has a valid signature a + short signature validity period over the DS minimises the time a + child is vulnerable in the case of a compromise of the child's + KSK(s). A signature validity period that is too short introduces the + possibility that a zone is marked bogus in case of a configuration + error in the signer; there may not be enough time to fix the problems + before signatures expire. Something as mundane as operator + unavailability during weekends shows the need for DS signature + lifetimes longer than 2 days. We recommend the minimum for a DS + signature validity period to be a few days. + + The maximum signature lifetime of the DS record depends on how long + child zones are willing to be vulnerable after a key compromise. We + consider a signature validity period of around one week to be a good + compromise between the operational constraints of the parent and + minimising damage for the child. + +6. Security Considerations + + DNSSEC adds data integrity to the DNS. This document tries to assess + considerations to operate a stable and secure DNSSEC service. Not + taking into account the 'data propagation' properties in the DNS will + cause validation failures and may make secured zones unavailable to + security aware resolvers. + +7. Acknowledgments + + We, the folk mentioned as authors, only acted as editors. Most of the + ideas in this draft were the result of collective efforts during + workshops, discussions and try outs. + + At the risk of forgetting individuals who where the original + + + +Kolkman & Gieben Expires August 30, 2004 [Page 17] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + contributors of the ideas we would like to acknowledge people who + where actively involved in the compilation of this document. In + random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson, + Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier + Courtay, Sam Weiler. + + Emma Bretherick and Adrian Bedford corrected many of the spelling and + style issues. + + Kolkman and Gieben take the blame for introducing all miscakes(SIC). + +8. References + +8.1 Normative References + + [1] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [2] Eastlake, D., "DNS Security Operational Considerations", RFC + 2541, March 1999. + + [3] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key + (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work + in progress), February 2003. + +8.2 Informative References + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [7] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-13 (work in progress), March + 2003. + + [8] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in + progress), March 2003. + + [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", + The Journal of Cryptology 14 (255-293), 2001. + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 18] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + The Netherlands + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Miek Gieben + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + EMail: miek@nlnetlabs.nl + URI: http://www.nlnetlabs.nl + +Appendix A. Terminology + + In this document there is some jargon used that is defined in other + documents. In most cases we have not copied the text from the + documents defining the terms but given a more elaborate explanation + of the meaning. Note that these explanations should not be seen as + authoritative. + + Private and Public Keys: DNSSEC secures the DNS through the use of + public key cryptography. Public key cryptography is based on the + existence of two keys, a public key and a private key. The public + keys are published in the DNS by use of the DNSKEY Resource Record + (DNSKEY RR). Private keys should remain private i.e. should not be + exposed to parties not-authorised to do the actual signing. + Signer: The system that has access to the private key material and + signs the Resource Record sets in a zone. A signer may be + configured to sign only parts of the zone e.g. only those RRsets + for which existing signatures are about to expire. + KSK: A Key-Signing Key (KSK) is a key that is used exclusively for + signing the apex keyset. The fact that a key is a KSK is only + relevant to the signing tool. + ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all + data in a zone. The fact that a key is a ZSK is only relevant to + the signing tool. + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 19] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + SEP Key: A KSK that has a parental DS record pointing to it. Note: + this is not enforced in the protocol. A SEP Key with no parental + DS is security lame. + Anchored Key: A DNSKEY configured in resolvers around the globe. This + Key is hard to update, hence the term anchored. + Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked + "Bogus" when a signature of a RRset does not validate against the + DNSKEY. Even if the key itself was not marked Bogus. A cache may + choose to cache Bogus data for various reasons. + Singing the Zone File: The term used for the event where an + administrator joyfully signs its zone file while producing melodic + sound patterns. + Zone Administrator: The 'role' that is responsible for signing a zone + and publishing it on the primary authoritative server. + +Appendix B. Zone-signing Key Rollover Howto + + Using the pre-published signature scheme and the most conservative + method to assure oneself that data does not live in distant caches + here follows the "HOWTO". [WES: has some comments about this] + Key notation: + Step 0: The preparation: Create two keys and publish both in your + keyset. Mark one of the keys as "active" and the other as + "published". Use the "active" key for signing your zone data. + Store the private part of the "published" key, preferably + off-line. + Step 1: Determine expiration: At the beginning of the rollover make a + note of the highest expiration time of signatures in your zone + file created with the current key marked as "active". + Wait until the expiration time marked in Step 1 has passed + Step 2: Then start using the key that was marked as "published" to + sign your data i.e. mark it as "active". Stop using the key that + was marked as "active", mark it as "rolled". + Step 3: It is safe to engage in a new rollover (Step 1) after at + least one "signature validity period". + +Appendix C. Typographic Conventions + + The following typographic conventions are used in this document: + Key notation: A key is denoted by KEYx, where x is a number, x could + be thought of as the key id. + RRset notations: RRs are only denoted by the type. All other + information - owner, class, rdata and TTL - is left out. Thus: + example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a + list of RRs. A example of this would be: A1,A2, specifying the + RRset containing two A records. This could again be abbreviated to + just: A. + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 20] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + Signature notation: Signatures are denoted as RRSIGx(RRset), which + means that RRset is signed with DNSKEYx. + Zone representation: Using the above notation we have simplified the + representation of a signed zone by leaving out all unnecessary + details such as the names and by representing all data by "SOAx" + SOA representation: SOA's are represented as SOAx, where x is the + serial number. + Using this notation the following zone : + + + example.net. 600 IN SOA ns.example.net. ernie.example.net. ( + 10 ; serial + 450 ; refresh (7 minutes 30 seconds) + 600 ; retry (10 minutes) + 345600 ; expire (4 days) + 300 ; minimum (5 minutes) + ) + 600 RRSIG SOA 5 2 600 20130522213204 ( + 20130422213204 14 example.net. + cmL62SI6iAX46xGNQAdQ... ) + 600 NS a.iana-servers.net. + 600 NS b.iana-servers.net. + 600 RRSIG NS 5 2 600 20130507213204 ( + 20130407213204 14 example.net. + SO5epiJei19AjXoUpFnQ ... ) + 3600 DNSKEY 256 3 5 ( + EtRB9MP5/AvOuVO0I8XDxy0... + ) ; key id = 14 + 3600 DNSKEY 256 3 5 ( + gsPW/Yy19GzYIY+Gnr8HABU... + ) ; key id = 15 + 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( + 20130422213204 14 example.net. + J4zCe8QX4tXVGjV4e1r9... ) + 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( + 20130422213204 15 example.net. + keVDCOpsSeDReyV6O... ) + 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC + 600 RRSIG NSEC 5 2 600 20130507213204 ( + 20130407213204 14 example.net. + obj3HEp1GjnmhRjX... ) + a.example.net. 600 IN TXT "A label" + 600 RRSIG TXT 5 3 600 20130507213204 ( + 20130407213204 14 example.net. + IkDMlRdYLmXH7QJnuF3v... ) + 600 NSEC b.example.com. TXT RRSIG NSEC + 600 RRSIG NSEC 5 3 600 20130507213204 ( + 20130407213204 14 example.net. + + + +Kolkman & Gieben Expires August 30, 2004 [Page 21] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + bZMjoZ3bHjnEz0nIsPMM... ) + + ... + + + is reduced to the following represenation: + + SOA10 + RRSIG14(SOA10) + + DNSKEY14 + DNSKEY15 + + RRSIG14(KEY) + RRSIG15(KEY) + + The rest of the zone data has the same signature as the SOA record, + i.e a RRSIG created with DNSKEY 14. + +Appendix D. Document Details and Changes + + This section is to be removed by the RFC editor if and when the + document is published. + + $Header: /var/cvs/dnssec-key/ + draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12 + 08:29:11 dnssec Exp $ + +D.1 draft-ietf-dnsop-dnssec-operational-practices-00 + + Submission as working group document. This document is a modified and + updated version of draft-kolkman-dnssec-operational-practices-00. + +D.2 draft-ietf-dnsop-dnssec-operational-practices-01 + + changed the definition of "Bogus" to reflect the one in the protocol + draft. + + Bad to Bogus + + Style and spelling corrections + + KSK - SEP mapping made explicit. + + Updates from Sam Weiler added + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 22] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Kolkman & Gieben Expires August 30, 2004 [Page 23] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 24] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt new file mode 100644 index 000000000000..42c3c0b7c7e3 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt @@ -0,0 +1,1321 @@ + +DNS Operations WG +Internet-Draft J. Jeong (ed.) + ETRI + +Expires: January 2005 18 July 2004 + + + IPv6 Host Configuration of DNS Server Information Approaches + draft-ietf-dnsop-ipv6-dns-configuration-02.txt + + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which we become aware will be disclosed, in accordance + with RFC3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 17, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes three approaches for IPv6 recursive DNS + server address configuration. It details the operational + attributes of three solutions: RA option, DHCPv6 option, and Well- + known anycast addresses for recursive DNS servers. Additionally, + it suggests four deployment scenarios considering multi-solution + resolution. Therefore, this document will give the audience a + + + +Jeong, et al. Expires - January 2005 [Page 1] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + guideline of IPv6 DNS configuration to select approaches suitable + for their host DNS configuration. + +Table of Contents + + 1. Introduction...................................................3 + 2. Terminology....................................................3 + 3. IPv6 DNS Configuration Approaches..............................3 + 3.1 RA Option..................................................3 + 3.1.1 Advantages...........................................4 + 3.1.2 Disadvantages........................................5 + 3.1.3 Observations.........................................5 + 3.2 DHCPv6 Option..............................................6 + 3.2.1 Advantages...........................................7 + 3.2.2 Disadvantages........................................8 + 3.2.3 Observations.........................................9 + 3.3 Well-known Anycast Addresses...............................9 + 3.3.1 Advantages...........................................9 + 3.3.2 Disadvantages.......................................10 + 3.3.3 Observations........................................10 + 4. Interworking among IPv6 DNS Configuration Approaches..........11 + 5. Deployment Scenarios..........................................12 + 5.1 ISP Network...............................................12 + 5.1.1 RA Option Approach..................................12 + 5.1.2 DHCPv6 Option Approach..............................13 + 5.1.3 Well-known Addresses Approach.......................13 + 5.2 Enterprise Network........................................14 + 5.3 3GPP Network..............................................14 + 5.3.1 Currently Available Mechanisms and Recommendations..15 + 5.3.2 RA Extension........................................16 + 5.3.3 Stateless DHCPv6....................................16 + 5.3.4 Well-known Addresses................................17 + 5.3.5 Recommendations.....................................17 + 5.4 Unmanaged Network.........................................18 + 5.4.1 Case A: Gateway does not provide IPv6 at all........18 + 5.4.2 Case B: A dual-stack gateway connected to a dual-stack + ISP.........................................18 + 5.4.3 Case C: A dual-stack gateway connected to an IPv4-only + ISP.........................................19 + 5.4.4 Case D: A gateway connected to an IPv6-only ISP.....19 + 6. Security Considerations.......................................19 + 7. Acknowledgements..............................................19 + 8. Normative References..........................................20 + 9. Informative References........................................20 + 10. Authors' Addresses...........................................21 + Intellectual Property Statement..................................23 + Full Copyright Statement.........................................23 + Acknowledgement..................................................24 + + +Jeong, et al. Expires - January 2005 [Page 2] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide ways to configure either fixed or mobile + nodes with one or more IPv6 addresses, default routes and some + other parameters [3][4]. To support access to additional services + in the Internet that are identified by a DNS name, such as a web + server, the configuration of at least one recursive DNS server is + also needed for DNS name resolution. + + This document describes three approaches of recursive DNS server + address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 + option [5]-[7], and (c) Well-known anycast addresses for recursive + DNS servers [9]. Also, it suggests applicable scenarios for four + kinds of networks: (a) ISP network, (b) Enterprise network, (c) + 3GPP network, and (d) Unmanaged network. + + This document is just an analysis of each possible approach, and + does not make any recommendation on particular one or on a + combination of particular ones. Some approaches may even not be + adopted at all as a result of further discussion. + + Therefore, the objective of this document is to help the audience + select approaches suitable for IPv6 host configuration of recursive + DNS server. + +2. Terminology + + This document uses the terminology described in [3]-[9]. In + addition, a new term is defined below: + + Recursive DNS Server (RDNSS) A Recursive DNS Server is a name + server that offers the recursive + service of DNS name resolution. + +3. IPv6 DNS Configuration Approaches + + In this section, the operational attributes of three solutions are + described in detail. + +3.1 RA Option + + RA approach is to define a new ND option called RDNSS option that + contains a recursive DNS server address. Existing ND transport + mechanisms (i.e., advertisements and solicitations) are used. This + works in the same way that nodes learn about routers and prefixes, + etc. An IPv6 host can configure the IPv6 addresses of one or more + + +Jeong, et al. Expires - January 2005 [Page 3] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + RDNSSes via RA message periodically sent by router or solicited by + a Router Solicitation (RS) [8]. This approach needs RDNSS + information to be configured in the routers doing the + advertisements. The configuration of RDNSS address can be + performed manually by operator or other ways, such as automatic + configuration through DHCPv6 client running on the router. When + advertising more than one RDNSS options, an RA message includes as + many RDNSS options as RDNSSes. Through ND protocol and RDNSS + option along with prefix information option, an IPv6 host can + perform its network configuration of its IPv6 address and RDNSS + simultaneously [3][4]. The RA option for RDNSS can be used on any + network that supports the use of ND. However, RA approach performs + poorly in some wireless environments where RA message is used for + IPv6 address autoconfiguration, such as WLAN networks. + + The RA approach is useful in some non-WLAN mobile environments + where the addresses of the RDNSSes are changing because the RA + option includes a lifetime field. This can be configured to a + value that will require the client to time out the entry and switch + over to another RDNSS address [8]. However, from the viewpoint of + implementation, lifetime would seem to make matters a bit more + complex. Instead of just writing DNS configuration file, such as + resolv.conf for the list of RDNSS addresses, we have to have a + daemon around (or a program that is called at the defined + intervals) that keeps monitoring the lifetime of RDNSSes all the + time. + + The preference value of RDNSS, included in RDNSS option, allows + IPv6 hosts to select primary RDNSS among several RDNSSes; this can + be used for load balancing of RDNSSes [8]. + +3.1.1 Advantages + + The RA option for RDNSS has a number of advantages. These include: + + 1) The RA option is an extension of existing ND/Autoconfig + mechanisms [3][4], and does not require a change in the base ND + protocol. + + 2) This approach, like ND, works well on a variety of link types + including point-to-point links, point-to-multipoint, and multi- + point (i.e., Ethernet LANs), etc. RFC2461 [3] states, however, + that there may be some link type on which ND is not possible; on + such a link, some other mechanism will be needed for DNS + configuration. + + 3) All of the information a host needs to run basic Internet + applications such as email, the web, ftp, etc., can be performed + + +Jeong, et al. Expires - January 2005 [Page 4] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + with the addition of this option to ND and address auto- + configuration. The use of a single mechanism is more reliable and + easier to provide than when the RDNSS information is learned via + another protocol mechanism. Debugging problems when multiple + protocol mechanisms are being used is harder and much more complex. + + 4) This mechanism works over a broad range of scenarios and + leverages IPv6 ND. This works well on links that support broadcast + reliably (e.g., Ethernet LANs) but not necessarily on other links + (e.g., Wireless LANs). Also, this works well on links that are + high performance (e.g., Ethernet LANs) and low performance (e.g., + Cellular networks). In the latter case, combining the RDNSS + information with the other information in the RA, the host can + learn all of the information needed to use most Internet + applications such as the web in a single packet. This not only + saves bandwidth where this is an issue, but also minimizes the + delay to learn the RDNSS information. + + 5) The RA approach could be used as a model for other similar types + of configuration information. New RA options for other server + addresses that are common to all clients on a subnet would be easy + to define. This includes things like NTP servers, SIP servers, etc. + +3.1.2 Disadvantages + + 1) ND is mostly implemented in kernel part of operating system. + Therefore, if ND supports the configuration of some additional + services, such as DNS, NTP and SIP servers, ND should be extended + in kernel part. DHCPv6, however, has more flexibility for + extension of service discovery because it is an application layer + protocol. + + 2) The current ND framework should be modified due to the + synchronization between another ND cache for RDNSSes in kernel + space and DNS configuration file in user space. Because it is + unacceptable to write and rewrite the DNS configuration file (e.g., + resolv.conf) from the kernel, another approach is needed. One + simple approach to solve this is to have a daemon listening to what + the kernel conveys, and to have the daemon do these steps, but such + a daemon is not necessary with the current ND framework. + + 3) It is necessary to configure RDNSS addresses at least at one + router on every link where this information needs to be configured + by RA option. + +3.1.3 Observations + + + + +Jeong, et al. Expires - January 2005 [Page 5] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + The proposed RDNSS RA option along with IPv6 ND and Auto- + configuration allows a host to obtain all of the information it + needs to access basic Internet services like the web, email, ftp, + etc. This is preferable in environments where hosts use RAs to + autoconfigure their addresses and all hosts on the subnet share the + same router and server addresses. If the configuration information + can be obtained from a single mechanism, it is preferable because + it does not add additional delay, and it uses a minimum of + bandwidth. Environments like this include homes, public cellular + networks, and enterprise environments where no per host + configuration is needed, but exclude public WLAN hot spots. + + DHCPv6 is preferable where it is being used for address + configuration and if there is a need for host specific + configuration [5]-[7]. Environments like this are most likely + enterprise environments where the local administration chooses to + have per host configuration control. + + Note: the observation section is based on what the proponents of + each approach think makes a good overall solution. + +3.2 DHCPv6 Option + + DHCPv6 [5] includes the "DNS Recursive Name Server" option, through + which a host can obtain a list of IP addresses of recursive DNS + servers [7]. The DNS Recursive Name Server option carries a list + of IPv6 addresses of RDNSSes to which the host may send DNS queries. + The DNS servers are listed in the order of preference for use by + the DNS resolver on the host. + + The DNS Recursive Name Server option can be carried in any DHCPv6 + Reply message, in response to either a Request or an Information- + request message. Thus, the DNS Recursive Name Server option can be + used either when DHCPv6 is used for address assignment, or when + DHCPv6 is used only for other configuration information as + stateless DHCPv6 [6]. + + Stateless DHCPv6 can be deployed either using DHCPv6 servers + running on general-purpose computers, or on router hardware. + Several router vendors currently implement stateless DHCPv6 servers. + Deploying stateless DHCPv6 in routers has the advantage that no + special hardware is required, and should work well for networks + where DHCPv6 is needed for very straightforward configuration of + network devices. + + However, routers can also act as DHCPv6 relay agents. In this case, + the DHCPv6 server need not be on the router - it can be on a + general purpose computer. This has the potential to give the + + +Jeong, et al. Expires - January 2005 [Page 6] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + operator of the DHCPv6 server more flexibility in how the DHCPv6 + server responds to individual clients - clients can easily be given + different configuration information based on their identity, or for + any other reason. Nothing precludes adding this flexibility to a + router, but generally in current practice, DHCP servers running on + general-purpose hosts tend to have more configuration options than + those that are embedded in routers. + + DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 + clients that use stateful configuration assignment. To do this, + the DHCPv6 server sends a Reconfigure message to the client. The + client validates the Reconfigure message, and then contacts the + DHCPv6 server to obtain updated configuration information. Using + this mechanism, it is currently possible to propagate new + configuration information to DHCPv6 clients as this information + changes. + + The DHC Working Group is currently studying an additional mechanism + through which configuration information, including the list of + RDNSSes, can be updated. The Lifetime Option for DHCPv6 [10], + assigns a lifetime to configuration information obtained through + DHCPv6. At the expiration of the lifetime, the host contacts the + DHCPv6 server to obtain updated configuration information, + including the list of RDNSSes. This lifetime gives the network + administrator another mechanism to configure hosts with new RDNSSes + by controlling the time at which the host refreshes the list. + + The DHC Working Group has also discussed the possibility of + defining an extension to DHCPv6 that would allow the use of + multicast to provide configuration information to multiple hosts + with a single DHCPv6 message. Because of the lack of deployment + experience, the WG has deferred consideration of multicast DHCPv6 + configuration at this time. Experience with DHCPv4 has not + identified a requirement for multicast message delivery, even in + large service provider networks with tens of thousands of hosts + that may initiate a DHCPv4 message exchange simultaneously. + +3.2.1 Advantages + + The DHCPv6 option for RDNSS has a number of advantages. These + include: + + 1) DHCPv6 currently provides a general mechanism for conveying + network configuration information to clients. So configuring + DHCPv6 servers allows the network administrator to configure + RDNSSes along with the addresses of other network services, as well + as location-specific information like time zones. + + + +Jeong, et al. Expires - January 2005 [Page 7] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + 2) As a consequence, when the network administrator goes to + configure DHCPv6, all the configuration information can be managed + through a single service, typically with a single user interface + and a single configuration database. + + 3) DHCPv6 allows for the configuration of a host with information + specific to that host, so that hosts on the same link can be + configured with different RDNSSes as well as other configuration + information. This capability is important in some network + deployments such as service provider networks or WiFi hot spots. + + 4) A mechanism exists for extending DHCPv6 to support the + transmission of additional configuration that has not yet been + anticipated. + + 5) Hosts that require other configuration information such as the + addresses of SIP servers and NTP servers are likely to need DHCPv6 + for other configuration information. + + 6) The specification for configuration of RDNSSes through DHCPv6 is + available as an RFC. No new protocol extensions such as new + options are necessary. + + 7) Interoperability among independent implementations has been + demonstrated. + +3.2.2 Disadvantages + + The DHCPv6 option for RDNSS has a few disadvantages. These + include: + + 1) Update currently requires message from server (however, see + [10]). + + 2) Because DNS information is not contained in RA message, the host + must receive two messages from the router, and must transmit at + least one message to the router. On networks where bandwidth is at + a premium, this is a disadvantage, although on most networks it is + not a practical concern. + + 3) Increased latency for initial configuration - in addition to + waiting for an RA message, the client must now exchange packets + with a DHCPv6 server; even if it is locally installed on a router, + this will slightly extend the time required to configure the client. + For clients that are moving rapidly from one network to another, + this will be a disadvantage. + + + + +Jeong, et al. Expires - January 2005 [Page 8] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + +3.2.3 Observations + + In the general case, on general-purpose networks, stateless DHCPv6 + provides significant advantages and no significant disadvantages. + Even in the case where bandwidth is at a premium and low latency is + desired, if hosts require other configuration information in + addition to a list of RDNSSes or if hosts must be configured + selectively, those hosts will use DHCPv6 and the use of the DHCPv6 + DNS recursive name server option will be advantageous. + + However, we are aware of some applications where it would be + preferable to put the RDNSS information into an RA packet; for + example, on a cell phone network, where bandwidth is at a premium + and extremely low latency is desired. The final DNS configuration + draft should be written so as to allow these special applications + to be handled using DNS information in the RA packet. + +3.3 Well-known Anycast Addresses + + First of all, the well-known anycast addresses approach is much + different from that discussed in IPv6 Working Group in the past. + + The approach with well-known anycast addresses is to set well-known + anycast addresses in clients' resolver configuration files from the + beginning, say, as factory default. Thus, there is no transport + mechanism and no packet format [9]. + + An anycast address is an address shared by multiple servers (in + this case, the servers are RDNSSes). Request from a client to the + anycast address is routed to a server selected by the routing + system. However, it is a bad idea to mandate "site" boundary on + anycast addresses, because most users just do not have their own + servers and want to access their ISPs' across their site boundaries. + Larger sites may also depend on their ISPs or may have their own + RDNSSes within "site" boundaries. + + It should be noted that "anycast" in this memo is simpler than that + of RFC1546 [11] and RFC3513 [12] where it is assumed to be + prohibited to have multiple servers on a single link sharing an + anycast address. That is, on a link, anycast address is assumed to + be unique. DNS clients today already have redundancy by having + multiple well-known anycast addresses configured as RDNSS addresses. + There is no point to have multiple RDNSSes sharing an anycast + address on a single link. + +3.3.1 Advantages + + + + +Jeong, et al. Expires - January 2005 [Page 9] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + The basic advantage of the well-known addresses approach is that it + uses no transport mechanism. Thus, + 1) There is no delay to get response and no further delay by packet + losses. + + 2) The approach can be combined with any other configuration + mechanisms including but not limited to factory default + configuration, RA-based approach and DHCP based approach. + + 3) The approach works over any environment where DNS works. + + Another advantage is that the approach needs to configure DNS + servers as a router, but nothing else. Considering that DNS + servers do need configuration, the amount of overall configuration + effort is proportional to the number of the DNS servers and scales + linearly. It should be noted that, in the simplest case where a + subscriber to an ISP does not have any DNS server, the subscriber + naturally access DNS servers of the ISP even though the subscriber + and the ISP do nothing and there is no protocol to exchange DNS + server information between the subscriber and the ISP. + +3.3.2 Disadvantages + + Well-known anycast addresses approach requires that DNS servers (or + routers near it as a proxy) act as routers to advertise their + anycast addresses to the routing system, which requires some + configuration (see the last paragraph of the previous section on + the scalability of the effort). + +3.3.3 Observations + + If other approaches are used in addition, the well-known anycast + addresses should also be set in RA or DHCP configuration files to + reduce configuration effort of users. + + Redundancy by multiple RDNSSes is better provided by multiple + servers having different anycast addresses than multiple servers + sharing same anycast address because the former approach allows + stale servers to still generate routes to their anycast addresses. + Thus, in a routing domain (or domains sharing DNS servers), there + will be only one server having an anycast address unless the domain + is so large that load distribution is necessary. + + Small ISPs will operate one RDNSS at each anycast address which is + shared by all the subscribers. Large ISPs may operate multiple + RDNSSes at each anycast address to distribute and reduce load, + where boundary between RDNSSes may be fixed (redundancy is still + provided by multiple addresses) or change dynamically. DNS packets + + +Jeong, et al. Expires - January 2005 [Page 10] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + with the well-known anycast addresses are not expected (though not + prohibited) to cross ISP boundaries, as ISPs are expected to be + able to take care of themselves. + + Because "anycast" in this memo is simpler than that of RFC1546 [11] + and RFC3513 [12] where it is assumed to be administratively + prohibited to have multiple servers on a single link sharing an + anycast address, anycast in this memo should be implemented as + UNICAST of RFC2461 [3] and RFC3513 [12]. As a result, ND-related + instability disappears. Thus, anycast in well-known anycast + addresses approach can and should use the anycast address as a + source unicast (according to RFC3513 [12]) address of packets of + UDP and TCP responses. With TCP, if route flips and packets to an + anycast address are routed to a new server, it is expected that the + flip is detected by ICMP or sequence number inconsistency and the + TCP connection is reset and retried. + +4. Interworking among IPv6 DNS Configuration Approaches + + Three approaches can work together for IPv6 host configuration of + RDNSS. This section shows a consideration on how these approaches + can interwork each other. + + For ordering between RA and DHCP approaches, O (Other stateful + configuration) flag in RA message can be used [8]. If no RDNSS + option is included, an IPv6 Host may perform DNS configuration + through DHCPv6 [5]-[7] regardless of whether the O flag is set or + not. + + The well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove + configuration effort on servers by using the well-known addresses + as the default configuration. Moreover, clients preconfigured with + well-known anycast addresses can be further configured to use other + approaches to override the well-known addresses, if configuration + information from other approaches are available. That is, all the + clients should have the well-known anycast addresses preconfigured, + in the case where there are no other mechanisms available. In + order to fly anycast approach with the other solutions, there are + three options. + + The first option is that well-known addresses are used as last + resort, when an IPv6 host can not get RDNSS information through RA + and DHCP. The well-known anycast addresses have to be pre- + configured in IPv6 hosts' resolver configuration files. + + + + + +Jeong, et al. Expires - January 2005 [Page 11] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + The second is that an IPv6 host can configure well-known addresses + as the most preferable in its configuration file even though either + RA option or DHCP option is available. + + The last is that the well-known anycast addresses can be set in RA + or DHCP configuration to reduce configuration effort of users. + According to either RA or DHCP mechanism, the well-known addresses + can be obtained by IPv6 host. Because this approach is the most + convenient for users, the last option is recommended. + + Note: this section does not necessarily mean this document suggests + adopting all these three approaches and making them interwork in + the way described here. In fact, some approaches may even not be + adopted at all as a result of further discussion. + +5. Deployment Scenarios + + Regarding DNS configuration on the IPv6 host, several mechanisms + have being considered at the DNSOP Working Group such as RA option, + DHCPv6 option and well-known preconfigured anycast addresses as of + today, and this document is a final result from the long thread. + In this section, we suggest four applicable scenarios of three + approaches for IPv6 DNS configuration. + + Note: in the applicable scenarios, authors do not implicitly push + any specific approaches into the restricted environments. No + enforcement is in each scenario and all mentioned scenarios are + probable. The main objective of this work is to provide a useful + guideline of IPv6 DNS configuration. + +5.1 ISP Network + + A characteristic of ISP network is that multiple Customer Premises + Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) + routers and each PE connects multiple CPE devices to the backbone + network infrastructure [13]. The CPEs may be hosts or routers. + + In the case where the CPE is a router, there is a customer network + that is connected to the ISP backbone through the CPE. Typically, + each customer network gets a different IPv6 prefix from an IPv6 PE + router, but the same RDNSS configuration will be distributed. + + This section discusses how the different approaches to distributing + DNS information are compared in an ISP network. + +5.1.1 RA Option Approach + + + + +Jeong, et al. Expires - January 2005 [Page 12] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + When the CPE is a host, the RA option for RDNSS can be used to + allow the CPE to get RDNSS information as well as /64 prefix + information for stateless address autoconfiguration at the same + time when the host is attached to a new subnet [8]. Because an + IPv6 host must receive at least one RA message for stateless + address autoconfiguration and router configuration, the host could + receive RDNSS configuration information in that RA without the + overhead of an additional message exchange. + + When the CPE is a router, the CPE may accept the RDNSS information + from the RA on the interface connected to the ISP, and copy that + information into the RAs advertised in the customer network. + + This approach is more valuable in the mobile host scenario, in + which the host must receive at least an RA message for detecting a + new network, than in other scenarios generally although + administrator should configure RDNSS information on the routers. + Secure ND [14] can provide extended security when using RA message. + +5.1.2 DHCPv6 Option Approach + + DHCPv6 can be used for RDNSS configuration through the use of the + DNS option, and can provide other configuration information in the + same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option + is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6- + lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6 + implementation. DHCP is a client-server model protocol, so ISP can + handle user identification on its network intentionally, and also + authenticated DHCP [15] can be used for secure message exchange. + + The expected model for deployment of IPv6 service by ISPs is to + assign a prefix to each customer, which will be used by the + customer gateway to assign a /64 prefix to each network in the + customer's network. Prefix delegation with DHCP (DHCPv6 PD) has + already been adopted by ISPs for automating the assignment of the + customer prefix to the customer gateway [17]. DNS configuration + can be carried in the same DHCPv6 message exchange used for DHCPv6 + to efficiently provide that information, along with any other + configuration information needed by the customer gateway or + customer network. This service model can be useful to Home or SOHO + subscribers. The Home or SOHO gateway, which is a customer gateway + for ISP, can then pass that RDNSS configuration information to the + hosts in the customer network through DHCP. + +5.1.3 Well-known Addresses Approach + + Well-known anycast addresses approach is also a feasible and simple + mechanism for ISP [9]. The use of well-known anycast addresses + + +Jeong, et al. Expires - January 2005 [Page 13] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + avoids some of the security risks in rogue messages sent through an + external protocol like RA or DHCPv6. The configuration of hosts + for the use of well-known anycast addresses requires no protocol or + manual configuration, but the configuration of routing for the + anycast addresses requires intervention on the part of the network + administrator. Also, the number of special addresses would be + equal to the number of RDNSSes that could be made available to + subscribers. + +5.2 Enterprise Network + + Enterprise network is defined as a network that has multiple + internal links, one or more router connections, to one or more + Providers and is actively managed by a network operations entity + [16]. An enterprise network can get network prefixes from ISP by + either manual configuration or prefix delegation [17]. In most + cases, because an enterprise network manages its own DNS domains, + it operates its own DNS servers for the domains. These DNS servers + within enterprise network process recursive DNS name resolution + requests of IPv6 hosts as RDNSS. RDNSS configuration in enterprise + network can be performed like in Section 4, in which three + approaches can be used together. + + IPv6 host can decide which approach is or may be used in its subnet + with O flag in RA message [8]. As the first option in Section 4, + well-known anycast addresses can be used as a last resort when + RDNSS information can not be obtained through either RA option or + DHCP option. This case needs IPv6 hosts to preconfigure the well- + known anycast addresses in their DNS configuration files. + + When the enterprise prefers well-known anycast approach to the + others, IPv6 hosts should preconfigure the well-known anycast + addresses like in the first option. + + The last option, a more convenient and transparent way, does not + need IPv6 hosts to preconfigure the well-known anycast addresses + because the addresses are delivered to IPv6 hosts through either RA + option or DHCPv6 option as if they were unicast addresses. This + way is most recommended for the sake of user's convenience. + +5.3 3GPP Network + + IPv6 DNS configuration is a missing part of IPv6 autoconfiguration + and an important part of the basic IPv6 functionality in the 3GPP + User Equipment (UE). Higher level description of the 3GPP + architecture can be found in [18], and transition to IPv6 in 3GPP + networks is analyzed in [19] and [20]. + + + +Jeong, et al. Expires - January 2005 [Page 14] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + In 3GPP architecture, there is a dedicated link between the UE and + the GGSN called the Packet Data Protocol (PDP) Context. This link + is created through the PDP Context activation procedure [21]. + There is a separate PDP context type for IPv4 and IPv6 traffic. If + a 3GPP UE user is communicating using IPv6 (having an active IPv6 + PDP context), it can not be assumed that (s)he has simultaneously + active IPv4 PDP context, and DNS queries could be done using IPv4. + A 3GPP UE can thus be an IPv6 node, and it needs to somehow + discover the address of the RDNSS. Before IP-based services (e.g., + web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS + addresses need to be discovered in the 3GPP UE. + + Section 5.3.1 briefly summarizes currently available mechanisms in + 3GPP networks and recommendations. 5.3.2 analyzes the Router + Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 + mechanism, and 5.3.4 analyzes the Well-known addresses approach. + Section 5.3.5 finally summarizes the recommendations. + +5.3.1 Currently Available Mechanisms and Recommendations + + 3GPP has defined a mechanism, in which RDNSS addresses can be + received in the PDP context activation (a control plane mechanism). + That is called the Protocol Configuration Options Information + Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be + received over the air (using text messages), or typed in manually + in the UE. Note that the two last mechanisms are not very well + scalable. The UE user most probably does not want to type IPv6 + RDNSS addresses manually in his/her UE. The use of well-known + addresses is briefly discussed in section 5.3.4. + + It is seen that the mechanisms above most probably are not + sufficient for the 3GPP environment. IPv6 is intended to operate + in a zero-configuration manner, no matter what the underlying + network infrastructure is. Typically, the RDNSS address is needed + to make an IPv6 node operational - and the DNS configuration should + be as simple as the address autoconfiguration mechanism. It must + also be noted that there will be additional IP interfaces in some + near future 3GPP UEs, e.g., Wireless LAN (WLAN), and 3GPP-specific + DNS configuration mechanisms (such as PCO-IE [22]) do not work for + those IP interfaces. In other words, a good IPv6 DNS configuration + mechanism should also work in a multi-access network environment. + + From 3GPP point of view, the best IPv6 DNS configuration solution + is feasible for a very large number of IPv6-capable UEs (can be + even hundreds of millions in one operator's network), is automatic + and thus requires no user action. It is suggested to standardize a + lightweight, stateless mechanism that works in all network + environments. The solution could then be used for 3GPP, 3GPP2, + + +Jeong, et al. Expires - January 2005 [Page 15] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + WLAN and other access network technologies. A light, stateless + IPv6 DNS configuration mechanism is thus not only needed in 3GPP + networks, but also 3GPP networks and UEs would certainly benefit + from the new mechanism. + +5.3.2 RA Extension + + Router Advertisement extension [8] is a lightweight IPv6 DNS + configuration mechanism that requires minor changes in 3GPP UE IPv6 + stack and Gateway GPRS Support Node (GGSN, the default router in + the 3GPP architecture) IPv6 stack. This solution can be specified + in the IETF (no action needed in the 3GPP) and taken in use in 3GPP + UEs and GGSNs. + + In this solution, an IPv6-capable UE configures DNS information + via RA message sent by its default router (GGSN), i.e., RDNSS + option for recursive DNS server is included in the RA message. + This solution is easily scalable for a very large number of UEs. + The operator can configure the RDNSS addresses in the GGSN as a + part of normal GGSN configuration. The IPv6 RDNSS address is + received in the Router Advertisement, and an extra Round Trip Time + (RTT) for asking RDNSS addresses can be avoided. + + If thinking about cons, this mechanism still requires + standardization effort in the IETF, and the end nodes and routers + need to support this mechanism. The equipment software update + should, however, be pretty straightforward, and new IPv6 equipment + could support RA extension already from the beginning. + +5.3.3 Stateless DHCPv6 + + DHCPv6-based solution needs the implementation of Stateless DHCP + [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in + the operator's network. A possible configuration is such that the + GGSN works as a DHCP relay. + + Pros for Stateless DHCPv6-based solution are + 1) Stateless DHCPv6 is a standardized mechanism. + + 2) DHCPv6 can be used for receiving other configuration information + than RDNSS addresses, e.g., SIP server addresses. + + 3) DHCPv6 works in different network environments. + + 4) When DHCPv6 service is deployed through a single, centralized + server, the RDNSS configuration information can be updated by the + network administrator at a single source. + + + +Jeong, et al. Expires - January 2005 [Page 16] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + Some issues with DHCPv6 in 3GPP networks are listed below: + 1) DHCPv6 requires an additional server in the network unless the + (Stateless) DHCPv6 functionality is integrated into an existing + router already, and it is one box more to be maintained. + + 2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing + (3GPP Stateless Address Autoconfiguration is typically used), and + not automatically implemented in 3GPP IPv6 UEs. + + 3) Scalability and reliability of DHCPv6 in very large 3GPP + networks (with tens or hundreds of millions of UEs) may be an issue, + at least the redundancy needs to be taken care of. However, if the + DHCPv6 service is integrated into the network elements, such as + router operating system, scalability and reliability is comparable + with other DNS configuration approaches. + + 4) It is sub-optimal to utilize the radio resources in 3GPP + networks for DHCPv6 messages if there is a simpler alternative + available. + + a) Use of Stateless DHCPv6 adds one round trip delay to the case + in which the UE can start transmitting data right after the + Router Advertisement. + + 5) If the DNS information (suddenly) changes, Stateless DHCPv6 can + not automatically update the UE, see [23]. + +5.3.4 Well-known Addresses + + Using well-known addresses is also a feasible and a light mechanism + for 3GPP UEs. Those well-known addresses can be preconfigured in + the UE software and the operator makes the corresponding + configuration on the network side. So this is a very easy + mechanism for the UE, but requires some configuration work in the + network. When using well-known addresses, UE forwards queries to + any of the preconfigured addresses. In the current proposal [9], + IPv6 anycast addresses are suggested. + + Note: IPv6 DNS configuration proposal based on the use of well- + known site-local addresses developed at the IPv6 Working Group was + seen as a feasible mechanism for 3GPP UEs, but opposition by some + people in the IETF and finally deprecating IPv6 site-local + addresses made it impossible to standardize it. Note that this + mechanism is implemented in some existing operating systems today + (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration. + +5.3.5 Recommendations + + + +Jeong, et al. Expires - January 2005 [Page 17] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + It is suggested that a lightweight, stateless DNS configuration + mechanism is specified as soon as possible. From 3GPP UE's and + networks' point of view, Router Advertisement based mechanism looks + most promising. The sooner a light, stateless mechanism is + specified, the sooner we can get rid of using well-known site-local + addresses for IPv6 DNS configuration. + +5.4 Unmanaged Network + + There are 4 deployment scenarios of interest in unmanaged networks + [24]: + + 1) A gateway which does not provide IPv6 at all; + + 2) A dual-stack gateway connected to a dual-stack ISP; + + 3) A dual-stack gateway connected to an IPv4-only ISP; and + + 4) A gateway connected to an IPv6-only ISP. + +5.4.1 Case A: Gateway does not provide IPv6 at all + + In this case, the gateway does not provide IPv6; the ISP may or may + not provide IPv6. Automatic or Configured tunnels are the + recommended transition mechanisms for this scenario. + + The case where dual-stack hosts behind an NAT, that need access to + an IPv6 RDNSS, can not be entirely ruled out. The DNS + configuration mechanism has to work over the tunnel, and the + underlying tunneling mechanism could be implementing NAT traversal. + The tunnel server assumes the role of a relay (both for DHCP and + Well-known anycast addresses approaches). + + RA-based mechanism is relatively straightforward in its operation, + assuming the tunnel server is also the IPv6 router emitting RAs. + Well-known anycast addresses approach seems also simple in + operation across the tunnel, but the deployment model using Well- + known anycast addresses in a tunneled environment is unclear or not + well understood. + +5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP + + This is similar to a typical IPv4 home user scenario, where DNS + configuration parameters are obtained using DHCP. Except that + Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the + DHCP server is stateful (maintains the state for clients). + + + + +Jeong, et al. Expires - January 2005 [Page 18] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + +5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP + + This is similar to Case B. If a gateway provides IPv6 connectivity + by managing tunnels, then it is also supposed to provide access to + an RDNSS. Like this, the tunnel for IPv6 connectivity originates + from the dual-stack gateway instead of the host. + +5.4.4 Case D: A gateway connected to an IPv6-only ISP + + This is similar to Case B. + +6. Security Considerations + + As security requirements depend solely on applications and are + different application by application, there can be no generic + requirement defined at higher IP or lower application layer of DNS. + + However, it should be noted that cryptographic security requires + configured secret information that full autoconfiguration and + cryptographic security are mutually exclusive. People insisting on + secure full autoconfiguration will get false security, false + autoconfiguration or both. + + In some deployment scenario [19], where cryptographic security is + required for applications, secret information for the cryptographic + security is preconfigured through which application specific + configuration data, including those for DNS, can be securely + configured. It should be noted that if applications requiring + cryptographic security depend on DNS, the applications also require + cryptographic security to DNS. Therefore, the full auto- + configuration of DNS is not acceptable. + + However, with full autoconfiguration, weaker but still reasonable + security is being widely accepted and will continue to be + acceptable. That is, with full autoconfiguration, which means + there is no cryptographic security for the autoconfiguration, it is + already assumed that local environment is secure enough that + information from local autoconfiguration server has acceptable + security even without cryptographic security. Thus, communication + between a local DNS client and a local DNS server has the + acceptable security. + + For security considerations of each approach, refer to the + corresponding drafts [5]-[9]. + +7. Acknowledgements + + + + +Jeong, et al. Expires - January 2005 [Page 19] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + This draft has greatly benefited from inputs by David Meyer, Rob + Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, + Christian Huitema, and Thomas Narten. The authors appreciate their + contribution. + +8. Normative References + + [1] S. Bradner, "Intellectual Property Rights in IETF Technology", + RFC 3668, February 2004. + + [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February + 2004. + + [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for + IP Version 6 (IPv6)", RFC 2461, December 1998. + + [4] S. Thomson and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [6] R. Droms, "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + [7] R. Droms et al., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December + 2003. + +9. Informative References + + [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS + Discovery based on Router Advertisement", draft-jeong-dnsop- + ipv6-dns-discovery-02.txt, July 2004. + + [9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta- + preconfigured-dns-01.txt, February 2004. + + [10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft- + ietf-dhc-lifetime-00.txt, March 2004. + + [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + + + +Jeong, et al. Expires - January 2005 [Page 20] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6 + into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis- + 02.txt, April 2004. + + [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft- + ietf-send-ndopt-05.txt, April 2004. + + [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft- + ietf-v6ops-ent-scenarios-01.txt, February 2004. + + [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, December + 2003. + + [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP + Standards", RFC 3314, September 2002. + + [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks", + RFC 3574, August 2003. + + [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP + Networks", draft-ietf-v6ops-3gpp-analysis-09.txt, March 2004. + + [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); + Service description; Stage 2 (Release 5)", December 2002. + + [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 + specification; Core network protocols; Stage 3 (Release 5)", + June 2003. + + [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering + Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless- + dhcpv6-renumbering-00.txt, March 2004. + + [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition + Scenarios", RFC 3750, April 2004. + +10. Authors' Addresses + + Jaehoon Paul Jeong, Editor + ETRI / PEC + 161 Gajeong-dong, Yuseong-gu + Daejeon 305-350 + Korea + + + +Jeong, et al. Expires - January 2005 [Page 21] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + Phone: +82 42 860 1664 + Fax: +82 42 861 5404 + EMail: paul@etri.re.kr + + Ralph Droms + Cisco Systems + 1414 Massachusetts Ave. + Boxboro, MA 01719 + USA + + Phone: +1 978 936 1674 + EMail: rdroms@cisco.com + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + USA + + Phone: +1 650 625 2004 + EMail: bob.hinden@nokia.com + + Ted Lemon + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94043 + USA + + EMail: Ted.Lemon@nominum.com + + Masataka Ohta + Graduate School of Information Science and Engineering + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku + Tokyo 152-8552 + Japan + + Phone: +81 3 5734 3299 + Fax: +81 3 5734 3299 + EMail: mohta@necom830.hpcl.titech.ac.jp + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics + 416, Maetan-3dong, Paldal-gu, Suwon + Gyeonggi-Do + Korea + + Phone: +82 31 200 4508 + + +Jeong, et al. Expires - January 2005 [Page 22] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + EMail: soohong.park@samsung.com + + Suresh Satapati + Cisco Systems, Inc. + San Jose, CA 95134 + USA + + EMail: satapati@cisco.com + + Juha Wiljakka + Nokia + Visiokatu 3 + FIN-33720 TAMPERE + Finland + + Phone: +358 7180 48372 + EMail: juha.wiljakka@nokia.com + +Intellectual Property Statement + + The following intellectual property notice is copied from RFC3668, + Section 5. + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; nor does it represent that + it has made any independent effort to identify any such rights. + Information on the procedures with respect to rights in RFC + documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Full Copyright Statement + + + + +Jeong, et al. Expires - January 2005 [Page 23] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + The following copyright notice is copied from RFC3667, Section 5.4. + It describes the applicable copyright for this document. + + Copyright (C) The Internet Society (2004). This document is + subject to the rights, licenses and restrictions contained in BCP + 78, and except as set forth therein, the authors retain all their + rights. + + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong, et al. Expires - January 2005 [Page 24] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt new file mode 100644 index 000000000000..b14f711d5314 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt @@ -0,0 +1,1969 @@ + + +DNS Operations WG A. Durand +Internet-Draft SUN Microsystems, Inc. +Expires: February 7, 2005 J. Ihren + Autonomica + P. Savola + CSC/FUNET + August 9, 2004 + + + + Operational Considerations and Issues with IPv6 DNS + draft-ietf-dnsop-ipv6-dns-issues-09.txt + + +Status of this Memo + + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + This Internet-Draft will expire on February 7, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + +Abstract + + + This memo presents operational considerations and issues with IPv6 + Domain Name System (DNS), including a summary of special IPv6 + addresses, documentation of known DNS implementation misbehaviour, + recommendations and considerations on how to perform DNS naming for + + + + +Durand, et al. Expires February 7, 2005 [Page 1] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + service provisioning and for DNS resolver IPv6 support, + considerations for DNS updates for both the forward and reverse + trees, and miscellaneous issues. This memo is aimed to include a + summary of information about IPv6 DNS considerations for those who + have experience with IPv4 DNS. + + +Table of Contents + + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 + 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 + 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 + 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 + 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 + 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 + 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 + 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 + 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 + 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 + 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 + 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 + 4. Recommendations for Service Provisioning using DNS . . . . . . 8 + 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 + 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 + 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 + 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 + 4.4.1 Description of Additional Data Scenarios . . . . . . . 10 + 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11 + 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12 + 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13 + 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13 + 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14 + 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15 + 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16 + 6. Considerations about Forward DNS Updating . . . . . . . . . . 16 + 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 + 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17 + 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18 + 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18 + 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19 + 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19 + 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20 + 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21 + 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22 + 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22 + 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 + + + + +Durand, et al. Expires February 7, 2005 [Page 2] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 + A. Site-local Addressing Considerations for DNS . . . . . . . . . 28 + B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28 + Intellectual Property and Copyright Statements . . . . . . . . 30 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires February 7, 2005 [Page 3] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + +1. Introduction + + + This memo presents operational considerations and issues with IPv6 + DNS; it is meant to be an extensive summary and a list of pointers + for more information about IPv6 DNS considerations for those with + experience with IPv4 DNS. + + + The purpose of this document is to give information about various + issues and considerations related to DNS operations with IPv6; it is + not meant to be a normative specification or standard for IPv6 DNS. + + + The first section gives a brief overview of how IPv6 addresses and + names are represented in the DNS, how transport protocols and + resource records (don't) relate, and what IPv4/IPv6 name space + fragmentation means and how to avoid it; all of these are described + at more length in other documents. + + + The second section summarizes the special IPv6 address types and how + they relate to DNS. The third section describes observed DNS + implementation misbehaviours which have a varying effect on the use + of IPv6 records with DNS. The fourth section lists recommendations + and considerations for provisioning services with DNS. The fifth + section in turn looks at recommendations and considerations about + providing IPv6 support in the resolvers. The sixth and seventh + sections describe considerations with forward and reverse DNS + updates, respectively. The eighth section introduces several + miscellaneous IPv6 issues relating to DNS for which no better place + has been found in this memo. Appendix A looks briefly at the + requirements for site-local addressing. + + +1.1 Representing IPv6 Addresses in DNS Records + + + In the forward zones, IPv6 addresses are represented using AAAA + records. In the reverse zones, IPv6 address are represented using + PTR records in the nibble format under the ip6.arpa. tree. See + [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] + for background information. + + + In particular one should note that the use of A6 records in the + forward tree or Bitlabels in the reverse tree is not recommended + [RFC3363]. Using DNAME records is not recommended in the reverse + tree in conjunction with A6 records; the document did not mean to + take a stance on any other use of DNAME records [RFC3364]. + + +1.2 Independence of DNS Transport and DNS Records + + + DNS has been designed to present a single, globally unique name space + [RFC2826]. This property should be maintained, as described here and + + + + +Durand, et al. Expires February 7, 2005 [Page 4] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + in Section 1.3. + + + The IP version used to transport the DNS queries and responses is + independent of the records being queried: AAAA records can be queried + over IPv4, and A records over IPv6. The DNS servers must not make + any assumptions about what data to return for Answer and Authority + sections based on the underlying transport used in a query. + + + However, there is some debate whether the addresses in Additional + section could be selected or filtered using hints obtained from which + transport was being used; this has some obvious problems because in + many cases the transport protocol does not correlate with the + requests, and because a "bad" answer is in a way worse than no answer + at all (consider the case where the client is led to believe that a + name received in the additional record does not have any AAAA records + at all). + + + As stated in [RFC3596]: + + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + + +1.3 Avoiding IPv4/IPv6 Name Space Fragmentation + + + To avoid the DNS name space from fragmenting into parts where some + parts of DNS are only visible using IPv4 (or IPv6) transport, the + recommendation is to always keep at least one authoritative server + IPv4-enabled, and to ensure that recursive DNS servers support IPv4. + See DNS IPv6 transport guidelines + [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information. + + +1.4 Query Type '*' and A/AAAA Records + + + QTYPE=* is typically only used for debugging or management purposes; + it is worth keeping in mind that QTYPE=* ("ANY" queries) only return + any available RRsets, not *all* the RRsets, because the caches do not + necessarily have all the RRsets and have no way of guaranteeing that + they have all the RRsets. Therefore, to get both A and AAAA records + reliably, two separate queries must be made. + + +2. DNS Considerations about Special IPv6 Addresses + + + There are a couple of IPv6 address types which are somewhat special; + these are considered here. + + + + + + +Durand, et al. Expires February 7, 2005 [Page 5] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + +2.1 Limited-scope Addresses + + + The IPv6 addressing architecture [RFC3513] includes two kinds of + local-use addresses: link-local (fe80::/10) and site-local (fec0::/ + 10). The site-local addresses have been deprecated + [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in + Appendix A. + + + Link-local addresses should never be published in DNS (whether in + forward or reverse tree), because they have only local (to the + connected link) significance + [I-D.ietf-dnsop-dontpublish-unreachable]. + + +2.2 Temporary Addresses + + + Temporary addresses defined in RFC3041 [RFC3041] (sometimes called + "privacy addresses") use a random number as the interface identifier. + Publishing (useful) DNS records relating to such addresses would + defeat the purpose of the mechanism and is not recommended. However, + it would still be possible to return a non-identifiable name (e.g., + the IPv6 address in hexadecimal format), as described in [RFC3041]. + + +2.3 6to4 Addresses + + + 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps + a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. + + + If the reverse DNS population would be desirable (see Section 7.1 for + applicability), there are a number of possible ways to do so + [I-D.moore-6to4-dns], some more applicable than the others. + + + The main proposal [I-D.huston-6to4-reverse-dns] aims to design an + autonomous reverse-delegation system that anyone being capable of + communicating using a specific 6to4 address would be able to set up a + reverse delegation to the corresponding 6to4 prefix. This could be + deployed by e.g., Regional Internet Registries (RIRs). This is a + practical solution, but may have some scalability concerns. + + +2.4 Other Transition Mechanisms + + + 6to4, above, is mentioned as a case of an IPv6 transition mechanism + requiring special considerations. In general, mechanisms which + include a special prefix may need a custom solution; otherwise, for + example when IPv4 address is embedded as the suffix or not embedded + at all, special solutions are likely not needed. This is why only + 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described. + + + Note that it does not seem feasible to provide reverse DNS with + + + + +Durand, et al. Expires February 7, 2005 [Page 6] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + another automatic tunneling mechanism, Teredo; this is because the + IPv6 address is based on the IPv4 address and UDP port of the current + NAT mapping which is likely to be relatively short-lived. + + +3. Observed DNS Implementation Misbehaviour + + + Several classes of misbehaviour in DNS servers, load-balancers and + resolvers have been observed. Most of these are rather generic, not + only applicable to IPv6 -- but in some cases, the consequences of + this misbehaviour are extremely severe in IPv6 environments and + deserve to be mentioned. + + +3.1 Misbehaviour of DNS Servers and Load-balancers + + + There are several classes of misbehaviour in certain DNS servers and + load-balancers which have been noticed and documented + [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations + silently drop queries for unimplemented DNS records types, or provide + wrong answers to such queries (instead of a proper negative reply). + While typically these issues are not limited to AAAA records, the + problems are aggravated by the fact that AAAA records are being + queried instead of (mainly) A records. + + + The problems are serious because when looking up a DNS name, typical + getaddrinfo() implementations, with AF_UNSPEC hint given, first try + to query the AAAA records of the name, and after receiving a + response, query the A records. This is done in a serial fashion -- + if the first query is never responded to (instead of properly + returning a negative answer), significant timeouts will occur. + + + In consequence, this is an enormous problem for IPv6 deployments, and + in some cases, IPv6 support in the software has even been disabled + due to these problems. + + + The solution is to fix or retire those misbehaving implementations, + but that is likely not going to be effective. There are some + possible ways to mitigate the problem, e.g., by performing the + lookups somewhat in parallel and reducing the timeout as long as at + least one answer has been received; but such methods remain to be + investigated; slightly more on this is included in Section 5. + + +3.2 Misbehaviour of DNS Resolvers + + + Several classes of misbehaviour have also been noticed in DNS + resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem + to directly impair IPv6 use, and are only referred to for + completeness. + + + + + +Durand, et al. Expires February 7, 2005 [Page 7] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + +4. Recommendations for Service Provisioning using DNS + + + When names are added in the DNS to facilitate a service, there are + several general guidelines to consider to be able to do it as + smoothly as possible. + + +4.1 Use of Service Names instead of Node Names + + + When a node provides multiple services which should not be + fate-sharing, or might support different IP versions, one should keep + them logically separate in the DNS. Using SRV records [RFC2782] + would avoid these problems. Unfortunately, those are not + sufficiently widely used to be applicable in most cases. Hence an + operation technique is to use service names instead of node names + (or, "hostnames"). This operational technique is not specific to + IPv6, but required to understand the considerations described in + Section 4.2 and Section 4.3. + + + For example, assume a node named "pobox.example.com" provides both + SMTP and IMAP service. Instead of configuring the MX records to + point at "pobox.example.com", and configuring the mail clients to + look up the mail via IMAP from "pobox.example.com", one should use + e.g., "smtp.example.com" for SMTP (for both message submission and + mail relaying between SMTP servers) and "imap.example.com" for IMAP. + Note that in the specific case of SMTP relaying, the server itself + must typically also be configured to know all its names to ensure + loops do not occur. DNS can provide a layer of indirection between + service names and where the service actually is, and using which + addresses. (Obviously, when wanting to reach a specific node, one + should use the hostname rather than a service name.) + + + This is a good practice with IPv4 as well, because it provides more + flexibility and enables easier migration of services from one host to + another. A specific reason why this is relevant for IPv6 is that the + different services may have a different level of IPv6 support -- that + is, one node providing multiple services might want to enable just + one service to be IPv6-visible while keeping some others as + IPv4-only, improving flexibility. + + +4.2 Separate vs the Same Service Names for IPv4 and IPv6 + + + The service naming can be achieved in basically two ways: when a + service is named "service.example.com" for IPv4, the IPv6-enabled + service could be either added to "service.example.com", or added + separately under a different name, e.g., in a sub-domain, like, + "service.ipv6.example.com". + + + These two methods have different characteristics. Using a different + + + + +Durand, et al. Expires February 7, 2005 [Page 8] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + name allows for easier service piloting, minimizing the disturbance + to the "regular" users of IPv4 service; however, the service would + not be used transparently, without the user/application explicitly + finding it and asking for it -- which would be a disadvantage in most + cases. When the different name is under a sub-domain, if the + services are deployed within a restricted network (e.g., inside an + enterprise), it's possible to prefer them transparently, at least to + a degree, by modifying the DNS search path; however, this is a + suboptimal solution. Using the same service name is the "long-term" + solution, but may degrade performance for those clients whose IPv6 + performance is lower than IPv4, or does not work as well (see Section + 4.3 for more). + + + In most cases, it makes sense to pilot or test a service using + separate service names, and move to the use of the same name when + confident enough that the service level will not degrade for the + users unaware of IPv6. + + +4.3 Adding the Records Only when Fully IPv6-enabled + + + The recommendation is that AAAA records for a service should not be + added to the DNS until all of following are true: + + + 1. The address is assigned to the interface on the node. + + + 2. The address is configured on the interface. + + + 3. The interface is on a link which is connected to the IPv6 + infrastructure. + + + In addition, if the AAAA record is added for the node, instead of + service as recommended, all the services of the node should be + IPv6-enabled prior to adding the resource record. + + + For example, if an IPv6 node is isolated from an IPv6 perspective + (e.g., it is not connected to IPv6 Internet) constraint #3 would mean + that it should not have an address in the DNS. + + + Consider the case of two dual-stack nodes, which both have IPv6 + enabled, but the server does not have (global) IPv6 connectivity. As + the client looks up the server's name, only A records are returned + (if the recommendations above are followed), and no IPv6 + communication, which would have been unsuccessful, is even attempted. + + + The issues are not always so black-and-white. Usually it's important + if the service offered using both protocols is of roughly equal + quality, using the appropriate metrics for the service (e.g., + latency, throughput, low packet loss, general reliability, etc.) -- + + + + +Durand, et al. Expires February 7, 2005 [Page 9] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + this is typically very important especially for interactive or + real-time services. In many cases, the quality of IPv6 connectivity + may not yet be equal to that of IPv4, at least globally -- this has + to be taken into consideration when enabling services + [I-D.savola-v6ops-6bone-mess]. + + +4.4 Behaviour of Additional Data in IPv4/IPv6 Environments + + +4.4.1 Description of Additional Data Scenarios + + + Consider the case where the query name is so long, the number of the + additional records is so high, or for other reasons that the entire + response would not fit in a single UDP packet. In some cases, the + responder truncates the response with the TC bit being set (leading + to a retry with TCP), in order for the querier to get the entire + response later. + + + There are two kinds of additional data: + + + 1. glue, i.e., "critical" additional data; this must be included in + all scenarios, with all the RRsets as possible, and + + + 2. "courtesy" additional data; this could be sent in full, with only + a few RRsets, or with no RRsets, and can be fetched separately as + well, but at the cost of additional queries. This data must + never cause setting of the TC bit. + + + The responding server can algorithmically determine which type the + additional data is by checking whether it's at or below a zone cut. + + + Meanwhile, resource record sets (RRsets) are never "broken up", so if + a name has 4 A records and 5 AAAA records, you can either return all + 9, all 4 A records, all 5 AAAA records or nothing. In particular, + notice that for the "critical" additional data getting all the RRsets + can be critical. + + + An example of the "courtesy" additional data is A/AAAA records in + conjunction of MX records as shown in Section 4.5; an example of the + "critical" additional data is shown below (where getting both the A + and AAAA RRsets is critical): + + + child.example.com. IN NS ns.child.example.com. + ns.child.example.com. IN A 192.0.2.1 + ns.child.example.com. IN AAAA 2001:db8::1 + + + When there is too much courtesy additional data, some or all of it + need to be removed [RFC2181]; if some is left in the response, the + issue is which data should be retained. When there is too much + + + + +Durand, et al. Expires February 7, 2005 [Page 10] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + critical additional data, TC bit will have to be set, and some or all + of it need to be removed; if some is left in the response, the issue + is which data should be retained. + + + If the implementation decides to keep as much data as possible, it + might be tempting to use the transport of the DNS query as a hint in + either of these cases: return the AAAA records if the query was done + over IPv6, or return the A records if the query was done over IPv4. + However, this breaks the model of independence of DNS transport and + resource records, as noted in Section 1.2. + + + It is worth remembering that often the host using the records is + different from the node requesting them from the authoritative DNS + server (or even a caching resolver). So, whichever version the + requestor (e.g., a recursive server in the middle) uses makes no + difference to the ultimate user of the records, whose transport + capabilities might differ from those of the requestor. This might + result in e.g., inappropriately returning A records to an IPv6-only + node, going through a translation, or opening up another IP-level + session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). + Therefore, at least in many scenarios, it would be very useful if the + information returned would be consistent and complete -- or if that + is not feasible, return no misleading information but rather leave it + to the client to query again. + + +4.4.2 Discussion of the Problems + + + As noted above, the temptation for omitting only some of the + additional data based on the transport of the query could be + problematic. In particular, there appears to be little justification + for doing so in the case of "courtesy" data. + + + However, with critical additional data, the alternatives are either + returning nothing (and requiring a retry with TCP) or returning + something (possibly obviating the need for a retry with TCP). If the + process for selecting "something" from the critical data would + otherwise be practically "flipping the coin" between A and AAAA + records, it could be argued that if one looked at the transport of + the query, it would have a larger possibility of being right than + just 50/50. In other words, if the returned critical additional data + would have to be selected somehow, using something more sophisticated + than a random process would seem justifiable. + + + The problem of too much additional data seems to be an operational + one: the zone administrator entering too many records which will be + returned either truncated or missing some RRsets to the users. A + protocol fix for this is using EDNS0 [RFC2671] to signal the capacity + for larger UDP packet sizes, pushing up the relevant threshold. + + + + +Durand, et al. Expires February 7, 2005 [Page 11] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + Further, DNS server implementations should rather omit courtesy + additional data completely rather than including only some RRsets + [RFC2181]. An operational fix for this is having the DNS server + implementations return a warning when the administrators create zones + which would result in too much additional data being returned. + Further, DNS server implementations should warn of or disallow such + zone configurations which are recursive or otherwise difficult to + manage by the protocol. + + + Additionally, to avoid the case where an application would not get an + address at all due to some of "courtesy" additional data being + omitted, the resolvers should be able to query the specific records + of the desired protocol, not just rely on getting all the required + RRsets in the additional section. + + +4.5 The Use of TTL for IPv4 and IPv6 RRs + + + In the previous section, we discussed a danger with queries, + potentially leading to omitting RRsets from the additional section; + this could happen to both critical and "courtesy" additional data. + This section discusses another problem with the latter, leading to + omitting RRsets in cached data, highlighted in the IPv4/IPv6 + environment. + + + The behaviour of DNS caching when different TTL values are used for + different RRsets of the same name requires explicit discussion. For + example, let's consider a part of a zone: + + + example.com. 300 IN MX foo.example.com. + foo.example.com. 300 IN A 192.0.2.1 + foo.example.com. 100 IN AAAA 2001:db8::1 + + + When a caching resolver asks for the MX record of example.com, it + gets back "foo.example.com". It may also get back either one or both + of the A and AAAA records in the additional section. So, there are + three cases about returning records for the MX in the additional + section: + + + 1. We get back no A or AAAA RRsets: this is the simplest case, + because then we have to query which information is required + explicitly, guaranteeing that we get all the information we're + interested in. + + + 2. We get back all the RRsets: this is an optimization as there is + no need to perform more queries, causing lower latency. However, + it is impossible to guarantee that in fact we would always get + back all the records (the only way to ensure that is to send a + AAAA query for the name after getting the cached reply with A + + + + +Durand, et al. Expires February 7, 2005 [Page 12] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + records or vice versa). + + + 3. We only get back A or AAAA RRsets even if both existed: this is + indistinguishable from the previous case, and may have problems + at least in certain environments as described in the previous + section. + + + As the third case was considered in the previous section, we assume + we get back both A and AAAA records of foo.example.com, or the stub + resolver explicitly asks, in two separate queries, both A and AAAA + records. + + + After 100 seconds, the AAAA record is removed from the cache(s) + because its TTL expired. It could be argued to be useful for the + caching resolvers to discard the A record when the shorter TTL (in + this case, for the AAAA record) expires; this would avoid the + situation where there would be a window of 200 seconds when + incomplete information is returned from the cache. The behaviour in + this scenario is unspecified. + + + To simplify the situation, it might help to use the same TTL for all + the resource record sets referring to the same name, unless there is + a particular reason for not doing so. However, there are some + scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where + a different strategy is preferable. + + + Thus, applications that use the response should not rely on a + particular TTL configuration. For example, even if an application + gets a response that only has the A record in the example described + above, it should be still aware that there could be a AAAA record for + "foo.example.com". That is, the application should try to fetch the + missing records itself if it needs the record. + + +4.6 IPv6 Transport Guidelines for DNS Servers + + + As described in Section 1.3 and + [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to + be at least one authoritative IPv4 DNS server for every zone, even if + the zone has only IPv6 records. (Note that obviously, having more + servers with robust connectivity would be preferable, but this is the + minimum recommendation; also see [RFC2182].) + + +5. Recommendations for DNS Resolver IPv6 Support + + + When IPv6 is enabled on a node, there are several things to consider + to ensure that the process is as smooth as possible. + + + + + + +Durand, et al. Expires February 7, 2005 [Page 13] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + +5.1 DNS Lookups May Query IPv6 Records Prematurely + + + The system library that implements the getaddrinfo() function for + looking up names is a critical piece when considering the robustness + of enabling IPv6; it may come in basically three flavours: + + + 1. The system library does not know whether IPv6 has been enabled in + the kernel of the operating system: it may start looking up AAAA + records with getaddrinfo() and AF_UNSPEC hint when the system is + upgraded to a system library version which supports IPv6. + + + 2. The system library might start to perform IPv6 queries with + getaddrinfo() only when IPv6 has been enabled in the kernel. + However, this does not guarantee that there exists any useful + IPv6 connectivity (e.g., the node could be isolated from the + other IPv6 networks, only having link-local addresses). + + + 3. The system library might implement a toggle which would apply + some heuristics to the "IPv6-readiness" of the node before + starting to perform queries; for example, it could check whether + only link-local IPv6 address(es) exists, or if at least one + global IPv6 address exists. + + + First, let us consider generic implications of unnecessary queries + for AAAA records: when looking up all the records in the DNS, AAAA + records are typically tried first, and then A records. These are + done in serial, and the A query is not performed until a response is + received to the AAAA query. Considering the misbehaviour of DNS + servers and load-balancers, as described in Section 3.1, the look-up + delay for AAAA may incur additional unnecessary latency, and + introduce a component of unreliability. + + + One option here could be to do the queries partially in parallel; for + example, if the final response to the AAAA query is not received in + 0.5 seconds, start performing the A query while waiting for the + result (immediate parallelism might be unoptimal, at least without + information sharing between the look-up threads, as that would + probably lead to duplicate non-cached delegation chain lookups). + + + An additional concern is the address selection, which may, in some + circumstances, prefer AAAA records over A records even when the node + does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. + In some cases, the implementation may attempt to connect or send a + datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], + incurring very long protocol timeouts, instead of quickly failing + back to IPv4. + + + Now, we can consider the issues specific to each of the three + + + + +Durand, et al. Expires February 7, 2005 [Page 14] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + possibilities: + + + In the first case, the node performs a number of completely useless + DNS lookups as it will not be able to use the returned AAAA records + anyway. (The only exception is where the application desires to know + what's in the DNS, but not use the result for communication.) One + should be able to disable these unnecessary queries, for both latency + and reliability reasons. However, as IPv6 has not been enabled, the + connections to IPv6 addresses fail immediately, and if the + application is programmed properly, the application can fall + gracefully back to IPv4 [I-D.ietf-v6ops-application-transition]. + + + The second case is similar to the first, except it happens to a + smaller set of nodes when IPv6 has been enabled but connectivity has + not been provided yet; similar considerations apply, with the + exception that IPv6 records, when returned, will be actually tried + first which may typically lead to long timeouts. + + + The third case is a bit more complex: optimizing away the DNS lookups + with only link-locals is probably safe (but may be desirable with + different lookup services which getaddrinfo() may support), as the + link-locals are typically automatically generated when IPv6 is + enabled, and do not indicate any form of IPv6 connectivity. That is, + performing DNS lookups only when a non-link-local address has been + configured on any interface could be beneficial -- this would be an + indication that either the address has been configured either from a + router advertisement, DHCPv6 [RFC3315], or manually. Each would + indicate at least some form of IPv6 connectivity, even though there + would not be guarantees of it. + + + These issues should be analyzed at more depth, and the fixes found + consensus on, perhaps in a separate document. + + +5.2 Obtaining a List of DNS Recursive Resolvers + + + In scenarios where DHCPv6 is available, a host can discover a list of + DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" + option [RFC3646]. This option can be passed to a host through a + subset of DHCPv6 [RFC3736]. + + + The IETF is considering the development of alternative mechanisms for + obtaining the list of DNS recursive name servers when DHCPv6 is + unavailable or inappropriate. No decision about taking on this + development work has been reached as of this writing (Aug 2004) + [I-D.ietf-dnsop-ipv6-dns-configuration]. + + + In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms + under consideration for development include the use of well-known + + + + +Durand, et al. Expires February 7, 2005 [Page 15] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + addresses [I-D.ohta-preconfigured-dns] and the use of Router + Advertisements to convey the information + [I-D.jeong-dnsop-ipv6-dns-discovery]. + + + Note that even though IPv6 DNS resolver discovery is a recommended + procedure, it is not required for dual-stack nodes in dual-stack + networks as IPv6 DNS records can be queried over IPv4 as well as + IPv6. Obviously, nodes which are meant to function without manual + configuration in IPv6-only networks must implement the DNS resolver + discovery function. + + +5.3 IPv6 Transport Guidelines for Resolvers + + + As described in Section 1.3 and + [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers + should be IPv4-only or dual-stack to be able to reach any IPv4-only + DNS server. Note that this requirement is also fulfilled by an + IPv6-only stub resolver pointing to a dual-stack recursive DNS + resolver. + + +6. Considerations about Forward DNS Updating + + + While the topic how to enable updating the forward DNS, i.e., the + mapping from names to the correct new addresses, is not specific to + IPv6, it should be considered especially due to the advent of + Stateless Address Autoconfiguration [RFC2462]. + + + Typically forward DNS updates are more manageable than doing them in + the reverse DNS, because the updater can often be assumed to "own" a + certain DNS name -- and we can create a form of security relationship + with the DNS name and the node which is allowed to update it to point + to a new address. + + + A more complex form of DNS updates -- adding a whole new name into a + DNS zone, instead of updating an existing name -- is considered out + of scope for this memo as it could require zone-wide authentication. + Adding a new name in the forward zone is a problem which is still + being explored with IPv4, and IPv6 does not seem to add much new in + that area. + + +6.1 Manual or Custom DNS Updates + + + The DNS mappings can also be maintained by hand, in a semi-automatic + fashion or by running non-standardized protocols. These are not + considered at more length in this memo. + + + + + + + +Durand, et al. Expires February 7, 2005 [Page 16] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + +6.2 Dynamic DNS + + + Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized + mechanism for dynamically updating the DNS. It works equally well + with stateless address autoconfiguration (SLAAC), DHCPv6 or manual + address configuration. It is important to consider how each of these + behave if IP address-based authentication, instead of stronger + mechanisms [RFC3007], was used in the updates. + + + 1. manual addresses are static and can be configured + + + 2. DHCPv6 addresses could be reasonably static or dynamic, depending + on the deployment, and could or could not be configured on the + DNS server for the long term + + + 3. SLAAC addresses are typically stable for a long time, but could + require work to be configured and maintained. + + + As relying on IP addresses for Dynamic DNS is rather insecure at + best, stronger authentication should always be used; however, this + requires that the authorization keying will be explicitly configured + using unspecified operational methods. + + + Note that with DHCP it is also possible that the DHCP server updates + the DNS, not the host. The host might only indicate in the DHCP + exchange which hostname it would prefer, and the DHCP server would + make the appropriate updates. Nonetheless, while this makes setting + up a secure channel between the updater and the DNS server easier, it + does not help much with "content" security, i.e., whether the + hostname was acceptable -- if the DNS server does not include + policies, they must be included in the DHCP server (e.g., a regular + host should not be able to state that its name is "www.example.com"). + DHCP-initiated DDNS updates have been extensively described in + [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and + [I-D.ietf-dnsext-dhcid-rr]. + + + The nodes must somehow be configured with the information about the + servers where they will attempt to update their addresses, sufficient + security material for authenticating themselves to the server, and + the hostname they will be updating. Unless otherwise configured, the + first could be obtained by looking up the authoritative name servers + for the hostname; the second must be configured explicitly unless one + chooses to trust the IP address-based authentication (not a good + idea); and lastly, the nodename is typically pre-configured somehow + on the node, e.g., at install time. + + + Care should be observed when updating the addresses not to use longer + TTLs for addresses than are preferred lifetimes for the addresses, so + + + + +Durand, et al. Expires February 7, 2005 [Page 17] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + that if the node is renumbered in a managed fashion, the amount of + stale DNS information is kept to the minimum. That is, if the + preferred lifetime of an address expires, the TTL of the record needs + be modified unless it was already done before the expiration. For + better flexibility, the DNS TTL should be much shorter (e.g., a half + or a third) than the lifetime of an address; that way, the node can + start lowering the DNS TTL if it seems like the address has not been + renewed/refreshed in a while. Some discussion on how an + administrator could manage the DNS TTL is included in + [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to + (smart) hosts as well. + + +7. Considerations about Reverse DNS Updating + + + Updating the reverse DNS zone may be difficult because of the split + authority over an address. However, first we have to consider the + applicability of reverse DNS in the first place. + + +7.1 Applicability of Reverse DNS + + + Today, some applications use reverse DNS to either look up some hints + about the topological information associated with an address (e.g. + resolving web server access logs), or as a weak form of a security + check, to get a feel whether the user's network administrator has + "authorized" the use of the address (on the premises that adding a + reverse record for an address would signal some form of + authorization). + + + One additional, maybe slightly more useful usage is ensuring that the + reverse and forward DNS contents match (by looking up the pointer to + the name by the IP address from the reverse tree, and ensuring that a + record under the name in the forward tree points to the IP address) + and correspond to a configured name or domain. As a security check, + it is typically accompanied by other mechanisms, such as a user/ + password login; the main purpose of the reverse+forward DNS check is + to weed out the majority of unauthorized users, and if someone + managed to bypass the checks, he would still need to authenticate + "properly". + + + It may also be desirable to store IPsec keying material corresponding + to an IP address to the reverse DNS, as justified and described in + [I-D.ietf-ipseckey-rr]. + + + It is not clear whether it makes sense to require or recommend that + reverse DNS records be updated. In many cases, it would just make + more sense to use proper mechanisms for security (or topological + information lookup) in the first place. At minimum, the applications + which use it as a generic authorization (in the sense that a record + + + + +Durand, et al. Expires February 7, 2005 [Page 18] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + exists at all) should be modified as soon as possible to avoid such + lookups completely. + + + The applicability is discussed at more length in + [I-D.ietf-dnsop-inaddr-required]. + + +7.2 Manual or Custom DNS Updates + + + Reverse DNS can of course be updated using manual or custom methods. + These are not further described here, except for one special case. + + + One way to deploy reverse DNS would be to use wildcard records, for + example, by configuring one name for a subnet (/64) or a site (/48). + As a concrete example, a site (or the site's ISP) could configure the + reverses of the prefix 2001:db8:f00::/48 to point to one name using a + wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR + site.example.com." Naturally, such a name could not be verified from + the forward DNS, but would at least provide some form of "topological + information" or "weak authorization" if that is really considered to + be useful. Note that this is not actually updating the DNS as such, + as the whole point is to avoid DNS updates completely by manually + configuring a generic name. + + +7.3 DDNS with Stateless Address Autoconfiguration + + + Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in + some regard, while being more difficult in another, as described + below. + + + The address space administrator decides whether the hosts are trusted + to update their reverse DNS records or not. If they are, a simple + address-based authorization is typically sufficient (i.e., check that + the DNS update is done from the same IP address as the record being + updated); stronger security can also be used [RFC3007]. If they + aren't allowed to update the reverses, no update can occur. (Such + address-based update authorization operationally requires that + ingress filtering [RFC3704] has been set up at the border of the site + where the updates occur, and as close to the updater as possible.) + + + Address-based authorization is simpler with reverse DNS (as there is + a connection between the record and the address) than with forward + DNS. However, when a stronger form of security is used, forward DNS + updates are simpler to manage because the host can be assumed to have + an association with the domain. Note that the user may roam to + different networks, and does not necessarily have any association + with the owner of that address space -- so, assuming stronger form of + authorization for reverse DNS updates than an address association is + generally unfeasible. + + + + +Durand, et al. Expires February 7, 2005 [Page 19] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + Moreover, the reverse zones must be cleaned up by an unspecified + janitorial process: the node does not typically know a priori that it + will be disconnected, and cannot send a DNS update using the correct + source address to remove a record. + + + A problem with defining the clean-up process is that it is difficult + to ensure that a specific IP address and the corresponding record are + no longer being used. Considering the huge address space, and the + unlikelihood of collision within 64 bits of the interface + identifiers, a process which would remove the record after no traffic + has been seen from a node in a long period of time (e.g., a month or + year) might be one possible approach. + + + To insert or update the record, the node must discover the DNS server + to send the update to somehow, similar to as discussed in Section + 6.2. One way to automate this is looking up the DNS server + authoritative (e.g., through SOA record) for the IP address being + updated, but the security material (unless the IP address-based + authorization is trusted) must also be established by some other + means. + + + One should note that Cryptographically Generated Addresses + [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of + treatment. CGAs are addresses where the interface identifier is + calculated from a public key, a modifier (used as a nonce), the + subnet prefix, and other data. Depending on the usage profile, CGAs + might or might not be changed periodically due to e.g., privacy + reasons. As the CGA address is not predicatable, a reverse record + can only reasonably be inserted in the DNS by the node which + generates the address. + + +7.4 DDNS with DHCP + + + With DHCPv4, the reverse DNS name is typically already inserted to + the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One + can assume similar practice may become commonplace with DHCPv6 as + well; all such mappings would be pre-configured, and would require no + updating. + + + If a more explicit control is required, similar considerations as + with SLAAC apply, except for the fact that typically one must update + a reverse DNS record instead of inserting one (if an address + assignment policy that reassigns disused addresses is adopted) and + updating a record seems like a slightly more difficult thing to + secure. However, it is yet uncertain how DHCPv6 is going to be used + for address assignment. + + + Note that when using DHCP, either the host or the DHCP server could + + + + +Durand, et al. Expires February 7, 2005 [Page 20] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + perform the DNS updates; see the implications in Section 6.2. + + + If disused addresses were to be reassigned, host-based DDNS reverse + updates would need policy considerations for DNS record modification, + as noted above. On the other hand, if disused address were not to be + assigned, host-based DNS reverse updates would have similar + considerations as SLAAC in Section 7.3. Server-based updates have + similar properties except that the janitorial process could be + integrated with DHCP address assignment. + + +7.5 DDNS with Dynamic Prefix Delegation + + + In cases where a prefix, instead of an address, is being used and + updated, one should consider what is the location of the server where + DDNS updates are made. That is, where the DNS server is located: + + + 1. At the same organization as the prefix delegator. + + + 2. At the site where the prefixes are delegated to. In this case, + the authority of the DNS reverse zone corresponding to the + delegated prefix is also delegated to the site. + + + 3. Elsewhere; this implies a relationship between the site and where + DNS server is located, and such a relationship should be rather + straightforward to secure as well. Like in the previous case, + the authority of the DNS reverse zone is also delegated. + + + In the first case, managing the reverse DNS (delegation) is simpler + as the DNS server and the prefix delegator are in the same + administrative domain (as there is no need to delegate anything at + all); alternatively, the prefix delegator might forgo DDNS reverse + capability altogether, and use e.g., wildcard records (as described + in Section 7.2). In the other cases, it can be slighly more + difficult, particularly as the site will have to configure the DNS + server to be authoritative for the delegated reverse zone, implying + automatic configuration of the DNS server -- as the prefix may be + dynamic. + + + Managing the DDNS reverse updates is typically simple in the second + case, as the updated server is located at the local site, and + arguably IP address-based authentication could be sufficient (or if + not, setting up security relationships would be simpler). As there + is an explicit (security) relationship between the parties in the + third case, setting up the security relationships to allow reverse + DDNS updates should be rather straightforward as well (but IP + address-based authentication might not be acceptable). In the first + case, however, setting up and managing such relationships might be a + lot more difficult. + + + + +Durand, et al. Expires February 7, 2005 [Page 21] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + +8. Miscellaneous DNS Considerations + + + This section describes miscellaneous considerations about DNS which + seem related to IPv6, for which no better place has been found in + this document. + + +8.1 NAT-PT with DNS-ALG + + + The DNS-ALG component of NAT-PT mangles A records to look like AAAA + records to the IPv6-only nodes. Numerous problems have been + identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. + This is a strong reason not to use NAT-PT in the first place. + + +8.2 Renumbering Procedures and Applications' Use of DNS + + + One of the most difficult problems of systematic IP address + renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that + an application which looks up a DNS name disregards information such + as TTL, and uses the result obtained from DNS as long as it happens + to be stored in the memory of the application. For applications + which run for a long time, this could be days, weeks or even months; + some applications may be clever enough to organize the data + structures and functions in such a manner that look-ups get refreshed + now and then. + + + While the issue appears to have a clear solution, "fix the + applications", practically this is not reasonable immediate advice; + the TTL information is not typically available in the APIs and + libraries (so, the advice becomes "fix the applications, APIs and + libraries"), and a lot more analysis is needed on how to practically + go about to achieve the ultimate goal of avoiding using the names + longer than expected. + + +9. Acknowledgements + + + Some recommendations (Section 4.3, Section 5.1) about IPv6 service + provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik + Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided + useful feedback and improvements. Scott Rose, Rob Austein, Masataka + Ohta, and Mark Andrews helped in clarifying the issues regarding + additional data and the use of TTL. Jefsey Morfin, Ralph Droms, + Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and + Rob Austein provided useful feedback during the WG last call. Thomas + Narten provided extensive feedback during the IESG evaluation. + + +10. Security Considerations + + + This document reviews the operational procedures for IPv6 DNS + + + + +Durand, et al. Expires February 7, 2005 [Page 22] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + operations and does not have security considerations in itself. + + + However, it is worth noting that in particular with Dynamic DNS + Updates, security models based on the source address validation are + very weak and cannot be recommended -- they could only be considered + in the environments where ingress filtering [RFC3704] has been + deployed. On the other hand, it should be noted that setting up an + authorization mechanism (e.g., a shared secret, or public-private + keys) between a node and the DNS server has to be done manually, and + may require quite a bit of time and expertise. + + + To re-emphasize which was already stated, the reverse+forward DNS + check provides very weak security at best, and the only + (questionable) security-related use for them may be in conjunction + with other mechanisms when authenticating a user. + + +11. References + + +11.1 Normative References + + + [I-D.ietf-dnsop-ipv6-dns-configuration] + Jeong, J., "IPv6 Host Configuration of DNS Server + Information Approaches", + draft-ietf-dnsop-ipv6-dns-configuration-02 (work in + progress), July 2004. + + + [I-D.ietf-dnsop-ipv6-transport-guidelines] + Durand, A. and J. Ihren, "DNS IPv6 transport operational + guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 + (work in progress), March 2004. + + + [I-D.ietf-dnsop-misbehavior-against-aaaa] + Morishita, Y. and T. Jinmei, "Common Misbehavior against + DNS Queries for IPv6 Addresses", + draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in + progress), April 2004. + + + [I-D.ietf-ipv6-deprecate-site-local] + Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work + in progress), March 2004. + + + [I-D.ietf-v6ops-application-transition] + Shin, M., "Application Aspects of IPv6 Transition", + draft-ietf-v6ops-application-transition-03 (work in + progress), June 2004. + + + [I-D.ietf-v6ops-renumbering-procedure] + + + + +Durand, et al. Expires February 7, 2005 [Page 23] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + Baker, F., Lear, E. and R. Droms, "Procedures for + Renumbering an IPv6 Network without a Flag Day", + draft-ietf-v6ops-renumbering-procedure-01 (work in + progress), July 2004. + + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + + [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection + and Operation of Secondary DNS Servers", BCP 16, RFC 2182, + July 1997. + + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and + M. Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", RFC 3364, + August 2002. + + + + + +Durand, et al. Expires February 7, 2005 [Page 24] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October + 2003. + + + [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + +11.2 Informative References + + + [I-D.durand-v6ops-natpt-dns-alg-issues] + Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", + draft-durand-v6ops-natpt-dns-alg-issues-00 (work in + progress), February 2003. + + + [I-D.huitema-v6ops-teredo] + Huitema, C., "Teredo: Tunneling IPv6 over UDP through + NATs", draft-huitema-v6ops-teredo-02 (work in progress), + June 2004. + + + [I-D.huston-6to4-reverse-dns] + Huston, G., "6to4 Reverse DNS", + draft-huston-6to4-reverse-dns-02 (work in progress), April + 2004. + + + [I-D.ietf-dhc-ddns-resolution] + Stapp, M., "Resolution of DNS Name Conflicts Among DHCP + Clients", draft-ietf-dhc-ddns-resolution-07 (work in + progress), July 2004. + + + [I-D.ietf-dhc-fqdn-option] + Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", + draft-ietf-dhc-fqdn-option-07 (work in progress), July + 2004. + + + [I-D.ietf-dnsext-dhcid-rr] + Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for + encoding DHCP information (DHCID RR)", + draft-ietf-dnsext-dhcid-rr-08 (work in progress), July + 2004. + + + [I-D.ietf-dnsop-bad-dns-res] + + + + +Durand, et al. Expires February 7, 2005 [Page 25] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in + progress), July 2004. + + + [I-D.ietf-dnsop-dontpublish-unreachable] + Hazel, P., "IP Addresses that should never appear in the + public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 + (work in progress), February 2002. + + + [I-D.ietf-dnsop-inaddr-required] + Senie, D., "Requiring DNS IN-ADDR Mapping", + draft-ietf-dnsop-inaddr-required-05 (work in progress), + April 2004. + + + [I-D.ietf-ipseckey-rr] + Richardson, M., "A method for storing IPsec keying + material in DNS", draft-ietf-ipseckey-rr-11 (work in + progress), July 2004. + + + [I-D.ietf-ipv6-unique-local-addr] + Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in + progress), June 2004. + + + [I-D.ietf-send-cga] + Aura, T., "Cryptographically Generated Addresses (CGA)", + draft-ietf-send-cga-06 (work in progress), April 2004. + + + [I-D.ietf-v6ops-3gpp-analysis] + Wiljakka, J., "Analysis on IPv6 Transition in 3GPP + Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in + progress), May 2004. + + + [I-D.ietf-v6ops-mech-v2] + Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms + for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04 + (work in progress), July 2004. + + + [I-D.ietf-v6ops-onlinkassumption] + Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery + On-Link Assumption Considered Harmful", + draft-ietf-v6ops-onlinkassumption-02 (work in progress), + May 2004. + + + [I-D.ietf-v6ops-v6onbydefault] + Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack + IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 + (work in progress), July 2004. + + + + +Durand, et al. Expires February 7, 2005 [Page 26] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + [I-D.jeong-dnsop-ipv6-dns-discovery] + Jeong, J., "IPv6 DNS Discovery based on Router + Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 + (work in progress), July 2004. + + + [I-D.moore-6to4-dns] + Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work + in progress), October 2002. + + + [I-D.ohta-preconfigured-dns] + Ohta, M., "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-01 (work in progress), + February 2004. + + + [I-D.savola-v6ops-6bone-mess] + Savola, P., "Moving from 6bone to IPv6 Internet", + draft-savola-v6ops-6bone-mess-01 (work in progress), + November 2002. + + + [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. + + + [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + + [RFC2826] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, May 2000. + + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + + +Authors' Addresses + + + Alain Durand + SUN Microsystems, Inc. + 17 Network circle UMPL17-202 + Menlo Park, CA 94025 + USA + + + EMail: Alain.Durand@sun.com + + + + + + + + + +Durand, et al. Expires February 7, 2005 [Page 27] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + + EMail: johani@autonomica.se + + + + Pekka Savola + CSC/FUNET + Espoo + Finland + + + EMail: psavola@funet.fi + + +Appendix A. Site-local Addressing Considerations for DNS + + + As site-local addressing has been deprecated, the considerations for + site-local addressing are discussed briefly here. Unique local + addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed + as a replacement, but being work-in-progress, it is not considered + further. + + + The interactions with DNS come in two flavors: forward and reverse + DNS. + + + To actually use site-local addresses within a site, this implies the + deployment of a "split-faced" or a fragmented DNS name space, for the + zones internal to the site, and the outsiders' view to it. The + procedures to achieve this are not elaborated here. The implication + is that site-local addresses must not be published in the public DNS. + + + To faciliate reverse DNS (if desired) with site-local addresses, the + stub resolvers must look for DNS information from the local DNS + servers, not e.g. starting from the root servers, so that the + site-local information may be provided locally. Note that the + experience of private addresses in IPv4 has shown that the root + servers get loaded for requests for private address lookups in any + case. + + +Appendix B. Issues about Additional Data or TTL + + + [[ note to the RFC-editor: remove this section upon publication. ]] + + + This appendix tries to describe the apparent rought consensus about + additional data and TTL issues (sections 4.4 and 4.5), and present + questions when there appears to be no consensus. The point of + + + + +Durand, et al. Expires February 7, 2005 [Page 28] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + + recording them here is to focus the discussion and get feedback. + + + Resolved: + + + a. If some critical additional data RRsets wouldn't fit, you set the + TC bit even if some RRsets did fit. + + + b. If some courtesy additional data RRsets wouldn't fit, you never + set the TC bit, but rather remove (at least some of) the courtesy + RRsets. + + + c. DNS servers should implement sanity checks on the resulting glue, + e.g., to disable circular dependencies. Then the responding + servers can use at-or-below-a-zone-cut criterion to determine + whether the additional data is critical or not. + + + Open issues (at least): + + + 1. if some critical additional data RRsets would fit, but some + wouldn't, and TC has to be set (see above), should one rather + remove the additional data that did fit, keep it, or leave + unspecified? + + + 2. if some courtesy additional data RRsets would fit, but some + wouldn't, and some will have to be removed from the response (no + TC is set, see above), what to do -- remove all courtesy RRsets, + keep all that fit, or leave unspecified? + + + 3. is it acceptable to use the transport used in the DNS query as a + hint which records to keep if not removing all the RRsets, if: a) + having to decide which critical additional data to keep, or b) + having to decide which courtesy additional data to keep? + + + 4. (this issue was discussed in section 4.5) if one RRset has TTL of + 100 seconds, and another the TTL of 300 seconds, what should the + caching server do after 100 seconds? Keep returning just one + RRset when returning additional data, or discard the other RRset + from the cache? + + + 5. how do we move forward from here? If we manage to get to some + form of consensus, how do we record it: a) just in + draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational + category only!), b) a separate BCP or similar by DNSEXT WG(?), + clarifying and giving recommendations, c) something else, what? + + + + + + + + +Durand, et al. Expires February 7, 2005 [Page 29] +Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + + +Intellectual Property Statement + + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + +Disclaimer of Validity + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Copyright Statement + + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + +Acknowledgment + + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Durand, et al. Expires February 7, 2005 [Page 30] \ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt new file mode 100644 index 000000000000..b2e2341be9f1 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt @@ -0,0 +1,300 @@ +Internet Engineering Task Force A.Durand +INTERNET-DRAFT SUN Microsystems,inc. +November, 24, 2003 J. Ihren +Expires May 25, 2004 Autonomica + + + DNS IPv6 transport operational guidelines + + + + +Status of this Memo + + This memo provides information to the Internet community. It does not + specify an Internet standard of any kind. This memo is in full + conformance with all provisions of Section 10 of RFC2026 + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + +Abstract + + This memo provides guidelines and Best Current Practice to operate + DNS in a world where queries and responses are carried in a mixed + environment of IPv4 and IPv6 networks. + + +Acknowledgment + + This document is the result of many conversations that happened in + the DNS community at IETF and elsewhere since 2001. During that + period of time, a number of Internet drafts have been published to + clarify various aspects of the issues at stake. This document focuses + on the conclusion of those discussions. + + The authors would like to acknowledge the role of Pekka Savola in his + thorough review of the document. + + +1. Terminology + + The phrase "IPv4 name server" indicates a name server available over + IPv4 transport. It does not imply anything about what DNS data is + served. Likewise, "IPv6 name server" indicates a name server + available over IPv6 transport. The phrase "dual-stack DNS server" + indicates a DNS server that is actually configured to run both + protocols, IPv4 and IPv6, and not merely a server running on a system + capable of running both but actually configured to run only one. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [2119]. + + +2. Introduction to the Problem of Name Space Fragmentation: + following the referral chain + + The caching resolver that tries to look up a name starts out at the + root, and follows referrals until it is referred to a nameserver that + is authoritative for the name. If somewhere down the chain of + referrals it is referred to a nameserver that is only accessible over + an unavailable type of transport, a traditional nameserver is unable + to finish the task. + + When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is + only a matter of time until this starts to happen. The complete DNS + hierarchy then starts to fragment into a graph where authoritative + nameservers for certain nodes are only accessible over a certain + transport. What is feared is that a node using only a particular + version of IP, querying information about another node using the same + version of IP can not do it because, somewhere in the chain of + servers accessed during the resolution process, one or more of them + will only be accessible with the other version of IP. + + With all DNS data only available over IPv4 transport everything is + simple. IPv4 resolvers can use the intended mechanism of following + referrals from the root and down while IPv6 resolvers have to work + through a "translator", i.e. they have to use a second name server on + a so-called "dual stack" host as a "forwarder" since they cannot + access the DNS data directly. + + With all DNS data only available over IPv6 transport everything would + be equally simple, with the exception of old legacy IPv4 name servers + having to switch to a forwarding configuration. + + However, the second situation will not arise in a foreseeable time. + Instead, it is expected that the transition will be from IPv4 only to + a mixture of IPv4 and IPv6, with DNS data of theoretically three + categories depending on whether it is available only over IPv4 + transport, only over IPv6 or both. + + Having DNS data available on both transports is the best situation. + The major question is how to ensure that it as quickly as possible + becomes the norm. However, while it is obvious that some DNS data + will only be available over v4 transport for a long time it is also + obvious that it is important to avoid fragmenting the name space + available to IPv4 only hosts. I.e. during transition it is not + acceptable to break the name space that we presently have available + for IPv4-only hosts. + + +3. Policy Based Avoidance of Name Space Fragmentation + + Today there are only a few DNS "zones" on the public Internet that + are available over IPv6 transport, and most of them can be regarded + as "experimental". However, as soon as the root and top level domains + are available over IPv6 transport, it is reasonable to expect that it + will become more common to have zones served by IPv6 servers. + + Having those zones served only by IPv6-only name server would not be + a good development, since this will fragment the previously + unfragmented IPv4 name space and there are strong reasons to find a + mechanism to avoid it. + + The RECOMMENDED approach to maintain name space continuity is to use + administrative policies, as described in the next section. + + +4. DNS IPv6 Transport RECOMMENDED Guidelines + + In order to preserve name space continuity, the following administrative + policies are RECOMMENDED: + - every recursive DNS server SHOULD be either IPv4-only or dual + stack, + - every single DNS zone SHOULD be served by at least one IPv4 + reachable DNS server. + + This rules out IPv6-only DNS servers performing full recursion and + DNS zones served only by IPv6-only DNS servers. However, one could + very well design a configuration where a chain of IPv6 only DNS + servers forward queries to a set of dual stack DNS servers actually + performing those recursive queries. This approach could be revisited + if/when translation techniques between IPv4 and IPv6 were to be + widely deployed. + + In order to help enforcing the second point, the optional operational + zone validation processes SHOULD ensure that there is at least one + IPv4 address record available for the name servers of any child + delegations within the zone. + + +5. Security Considerations + + Being a critical piece of the Internet infrastructure, the DNS is a + potential value target and thus should be protected. Great care + should be taken not to weaken the security of DNS while introducing + IPv6 operation. + + Keeping the DNS name space from fragmenting is a critical thing for + the availability and the operation of the Internet; this memo + addresses this issue by clear and simple operational guidelines. + + The RECOMMENDED guidelines are compatible with the operation of + DNSSEC and do not introduce any new security issues. + + +6. Author Addresses + + Alain Durand + SUN Microsystems, Inc + 17 Network circle UMPK17-202 + Menlo Park, CA, 94025 + USA + Mail: Alain.Durand@sun.com + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm, Sweden + Mail: johani@autonomica.se + + +7. Normative References + + [2119] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +8. Full Copyright Statement + + "Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt new file mode 100644 index 000000000000..2311ee6c18a0 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt @@ -0,0 +1,391 @@ + +DNSOP G. Guette +Internet-Draft IRISA / INRIA +Expires: February 5, 2005 O. Courtay + Thomson R&D + August 7, 2004 + + + Requirements for Automated Key Rollover in DNSSEC + draft-ietf-dnsop-key-rollover-requirements-01.txt + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on February 5, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes problems that appear during an automated + rollover and gives the requirements for the design of communication + between parent zone and child zone in an automated rollover process. + This document is essentially about key rollover, the rollover of + another Resource Record present at delegation point (NS RR) is also + discussed. + + + + + +Guette & Courtay Expires February 5, 2005 [Page 1] + +Internet-Draft Automated Rollover Requirements August 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Messages authentication and information exchanged . . . . . . 4 + 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Other Resource Record concerned by automatic rollover . . . . 5 + 7. Security consideration . . . . . . . . . . . . . . . . . . . . 5 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 + 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 + Intellectual Property and Copyright Statements . . . . . . . . 7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Guette & Courtay Expires February 5, 2005 [Page 2] + +Internet-Draft Automated Rollover Requirements August 2004 + + +1. Introduction + + The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key + cryptography and digital signatures. It stores the public part of + keys in DNSKEY Resource Records (RRs). Because old keys and + frequently used keys are vulnerable, they must be renewed + periodically. In DNSSEC, this is the case for Zone Signing Keys + (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key + rollover process is necessary for large zones because there are too + many changes to handle a manual administration. + + Let us consider for example a zone with 100000 secure delegations. + If the child zones change their keys once a year on average, that + implies 300 changes per day for the parent zone. This amount of + changes are hard to manage manually. + + Automated rollover is optional and resulting from an agreement + between the administrator of the parent zone and the administrator of + the child zone. Of course, key rollover can also be done manually by + administrators. + + This document describes the requirements for the design of messages + of automated key rollover process and focusses on interaction between + parent and child zone. + +2. The Key Rollover Process + + Key rollover consists in renewing the DNSSEC keys used to sign + resource records in a given DNS zone file. There are two types of + rollover, ZSK rollovers and KSK rollovers. + + In a ZSK rollover, all changes are local to the zone that renews its + key: there is no need to contact other zones (e.g., parent zone) to + propagate the performed changes because a ZSK has no associated DS + record in the parent zone. + + In a KSK rollover, new DS RR(s) must be created and stored in the + parent zone. In consequence, the child zone must contact its parent + zone and must notify it about the KSK change(s). + + Manual key rollover exists and works [3]. The key rollover is built + from two parts of different nature: + o An algorithm that generates new keys and signs the zone file. It + could be local to the zone + o The interaction between parent and child zones + + One example of manual key rollover is: + + + + +Guette & Courtay Expires February 5, 2005 [Page 3] + +Internet-Draft Automated Rollover Requirements August 2004 + + + o The child zone creates a new KSK + o The child zone waits for the creation of the DS RR in its parent + zone + o The child zone deletes the old key. + + In manual rollover, communications are managed by the zone + administrators and the security of these communications is out of + scope of DNSSEC. + + Automated key rollover should use a secure communication between + parent and child zones. This document concentrates on defining + interactions between entities present in key rollover process. + +3. Basic Requirements + + The main constraint to respect during a key rollover is that the + chain of trust MUST be preserved, even if a resolver retrieves some + RRs from recursive cache server. Every RR MUST be verifiable at any + time, every RRs exchanged during the rollover should be authenticated + and their integrity should be guaranteed. + + Two entities act during a KSK rollover: the child zone and its parent + zone. These zones are generally managed by different administrators. + These administrators should agree on some parameters like + availability of automated rollover, the maximum delay between + notification of changes in the child zone and the resigning of the + parent zone. The child zone needs to know this delay to schedule its + changes. + +4. Messages authentication and information exchanged + + Every exchanged message MUST be authenticated and the authentication + tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC + request with verifiable SIG records. + + Once the changes related to a KSK are made in a child zone, this zone + MUST notify its parent zone in order to create the new DS RR and + store this DS RR in parent zone file. + + The parent zone MUST receive all the child keys that needs the + creation of associated DS RRs in the parent zone. + + Some errors could occur during transmission between child zone and + parent zone. Key rollover solution MUST be fault tolerant, i.e. at + any time the rollover MUST be in a consistent state and all RRs MUST + be verifiable, even if an error occurs. That is to say that it MUST + remain a valid chain of trust. + + + + +Guette & Courtay Expires February 5, 2005 [Page 4] + +Internet-Draft Automated Rollover Requirements August 2004 + + +5. Emergency Rollover + + A key of a zone might be compromised and this key MUST be changed as + soon as possible. Fast changes could break the chain of trust. The + part of DNS tree having this zone as apex can become unverifiable, + but the break of the chain of trust is necessary if we want to no one + can use the compromised key to spoof DNS data. + + In case of emergency rollover, the administrators of parent and child + zones should create new key(s) and DS RR(s) as fast as possible in + order to reduce the time the chain of trust is broken. + +6. Other Resource Record concerned by automatic rollover + + NS records are also present at delegation point, so when the child + zone renews some NS RR, the corresponding records at delegation point + in parent zone (glue) MUST be updated. NS records are concerned by + rollover and this rollover could be automated too. In this case, + when the child zone notifies its parent zone that some NS records + have been changed, the parent zone MUST verify that these NS records + are present in child zone before doing any changes in its own zone + file. This allows to avoid inconsistency between NS records at + delegation point and NS records present in the child zone. + +7. Security consideration + + This document describes requirements to design an automated key + rollover in DNSSEC based on DNSSEC security. In the same way, as + plain DNSSEC, the automatic key rollover contains no mechanism + protecting against denial of service (DoS). The security level + obtain after an automatic key rollover, is the security level + provided by DNSSEC. + +8. Acknowledgments + + The authors want to acknowledge Francis Dupont, Mohsen Souissi, + Bernard Cousin, Bertrand L‰onard and members of IDsA project for + their contribution to this document. + +9 Normative References + + [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + + + +Guette & Courtay Expires February 5, 2005 [Page 5] + +Internet-Draft Automated Rollover Requirements August 2004 + + + [3] Kolkman, O., "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practice-01 (work in + progress), May 2004. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [7] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-09 (work in progress), July + 2004. + + [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004. + + [9] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in + progress), July 2004. + + +Authors' Addresses + + Gilles Guette + IRISA / INRIA + Campus de Beaulieu + 35042 Rennes CEDEX + FR + + EMail: gilles.guette@irisa.fr + URI: http://www.irisa.fr + + + Olivier Courtay + Thomson R&D + 1, avenue Belle Fontaine + 35510 Cesson S‰vign‰ CEDEX + FR + + EMail: olivier.courtay@thomson.net + + + + + +Guette & Courtay Expires February 5, 2005 [Page 6] + +Internet-Draft Automated Rollover Requirements August 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Guette & Courtay Expires February 5, 2005 [Page 7] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt new file mode 100644 index 000000000000..1094275d3e40 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt @@ -0,0 +1,505 @@ + + +IETF DNSOP Working Group Y. Morishita +Internet-Draft JPRS +Expires: July 11, 2004 T. Jinmei + Toshiba + January 11, 2004 + + + Common Misbehavior against DNS Queries for IPv6 Addresses + draft-ietf-dnsop-misbehavior-against-aaaa-00.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 11, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + There is some known misbehavior of DNS authoritative servers when + they are queried for AAAA resource records. Such behavior can block + IPv4 communication which should actually be available, cause a + significant delay in name resolution, or even make a denial of + service attack. This memo describes details of the known cases and + discusses the effect of the cases. + +1. Introduction + + Many DNS clients (resolvers) that support IPv6 first search for AAAA + Resource Records (RRs) of a target host name, and then for A RRs of + + + +Morishita & Jinmei Expires July 11, 2004 [Page 1] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + + the same name. This fallback mechanism is based on the DNS + specifications, which if not obeyed by authoritative servers can + produce unpleasant results. In some cases, for example, a web browser + fails to connect to a web server it could otherwise. In the following + sections, this memo describes some typical cases of the misbehavior + and its (bad) effects. + + Note that the misbehavior is not specific to AAAA RRs. In fact, all + known examples also apply to the cases of queries for MX, NS, and SOA + RRs. The authors even believe this can be generalized for all types + of queries other than those for A RRs. In this memo, however, we + concentrate on the case for AAAA queries, since the problem is + particularly severe for resolvers that support IPv6, which thus + affects many end users. Resolvers at end users normally send A and/or + AAAA queries only, and so the problem for the other cases is + relatively minor. + +2. Network Model + + In this memo, we assume a typical network model of name resolution + environment using DNS. It consists of three components; stub + resolvers, caching servers, and authoritative servers. A stub + resolver issues a recursive query to a caching server, which then + handles the entire name resolution procedure recursively. The caching + server caches the result of the query as well as sends the result to + the stub resolver. The authoritative servers respond to queries for + names for which they have the authority, normally in a non-recursive + manner. + +3. Expected Behavior + + Suppose that an authoritative server has an A RR but not a AAAA RR + for a host name. Then the server should return a response to a query + for a AAAA RR of the name with the RCODE being 0 (indicating no + error) and with an empty answer section [1]. Such a response + indicates that there is at least one RR of a different type than AAAA + for the queried name, and the stub resolver can then look for A RRs. + + This way, the caching server can cache the fact that the queried name + does not have a AAAA RR (but may have other types of RRs), and thus + can improve the response time to further queries for a AAAA RR of the + name. + +4. Problematic Behaviors + + There are some known cases at authoritative servers that do not + conform to the expected behavior. This section describes those + problematic cases. + + + +Morishita & Jinmei Expires July 11, 2004 [Page 2] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + +4.1 Return NXDOMAIN + + This type of server returns a response with the RCODE being 3 + (NXDOMAIN) to a query for a AAAA RR, indicating it does not have any + RRs of any type for the queried name. + + With this response, the stub resolver may immediately give up and + never fall back. Even if the resolver retries with a query for an A + RR, the negative response for the name has been cached in the caching + server, and the caching server will simply return the negative + response. As a result, the stub resolver considers this as a fatal + error in name resolution. + + There have been several known examples of this behavior, but all the + examples that the authors know have changed their behavior as of this + writing. + +4.2 Return NOTIMP + + Other authoritative servers return a response with the RCODE being 4 + (NOTIMP), indicating the servers do not support the requested type of + query. + + This case is less harmful than the previous one; if the stub resolver + falls back to querying for an A RR, the caching server will process + the query correctly and return an appropriate response. + + In this case, the caching server does not cache the fact that the + queried name has no AAAA RR, resulting in redundant queries for AAAA + RRs in the future. The behavior will waste network bandwidth and + increase the load of the authoritative server. + + Using SERVFAIL or FORMERR would cause the same effect, though the + authors have not seen such implementations yet. + +4.3 Return a Broken Response + + Another different type of authoritative servers returns broken + responses to AAAA queries. A known behavior of this category is to + return a response whose RR type is AAAA, but the length of the RDATA + is 4 bytes. The 4-byte data looks like the IPv4 address of the + queried host name. That is, the RR in the answer section would be + described like this: + + www.bad.example. 600 IN AAAA 192.0.2.1 + + which is, of course, bogus (or at least meaningless). + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 3] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + + A widely deployed caching server implementation transparently returns + the broken response (as well as caches it) to the stub resolver. + Another known server implementation parses the response by + themselves, and sends a separate response with the RCODE being 2 + (SERVFAIL). + + In either case, the broken response does not affect queries for an A + RR of the same name. If the stub resolver falls back to A queries, it + will get an appropriate response. + + The latter case, however, causes the same bad effect as that + described in the previous section: redundant queries for AAAA RRs. + +4.4 Make Lame Delegation + + Some authoritative servers respond to AAAA queries in a way causing + lame delegation. In this case the parent zone specifies that the + authoritative server should have the authority of a zone, but the + server does not return an authoritative response for AAAA queries + within the zone (i.e., the AA bit in the response is not set). On the + other hand, the authoritative server returns an authoritative + response for A queries. + + When a caching server asks the server for AAAA RRs in the zone, it + recognizes the delegation is lame, and return a response with the + RCODE being 2 (SERVFAIL) to the stub resolver. + + Furthermore, some caching servers record the authoritative server as + lame for the zone and will not use it for a certain period of time. + With this type of caching server, even if the stub resolver falls + back to querying for an A RR, the caching server will simply return a + response with the RCODE being SERVFAIL, since all the servers are + known to be "lame." + + There is also an implementation that relaxes the behavior a little + bit. It basically tries to avoid using the lame server, but still + continues to try it as a last resort. With this type of caching + server, the stub resolver will get a correct response if it falls + back after SERVFAIL. However, this still causes redundant AAAA + queries as explained in the previous sections. + +4.5 Ignore Queries for AAAA + + Some authoritative severs seem to ignore queries for a AAAA RR, + causing a delay at the stub resolver to fall back to a query for an A + RR. This behavior may even cause a fatal timeout at the resolver. + + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 4] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + +5. Security Considerations + + The CERT/CC pointed out that the response with NXDOMAIN described in + Section 4.1 can be used for a denial of service attack [2]. The same + argument applies to the case of "lame delegation" described in + Section 4.4 with a certain type of caching server. + +6. Acknowledgements + + Erik Nordmark encouraged the authors to publish this document as an + Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary + version of this document. Pekka Savola carefully reviewed a previous + version and provided detailed comments. + +Informative References + + [1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC + 1034, November 1987. + + [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from + AAAA queries could cause denial-of-service conditions", March + 2003, . + + +Authors' Addresses + + MORISHITA Orange Yasuhiro + Research and Development Department, Japan Registry Service Co.,Ltd. + Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi + Chiyoda-ku, Tokyo 101-0052 + Japan + + EMail: yasuhiro@jprs.co.jp + + + JINMEI Tatuya + Corporate Research & Development Center, Toshiba Corporation + 1 Komukai Toshiba-cho, Saiwai-ku + Kawasaki-shi, Kanagawa 212-8582 + Japan + + EMail: jinmei@isl.rdc.toshiba.co.jp + +Appendix A. Live Examples + + In this appendix, we show concrete implementations and domain names + that may cause problematic cases so that the behavior can be + reproduced in a practical environment. The examples are for + + + +Morishita & Jinmei Expires July 11, 2004 [Page 5] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + + informational purposes only, and the authors do not intend to accuse + any implementations or zone administrators. + + The behavior described in Section 4.2 (return NOTIMP) can be found by + looking for a AAAA RR of www.css.vtext.com at 66.174.3.4. + + The behavior described in Section 4.3 (broken responses) can be seen + by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an + alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior + can be found with the name "vip.alt.ihp.sony.co.jp," an alias of + "www.sony.co.jp," at 210.139.255.204. + + The behavior described in Section 4.4 (lame delegation) can be found + by querying for a AAAA RR of "www.ual.com" at 209.87.113.4. + + The behavior described in Section 4.5 (ignore queries) can be seen by + trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an + alias of "ad.jp.doubleclick.net," at 210.153.90.9. + + Many authoritative server implementations show the expected behavior + described in Section 3. Some DNS load balancers reportedly have a + problematic behavior shown in Section 4, but the authors do not have + a concrete example. The CERT/CC provides a list of implementations + that behave as described in Section 4.1 [2]. + + The BIND9 caching server implementation is an example of the latter + cases described in Section 4.3 and Section 4.4, respectively. The + BIND8 caching server implementation is an example of the former case + described in Section 4.3. As for the issue shown in Section 4.4, + BIND8 caching servers prior to 8.3.5 show the behavior described as + the former case in this section. The versions 8.3.5 and later of + BIND8 caching server behave like the BIND9 caching server + implementation with this matter. + + Regarding resolver implementations, the authors are only familiar + with the ones derived from the BIND implementation. These + implementations always fall back regardless of the RCODE; NXDOMAIN, + NOTIMP, or SERVFAIL. It even falls back when getting a broken + response. However, the behavior does not help the situation in the + NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also + causes a fatal error at the resolver side if the resolver is using + some older versions of BIND8 caching server. + + The authors hear that a stub resolver routine implemented in some web + browsers interprets the broken response described in Section 4.3 as a + fatal error and does not fall back to A queries. However, we have not + confirmed this information. + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 6] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + +Appendix B. Change History + + Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are: + + o Made a separate appendix and moved live examples to appendix so + that we can remove them when this document is (ever) officially + published. + + o Revised some live examples based on the recent status. + + o Noted in introduction that the misbehavior is not specific to AAAA + and that this document still concentrates on the AAAA case. + + o Changed the section title of "delegation loop" to "lame + delegation" in order to reflect the essential point of the issue. + Wording on this matter was updated accordingly. + + o Updated the Acknowledgements list. + + o Changed the reference category from normative to informative (this + is an informational document after all). + + o Changed the draft name to an IETF dnsop working group document (as + agreed). + + o Applied several editorial fixes. + + + + + + + + + + + + + + + + + + + + + + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 7] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Morishita & Jinmei Expires July 11, 2004 [Page 8] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 9] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt new file mode 100644 index 000000000000..f6ece8821034 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt @@ -0,0 +1,485 @@ + DNSOP Working Group Paul Vixie, ISC (Ed.) + INTERNET-DRAFT Akira Kato, WIDE + July, 2004 + + + DNS Response Size Issues + + + Status of this Memo + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which we are aware have been or will be disclosed, and any of which + we become aware will be disclosed, in accordance with RFC 3668. + + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + Copyright Notice + + + Copyright (C) The Internet Society (2003-2004). All Rights Reserved. + + + + + + Abstract + + + With a mandated default minimum maximum message size of 512 octets, + the DNS protocol presents some special problems for zones wishing to + expose a moderate or high number of authority servers (NS RRs). This + document explains the operational issues caused by, or related to + this response size limit. + + + + + + + Expires December 2004 [Page 1] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 1 - Introduction and Overview + + + 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 + octets. Even though this limitation was due to the required minimum UDP + reassembly limit for IPv4, it is a hard DNS protocol limit and is not + implicitly relaxed by changes in transport, for example to IPv6. + + + 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger + responses by mutual agreement of the requestor and responder. However, + deployment of EDNS0 cannot be expected to reach every Internet resolver + in the short or medium term. The 512 octet message size limit remains + in practical effect at this time. + + + 1.3. Since DNS responses include a copy of the request, the space + available for response data is somewhat less than the full 512 octets. + For negative responses, there is rarely a space constraint. For + positive and delegation responses, though, every octet must be carefully + and sparingly allocated. This document specifically addresses + delegation response sizes. + + + 2 - Delegation Details + + + 2.1. A delegation response will include the following elements: + + + Header Section: fixed length (12 octets) + Question Section: original query (name, class, type) + Answer Section: (empty) + Authority Section: NS RRset (nameserver names) + Additional Section: A and AAAA RRsets (nameserver addresses) + + + 2.2. If the total response size would exceed 512 octets, and if the data + that would not fit was in the question, answer, or authority section, + then the TC bit will be set (indicating truncation) which may cause the + requestor to retry using TCP, depending on what information was present + and what was omitted. If a retry using TCP is needed, the total cost of + the transaction is much higher. + + + 2.3. RRsets are never sent partially, so if truncation occurs, entire + RRsets are omitted. Note that the authority section consists of a + single RRset. It is absolutely essential that truncation not occur in + the authority section. + + + + + + + + + Expires December 2004 [Page 2] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 2.4. DNS label compression allows a domain name to be instantiated only + once per DNS message, and then referenced with a two-octet "pointer" + from other locations in that same DNS message. If all nameserver names + in a message are similar (for example, all ending in ".ROOT- + SERVERS.NET"), then more space will be available for uncompressable data + (such as nameserver addresses). + + + 2.5. The query name can be as long as 255 characters of presentation + data, which can be up to 256 octets of network data. In this worst case + scenario, the question section will be 260 octets in size, which would + leave only 240 octets for the authority and additional sections (after + deducting 12 octets for the fixed length header.) + + + 2.6. Average and maximum question section sizes can be predicted by the + zone owner, since they will know what names actually exist, and can + measure which ones are queried for most often. For cost and performance + reasons, the majority of requests should be satisfied without truncation + or TCP retry. + + + 2.7. Requestors who deliberately send large queries to force truncation + are only increasing their own costs, and cannot effectively attack the + resources of an authority server since the requestor would have to retry + using TCP to complete the attack. An attack that always used TCP would + have a lower cost. + + + 2.8. The minimum useful number of address records is two, since with + only one address, the probability that it would refer to an unreachable + server is too high. Truncation which occurs after two address records + have been added to the additional data section is therefore less + operationally significant than truncation which occurs earlier. + + + 2.9. The best case is no truncation. (This is because many requestors + will retry using TCP by reflex, without considering whether the omitted + data was actually necessary.) + + + + + + + + + + + + + + + + Expires December 2004 [Page 3] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 3 - Analysis + + + 3.1. An instrumented protocol trace of a best case delegation response + follows. Note that 13 servers are named, and 13 addresses are given. + This query was artificially designed to exactly reach the 512 octet + limit. + + + ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 + ;; QUERY SECTION: + ;; [23456789.123456789.123456789.\ + 123456789.123456789.123456789.com A IN] ;; @80 + + + ;; AUTHORITY SECTION: + com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 + com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 + com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 + com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 + com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 + com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 + com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 + com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 + com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 + com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 + com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 + com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 + com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 + + + ;; ADDITIONAL SECTION: + A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 + B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 + C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 + D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 + E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 + F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 + G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 + H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 + I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 + J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 + K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 + L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 + M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 + + + ;; MSG SIZE sent: 80 rcvd: 512 + + + + + + + Expires December 2004 [Page 4] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 3.2. For longer query names, the number of address records supplied will + be lower. Furthermore, it is only by using a common parent name (which + is GTLD-SERVERS.NET in this example) that all 13 addresses are able to + fit. The following output from a response simulator demonstrates these + properties: + + + % perl respsize.pl 13 13 0 + common name, average case: msg:303 nsaddr#13 (green) + common name, worst case: msg:495 nsaddr# 1 (red) + uncommon name, average case: msg:457 nsaddr# 3 (orange) + uncommon name, worst case: msg:649(*) nsaddr# 0 (red) + % perl respsize.pl 13 13 2 + common name, average case: msg:303 nsaddr#11 (orange) + common name, worst case: msg:495 nsaddr# 1 (red) + uncommon name, average case: msg:457 nsaddr# 2 (orange) + uncommon name, worst case: msg:649(*) nsaddr# 0 (red) + + + (Note: The response simulator program is shown in Section 5.) + + + Here we use the term "green" if all address records could fit, or + "orange" if two or more could fit, or "red" if fewer than two could fit. + It's clear that without a common parent for nameserver names, much space + would be lost. + + + We're assuming an average query name size of 64 since that is the + typical average maximum size seen in trace data at the time of this + writing. If Internationalized Domain Name (IDN) or any other technology + which results in larger query names be deployed significantly in advance + of EDNS, then more new measurements and new estimates will have to be + made. + + + 4 - Conclusions + + + 4.1. The current practice of giving all nameserver names a common parent + (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS + responses and allows for more nameservers to be enumerated than would + otherwise be possible. (Note that in this case it is wise to serve the + common parent domain's zone from the same servers that are named within + it, in order to limit external dependencies when all your eggs are in a + single basket.) + + + 4.2. Thirteen (13) seems to be the effective maximum number of + nameserver names usable traditional (non-extended) DNS, assuming a + common parent domain name, and assuming that additional-data truncation + is undesirable in the average case. + + + + + Expires December 2004 [Page 5] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a + prototypical delegation that currently contains thirteen (13) IPv4 + nameserver addresses (A RRs) for thirteen (13) nameserver names under a + common parent, would not have a significant negative operational impact + on the domain name system. + + + 5 - Source Code + + + #!/usr/bin/perl -w + + + $asize = 2+2+2+4+2+4; + $aaaasize = 2+2+2+4+2+16; + ($nns, $na, $naaaa) = @ARGV; + test("common", "average", common_name_average($nns), + $na, $naaaa); + test("common", "worst", common_name_worst($nns), + $na, $naaaa); + test("uncommon", "average", uncommon_name_average($nns), + $na, $naaaa); + test("uncommon", "worst", uncommon_name_worst($nns), + $na, $naaaa); + exit 0; + + + sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_; + my $nglue = numglue($msg, $na, $naaaa); + printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n", + $namekind, $casekind, + $msg, ($msg > 512) ? "(*)" : " ", + $nglue, ($nglue == $na + $naaaa) ? "green" + : ($nglue >= 2) ? "orange" + : "red"; + } + + + sub pnum { my ($num, $tot) = @_; + return sprintf "%3d%s", + } + + + sub numglue { my ($msg, $na, $naaaa) = @_; + my $space = ($msg > 512) ? 0 : (512 - $msg); + my $num = 0; + + + while ($space && ($na || $naaaa )) { + if ($na) { + if ($space >= $asize) { + $space -= $asize; + + + + + Expires December 2004 [Page 6] + INTERNET-DRAFT June 2003 RESPSIZE + + + + $num++; + } + $na--; + } + if ($naaaa) { + if ($space >= $aaaasize) { + $space -= $aaaasize; + $num++; + } + $naaaa--; + } + } + return $num; + } + + + sub msgsize { my ($qname, $nns, $nsns) = @_; + return 12 + # header + $qname+2+2 + # query + 0 + # answer + $nns * (4+2+2+4+2+$nsns); # authority + } + + + sub average_case { my ($nns, $nsns) = @_; + return msgsize(64, $nns, $nsns); + } + + + sub worst_case { my ($nns, $nsns) = @_; + return msgsize(256, $nns, $nsns); + } + + + sub common_name_average { my ($nns) = @_; + return 15 + average_case($nns, 2); + } + + + sub common_name_worst { my ($nns) = @_; + return 15 + worst_case($nns, 2); + } + + + sub uncommon_name_average { my ($nns) = @_; + return average_case($nns, 15); + } + + + sub uncommon_name_worst { my ($nns) = @_; + return worst_case($nns, 15); + } + + + + + Expires December 2004 [Page 7] + INTERNET-DRAFT June 2003 RESPSIZE + + + + Security Considerations + + + The recommendations contained in this document have no known security + implications. + + + IANA Considerations + + + This document does not call for changes or additions to any IANA + registry. + + + IPR Statement + + + Copyright (C) The Internet Society (2003-2004). This document is + subject to the rights, licenses and restrictions contained in BCP 78, + and except as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR + IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + Authors' Addresses + + + Paul Vixie + 950 Charter Street + Redwood City, CA 94063 + +1 650 423 1301 + vixie@isc.org + + + Akira Kato + University of Tokyo, Information Technology Center + 2-11-16 Yayoi Bunkyo + Tokyo 113-8658, JAPAN + +81 3 5841 2750 + kato@wide.ad.jp + + + + + + + + + + + Expires December 2004 [Page 8] \ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt new file mode 100644 index 000000000000..b593c57179e3 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt @@ -0,0 +1,617 @@ + + +Network Working Group S. Woolf +Internet-Draft Internet Systems Consortium, Inc. +Expires: January 16, 2005 D. Conrad + Nominum, Inc. + July 18, 2004 + + + Identifying an Authoritative Name `Server + draft-ietf-dnsop-serverid-02 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 16, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. A standardized mechanism to + determine the identity of a name server responding to a particular + query would be useful, particularly as a diagnostic aid. Existing ad + + + +Woolf & Conrad Expires January 16, 2005 [Page 1] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + + hoc mechanisms for addressing this concern are not adequate. This + document attempts to describe the common ad hoc solution to this + problem, including its advantages and disadvantasges, and to + characterize an improved mechanism. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 2] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +1. Introduction + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. A standardized mechanism to + determine the identity of a name server responding to a particular + query would be useful, particularly as a diagnostic aid. + + Unfortunately, existing ad-hoc mechanisms for providing such + identification have some shortcomings, not the least of which is the + lack of prior analysis of exactly how such a mechanism should be + designed and deployed. This document describes the existing + convention used in one widely deployed implementation of the DNS + protocol and discusses requirements for an improved solution to the + problem. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 3] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +2. Rationale + + Identifying which name server is responding to queries is often + useful, particularly in attempting to diagnose name server + difficulties. However, relying on the IP address of the name server + has become more problematic due the deployment of various load + balancing solutions, including the use of shared unicast addresses as + documented in [RFC3258]. + + An unfortunate side effect of these load balancing solutions is that + traditional methods of determining which server is responding can be + unreliable. Specifically, non-DNS methods such as ICMP ping, TCP + connections, or non-DNS UDP packets (e.g., as generated by tools such + as "traceroute"), etc., can end up going to a different server than + that which receives the DNS queries. + + The widespread use of the existing convention suggests a need for a + documented, interoperable means of querying the identity of a + nameserver that may be part of an anycast or load-balancing cluster. + At the same time, however, it also has some drawbacks that argue + against standardizing it as it's been practiced so far. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 4] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +3. Existing Conventions + + Recent versions of the commonly deployed Berkeley Internet Name + Domain implementation of the DNS protocol suite from the Internet + Software Consortium [BIND] support a way of identifying a particular + server via the use of a standard, if somewhat unusual, DNS query. + Specifically, a query to a late model BIND server for a TXT resource + record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will + return a string that can be configured by the name server + administrator to provide a unique identifier for the responding + server (defaulting to the value of a gethostname() call). This + mechanism, which is an extension of the BIND convention of using + CHAOS class TXT RR queries to sub-domains of the "BIND." domain for + version information, has been copied by several name server vendors. + + For reference, the other well-known name used by recent versions of + BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A + query for a TXT RR for this name will return an administratively re- + definable string which defaults to the version of the server + responding. + +3.1 Advantages + + There are several valuable attributes to this mechanism, which + account for its usefulness. + 1. This mechanism is within the DNS protocol itself. An + identification mechanism that relies on the DNS protocol is more + likely to be successful (although not guaranteed) in going to the + same machine as a "normal" DNS query. + 2. It is simple to configure. An administrator can easily turn on + this feature and control the results of the relevant query. + 3. It allows the administrator complete control of what information + is given out in the response, minimizing passive leakage of + implementation or configuration details. Such details are often + considered sensitive by infrastructure operators. + +3.2 Disadvantages + + At the same time, there are some forbidding drawbacks to the + VERSION.BIND mechanism that argue against standardizing it as it + currently operates. + 1. It requires an additional query to correlate between the answer + to a DNS query under normal conditions and the supposed identity + of the server receiving the query. There are a number of + situations in which this simply isn't reliable. + 2. It reserves an entire class in the DNS (CHAOS) for what amounts + to one zone. While CHAOS class is defined in [RFC1034] and + [RFC1035], it's not clear that supporting it solely for this + + + +Woolf & Conrad Expires January 16, 2005 [Page 5] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + + purpose is a good use of the namespace or of implementation + effort. + 3. It is implementation specific. BIND is one DNS implementation. + At the time of this writing, it is probably the most prevalent, + for authoritative servers anyway. This does not justify + standardizing on its ad hoc solution to a problem shared across + many operators and implementors. + + The first of the listed disadvantages is technically the most + serious. It argues for an attempt to design a good answer to the + problem that "I need to know what nameserver is answering my + queries", not simply a convenient one. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 6] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +4. Characteristics of an Implementation Neutral Convention + + The discussion above of advantages and disadvantages to the + HOSTNAME.BIND mechanism suggest some requirements for a better + solution to the server identification problem. These are summarized + here as guidelines for any effort to provide appropriate protocol + extensions: + 1. The mechanism adopted MUST be in-band for the DNS protocol. That + is, it needs to allow the query for the server's identifying + information to be part of a normal, operational query. It SHOULD + also permit a separate, dedicated query for the server's + identifying information. + 2. The new mechanism should not require dedicated namespaces or + other reserved values outside of the existing protocol mechanisms + for these, i.e. the OPT pseudo-RR. + 3. Support for the identification functionality SHOULD be easy to + implement and easy to enable. It MUST be easy to disable and + SHOULD lend itself to access controls on who can query for it. + 4. It should be possible to return a unique identifier for a server + without requiring the exposure of information that may be + non-public and considered sensitive by the operator, such as a + hostname or unicast IP address maintained for administrative + purposes. + 5. The identification mechanism SHOULD NOT be + implementation-specific. + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 7] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +5. IANA Considerations + + This document proposes no specific IANA action. Protocol extensions, + if any, to meet the requirements described are out of scope for this + document. Should such extensions be specified and adopted by normal + IETF process, the specification will include appropriate guidance to + IANA. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 8] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +6. Security Considerations + + Providing identifying information as to which server is responding + can be seen as information leakage and thus a security risk. This + motivates the suggestion above that a new mechanism for server + identification allow the administrator to disable the functionality + altogether or partially restrict availability of the data. It also + suggests that the serverid data should not be readily correlated with + a hostname or unicast IP address that may be considered private to + the nameserver operator's management infrastructure. + + Propagation of protocol or service meta-data can sometimes expose the + application to denial of service or other attack. As DNS is a + critically important infrastructure service for the production + Internet, extra care needs to be taken against this risk for + designers, implementors, and operators of a new mechanism for server + identification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 9] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +7. Acknowledgements + + The technique for host identification documented here was initially + implemented by Paul Vixie of the Internet Software Consortium in the + Berkeley Internet Name Daemon package. Comments and questions on + earlier drafts were provided by Bob Halley, Brian Wellington, Andreas + Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the + ICANN Root Server System Advisory Committee. The newest draft takes + a significantly different direction from previous versions, owing to + discussion among contributors to the DNSOP working group and others, + particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler, + and Rob Austein. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 10] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Woolf & Conrad Expires January 16, 2005 [Page 11] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt new file mode 100644 index 000000000000..3353b3bb423f --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt @@ -0,0 +1,1588 @@ + + Mark Foster +Internet Draft Tom McGarry +Document: James Yu + NeuStar, Inc. +Category: Informational June 24, 2002 + + + Number Portability in the GSTN: An Overview + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [RFC]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of + six months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + Copyright Notice + + Copyright (C) The Internet Society (2002). All rights reserved. + + + Abstract + + This document provides an overview of E.164 telephone number + portability (NP) in the Global Switched Telephone Network (GSTN). + NP is a regulatory imperative seeking to liberalize local telephony + service competition, by enabling end-users to retain telephone + numbers while changing service providers. NP changes the + fundamental nature of a dialed E.164 number from a hierarchical + physical routing address to a virtual address, thereby requiring the + transparent translation of the later to the former. In addition, + there are various regulatory constraints that establish relevant + parameters for NP implementation, most of which are not network + technology specific. Consequently, the implementation of NP + behavior consistent with applicable regulatory constraints, as well + as the need for interoperation with the existing GSTN NP + implementations, are relevant topics for numerous areas of IP + telephony work-in-progress at IETF. + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 1] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + Table of Contents + + 1. Introduction ............................................... 2 + 2. Abbreviations and Acronyms ................................. 4 + 3. Types of Number Portability ................................ 5 + 4. Service Provider Number Portability Schemes ................ 7 + 4.1 All Call Query (ACQ) .................................. 7 + 4.2 Query on Release (QoR) ................................ 8 + 4.3 Call Dropback ......................................... 9 + 4.4 Onward Routing (OR) ................................... 9 + 4.5 Comparisons of the Four Schemes ....................... 10 + 5. Database Queries in the NP Environment ..................... 11 + 5.1 U.S. and Canada ....................................... 12 + 5.2 Europe ................................................ 13 + 6. Call Routing in the NP Environment ......................... 14 + 6.1 U.S. and Canada ....................................... 14 + 6.2 Europe ................................................ 15 + 7. NP Implementations for Geographic E.164 Numbers ............ 17 + 8. Number Conservation Method Enabled By NP ................... 20 + 8.1 Block Pooling ......................................... 20 + 8.2 ITN Pooling ........................................... 21 + 9. Potential Implications ..................................... 21 + 10. Security Considerations .................................... 24 + 11. IANA Considerations ........................................ 24 + 12. Normative References ....................................... 24 + 13. Informative References ..................................... 25 + 14. Acknowledgement ............................................ 25 + 15. AuthorsË Addresses ......................................... 25 + + + +1. Introduction + + This document provides an overview of E.164 telephone number + portability in the Global Switched Telephone Network (GSTN). There + are considered to be three types of number portability (NP): service + provider portability (SPNP), location portability (not to be + confused with terminal mobility), and service portability. + + Service provider portability (SPNP), the focus of the present draft, + is a regulatory imperative in many countries seeking to liberalize + telephony service competition, especially local service. + Historically, local telephony service (as compared to long distance + or international service) has been regulated as a utility-like form + of service. While a number of countries had begun liberalization + (e.g. privatization, de-regulation, or re-regulation) some years + ago, the advent of NP is relatively recent (since ~1995). + + E.164 numbers can be non-geographic and geographic numbers. Non- + geographic numbers do not reveal the locations information of those + numbers. Geographic E.164 numbers were intentionally designed as + hierarchical routing addresses which could systematically be digit- + analyzed to ascertain the country, serving network provider, serving + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 2] + +Number Portability in the GSTN: An Overview June 24, 2002 + + end-office switch, and specific line of the called party. As such, + without NP a subscriber wishing to change service providers would + incur a number change as a consequence of being served off of a + different end-office switch operated by the new service provider. + The cost and convenience impact to the subscriber of changing + numbers is seen as barrier to competition. Hence NP has become + associated with GSTN infrastructure enhancements associated with a + competitive environment driven by regulatory directives. + + Forms of SPNP have been deployed or are being deployed widely in the + GSTN in various parts of the world, including the U.S., Canada, + Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). + Other regions, such as South America (e.g. Brazil) are actively + considering it. + + Implementation of NP within a national telephony infrastructure + entails potentially significant changes to numbering administration, + network element signaling, call routing and processing, billing, + service management, and other functions. + + NP changes the fundamental nature of a dialed E.164 number from a + hierarchical physical routing address to a virtual address. NP + implementations attempt to encapsulate the impacts to the GSTN and + make NP transparent to subscribers by incorporating a translation + function to map a dialed, potentially ported E.164 address, into a + network routing address (either a number prefix or another E.164 + address) which can be hierarchically routed. + + This is roughly analogous to the use of network address translation + on IP addresses to enable IP address portability by containing the + impact of the address change to the edge of the network and retain + the use of CIDR blocks in the core which can be route aggregated by + the network service provider to the rest of the internet. + + NP bifurcates the historical role of a subscriberËs E.164 address + into two or more data elements (a dialed or virtual address, and a + network routing address) that must be made available to network + elements through an NP translations database, carried by forward + call signaling, and recorded on call detail records. Not only is + call processing and routing affected, but also so is SS7/C7 + messaging. A number of TCAP-based SS7 messaging sets utilize an + E.164 address as an application-level network element address in the + global title address (GTA) field of the SCCP message header. + Consequently, SS7/C7 signaling transfer points (STPs) and gateways + need to be able to perform n-digit global title translation (GTT) to + translate a dialed E.164 address into its network address + counterpart via the NP database. + + In addition, there are various national regulatory constraints that + establish relevant parameters for NP implementation, most of which + are not network technology specific. Consequently, implementations + of NP behavior in IP telephony consistent with applicable regulatory + constraints, as well as the need for interoperation with the + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 3] + +Number Portability in the GSTN: An Overview June 24, 2002 + + existing GSTN NP implementations, are relevant topics for numerous + areas of IP telephony work-in-progress at IETF. + + This document describes three types of number portability and the + four schemes that have been standardized to support SPNP for + geographic E.164 numbersspecifically. Following that, specific + information regarding the call routing and database query + implementations are described for several regions (North American + and Europe) and industries (wireless vs. wireline). The Number + Portability Database (NPDB) interfaces and the call routing schemes + that are used in the North America and Europe are described to show + the variety of standards that may be implemented worldwide. A + glance of the NP implementations worldwide is provided. Number + pooling is briefly discussed to show how NP is being enhanced in the + U.S. to conserve North American area codes. The conclusion briefly + touches the potential impacts of NP on IP & Telecommunications + Interoperability. Appendix A provides some specific technical and + regulatory information on NP in North America. Appendix B describes + the number portability administration process that manages the + number portability database in North America. + + +2. Abbreviations and Acronyms + + ACQ All Call Query + AIN Advanced Intelligent Network + AMPS Advanced Mobile Phone System + ANSI American National Standards Institute + CDMA Code Division Multiple Access + CdPA Called Party Address + CdPN Called Party Number + CH Code Holder + CMIP Common Management Information Protocol + CS1 Capability Set 1 + CS2 Capability Set 2 + DN Directory Number + DNS Domain Name System + ETSI European Technical Standards Institute + FCI Forward Call Indicator + GAP Generic Address Parameter + GMSC Gateway Mobile Services Switching Center or Gateway Mobile + Switching Center + GSM Global System for Mobile Communications + GSTN Global Switched Telephone Network + GW Gateways + HLR Home Location Register + IAM Initial Address Message + IETF Internet Engineering Task Force + ILNP Interim LNP + IN Intelligent Network + INAP Intelligent Network Application Part + INP Interim NP + IP Internet Protocol + IS-41 Interim Standards Number 41 + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 4] + +Number Portability in the GSTN: An Overview June 24, 2002 + + ISDN Integrated Services Digital Network + ISUP ISDN User Part + ITN Individual Telephony Number + ITU International Telecommunication Union + ITU-TS ITU-Telecommunication Sector + LDAP Lightweight Directory Access Protocol + LEC Local Exchange Carrier + LERG Local Exchange Routing Guide + LNP Local Number Portability + LRN Location Routing Number + MAP Mobile Application Part + MNP Mobile Number Portability + MSRN Mobile Station Roaming Number + MTP Message Transfer Part + NANP North American Numbering Plan + NP Number Portability + NPDB Number Portability Database + NRN Network Routing Number + OR Onward Routing + OSS Operation Support System + PCS Personal Communication Services + PNTI Ported Number Translation Indicator + PODP Public Office Dialing Plan + PUC Public Utility Commission + QoR Query on Release + RN Routing Number + RTP Return to Pivot + SCCP Signaling Connection Control Part + SCP Service Control Point + SIP Session Initiation Protocol + SMR Special Mobile Radio + SMS Service Management System + SPNP Service Provider Number Portability + SRF Signaling Relaying Function + SRI Send Routing Information + SS7 Signaling System Number 7 + STP Signaling Transfer Point + TCAP Transaction Capabilities Application Part + TDMA Time Division Multiple Access + TN Telephone Number + TRIP Telephony Routing Information Protocol + URL Universal Resource Locator + U.S. United States + + +3. Types of Number Portability + + As there are several types of E.164 numbers (telephone numbers, or + just TN) in the GSTN, there are correspondingly several types of + E.164 NP in the GSTN. First there are so-call non-geographic E.164 + numbers, commonly used for service-specific applications such as + freephone (800 or 0800). Portability of these numbers is called + non-geographic number portability (NGNP). NGNP, for example, was + deployed in the U.S. in 1986-92. + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 5] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + Geographic number portability, which includes traditional fixed or + wireline numbers as well as mobile numbers which are allocated out + of geographic number range prefixes, is called NP or GNP or in the + U.S. local number portability (LNP). + + Number portability allows the telephony subscribers in the Global + Switched Telephone Network (GSTN) to keep their phone numbers when + they change their service providers or subscribed services, or when + they move to a new location. + + The ability to change the service provider while keeping the same + phone number is called service provider portability (SPNP) also + known as "operator portability." + + The ability to change the subscriberËs fixed service location while + keeping the same phone number is called location portability. + + The ability to change the subscribed services (e.g., from the plain + old telephone service to Integrated Services Digital Network (ISDN) + services) while keeping the same phone number is called service + portability. Another aspect of service portability is to allow the + subscribers to enjoy the subscribed services in the same way when + they roam outside their home networks as is supported by the + cellular/wireless networks. + + In addition, mobile number portability (MNP) refers to specific NP + implementation in mobile networks either as part of a broader NP + implementation in the GSTN or on a stand-alone basis. Where + interoperation of LNP and MNP is supported, service portability + between fixed and mobile service types is possible. + + At present, SPNP has been the primary form of NP deployed due to its + relevance in enabling local service competition. + + Also in use in the GSTN are the terms interim NP (INP) or Interim + LNP (ILNP) and true NP. Interim NP usually refers to the use of + remote call forwarding-like measures to forward calls to ported + numbers through the donor network to the new service network. These + are considered interim relative to true NP, which seeks to remove + the donor network or old service provider from the call or signaling + path altogether. Often the distinction between interim and true NP + is a national regulatory matter relative to the + technical/operational requirements imposed on NP in that country. + + Implementations of true NP in certain countries (e.g. U.S., Canada, + Spain, Belgium, Denmark) may pose specific requirements for IP + telephony implementations as a result of regulatory and industry + requirements for providing call routing and signaling independent of + the donor network or last previous serving network. + + + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 6] + +Number Portability in the GSTN: An Overview June 24, 2002 + + +4. Service Provider Number Portability Schemes + + Four schemes can be used to support service provider portability and + are briefly described below. But first, some further terms are + introduced. + + The donor network is the network that first assigned a telephone + number (e.g., TN +1-202-533-1234) to a subscriber, out of a number + range administratively (e.g., +1 202-533) assigned to it. The + current service provider (new SP) or new serving network is the + network that currently serves the ported number. The old serving + network (or old SP) is the network that previously served the ported + number before the number was ported to the new serving network. + Since a TN can port a number of times, the old SP is not necessarily + the same as the donor network, except for the first time the TN + ports away, or if the TN ports back into the donor network and away + again. While the new SP and old SP roles are transitory as a TN + ports around, the donor network is always the same for any + particular TN based on the service provider to whom the subtending + number range was administratively assigned. See the discussion + below on number pooling, as this enhancement to NP further + bifurcates the role of donor network into two (the number range or + code holder network, and the block holder network). + + To simplify the illustration, all the transit networks are ignored, + the originating or donor network is the one that performs the + database queries or call redirection, and the dialed directory + number (TN) has been ported out of the donor network before. + + It is assumed that the old serving network, the new serving network + and the donor network are different networks so as to show which + networks are involved in call handling and routing and database + queries in each of four schemes. Please note that the port of the + number (process of moving it from one network to another) happened + prior to the call setup and is not included in the call steps. + Information carried in the signaling messages to support each of the + four schemes is not discussed to simplify the explanation. + + +4.1 All Call Query (ACQ) + + Figure 1 shows the call steps for the ACQ scheme. Those call steps + are as follows: + + (1) The Originating Network receives a call from the caller and + sends a query to a centrally administered Number Portability + Database (NPDB), a copy of which is usually resident on a + network element within its network or through a third party + provider. + (2) The NPDB returns the routing number associated with the dialed + directory number. The routing number is discussed later in + Section 6. + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 7] + +Number Portability in the GSTN: An Overview June 24, 2002 + + (3) The Originating Network uses the routing number to route the + call to the new serving network. + + + +-------------+ +-----------+ Number +-----------+ + | Centralized | | New Serv. | ported | Old Serv. | + | NPDB | +-------->| Network |<------------| Network | + +-------------+ | +-----------+ +-----------+ + ^ | | + | | | + 1| | 3.| + | | 2. | + | | | + | v | + +----------+ | +----------+ +----------+ + | Orig. |------+ | Donor | | Internal | + | Network | | Network | | NPDB | + +----------+ +----------+ +----------+ + + + Figure 1 - All Call Query (ACQ) Scheme. + + +4.2 Query on Release (QoR) + + Figure 2 shows the call steps for the QoR scheme. Those call steps + are as follows: + + + +-------------+ +-----------+ Number +-----------+ + | Centralized | | New Serv. | ported | Old Serv. | + | NPDB | | Network |<------------| Network | + +-------------+ +-----------+ +-----------+ + ^ | ^ + | | 4. | + 3.| | 5. | + | | +----------------------+ + | | | + | v | + +----------+ 2. +----------+ +----------+ + | Orig. |<---------------| Donor | | Internal | + | Network |--------------->| Network | | NPDB | + +----------+ 1. +----------+ +----------+ + + + Figure 2 - Query on Release (QoR) Scheme. + + (1) The Originating Network receives a call from the caller and + routes the call to the donor network. + (2) The donor network releases the call and indicates that the + dialed directory number has been ported out of that switch. + (3) The Originating Network sends a query to its copy of the + centrally administered NPDB. + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 8] + +Number Portability in the GSTN: An Overview June 24, 2002 + + (4) The NPDB returns the routing number associated with the dialed + directory number. + (5) The Originating Network uses the routing number to route the + call to the new serving network. + + +4.3 Call Dropback + + Figure 3 shows the call steps for the Dropback scheme. This scheme + is also known as "Return to Pivot (RTP)." Those call steps are as + follows: + + (1) The Originating Network receives a call from the caller and + routes the call to the donor network. + (2) The donor network detects that the dialed directory number has + been ported out of the donor switch and checks with an internal + network-specific NPDB. + (3) The internal NPDB returns the routing number associated with the + dialed directory number. + (4) The donor network releases the call by providing the routing + number. + (5) The Originating Network uses the routing number to route the + call to the new serving network. + + +-------------+ +-----------+ Number +-----------+ + | Centralized | | New Serv. | porting | Old Serv. | + | NPDB | | Network |<------------| Network | + +-------------+ +-----------+ +-----------+ + /\ + | + 5. | + +------------------------+ + | + | + +----------+ 4. +----------+ 3. +----------+ + | Orig. |<---------------| Donor |<----------| Internal | + | Network |--------------->| Network |---------->| NPDB | + +----------+ 1. +----------+ 2. +----------+ + + + Figure 3 - Dropback Scheme. + + +4.4 Onward Routing (OR) + + Figure 4 shows the call steps for the OR scheme. Those call steps + are as follows: + + (1) The Originating Network receives a call from the caller and + routes the call to the donor network. + (2) The donor network detects that the dialed directory number has + been ported out of the donor switch and checks with an internal + network-specific NPDB. + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 9] + +Number Portability in the GSTN: An Overview June 24, 2002 + + (3) The internal NPDB returns the routing number associated with the + dialed directory number. + (4) The donor network uses the routing number to route the call to + the new serving network. + + + +-------------+ +-----------+ Number +-----------+ + | Centralized | | New Serv. | porting | Old Serv. | + | NPDB | | Network |<------------| Network | + +-------------+ +-----------+ +-----------+ + /\ + | + 4.| + | + +----------+ +----------+ 3. +----------+ + | Orig. | | Donor |<----------| Internal | + | Network |--------------->| Network |---------->| NPDB | + +----------+ 1. +----------+ 2. +----------+ + + + Figure 4 - Onward Routing (OR) Scheme. + +4.5 Comparisons of the Four Schemes + + Only the ACQ scheme does not involve the donor network when routing + the call to the new serving network of the dialed ported number. + The other three schemes involve call setup to or signaling with the + donor network. + + Only the OR scheme requires the setup of two physical call segments, + one from the Originating Network to the donor network and the other + from the donor network to the new serving network. The OR scheme is + the least efficient in terms of using the network transmission + facilities. The QoR and Dropback schemes set up calls to the donor + network first but release the call back to the Originating Network + that then initiates a new call to the Current Serving Network. For + the QoR and Dropback schemes, circuits are still reserved one by one + between the Originating Network and the donor network when the + Originating Network sets up the call towards the donor network. + Those circuits are released one by one when the call is released + from the donor network back to the Originating Network. The ACQ + scheme is the most efficient in terms of using the switching and + transmission facilities for the call. + + Both the ACQ and QoR schemes involve Centralized NPDBs for the + Originating Network to retrieve the routing information. + Centralized NPDB means that the NPDB contains ported number + information from multiple networks. This is in contrast to the + internal network-specific NPDB that is used for the Dropback and OR + schemes. The internal NPDB only contains information about the + numbers that were ported out of the donor network. The internal + NPDB can be a stand-alone database that contains information about + all or some ported-out numbers from the donor network. It can also + reside on the donor switch and only contains information about those + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 10] + +Number Portability in the GSTN: An Overview June 24, 2002 + + numbers ported out of the donor switch. In that case, no query to a + stand-alone internal NPDB is required. The donor switch for a + particular phone number is the switch to which the number range is + assigned from which that phone number was originally assigned. + + For example, number ranges in the North American Numbering Plan + (NANP) are usually assigned in the form of central office codes (CO + codes) comprising a six-digit prefix formatted as a NPA+NXX. Thus a + switch serving +1-202-533 would typically serve +1-202-533-0000 + through +1-202-533-9999. In major cities, switches usually host + several CO codes. NPA stands for Numbering Plan Area that is also + known as the area code. It is three-digit long and has the format + of NXX where N is any digit from 2 to 9 and X is any digit from 0 to + 9. NXX in the NPA+NXX format is known as the office code that has + the same format as the NPA. When a NPA+NXX code is set as + Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a + "portable NPA+NXX" code. + + Similarly, in other national E.164 numbering plans, number ranges + cover a contiguous range of numbers within that range. Once a + number within that range has ported away from the donor network, all + numbers in that range are considered potentially ported and should + be queried in the NPDB. + + The ACQ scheme has two versions. One version is for the Originating + Network to always query the NPDB when a call is received from the + caller regardless whether the dialed directory number belongs to any + number range that is portable or has at least one number ported out. + The other version is to check whether the dialed directory number + belongs to any number range that is portable or has at least one + number ported out. If yes, an NPDB query is sent. If not, no NPDB + query is sent. The former performs better when there are many + portable number ranges. The latter performs better when there are + not too many portable number ranges at the expense of checking every + call to see whether NPDB query is needed. The latter ACQ scheme is + similar to the QoR scheme except that the QoR scheme uses call setup + and relies on the donor network to indicate "number ported out" + before launching the NPDB query. + + +5. Database Queries in the NP Environment + + As indicated earlier, the ACQ and QoR schemes require that a switch + query the NPDB for routing information. Various standards have been + defined for the switch-to-NPDB interface. Those interfaces with + their protocol stacks are briefly described below. The term "NPDB" + is used for a stand-alone database that may support just one or some + or all of the interfaces mentioned below. The NPDB query contains + the dialed directory number and the NPDB response contains the + routing number. There are certainly other information that is sent + in the query and response. The primary interest is to get the + routing number from the NPDB to the switch for call routing. + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 11] + +Number Portability in the GSTN: An Overview June 24, 2002 + +5.1 U.S. and Canada + + One of the following five NPDB interfaces can be used to query an + NPDB: + + (a) Advanced Intelligent Network (AIN) using the American National + Standards Institute (ANSI) version of the Intelligent Network + Application Part (INAP) [ANSI SS] [ANSI DB]. The INAP is + carried on top of the protocol stack that includes the (ANSI) + Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling + Connection Control Part (SCCP), and ANSI Transaction + Capabilities Application Part (TCAP). This interface can be + used by the wireline or wireless switches, is specific to the NP + implementation in North America, and is modeled on the Public + Office Dialing Plan (PODP) trigger defined in the Advanced + Intelligent Network (AIN) 0.1 call model. + + (b) Intelligent Network (IN), which is similar to the one used for + querying the 800 databases. The IN protocol is carried on top + of the protocol stack that includes the ANSI MTP Levels 1 + through 3, ANSI SCCP, and ANSI TCAP. This interface can be used + by the wireline or wireless switches. + + (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the + protocol stack that includes the ANSI MTP Levels 1 through 3, + ANSI SCCP, and ANSI TCAP. This interface can be used by the IS- + 41 based cellular/Personal Communication Services (PCS) wireless + switches (e.g., AMPS, TDMA and CDMA). Cellular systems use + spectrum at 800 MHz range and PCS systems use spectrum at 1900 + MHz range. + + (d) Global System for Mobile Communication Mobile Application Part + (GSM MAP) [GSM], which is carried on top of the protocol stack + that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and + International Telecommunication Union - Telecommunication Sector + (ITU-TS) TCAP. It can be used by the PCS1900 wireless switches + that are based on the GSM technologies. GSM is a series of + wireless standards defined by the European Telecommunications + Standards Institute (ETSI). + + (e) ISUP triggerless translation. NP translations are performed + transparently to the switching network by the signaling network + (e.g. Signaling Transfer Points (STPs) or signaling gateways). + ISUP IAM messages are examined to determine if the CdPN field + has already been translated, and if not, an NPDB query is + performed, and the appropriate parameters in the IAM message + modified to reflect the results of the translation. The + modified IAM message is forwarded by the signaling node on to + the designated DPC in a transparent manner to continue call + setup. The NPDB can be integrated with the signaling node or be + accessed via an API locally or by a query to a remote NPDB using + a proprietary protocol or the schemes described above. + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 12] + +Number Portability in the GSTN: An Overview June 24, 2002 + + Wireline switches have the choice of using either (a), (b), or (e). + IS-41 based wireless switches have the choice of using (a), (b), + (c), or (e). PCS1900 wireless switches have the choice of using + (a), (b), (d), or (e). In the United States, service provider + portability will be supported by both the wireline and wireless + systems, not only within the wireline or wireless domain but also + across the wireline/wireless boundary. However, this is not true in + Europe where service provider portability is usually supported only + within the wireline or wireless domain, not across the + wireline/wireless boundary due to explicit use of service-specific + number range prefixes. The reason is to avoid caller confusion + about the call charge. GSM systems in Europe are assigned + distinctive destination network codes, and the caller pays a higher + charge when calling a GSM directory number. + + +5.2 Europe + + One of the following two interfaces can be used to query an NPDB: + + (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is + carried on top of the protocol stack that includes the ITU-TS + MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. + + (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is + carried on top of the protocol stack that includes the ITU-TS + MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, + and ITU-TS TCAP. + + Wireline switches have the choice of using either (a) or (b); + however, all the implementations in Europe so far are based on CS1. + As indicated earlier that number portability in Europe does not go + across the wireline/wireless boundary. The wireless switches can + also use (a) or (b) to query the NPDBs if those NPDBs contains + ported wireless directory numbers. The term "Mobile Number + Portability (MNP)" is used for the support of service provider + portability by the GSM networks in Europe. + + In most, if not all, cases in Europe, the calls to the wireless + directory numbers are routed to the wireless donor network first. + Over there, an internal NPDB is queried to determine whether the + dialed wireless directory number has been ported out or not. In + this case, the interface to the internal NPDB is not subject to + standardization. + + MNP in Europe can also be supported via MNP Signaling Relay Function + (MNP-SRF). Again, an internal NPDB or a database integrated at the + MNP-SRF is used to modify the SCCP Called Party Address parameter in + the GSM MAP messages so that they can be re-directed to the wireless + serving network. Call routing involving MNP will be explained in + Section 6.2. + + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 13] + +Number Portability in the GSTN: An Overview June 24, 2002 + +6. Call Routing in the NP Environment + + This section discusses the call routing after the routing + information has been retrieved either through an NPDB query or an + internal database lookup at the donor switch, or from the Integrated + Services Digital Network User Part (ISUP) signaling message (e.g., + for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it + is the Originating Network that has the routing information and is + ready to route the call. For the OR scheme, it is the donor network + that has the routing information and is ready to route the call. + + A number of triggering schemes may be employed that determine where + in the call path the NPDB query is performed. In the U.S. an ŸN-1÷ + policy is used, which essentially says that for domestic calls, the + originating local carriers performs the query, otherwise, the long + distance carrier is expected to. To ensure independence of the + actual trigger policy employed in any one carrier, forward call + signaling is used to flag that an NPDB query has already been + performed and to therefore suppress any subsequent NP triggers that + may be encountered in downstream switches, in downstream networks. + This allows the earliest able network in the call path to perform + the query without introducing additional costs and call setup delays + were redundant queries performed downstream. + + +6.1 U.S. and Canada + + In the U.S. and Canada, a ten-digit North American Numbering Plan + (NANP) number called Location Routing Number (LRN) is assigned to + every switch involved in NP. In the NANP, a switch is not reachable + unless it has a unique number range (CO code) assigned to it. + Consequently, the LRN for a switch is always assigned out of a CO + code that is assigned to that switch. + + The LRN assigned to a switch currently serving a particular ported + telephone number is returned as the network routing address in the + NPDB response. The service portability scheme that was adopted in + the North America is very often referred to as the LRN scheme or + method. + + LRN serves as a network address for terminating calls served off + that switch using ported numbers. The LRN is assigned by the switch + operator using any of the unique CO codes (NPA+NXX) assigned to that + switch. The LRN is considered a non-dialable address, as the same + 10-digit number value may be assigned to a line on that switch. A + switch may have more than one LRN. + + During call routing/processing, a switch performs an NPDB query to + obtain the LRN associated with the dialed directory number. NPDB + queries are performed for all the dialed directory numbers whose + NPA+NXX codes are marked as portable NPA+NXX at that switch. When + formulating the ISUP Initial Address Message (IAM) to be sent to the + next switch, the switch puts the ten-digit LRN in the ISUP Called + Party Number (CdPN) parameter and the originally dialed directory + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 14] + +Number Portability in the GSTN: An Overview June 24, 2002 + + number in the ISUP Generic Address parameter (GAP). A new code in + the GAP was defined to indicate that the address information in the + GAP is the dialed directory number. A new bit in the ISUP Forward + Call Indicator (FCI) parameter, the Ported Number Translation + Indicator (PNTI) bit, is set to imply that NPDB query has already + been performed. All the switches in the downstream will not perform + the NPDB query if the PNTI bit is set. + + When the terminating switch receives the IAM and sees the PNTI bit + in the FCI parameter set and its own LRN in the CdPN parameter, it + retrieves the originally dialed directory number from the GAP and + uses the dialed directory number to terminate the call. + + A dialed directory number with a portable NPA+NXX does not imply + that directory number has been ported. The NPDBs currently do not + store records for non-ported directory numbers. In that case, the + NPDB will return the same dialed directory number instead of the + LRN. The switch will then set the PNTI bit but keep the dialed + directory number in the CdPN parameter. + + In the real world environment, the Originating Network is not always + the one that performs the NPDB query. For example, it is usually + the long distance carriers that query the NPDBs for long distance + calls. In that case, the Originating Network operated by the local + exchange carrier (LEC) simply routes the call to the long distance + carrier that is to handle that call. A wireless network acting as + the Originating Network can also route the call to the + interconnected local exchange carrier network if it does not want to + support the NPDB interface at its mobile switches. + + +6.2 Europe + + In some European countries, a routing number is prefixed to the + dialed directory number. The ISUP CdPN parameter in the IAM will + contain the routing prefix and the dialed directory number. For + example, United Kingdom uses routing prefixes with the format of + 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks + use the information in the ISUP CdPN parameter to route the call to + the New/Current Serving Network. + + The routing prefix can identify the Current Serving Network or the + Current Serving Switch of a ported number. For the former case, + another query to the "internal" NPDB at the Current Serving Network + is required to identify the Current Serving Switch before routing + the call to that switch. This shields the Current Serving Switch + information for a ported number from the other networks at the + expense of an additional NPDB query. Another routing number, may be + meaningful within the Current Serving Network, will replace the + previously prefixed routing number in the ISUP CdPN parameter. For + the latter case, the call is routed to the Current Serving Switch + without an additional NPDB query. + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 15] + +Number Portability in the GSTN: An Overview June 24, 2002 + + When the terminating switch receives the IAM and sees its own + routing prefix in the CdPN parameter, it retrieves the originally + dialed directory number after the routing prefix, and uses the + dialed directory number to terminate the call. + + The call routing example described above shows one of the three + methods that can be used to transport the Directory Number (DN) and + the Routing Number (RN) in the ISUP IAM message. In addition, some + other information may be added/modified as is listed in the ETSI 302 + 097 document [ETSIISUP], which is based on the ITU-T Recommendation + Q.769.1 [ITUISUP]. The three methods and the enhancements in the + ISUP to support number portability are briefly described below + + (a) Two separate parameters with the CdPN parameter containing the + RN and a new Called Directory Number (CdDN) parameter containing + the DN. A new value for the Nature of Address (NOA) indicator in + the CdPN parameter is defined to indicate that the RN is in the + CdPN parameter. The switches use the CdPN parameter to route the + call as is done today. + + (b) Two separate parameters with the CdPN parameter containing the + DN and a new Network Routing Number (NRN) parameter containing + the RN. This method requires that the switches use the NRN + parameter to route the call. + + (c) Concatenated parameter with the CdPN parameter containing the RN + plus the DN. A new Nature of Address (NOA) indicator in the CdPN + parameter is defined to indicate that the RN is concatenated with + the DN in the CdPN parameter. Some countries may not use new NOA + value because the routing prefix does not overlap with the dialed + directory numbers. But if the routing prefix overlaps with the + dialed directory numbers, a new NOA value must be assigned. For + example, Spain uses "XXXXXX" as the routing prefix to identify + the new serving network and uses a new NOA value of 126. + + There is also a network option to add a new ISUP parameter called + Number Portability Forwarding Information parameter. This parameter + has a four-bit Number Portability Status Indicator field that can + provide an indication whether number portability query is done for + the called directory number and whether the called directory number + is ported or not if the number portability query is done. + + Please note that all those NP enhancements for a ported number can + only be used in the country that defined them. This is because + number portability is supported within a nation. Within each + nation, the telecommunications industry or the regulatory bodies can + decide which method or methods to use. Number portability related + parameters and coding are usually not passed across the national + boundaries unless the interconnection agreements allow that. For + example, a UK routing prefix can only be used in UK, and would cause + routing problem if it appears outside UK. + + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 16] + +Number Portability in the GSTN: An Overview June 24, 2002 + + As indicated earlier, an originating wireless network can query the + NPDB and concatenate the RN with DN in the CdPN parameter and route + the call directly to the Current Serving Network. + + If NPDBs do not contain information about the wireless directory + numbers, the call, originated from either a wireline or a wireless + network, will be routed to the Wireless donor network. Over there, + an internal NPDB is queried to retrieve the RN that then is + concatenated with the DN in the CdPN parameter. + + There are several ways of realizing MNP. When MNP-SRF is supported, + the Gateway Mobile Services Switching Center (GMSC) at the wireless + donor network, when receiving a call from the wireline network, can + send the GSM MAP Send Routing Information (SRI) message to the MNP- + SRF. The MNP-SRF interrogates an internal or integrated NPDB for + the RN of the MNP-SRF of the wireless Current Serving Network and + prefixes the RN to the dialed wireless directory number in the + global title address information in the SCCP Called Party Address + (CdPA) parameter. This SRI message will be routed to the MNP-SRF of + the wireless Current Serving Network, which then responds with an + acknowledgement by providing the RN plus the dialed wireless + directory number as the Mobile Station Roaming Number (MSRN). The + GMSC of the wireless donor network formulates the ISUP IAM with the + RN plus the dialed wireless directory number in the CdPN parameter + and routes the call to the wireless Current Serving Network. A GMSC + of the wireless Current Serving Network receives the call and sends + an SRI message to the associated MNP-SRF where the global title + address information of the SCCP CdPA parameter contains only the + dialed wireless directory number. The MNP-SRF then replaces the + global title address information in the SCCP CdPA parameter with the + address information associated with a Home Location Register (HLR) + that hosts the dialed wireless directory number and forwards the + message to that HLR after verifying that the dialed wireless + directory number is a ported-in number. The HLR then returns an + acknowledgement by providing an MSRN for the GMSC to route the call + to the MSC that currently serves the mobile station that is + associated with the dialed wireless directory number. Please see + [MNP] for details and additional scenarios. + + +7. NP Implementations for Geographic E.164 Numbers + + This section shows the known SPNP implementations worldwide. + + +-------------+----------------------------------------------------+ + + Country + SPNP Implementation + + +-------------+----------------------------------------------------+ + + Argentina + Analyzing operative viability now. Will determine + + + + whether portability should be made obligatory + + + + after a technical solution has been determined. + + +-------------+----------------------------------------------------+ + + Australia + NP supported by wireline operators since 11/30/99. + + + + NP among wireless operators in March/April 2000, + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 17] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + + but may be delayed to 1Q01. The access provider + + + + or long distance provider has the obligation to + + + + route the call to the correct destination. The + + + + donor network is obligated to maintain and make + + + + available a register of numbers ported away from + + + + its network. Telstra uses onward routing via an + + + + on-switch solution. + + +-------------+----------------------------------------------------+ + + Austria + Uses onward routing at the donor network. Routing + + + + prefix is "86xx" where "xx" identifies the + + + + recipient network. + + +-------------+----------------------------------------------------+ + + Belgium + ACQ selected by the industry. Routing prefix is + + + + "Cxxxx" where "xxxx" identifies the recipient + + + + switch. Another routing prefix is "C00xx" with "xx"+ + + + identifying the recipient network. Plan to use NOA+ + + + to identify concatenated numbers and abandon the + + + + hexadecimal routing prefix. + + +-------------+----------------------------------------------------+ + + Brazil + Considering NP for wireless users. + + +-------------+----------------------------------------------------+ + + Chile + There has been discussions lately on NP. + + +-------------+----------------------------------------------------+ + + Colombia + There was an Article 3.1 on NP to support NP prior + + + + to December 31, 1999 when NP became technically + + + + possible. Regulator has not yet issued regulations + + + + concerning this matter. + + +-------------+----------------------------------------------------+ + + Denmark + Uses ACQ. Routing number not passed between + + + + operators; however, NOA is set to "112" to + + + + indicate "ported number." QoR can be used based + + + + on bilateral agreements. + + +-------------+----------------------------------------------------+ + + Finland + Uses ACQ. Routing prefix is "1Dxxy" where "xxy" + + + + identifies the recipient network and service type. + + +-------------+----------------------------------------------------+ + + France + Uses onward routing. Routing prefix is "Z0xxx" + + + + where "xxx" identifies the recipient switch. + + +-------------+----------------------------------------------------+ + + Germany + The originating network needs to do necessary + + + + rerouting. Operators decide their own solution(s).+ + + + Deutsche Telekom uses ACQ. Routing prefix is + + + + "Dxxx" where "xxx" identifies the recipient + + + + network. + + +-------------+----------------------------------------------------+ + + Hong Kong + Recipient network informs other networks about + + + + ported-in numbers. Routing prefix is "14x" where + + + + "14x" identifies the recipient network, or a + + + + routing number of "4x" plus 7 or 8 digits is used + + + + where "4x" identifies the recipient network and + + + + the rest of digits identify the called party. + + +-------------+----------------------------------------------------+ + + Ireland + Operators choose their own solution but use onward + + + + routing now. Routing prefix is "1750" as the intra-+ + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 18] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + + network routing code (network-specific) and + + + + "1752xxx" to "1759xxx" for GNP where "xxx" + + + + identifies the recipient switch. + + +-------------+----------------------------------------------------+ + + Italy + Uses onward routing. Routing prefix is "C600xxxxx" + + + + where "xxxxx" identifies the recipient switch. + + + + Telecom Italia uses IN solution and other operators+ + + + use on-switch solution. + + +-------------+----------------------------------------------------+ + + Japan + Uses onward routing. Donor switch uses IN to get + + + + routing number. + + +-------------+----------------------------------------------------+ + + Mexico + NP is considered in the Telecom law; however, the + + + + regulator (Cofetel) or the new local entrants have + + + + started no initiatives on this process. + + +-------------+----------------------------------------------------+ + + Netherlands + Operators decide NP scheme to use. Operators have + + + + chosen ACQ or QoR. KPN implemented IN solution + + + + similar to U.S. solution. Routing prefix is not + + + + passed between operators. + + +-------------+----------------------------------------------------+ + + Norway + OR for short-term and ACQ for long-term. QoR is + + + + optional. Routing prefix can be "xxx" with NOA=8, + + + + or "142xx" with NOA=3 where "xxx" or "xx" + + + + identifies the recipient network. + + +------------ +----------------------------------------------------+ + + Peru + Wireline NP may be supported in 2001. + + +-------------+----------------------------------------------------+ + + Portugal + No NP today. + + +-------------+----------------------------------------------------+ + + Spain + Uses ACQ. Telefonica uses QoR within its network. + + + + Routing prefix is "xxyyzz" where "xxyyzz" + + + + identifies the recipient network. NOA is set to + + + + 126. + + +-------------+----------------------------------------------------+ + + Sweden + Standardized the ACQ but OR for operators without + + + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + + + + with NOA=3 where "xxx" identifies the recipient + + + + network. But operators decide NP scheme to use. + + + + Telia uses onward routing between operators. + + +-------------+----------------------------------------------------+ + + Switzerland + Uses OR now and QoR in 2001. Routing prefix is + + + + "980xxx" where "xxx" identifies the recipient + + + + network. + + +-------------+----------------------------------------------------+ + + UK + Uses onward routing. Routing prefix is "5xxxxx" + + + + where "xxxxx" identifies the recipient switch. NOA + + + + is 126. BT uses the dropback scheme in some parts + + + + of its network. + + +-------------+----------------------------------------------------+ + + US + Uses ACQ. "Location Routing Number (LRN)" is used + + + + in the Called Party Number parameter. Called party+ + + + number is carried in the Generic Address Parameter + + + + Use a PNTI indicator in the Forward Call Indicator + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 19] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + + parameter to indicate that NPDB dip has been + + + + performed. + + +-------------+----------------------------------------------------+ + + +8. Number Conservation Methods Enabled by NP + + In addition to porting numbers NP provides the ability for number + administrators to assign numbering resources to operators in smaller + increments. Today it is common for numbering resources to be + assigned to telephone operators in a large block of consecutive + telephone numbers (TNs). For example, in North America each of + these blocks contains 10,000 TNs and is of the format NXX+0000 to + NXX+9999. Operators are assigned a specific NXX, or block. That + operator is referred to as the block holder. In that block there + are 10,000 TNs with line numbers ranging from 0000 to 9999. + + Instead of assigning an entire block to the operator NP allows the + administrator to assign a sub-block or even an individual telephone + number. This is referred to as block pooling and individual + telephone number (ITN) pooling, respectively. + + +8.1 Block Pooling + + Block Pooling refers to the process whereby the number administrator + assigns a range of numbers defined by a logical sub-block of the + existing block. Using North America as an example, block pooling + would allow the administrator to assign sub-blocks of 1,000 TNs to + multiple operators. That is, NXX+0000 to NXX+0999 can be assigned + to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, + NXX-2000 to 2999 can be assigned to operator C, etc. In this + example block pooling divides one block of 10,000 TNs into ten + blocks of 1,000 TNs. + + Porting the sub-blocks from the block holder enables block pooling. + Using the example above operator A is the block holder, as well as, + the holder of the first sub-block, NXX+0000 to NXX+0999. The second + sub-block, NXX+1000 to NXX+1999, is ported from operator A to + operator B. The third sub-block, NXX+2000 to NXX+2999, is ported + from operator A to operator C, and so on. NP administrative + processes and call processing will enable proper and efficient + routing. + + From a number administration and NP administration perspective block + pooling introduces a new concept, that of the sub-block holder. + Block pooling requires coordination between the number + administrator, the NP administrator, the block holder, and the sub- + block holder. Block pooling must be implemented in a manner that + allows for NP within the sub-blocks. Each TN can have a different + serving operator, sub-block holder, and block holder. + + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 20] + +Number Portability in the GSTN: An Overview June 24, 2002 + +8.2 ITN Pooling + + ITN pooling refers to the process whereby the number administrator + assigns individual telephone numbers to operators. Using the North + American example, one block of 10,000 TNs can be divided into 10,000 + ITNs. ITN is more commonly deployed in freephone services. + + In ITN the block is not assigned to an operator but to a central + administrator. The administrator then assigns ITNs to operators. + NP administrative processes and call processing will enable proper + and efficient routing. + + +9. Potential Implications + + There are three general areas of impact to IP telephony work-in- + progress at IETF: + + - Interoperation between NP in GSTN and IP telephony + - NP implementation or emulation in IP telephony + - Interconnection to NP administrative environment + + A good understanding of how number portability is supported in the + GSTN is important when addressing the interworking issues between + IP-based networks and the GSTN. This is especially important when + the IP-based network needs to route the calls to the GSTN. As shown + in Section 5, there are a variety of standards with various protocol + stacks for the switch-to-NPDB interface. Not only that, the + national variations of the protocol standards make it very + complicated to deal with in a global environment. If an entity in + the IP-based network needs to query those existing NPDBs for routing + number information to terminate the calls to the destination GSTN, + it would be impractical, if not an impossible, job for that entity + to support all those interface standards to access the NPDBs in many + countries. + + Several alternatives may address this particular problem. One + alternative is to use certain entities in the IP-based networks for + dealing with NP query, similar to the International Switches that + are used in the GSTN to interwork different national ISUP + variations. This will force signaling information associated with + the calls to certain NP-capable networks in the terminating GSTN to + be routed to those IP entities that support the NP functions. Those + IP entities then query the NPDBs in the terminating country. This + will limit the number of NPDB interfaces that certain IP entities + need to support. Another alternative can be to define a "common" + interface to be supported by all the NPDBs so that all the IP + entities use that standardized protocol to query them. The + existing NPDBs can support this additional interface, or new NPDBs + can be deployed that contain the same information but support the + common IP interface. The candidates for such a common interface + include Lightweight Directory Access Protocol (LDAP) and SIP + [SIP](e.g., using the SIP redirection capability). Certainly + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 21] + +Number Portability in the GSTN: An Overview June 24, 2002 + + another possibility is to use interworking function to convert from + one protocol to another. + + IP-based networks can handle the domestic calls between two GSTNs. + If the originating GSTN has performed NPDB query, SIP will need to + transport and make use of some of the ISUP signaling information + even if ISUP signaling may be encapsulated in SIP. Also, IP-based + networks may perform the NPDB queries, as the N-1 carrier. In that + case, SIP also needs to transport the NP related information while + the call is being routed to the destination GSTN. There are three + pieces of NP related information that SIP needs to transport. They + are 1) the called directory number, 2) a routing number, and 3) a + NPDB dip indicator. The NPDB dip indicator is needed so that the + terminating GSTN will not perform another NPDB dip. The routing + number is needed so that it is used to route the call to the + destination network or switch in the destination GSTN. The called + directory number is needed so that the terminating GSTN switch can + terminate the call. When the routing number is present, the NPDB + dip indicator may not be present because there are cases where + routing number is added for routing the call even if NP is not + involved. One issue is how to transport the NP related information + via SIP. The SIP Universal Resource Locator (URL) is one mechanism. + Another better choice may be to add an extension to the "tel" URL + [TEL] that is also supported by SIP. Please see [TELNP] for the + proposed extensions to the "tel" URL to support NP and freephone + service. Those extensions to the "tel" URL will be automatically + supported by SIP because they can be carried as the optional + parameters in the user portion of the "sip" URL. + + For a called directory number that belongs to a country that + supports NP, and if the IP-based network is to perform the NPDB + query, the logical step is to perform the NPDB dip first to retrieve + the routing number and use that routing number to select the correct + IP telephony gateways that can reach the serving switch that serves + the called directory number. Therefore, if the "rn" parameter is + present in the "tel" URL or sip URL in the SIP INVITE message, it + instead of the called directory number should be used for making + routing decisions assuming that no other higher priority routing- + related parameters such as the Ÿcic÷ are present. If "rn" is not + present, then the dialed directory number can be used as the routing + number for making routing decisions. + + Telephony Routing Information Protocol (TRIP) [TRIP] is a policy + driven inter-administrative domain protocol for advertising the + reachability of telephony destinations between location servers, and + for advertising attributes of the routes to those destinations. + With the NP in mind, it is very important to know that it is the + routing number, if present, not the called directory number that + should be used to check against the TRIP tables for making the + routing decisions. + + Overlap signaling exists in the GSTN today. For a call routing from + the originating GSTN to the IP-based network that involves overlap + signaling, NP will impact the call processing within the IP-based + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 22] + +Number Portability in the GSTN: An Overview June 24, 2002 + + networks if they must deal with the overlap signaling. The entities + in the IP-based networks that are to retrieve the NP information + (e.g., the routing number) must collect a complete called directory + number information before retrieving the NP information for a ported + number. Otherwise, the information retrieval won't be successful. + This is an issue for the IP-based networks if the originating GSTN + does not handle the overlap signaling by collecting the complete + called directory number. + + The IETF enum working group is defining the use of Domain Name + System (DNS) for identifying available services associated with a + particular E.164 number [ENUM]. [ENUMPO] outlines the principles + for the operation of a telephone number service that resolves + telephone numbers into Internet domain name addresses and service- + specific directory discovery. [ENUMPO] implements a three-level + approach where the first level is the mapping of the telephone + number delegation tree to the authority to which the number has been + delegated, the second level is the provision of the requested DNS + resource records from a service registrar, and the third level is + the provision of service specific data from the service provider + itself. NP certainly must be considered at the first level because + the telephony service providers do not "own" or control the + telephone numbers under the NP environment; therefore, they may not + be the proper entities to have the authority for a given E.164 + number. Not only that, there is a regulatory requirement on NP in + some countries that the donor network should not be relied on to + reach the delegated authority during the DNS process . The + delegated authority for a given E.164 number is likely to be an + entity designated by the end user that owns/controls a specific + telephone number or one that is designated by the service registrar. + + Since the telephony service providers may have the need to use ENUM + for their network-related services (e.g., map an E.164 number to a + HLR Identifier in the wireless networks), their ENUM records must be + collocated with those of the telephony subscribers. If that is the + case, NP will impact ENUM when a telephony subscriber who has ENUM + service changes the telephony service provider. This is because + that the ENUM records from the new telephony service provider must + replace those from the old telephony service provider. To avoid the + NP impact on ENUM, it is recommended that the telephony service + providers use a different domain tree for their network-related + service. For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a + domain tree different from e164.arpa should be used for Ÿcarrier÷ + ENUM. + + The IP-based networks also may need to support some forms of number + portability in the future if E.164 numbers [E164] are assigned to + the IP-based end users. One method is to assign a GSTN routing + number for each IP-based network domain or entity in a NP-capable + country. This may increase the number of digits in the routing + number to incorporate the IP entities and impact the existing + routing in the GSTN. Another method is to associate each IP entity + with a particular GSTN gateway. At that particular GSTN gateway, + the called directory number then is used to locate the IP-entity + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 23] + +Number Portability in the GSTN: An Overview June 24, 2002 + + that serves that dialed directory number. Yet, another method can + be to assign a special routing number so that the call to an end + user currently served by an IP entity is routed to the nearest GSTN + gateway. The called directory number then is used to locate the IP- + entity that serves that dialed directory number. A mechanism can be + developed or used for the IP-based network to locate the IP entity + that serves a particular dialed directory number. Many other types + of networks use E.164 numbers to identify the end users or terminals + in those networks. Number portability among GSTN, IP-based network + and those various types of networks may also need to be supported in + the future. + + +10. Security Considerations + + This document does not raise any security issues. + + +11. IANA Considerations + + This document introduces no new values for IANA registration. + + +12. Normative References + + [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability - + Operator Services Switching Systems," April 1999. + + [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability - + Switching Systems," April 1999. + + [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability + Database and Global Title Translation," April 1999. + + [CS1] ITU-T Q-series Recommendations - Supplement 4, "Number + portability Capability set 1 requirements for service provider + portability (All call query and onward routing)," May 1998. + + [CS2] ITU-T Q-series Recommendations - Supplement 5, "Number + portability -Capability set 2 requirements for service provider + portability (Query on release and Dropback)," March 1999. + + [E164] ITU-T Recommendation E.164, "The International Public + Telecommunications Numbering Plan," 1997. + + [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. + + [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital + Network (ISDN); Signalling System No.7 (SS7); ISDN User Part + (ISUP); Enhancement for support of Number Portability (NP) + [ITU-T Recommendation Q.769.1 (2000), modified] + + [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase + 2+); Mobile Application Part (MAP) specification". + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 24] + +Number Portability in the GSTN: An Overview March 1, 2002 + + + + [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for + Wireless Number Portability Phase II (December 1998)"Number + Portability Network Support," April 1998. + + [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - + ISDN User Part Enhancements for the Support of Number + Portability," December 1999. + + [MNP] ETSI EN 301 716 (2000-10) European Standard + (Telecommunications series) Digital cellular telecommunications + system (Phase 2+); Support of Mobile Number Portability (MNP); + Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 + Release 1998). + + [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- + Revision 3," October 1996. + + +13. Informative References + + [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific + Provisioning: Principles of Operations," draft-ietf-enum- + operation-02.txt, February 23, 2001. + + [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: + Session Initiation Protocol," February 27, 2002. + + [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis- + 04.txt, "URIs for Telephone Calls," May 24, 2002. + + [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL + to support Number Portability and Freephone Service," June 14, + 2002. + + [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony + Routing Information Protocol (TRIP)," January 2002. + + +14. Acknowledgment + + The authors would like to thank Monika Muench for providing + information on ISUP and MNP. + + +15. Authors' Addresses + + Mark D. Foster + NeuStar, Inc. + 1120 Vermont Avenue, NW, + Suite 400 + Washington, D.C. 20005 + United States + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 25] + +Number Portability in the GSTN: An Overview March 1, 2002 + + + + Phone: +1-202-533-2800 + Fax: +1-202-533-2987 + Email: mark.foster@neustar.biz + + Tom McGarry + NeuStar, Inc. + 1120 Vermont Avenue, NW, + Suite 400 + Washington, D.C. 20005 + United States + + Phone: +1-202-533-2810 + Fax: +1-202-533-2987 + Email: tom.mcgarry@neustar.biz + + James Yu + NeuStar, Inc. + 1120 Vermont Avenue, NW, + Suite 400 + Washington, D.C. 20005 + United States + + Phone: +1-202-533-2814 + Fax: +1-202-533-2987 + Email: james.yu@neustar.biz + + + +Full Copyright Statement + + "Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 26] + +Number Portability in the GSTN: An Overview March 1, 2002 + + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 27] + \ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt b/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt new file mode 100644 index 000000000000..423a119f39f8 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt @@ -0,0 +1,951 @@ + + +IPSECKEY WG M. Richardson +Internet-Draft SSW +|Expires: August 1, 2004 February 2004 + + + A Method for Storing IPsec Keying Material in DNS +| draft-ietf-ipseckey-rr-09.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +| This Internet-Draft will expire on August 1, 2004. + +Copyright Notice + +| Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + +| This document describes a new resource record for Domain Name System +| (DNS). This record may be used to store public keys for use in IP +| security (IPsec) systems. The record also includes provisions for +| indicating what system should be contacted when establishing an IPsec +| tunnel with the entity in question. + + This record replaces the functionality of the sub-type #1 of the KEY + Resource Record, which has been obsoleted by RFC3445. + + + + + + + +|Richardson Expires August 1, 2004 [Page 1] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 +| 1.2 Use of reverse (in-addr.arpa) map . . . . . . . . . . . . . . 3 +| 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3 +| 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 5 +| 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5 +| 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5 +| 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . . 5 +| 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . . 6 +| 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6 +| 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 6 +| 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 8 +| 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 8 +| 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 +| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 +| 4.1 Active attacks against unsecured IPSECKEY resource records . . 10 +| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 +| 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 13 +| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 +| Normative references . . . . . . . . . . . . . . . . . . . . . 15 +| Non-normative references . . . . . . . . . . . . . . . . . . . 16 +| Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 +| Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 + + + + + + + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 2] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +1. Introduction + + It postulated that there is an end system desiring to establish an + IPsec tunnel with some remote entity on the network. This system, + having only a DNS name of some kind (forward, reverse or even + user@FQDN) needs a public key to authenticate the remote entity. It + also desires some guidance about whether to contact the entity + directly, or whether to contact another entity, as the gateway to + that desired entity. + + The IPSECKEY RR provides a storage mechanism for such items as the + public key, and the gateway information. + + The type number for the IPSECKEY RR is TBD. + +1.1 Overview + + The IPSECKEY resource record (RR) is used to publish a public key + that is to be associated with a Domain Name System (DNS) name for use + with the IPsec protocol suite. This can be the public key of a + host, network, or application (in the case of per-port keying). + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC2119 [7]. + +|1.2 Use of reverse (in-addr.arpa) map + +| Often a security gateway will only have access to the IP address to +| which communication is desired. It will not know the forward name. +| As such, it will frequently be the case that the IP address will be +| used an index into the reverse map. + +| The lookup is done in the usual fashion as for PTR records. The IP +| address' octets (IPv4) or nibbles (IPv6) are reversed and looked up +| under the .arpa. zone. Any CNAMEs or DNAMEs found SHOULD be +| followed. + +| Note: even when the IPsec function is the end-host, often only the +| application will know the forward name used. While the case where +| the application knows the forward name is common, the user could +| easily have typed in a literal IP address. This storage mechanism +| does not preclude using the forward name when it is available, but +| does not require it. + +|1.3 Usage Criteria + + An IPSECKEY resource record SHOULD be used in combination with DNSSEC + + + +|Richardson Expires August 1, 2004 [Page 3] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + + unless some other means of authenticating the IPSECKEY resource + record is available. + + It is expected that there will often be multiple IPSECKEY resource + records at the same name. This will be due to the presence of + multiple gateways and the need to rollover keys. + + This resource record is class independent. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 4] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +2. Storage formats + +2.1 IPSECKEY RDATA format + + The RDATA for an IPSECKEY RR consists of a precedence value, a + gateway type, a public key, algorithm type, and an optional gateway + address. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | precedence | gateway type | algorithm | gateway | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + + ~ gateway ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + +2.2 RDATA format - precedence + + This is an 8-bit precedence for this record. This is interpreted in + the same way as the PREFERENCE field described in section 3.3.9 of + RFC1035 [2]. + + Gateways listed in IPSECKEY records with lower precedence are to be + attempted first. Where there is a tie in precedence, the order + should be non-deterministic. + +2.3 RDATA format - gateway type + + The gateway type field indicates the format of the information that + is stored in the gateway field. + + The following values are defined: + + 0 No gateway is present + + 1 A 4-byte IPv4 address is present + + 2 A 16-byte IPv6 address is present + + 3 A wire-encoded domain name is present. The wire-encoded format is + self-describing, so the length is implicit. The domain name MUST + NOT be compressed. (see section 3.3 of RFC1035 [2]). + + + + +|Richardson Expires August 1, 2004 [Page 5] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +2.4 RDATA format - algorithm type + + The algorithm type field identifies the public key's cryptographic + algorithm and determines the format of the public key field. + + A value of 0 indicates that no key is present. + + The following values are defined: + + 1 A DSA key is present, in the format defined in RFC2536 [10] + + 2 A RSA key is present, in the format defined in RFC3110 [11] + + +2.5 RDATA format - gateway + + The gateway field indicates a gateway to which an IPsec tunnel may be + created in order to reach the entity named by this resource record. + + There are three formats: + + A 32-bit IPv4 address is present in the gateway field. The data + portion is an IPv4 address as described in section 3.4.1 of RFC1035 + [2]. This is a 32-bit number in network byte order. + + A 128-bit IPv6 address is present in the gateway field. The data + portion is an IPv6 address as described in section 2.2 of RFC3596 + [13]. This is a 128-bit number in network byte order. + + The gateway field is a normal wire-encoded domain name, as described + in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. + +2.6 RDATA format - public keys + + Both of the public key types defined in this document (RSA and DSA) + inherit their public key formats from the corresponding KEY RR + formats. Specifically, the public key field contains the algorithm- + specific portion of the KEY RR RDATA, which is all of the KEY RR DATA + after the first four octets. This is the same portion of the KEY RR + that must be specified by documents that define a DNSSEC algorithm. + Those documents also specify a message digest to be used for + generation of SIG RRs; that specification is not relevant for + IPSECKEY RR. + + Future algorithms, if they are to be used by both DNSSEC (in the KEY + RR) and IPSECKEY, are likely to use the same public key encodings in + both records. Unless otherwise specified, the IPSECKEY public key + field will contain the algorithm-specific portion of the KEY RR RDATA + + + +|Richardson Expires August 1, 2004 [Page 6] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + + for the corresponding algorithm. The algorithm must still be + designated for use by IPSECKEY, and an IPSECKEY algorithm type number + (which might be different than the DNSSEC algorithm number) must be + assigned to it. + + The DSA key format is defined in RFC2536 [10] + + The RSA key format is defined in RFC3110 [11], with the following + changes: + + The earlier definition of RSA/MD5 in RFC2065 limited the exponent and + modulus to 2552 bits in length. RFC3110 extended that limit to 4096 + bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on + RSA public keys, other than the 65535 octet limit imposed by the two- + octet length encoding. This length extension is applicable only to + IPSECKEY and not to KEY RRs. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 7] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +3. Presentation formats + +3.1 Representation of IPSECKEY RRs + + IPSECKEY RRs may appear in a zone data master file. The precedence, + gateway type and algorithm and gateway fields are REQUIRED. The + base64 encoded public key block is OPTIONAL; if not present, then the + public key field of the resource record MUST be construed as being + zero octets in length. + + The algorithm field is an unsigned integer. No mnemonics are + defined. + + If no gateway is to be indicated, then the gateway type field MUST be + zero, and the gateway field MUST be "." + + The Public Key field is represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see RFC3548 [6] Section 5.2. + + The general presentation for the record as as follows: + + IN IPSECKEY ( precedence gateway-type algorithm + gateway base64-encoded-public-key ) + + +3.2 Examples + + An example of a node 192.0.2.38 that will accept IPsec tunnels on its + own behalf. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.38 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.2.38 that has published its key only. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 + . + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.2.38 that has delegated authority to the + node 192.0.2.3. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.3 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + + + +|Richardson Expires August 1, 2004 [Page 8] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + + An example of a node, 192.0.1.38 that has delegated authority to the + node with the identity "mygateway.example.com". + + 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 + mygateway.example.com. + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has + delegated authority to the node 2001:0DB8:c000:0200:2::1 + + $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. + 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 + 2001:0DB8:0:8002::2000:1 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 9] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +4. Security Considerations + + This entire memo pertains to the provision of public keying material + for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. + + The IPSECKEY resource record contains information that SHOULD be + communicated to the end client in an integral fashion - i.e. free + from modification. The form of this channel is up to the consumer of + the data - there must be a trust relationship between the end + consumer of this resource record and the server. This relationship + may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to + another secure source, a secure local channel on the host, or some + combination of the above. + + The keying material provided by the IPSECKEY resource record is not + sensitive to passive attacks. The keying material may be freely + disclosed to any party without any impact on the security properties + of the resulting IPsec session: IPsec and IKE provide for defense + against both active and passive attacks. + + Any derivative standard that makes use of this resource record MUST + carefully document their trust model, and why the trust model of + DNSSEC is appropriate, if that is the secure channel used. + +4.1 Active attacks against unsecured IPSECKEY resource records + + This section deals with active attacks against the DNS. These + attacks require that DNS requests and responses be intercepted and + changed. DNSSEC is designed to defend against attacks of this kind. + + The first kind of active attack is when the attacker replaces the + keying material with either a key under its control or with garbage. + + If the attacker is not able to mount a subsequent man-in-the-middle + attack on the IKE negotiation after replacing the public key, then + this will result in a denial of service, as the authenticator used by + IKE would fail. + + If the attacker is able to both to mount active attacks against DNS + and is also in a position to perform a man-in-the-middle attack on + IKE and IPsec negotiations, then the attacker will be in a position + to compromise the resulting IPsec channel. Note that an attacker + must be able to perform active DNS attacks on both sides of the IKE + negotiation in order for this to succeed. + + The second kind of active attack is one in which the attacker + replaces the the gateway address to point to a node under the + attacker's control. The attacker can then either replace the public + + + +|Richardson Expires August 1, 2004 [Page 10] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + + key or remove it, thus providing an IPSECKEY record of its own to + match the gateway address. + + This later form creates a simple man-in-the-middle since the attacker + can then create a second tunnel to the real destination. Note that, + as before, this requires that the attacker also mount an active + attack against the responder. + + Note that the man-in-the-middle can not just forward cleartext + packets to the original destination. While the destination may be + willing to speak in the clear, replying to the original sender, the + sender will have already created a policy expecting ciphertext. + Thus, the attacker will need to intercept traffic from both sides. + In some cases, the attacker may be able to accomplish the full + intercept by use of Network Addresss/Port Translation (NAT/NAPT) + technology. + +| Note that risk of a man-in-the-middle attack mediated by the IPSECKEY +| RR only applies to cases where the gateway field of the IPSECKEY RR +| indicates a different entity than the owner name of the IPSECKEY RR. + +| An active attack on the DNS that caused the wrong IP address to be +| retrieved (via forged A RR), and therefore the wrong QNAME to be +| queried would also result in a man-in-the-middle attack. This +| situation exists independantly of whether or not the IPSECKEY RR is +| used. + +| In cases where the end-to-end integrity of the IPSECKEY RR is +| suspect, the end client MUST restrict its use of the IPSECKEY RR to +| cases where the RR owner name matches the content of the gateway +| field. + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 11] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +5. IANA Considerations + + This document updates the IANA Registry for DNS Resource Record Types + by assigning type X to the IPSECKEY record. + + This document creates two new IANA registries, both specific to the + IPSECKEY Resource Record: + + This document creates an IANA registry for the algorithm type field. + + Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 + through 255 can be assigned by IETF Consensus (see RFC2434 [5]). + + This document creates an IANA registry for the gateway type field. + + Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type + numbers 4 through 255 can be assigned by Standards Action (see + RFC2434 [5]). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 12] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +6. Intellectual Property Claims + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 13] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +7. Acknowledgments + + My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob + Austein, and Olafur Gurmundsson who reviewed this document carefully. + Additional thanks to Olafur Gurmundsson for a reference + implementation. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 14] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +Normative references + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [4] Eastlake, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 15] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +Non-normative references + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] Piper, D., "The Internet IP Security Domain of Interpretation + for ISAKMP", RFC 2407, November 1998. + + [9] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October 2003. + + +Author's Address + + Michael C. Richardson + Sandelman Software Works + 470 Dawson Avenue + Ottawa, ON K1Z 5V7 + CA + + EMail: mcr@sandelman.ottawa.on.ca + URI: http://www.sandelman.ottawa.on.ca/ + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 16] + +|Internet-Draft Storing IPsec keying material in DNS February 2004 + + +Full Copyright Statement + +| Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +|Richardson Expires August 1, 2004 [Page 17] diff --git a/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt new file mode 100644 index 000000000000..2d5c87eb3caa --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt @@ -0,0 +1,1200 @@ + + + + + + +IPv6 Working Group John Loughney (ed) +Internet-Draft Nokia + January 14, 2004 + +Expires: July 14, 2004 + + + + IPv6 Node Requirements + draft-ietf-ipv6-node-requirements-08.txt + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines requirements for IPv6 nodes. It is expected + that IPv6 will be deployed in a wide range of devices and situations. + Specifying the requirements for IPv6 nodes allows IPv6 to function + well and interoperate in a large number of situations and + deployments. + + + + + +Loughney (editor) February 16, 2004 [Page 1] + + + + + +Internet-Draft + + +Table of Contents + + 1. Introduction + 1.1 Requirement Language + 1.2 Scope of this Document + 1.3 Description of IPv6 Nodes + 2. Abbreviations Used in This Document + 3. Sub-IP Layer + 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + 3.2 IP version 6 over PPP - RFC2472 + 3.3 IPv6 over ATM Networks - RFC2492 + 4. IP Layer + 4.1 Internet Protocol Version 6 - RFC2460 + 4.2 Neighbor Discovery for IPv6 - RFC2461 + 4.3 Path MTU Discovery & Packet Size + 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + 4.5 Addressing + 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + 5. Transport and DNS + 5.1 Transport Layer + 5.2 DNS + 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + 6. IPv4 Support and Transition + 6.1 Transition Mechanisms + 7. Mobility + 8. Security + 8.1 Basic Architecture + 8.2 Security Protocols + 8.3 Transforms and Algorithms + 8.4 Key Management Methods + 9. Router Functionality + 9.1 General + 10. Network Management + 10.1 MIBs + 11. Security Considerations + 12. References + 12.1 Normative + 12.2 Non-Normative + 13. Authors and Acknowledgements + 14. Editor's Address + Notices + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 2] + + + + + +Internet-Draft + + +1. Introduction + + The goal of this document is to define the common functionality + required from both IPv6 hosts and routers. Many IPv6 nodes will + implement optional or additional features, but all IPv6 nodes can be + expected to implement the mandatory requirements listed in this + document. + + This document tries to avoid discussion of protocol details, and + references RFCs for this purpose. In case of any conflicting text, + this document takes less precedence than the normative RFCs, unless + additional clarifying text is included in this document. + + Although the document points to different specifications, it should + be noted that in most cases, the granularity of requirements are + smaller than a single specification, as many specifications define + multiple, independent pieces, some of which may not be mandatory. + + As it is not always possible for an implementer to know the exact + usage of IPv6 in a node, an overriding requirement for IPv6 nodes is + that they should adhere to Jon Postel's Robustness Principle: + + Be conservative in what you do, be liberal in what you accept from + others [RFC-793]. + +1.1 Requirement Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC-2119]. + +1.2 Scope of this Document + + IPv6 covers many specifications. It is intended that IPv6 will be + deployed in many different situations and environments. Therefore, + it is important to develop the requirements for IPv6 nodes, in order + to ensure interoperability. + + This document assumes that all IPv6 nodes meet the minimum + requirements specified here. + +1.3 Description of IPv6 Nodes + + From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we + have the following definitions: + + Description of an IPv6 Node + + + + +Loughney (editor) February 16, 2004 [Page 3] + + + + + +Internet-Draft + + + - a device that implements IPv6 + + Description of an IPv6 router + + - a node that forwards IPv6 packets not explicitly addressed to + itself. + + Description of an IPv6 Host + + - any node that is not a router. + +2. Abbreviations Used in This Document + + ATM Asynchronous Transfer Mode + + AH Authentication Header + + DAD Duplicate Address Detection + + ESP Encapsulating Security Payload + + ICMP Internet Control Message Protocol + + IKE Internet Key Exchange + + MIB Management Information Base + + MLD Multicast Listener Discovery + + MTU Maximum Transfer Unit + + NA Neighbor Advertisement + + NBMA Non-Broadcast Multiple Access + + ND Neighbor Discovery + + NS Neighbor Solicitation + + NUD Neighbor Unreachability Detection + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SVC Switched Virtual Circuit + +3. Sub-IP Layer + + + +Loughney (editor) February 16, 2004 [Page 4] + + + + + +Internet-Draft + + + An IPv6 node must include support for one or more IPv6 link-layer + specifications. Which link-layer specifications are included will + depend upon what link-layers are supported by the hardware available + on the system. It is possible for a conformant IPv6 node to support + IPv6 on some of its interfaces and not on others. + + As IPv6 is run over new layer 2 technologies, it is expected that new + specifications will be issued. This section highlights some major + layer 2 technologies and is not intended to be complete. + +3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + + Nodes supporting IPv6 over Ethernet interfaces MUST implement + Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. + +3.2 IP version 6 over PPP - RFC2472 + + Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- + 2472]. + +3.3 IPv6 over ATM Networks - RFC2492 + + Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM + Networks [RFC-2492]. Additionally, RFC 2492 states: + + A minimally conforming IPv6/ATM driver SHALL support the PVC mode + of operation. An IPv6/ATM driver that supports the full SVC mode + SHALL also support PVC mode of operation. + +4. IP Layer + +4.1 Internet Protocol Version 6 - RFC2460 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification MUST be supported. + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions MUST be processed as described in RFC 2460. + + The node MUST follow the packet transmission rules in RFC 2460. + + Nodes MUST always be able to send, receive and process fragment + headers. All conformant IPv6 implementations MUST be capable of + sending and receving IPv6 packets; forwarding functionality MAY be + supported + + RFC 2460 specifies extension headers and the processing for these + headers. + + + +Loughney (editor) February 16, 2004 [Page 5] + + + + + +Internet-Draft + + + A full implementation of IPv6 includes implementation of the + following extension headers: Hop-by-Hop Options, Routing (Type 0), + Fragment, Destination Options, Authentication and Encapsulating + Security Payload. [RFC-2460] + + An IPv6 node MUST be able to process these headers. It should be + noted that there is some discussion about the use of Routing Headers + and possible security threats [IPv6-RH] caused by them. + +4.2 Neighbor Discovery for IPv6 - RFC2461 + + Neighbor Discovery SHOULD be supported. RFC 2461 states: + + "Unless specified otherwise (in a document that covers operating + IP over a particular link type) this document applies to all link + types. However, because ND uses link-layer multicast for some of + its services, it is possible that on some link types (e.g., NBMA + links) alternative protocols or mechanisms to implement those + services will be specified (in the appropriate document covering + the operation of IP over a particular link type). The services + described in this document that are not directly dependent on + multicast, such as Redirects, Next-hop determination, Neighbor + Unreachability Detection, etc., are expected to be provided as + specified in this document. The details of how one uses ND on + NBMA links is an area for further study." + + Some detailed analysis of Neighbor Discovery follows: + + Router Discovery is how hosts locate routers that reside on an + attached link. Router Discovery MUST be supported for + implementations. + + Prefix Discovery is how hosts discover the set of address prefixes + that define which destinations are on-link for an attached link. + Prefix discovery MUST be supported for implementations. Neighbor + Unreachability Detection (NUD) MUST be supported for all paths + between hosts and neighboring nodes. It is not required for paths + between routers. However, when a node receives a unicast Neighbor + Solicitation (NS) message (that may be a NUD's NS), the node MUST + respond to it (i.e. send a unicast Neighbor Advertisement). + + Duplicate Address Detection MUST be supported on all links supporting + link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take + place on all unicast addresses). + + A host implementation MUST support sending Router Solicitations. + + Receiving and processing Router Advertisements MUST be supported for + + + +Loughney (editor) February 16, 2004 [Page 6] + + + + + +Internet-Draft + + + host implementations. The ability to understand specific Router + Advertisement options is dependent on supporting the specification + where the RA is specified. + + Sending and Receiving Neighbor Solicitation (NS) and Neighbor + Advertisement (NA) MUST be supported. NS and NA messages are required + for Duplicate Address Detection (DAD). + + Redirect functionality SHOULD be supported. If the node is a router, + Redirect functionality MUST be supported. + +4.3 Path MTU Discovery & Packet Size + +4.3.1 Path MTU Discovery - RFC1981 + + Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal + implementations MAY choose to not support it and avoid large packets. + The rules in RFC 2460 MUST be followed for packet fragmentation and + reassembly. + +4.3.2 IPv6 Jumbograms - RFC2675 + + IPv6 Jumbograms [RFC-2675] MAY be supported. + +4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + + ICMPv6 [RFC-2463] MUST be supported. + +4.5 Addressing + +4.5.1 IP Version 6 Addressing Architecture - RFC3513 + + The IPv6 Addressing Architecture [RFC-3513] MUST be supported. + +4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification MUST be supported for nodes that are hosts. + + Nodes that are routers MUST be able to generate link local addresses + as described in RFC 2462 [RFC-2462]. + + From 2462: + + The autoconfiguration process specified in this document applies + only to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be + configured by some other means. However, it is expected that + + + +Loughney (editor) February 16, 2004 [Page 7] + + + + + +Internet-Draft + + + routers will generate link-local addresses using the mechanism + described in this document. In addition, routers are expected to + successfully pass the Duplicate Address Detection procedure + described in this document on all addresses prior to assigning + them to an interface. + + Duplicate Address Detection (DAD) MUST be supported. + +4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + SHOULD be supported. It is recommended that this behavior be + configurable on a connection basis within each application when + available. It is noted that a number of applications do not work + with addresses generated with this method, while other applications + work quite well with them. + +4.5.4 Default Address Selection for IPv6 - RFC3484 + + The rules specified in the Default Address Selection for IPv6 [RFC- + 3484] document MUST be implemented. It is expected that IPv6 nodes + will need to deal with multiple addresses. + +4.5.5 Stateful Address Autoconfiguration + + Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- + 3315] is the standard stateful address configuration protocol; see + section 5.3 for DHCPv6 support. + + Nodes which do not support Stateful Address Autoconfiguration may be + unable to obtain any IPv6 addresses aside from link-local addresses + when it receives a router advertisement with the 'M' flag (Managed + address configuration) set and which contains no prefixes advertised + for Stateless Address Autoconfiguration (see section 4.5.2). + Additionally, such nodes will be unable to obtain other configuration + information such as the addresses of DNS servers when it is connected + to a link over which the node receives a router advertisement in + which the 'O' flag ("Other stateful configuration") is set. + +4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + + Nodes that need to join multicast groups SHOULD implement MLDv2 + [MLDv2]. However, if the node has applications, which only need + support for Any- Source Multicast [RFC3569], the node MAY implement + MLDv1 [MLDv1] instead. If the node has applications, which need + support for Source- Specific Multicast [RFC3569, SSMARCH], the node + MUST support MLDv2 [MLDv2]. + + + + +Loughney (editor) February 16, 2004 [Page 8] + + + + + +Internet-Draft + + + When MLD is used, the rules in "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be + followed. + +5. Transport Layer and DNS + +5.1 Transport Layer + +5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 + + This specification MUST be supported if jumbograms are implemented + [RFC- 2675]. + +5.2 DNS + + DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] + and [RFC-3596] MAY be supported. Not all nodes will need to resolve + names. All nodes that need to resolve names SHOULD implement stub- + resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with + support for: + + - AAAA type Resource Records [RFC-3596]; + - reverse addressing in ip6.arpa using PTR records [RFC-3152]; + - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 + octets. + + Those nodes are RECOMMENDED to support DNS security extentions + [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. + + Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC-3363]. + +5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 + + RFC 2732 MUST be supported if applications on the node use URL's. + +5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 + +5.3.1 Managed Address Configuration + + Those IPv6 Nodes that use DHCP for address assignment initiate DHCP + to obtain IPv6 addresses and other configuration information upon + receipt of a Router Advertisement with the 'M' flag set, as described + in section 5.5.3 of RFC 2462. In addition, in the absence of a + router, those IPv6 Nodes that use DHCP for address assignment MUST + initiate DHCP to obtain IPv6 addresses and other configuration + information, as described in section 5.5.2 of RFC 2462. Those IPv6 + nodes that do not use DHCP for address assignment can ignore the 'M' + + + +Loughney (editor) February 16, 2004 [Page 9] + + + + + +Internet-Draft + + + flag in Router Advertisements. + +5.3.2 Other Configuration Information + + Those IPv6 Nodes that use DHCP to obtain other configuration + information initiate DHCP for other configuration information upon + receipt of a Router Advertisement with the 'O' flag set, as described + in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP + for other configuration information can ignore the 'O' flag in Router + Advertisements. + + An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to + obtain other configuration information. + +6. IPv4 Support and Transition + + IPv6 nodes MAY support IPv4. + +6.1 Transition Mechanisms + +6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 + + If an IPv6 node implements dual stack and tunneling, then RFC2893 + MUST be supported. + + RFC 2893 is currently being updated. + +7. Mobile IP + + The Mobile IPv6 [MIPv6] specification defines requirements for the + following types of nodes: + + - mobile nodes + - correspondent nodes with support for route optimization + - home agents + - all IPv6 routers + + Hosts MAY support mobile node functionality described in Section 8.5 + of [MIPv6], including support of generic packet tunneling [RFC-2473] + and secure home agent communications [MIPv6-HASEC]. + + Hosts SHOULD support route optimization requirements for + correspondent nodes described in Section 8.2 of [MIPv6]. + + Routers SHOULD support the generic mobility-related requirements for + all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY + support the home agent functionality described in Section 8.4 of + [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. + + + +Loughney (editor) February 16, 2004 [Page 10] + + + + + +Internet-Draft + + +8. Security + + This section describes the specification of IPsec for the IPv6 node. + +8.1 Basic Architecture + + Security Architecture for the Internet Protocol [RFC-2401] MUST be + supported. RFC-2401 is being updated by the IPsec Working Group. + +8.2 Security Protocols + + ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. + RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group. + + +8.3 Transforms and Algorithms + + Current IPsec RFCs specify the support of certain transforms and + algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. + The requirements for these are discussed first, and then additional + algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed. + + NULL encryption algorithm [RFC-2410] MUST be supported for providing + integrity service and also for debugging use. + + The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD + NOT be supported. Security issues related to the use of DES are + discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as + required by the existing IPsec RFCs, but as it is currently viewed as + an inherently weak algorithm, and no longer fulfills its intended + role. + + The NULL authentication algorithm [RFC-2406] MUST be supported within + ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- + 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP, + described in [RFC-2403] MUST be supported. An implementer MUST refer + to Keyed- Hashing for Message Authentication [RFC-2104]. + + 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC + and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES- + CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected + to be a widely available, secure algorithm that is required for + interoperability. It is not required by the current IPsec RFCs, but + is expected to become required in the future. + + In addition to the above requirements, "Cryptographic Algorithm + Implementation Requirements For ESP And AH" [CRYPTREQ] contains the + current set of mandatory to implement algorithms for ESP and AH as + + + +Loughney (editor) February 16, 2004 [Page 11] + + + + + +Internet-Draft + + + well as specifying algorithms that should be implemented because they + may be promoted to mandatory at some future time. It is RECOMMENDED + that IPv6 nodes conform to the requirements in this document. + +8.4 Key Management Methods + + Manual keying MUST be supported. + + IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast + traffic. Where key refresh, anti-replay features of AH and ESP, or + on- demand creation of Security Associations (SAs) is required, + automated keying MUST be supported. Note that the IPsec WG is working + on the successor to IKE [IKE2]. Key management methods for multicast + traffic are also being worked on by the MSEC WG. + + "Cryptographic Algorithms for use in the Internet Key Exchange + Version 2" [IKEv2ALGO] defines the current set of mandatory to + implement algorithms for use of IKEv2 as well as specifying + algorithms that should be implemented because they made be promoted + to mandatory at some future time. It is RECOMMENDED that IPv6 nodes + implementing IKEv2 conform to the requirements in this + document. + +9. Router-Specific Functionality + + This section defines general host considerations for IPv6 nodes that + act as routers. Currently, this section does not discuss routing- + specific requirements. + +9.1 General + +9.1.1 IPv6 Router Alert Option - RFC2711 + + + The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- + Hop Header that is used in conjunction with some protocols (e.g., + RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will + need to be implemented whenever protocols that mandate its usage are + implemented. See Section 4.6. + +9.1.2 Neighbor Discovery for IPv6 - RFC2461 + + Sending Router Advertisements and processing Router Solicitation MUST + be supported. + +10. Network Management + + Network Management MAY be supported by IPv6 nodes. However, for IPv6 + + + +Loughney (editor) February 16, 2004 [Page 12] + + + + + +Internet-Draft + + + nodes that are embedded devices, network management may be the only + possibility to control these nodes. + +10.1 Management Information Base Modules (MIBs) + + The following two MIBs SHOULD be supported by nodes that support an + SNMP agent. + +10.1.1 IP Forwarding Table MIB + + IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes + that support an SNMP agent. + +10.1.2 Management Information Base for the Internet Protocol (IP) + + IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an + SNMP agent. + +11. Security Considerations + + This draft does not affect the security of the Internet, but + implementations of IPv6 are expected to support a minimum set of + security features to ensure security on the Internet. "IP Security + Document Roadmap" [RFC-2411] is important for everyone to read. + + The security considerations in RFC2460 describe the following: + + The security features of IPv6 are described in the Security + Architecture for the Internet Protocol [RFC-2401]. + +12. References + +12.1 Normative + + [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- + tion Requirements For ESP And AH", draft-ietf-ipsec- + esp-ah-algorithms-01.txt, January 2004. + + [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the + Internet Key Exchange Version 2", draft-ietf-ipsec- + ikev2-algorithms-04.txt, Work in Progress. + + [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 + Service", draft- ietf-dhc-dhcpv6-stateless-00.txt, + Work in Progress. + + [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support + in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 13] + + + + + +Internet-Draft + + + progress. + + [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec + to Protect Mobile IPv6 Signaling between Mobile Nodes + and Home Agents", draft-ietf- mobileip-mipv6-ha- + ipsec-06.txt, Work in Progress. + + [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version + 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in + Progress. + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table + MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in + Progress. + + [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the + Internet Protocol (IP)", draft-ietf-ipv6-rfc2011- + update-07.txt, Work in progress. + + [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication + Header", RFC 2402, November 1998. + + [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within + ESP and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 + within ESP and AH", RFC 2404, November 1998. + + [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security + + + +Loughney (editor) February 16, 2004 [Page 14] + + + + + +Internet-Draft + + + Protocol (ESP)", RFC 2406, November 1998. + + [RFC-2407] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, + J., "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2408, November 1998. + + [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key + Exchange (IKE)", RFC 2409, November 1998. + + [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm + and Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- + sion 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address + Autoconfiguration", RFC 2462. + + [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- + tocol Version 6 (IPv6)", RFC 2463, December 1998. + + [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC + 2472, December 1998. + + [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling + in IPv6 Specification", RFC 2473, December 1998. Xxx + add + + [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert + Option", RFC 2711, October 1999. + + + + +Loughney (editor) February 16, 2004 [Page 15] + + + + + +Internet-Draft + + + [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC + 3041, January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August + 2001. + + [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver- + sion 6 (IPv6) Addresses in the Domain Name System + (DNS)", RFC 3363, August 2002. + + [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC + 3484, February 2003. + + [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing + Architecture", RFC 3513, April 2003. + + [RFC-3590] Haberman, B., "Source Address Selection for the Multi- + cast Listener Discovery (MLD) Protocol", RFC 3590, + September 2003. + + [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP + version 6", RFC 3596, October 2003. + + [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use + with IPsec", RFC 3602, September 2003. + +12.2 Non-Normative + + [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", + draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in + Progress. + + [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of + DES-like cryptosystems", Journal of Cryptology Vol 4, Jan + 1991. + + [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. + + [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, Danvers, + MA, April 1995. + + [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser- + vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 16] + + + + + +Internet-Draft + + + Progress. + + [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "DNS Security Introduction and Requirements" draft- + ietf-dnsext-dnssec-intro- 06.txt, Work in Progress. + + [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro- + gress. + + [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Protocol Modifications for the DNS Security Exten- + sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work + in Progress. + + [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- + col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress. + + [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home + Address Options", draft-savola-ipv6-rh-ha-security- + 03.txt, Work in Progress, March 2002. + + [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- + rity Threats and Counter-Measures; In Proceedings "Sympo- + sium on Network and Distributed System Security", Febru- + ary 1995, pp.2-16. + + [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, + August 1980. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- + ties", RFC 1034, November 1987. + + [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, + May 1997. + + [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and + S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC + 2205, September 1997. + + [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2462, December 1998. + + [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over + ATM Networks", RFC 2492, January 1999. + + [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 + + + +Loughney (editor) February 16, 2004 [Page 17] + + + + + +Internet-Draft + + + Jumbograms", RFC 2675, August 1999. + + [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal + IPv6 Addresses in URL's", RFC 2732, December 1999. + + [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, + "Textual Conventions for Internet Network Addresses", RFC + 2851, June 2000. + + [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 2893, August 2000. + + [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", + draft-ietf- ssm-arch-03.txt, Work in Progress. + +13. Authors and Acknowledgements + + This document was written by the IPv6 Node Requirements design team: + + Jari Arkko + [jari.arkko@ericsson.com] + + Marc Blanchet + [marc.blanchet@viagenie.qc.ca] + + Samita Chakrabarti + [samita.chakrabarti@eng.sun.com] + + Alain Durand + [alain.durand@sun.com] + + Gerard Gastaud + [gerard.gastaud@alcatel.fr] + + Jun-ichiro itojun Hagino + [itojun@iijlab.net] + + Atsushi Inoue + [inoue@isl.rdc.toshiba.co.jp] + + Masahiro Ishiyama + [masahiro@isl.rdc.toshiba.co.jp] + + John Loughney + [john.loughney@nokia.com] + + + +Loughney (editor) February 16, 2004 [Page 18] + + + + + +Internet-Draft + + + Rajiv Raghunarayan + [raraghun@cisco.com] + + Shoichi Sakane + [shouichi.sakane@jp.yokogawa.com] + + Dave Thaler + [dthaler@windows.microsoft.com] + + Juha Wiljakka + [juha.wiljakka@Nokia.com] + + The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- + penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, + Juha Ollila and Pekka Savola for their comments. + +14. Editor's Contact Information + + Comments or questions regarding this document should be sent to the + IPv6 Working Group mailing list (ipv6@ietf.org) or to: + + John Loughney + Nokia Research Center + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + Phone: +358 50 483 6242 + Email: John.Loughney@Nokia.com + +Notices + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to per- + tain to the implementation or use of the technology described in this + document or the extent to which any license under such rights might + or might not be available; neither does it represent that it has made + any effort to identify any such rights. Information on the IETF's + procedures with respect to rights in standards-track and standards- + related documentation can be found in BCP-11. Copies of claims of + rights made available for publication and any assurances of licenses + to be made available, or the result of an attempt made to obtain a + general license or permission for the use of such proprietary rights + by implementors or users of this specification can be obtained from + the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + + + +Loughney (editor) February 16, 2004 [Page 19] + + + + + +Internet-Draft + + + rights, which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 20] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt b/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt new file mode 100644 index 000000000000..a272d81b0a60 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt @@ -0,0 +1,614 @@ +Secure Shell Working Group J. Schlyter +Internet-Draft OpenSSH +Expires: March 5, 2004 W. Griffin + SPARTA + September 5, 2003 + + + Using DNS to Securely Publish SSH Key Fingerprints + draft-ietf-secsh-dns-05.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 5, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a method to verify SSH host keys using + DNSSEC. The document defines a new DNS resource record that contains + a standard SSH key fingerprint. + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 1] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 + 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 + 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 + 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 + 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5 + 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 + 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 + 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + Normative References . . . . . . . . . . . . . . . . . . . . 8 + Informational References . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 2] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +1. Introduction + + The SSH [6] protocol provides secure remote login and other secure + network services over an insecure network. The security of the + connection relies on the server authenticating itself to the client + as well as the user authenticating itself to the server. + + If a connection is established to a server whose public key is not + already known to the client, a fingerprint of the key is presented to + the user for verification. If the user decides that the fingerprint + is correct and accepts the key, the key is saved locally and used for + verification for all following connections. While some + security-conscious users verify the fingerprint out-of-band before + accepting the key, many users blindly accept the presented key. + + The method described here can provide out-of-band verification by + looking up a fingerprint of the server public key in the DNS [1][2] + and using DNSSEC [5] to verify the lookup. + + In order to distribute the fingerprint using DNS, this document + defines a new DNS resource record, "SSHFP", to carry the fingerprint. + + Basic understanding of the DNS system [1][2] and the DNS security + extensions [5] is assumed by this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [3]. + +2. SSH Host Key Verification + +2.1 Method + + Upon connection to a SSH server, the SSH client MAY look up the SSHFP + resource record(s) for the host it is connecting to. If the + algorithm and fingerprint of the key received from the SSH server + match the algorithm and fingerprint of one of the SSHFP resource + record(s) returned from DNS, the client MAY accept the identity of + the server. + +2.2 Implementation Notes + + Client implementors SHOULD provide a configurable policy used to + select the order of methods used to verify a host key. This document + defines one method: Fingerprint storage in DNS. Another method + defined in the SSH Architecture [6] uses local files to store keys + for comparison. Other methods that could be defined in the future + might include storing fingerprints in LDAP or other databases. A + + + +Schlyter & Griffin Expires March 5, 2004 [Page 3] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + + configurable policy will allow administrators to determine which + methods they want to use and in what order the methods should be + prioritized. This will allow administrators to determine how much + trust they want to place in the different methods. + + One specific scenario for having a configurable policy is where + clients do not use fully qualified host names to connect to servers. + In this scenario, the implementation SHOULD verify the host key + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from injecting + a DNS search path into the local resolver and forcing the client to + connect to a different host. + +2.3 Fingerprint Matching + + The public key and the SSHFP resource record are matched together by + comparing algorithm number and fingerprint. + + The public key algorithm and the SSHFP algorithm number MUST + match. + + A message digest of the public key, using the message digest + algorithm specified in the SSHFP fingerprint type, MUST match the + SSHFP fingerprint. + + +2.4 Authentication + + A public key verified using this method MUST NOT be trusted if the + SSHFP resource record (RR) used for verification was not + authenticated by a trusted SIG RR. + + Clients that do validate the DNSSEC signatures themselves SHOULD use + standard DNSSEC validation procedures. + + Clients that do not validate the DNSSEC signatures themselves MUST + use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8], + between themselves and the entity performing the signature + validation. + +3. The SSHFP Resource Record + + The SSHFP resource record (RR) is used to store a fingerprint of a + SSH public host key that is associated with a Domain Name System + (DNS) name. + + The RR type code for the SSHFP RR is TBA. + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 4] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +3.1 The SSHFP RDATA Format + + The RDATA for a SSHFP RR consists of an algorithm number, fingerprint + type and the fingerprint of the public host key. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | fp type | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / + / / + / fingerprint / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 Algorithm Number Specification + + This algorithm number octet describes the algorithm of the public + key. The following values are assigned: + + Value Algorithm name + ----- -------------- + 0 reserved + 1 RSA + 2 DSS + + Reserving other types requires IETF consensus [4]. + +3.1.2 Fingerprint Type Specification + + The fingerprint type octet describes the message-digest algorithm + used to calculate the fingerprint of the public key. The following + values are assigned: + + Value Fingerprint type + ----- ---------------- + 0 reserved + 1 SHA-1 + + Reserving other types requires IETF consensus [4]. + + For interoperability reasons, as few fingerprint types as possible + should be reserved. The only reason to reserve additional types is + to increase security. + +3.1.3 Fingerprint + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 5] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + + The fingerprint is calculated over the public key blob as described + in [7]. + + The message-digest algorithm is presumed to produce an opaque octet + string output which is placed as-is in the RDATA fingerprint field. + +3.2 Presentation Format of the SSHFP RR + + The RDATA of the presentation format of the SSHFP resource record + consists of two numbers (algorithm and fingerprint type) followed by + the fingerprint itself presented in hex, e.g: + + host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 + + The use of mnemonics instead of numbers is not allowed. + +4. Security Considerations + + Currently, the amount of trust a user can realistically place in a + server key is proportional to the amount of attention paid to + verifying that the public key presented actually corresponds to the + private key of the server. If a user accepts a key without verifying + the fingerprint with something learned through a secured channel, the + connection is vulnerable to a man-in-the-middle attack. + + The overall security of using SSHFP for SSH host key verification is + dependent on the security policies of the SSH host administrator and + DNS zone administrator (in transferring the fingerprint), detailed + aspects of how verification is done in the SSH implementation, and in + the client's diligence in accessing the DNS in a secure manner. + + One such aspect is in which order fingerprints are looked up (e.g. + first checking local file and then SSHFP). We note that in addition + to protecting the first-time transfer of host keys, SSHFP can + optionally be used for stronger host key protection. + + If SSHFP is checked first, new SSH host keys may be distributed by + replacing the corresponding SSHFP in DNS. + + If SSH host key verification can be configured to require SSHFP, + SSH host key revocation can be implemented by removing the + corresponding SSHFP from DNS. + + As stated in Section 2.2, we recommend that SSH implementors provide + a policy mechanism to control the order of methods used for host key + verification. One specific scenario for having a configurable policy + is where clients use unqualified host names to connect to servers. In + this case, we recommend that SSH implementations check the host key + + + +Schlyter & Griffin Expires March 5, 2004 [Page 6] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from injecting + a DNS search path into the local resolver and forcing the client to + connect to a different host. + + A different approach to solve the DNS search path issue would be for + clients to use a trusted DNS search path, i.e., one not acquired + through DHCP or other autoconfiguration mechanisms. Since there is no + way with current DNS lookup APIs to tell whether a search path is + from a trusted source, the entire client system would need to be + configured with this trusted DNS search path. + + Another dependency is on the implementation of DNSSEC itself. As + stated in Section 2.4, we mandate the use of secure methods for + lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This + is especially important if SSHFP is to be used as a basis for host + key rollover and/or revocation, as described above. + + Since DNSSEC only protects the integrity of the host key fingerprint + after it is signed by the DNS zone administrator, the fingerprint + must be transferred securely from the SSH host administrator to the + DNS zone administrator. This could be done manually between the + administrators or automatically using secure DNS dynamic update [11] + between the SSH server and the nameserver. We note that this is no + different from other key enrollment situations, e.g. a client sending + a certificate request to a certificate authority for signing. + +5. IANA Considerations + + IANA needs to allocate a RR type code for SSHFP from the standard RR + type space (type 44 requested). + + IANA needs to open a new registry for the SSHFP RR type for public + key algorithms. Defined types are: + + 0 is reserved + 1 is RSA + 2 is DSA + + Adding new reservations requires IETF consensus [4]. + + IANA needs to open a new registry for the SSHFP RR type for + fingerprint types. Defined types are: + + 0 is reserved + 1 is SHA-1 + + Adding new reservations requires IETF consensus [4]. + + + +Schlyter & Griffin Expires March 5, 2004 [Page 7] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [5] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. + Lehtinen, "SSH Protocol Architecture", + draft-ietf-secsh-architecture-14 (work in progress), July 2003. + + [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. + Lehtinen, "SSH Transport Layer Protocol", + draft-ietf-secsh-transport-16 (work in progress), July 2003. + +Informational References + + [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document + Roadmap", RFC 2411, November 1998. + + [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [10] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 8] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +Authors' Addresses + + Jakob Schlyter + OpenSSH + 812 23rd Avenue SE + Calgary, Alberta T2G 1N8 + Canada + + EMail: jakob@openssh.com + URI: http://www.openssh.com/ + + + Wesley Griffin + SPARTA + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + + EMail: wgriffin@sparta.com + URI: http://www.sparta.com/ + +Appendix A. Acknowledgements + + The authors gratefully acknowledge, in no particular order, the + contributions of the following persons: + + Martin Fredriksson + + Olafur Gudmundsson + + Edward Lewis + + Bill Sommerfeld + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 9] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Schlyter & Griffin Expires March 5, 2004 [Page 10] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 11] + diff --git a/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt new file mode 100644 index 000000000000..3578d2a15eb8 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt @@ -0,0 +1,519 @@ + +Internet Draft Johan Ihren +draft-ihren-dnsext-threshold-validation-00.txt Autonomica +February 2003 +Expires in six months + + + Threshold Validation: + + A Mechanism for Improved Trust and Redundancy for DNSSEC Keys + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + +Abstract + + This memo documents a proposal for a different method of validation + for DNSSEC aware resolvers. The key change is that by changing from + a model of one Key Signing Key, KSK, at a time to multiple KSKs it + will be possible to increase the aggregated trust in the signed + keys by leveraging from the trust associated with the different + signees. + + By having multiple keys to chose from validating resolvers get the + opportunity to use local policy to reflect actual trust in + different keys. For instance, it is possible to trust a single, + particular key ultimately, while requiring multiple valid + signatures by less trusted keys for validation to succeed. + Furthermore, with multiple KSKs there are additional redundancy + benefits available since it is possible to roll over different KSKs + at different times which may make rollover scenarios easier to + manage. + +Contents + + 1. Terminology + 2. Introduction and Background + + 3. Trust in DNSSEC Keys + 3.1. Key Management, Split Keys and Trust Models + 3.2. Trust Expansion: Authentication versus Authorization + + 4. Proposed Semantics for Signing the KEY Resource Record + Set + 4.1. Packet Size Considerations + + 5. Proposed Use of Multiple "Trusted Keys" in a Validating + Resolver + 5.1. Not All Possible KSKs Need to Be Trusted + 5.2. Possible to do Threshold Validation + 5.3. Not All Trusted Keys Will Be Available + + 6. Additional Benefits from Having Multiple KSKs + 6.1. More Robust Key Rollovers + 6.2. Evaluation of Multiple Key Distribution Mechanisms + + 7. Security Considerations + 8. IANA Considerations. + 9. References + 9.1. Normative. + 9.2. Informative. + 10. Acknowledgments. + 11. Authors' Address + + +1. Terminology + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", + and "MAY" in this document are to be interpreted as described in + RFC 2119. + + The term "zone" refers to the unit of administrative control in the + Domain Name System. "Name server" denotes a DNS name server that is + authoritative (i.e. knows all there is to know) for a DNS zone, + typically the root zone. A "resolver", is a DNS "client", i.e. an + entity that sends DNS queries to authoritative nameservers and + interpret the results. A "validating resolver" is a resolver that + attempts to perform DNSSEC validation on data it retrieves by doing + DNS lookups. + + +2. Introduction and Background + + From a protocol perspective there is no real difference between + different keys in DNSSEC. They are all just keys. However, in + actual use there is lots of difference. First and foremost, most + DNSSEC keys have in-band verification. I.e. the keys are signed by + some other key, and this other key is in its turn also signed by + yet another key. This way a "chain of trust" is created. Such + chains have to end in what is referred to as a "trusted key" for + validation of DNS lookups to be possible. + + A "trusted key" is a the public part of a key that the resolver + acquired by some other means than by looking it up in DNS. The + trusted key has to be explicitly configured. + + A node in the DNS hierarchy that issues such out-of-band "trusted + keys" is called a "security apex" and the trusted key for that apex + is the ultimate source of trust for all DNS lookups within that + entire subtree. + + DNSSEC is designed to be able to work with more than on security + apex. These apexes will all share the problem of how to distribute + their "trusted keys" in a way that provides validating resolvers + confidence in the distributed keys. + + Maximizing that confidence is crucial to the usefulness of DNSSEC + and this document tries to address this issue. + + +3. Trust in DNSSEC Keys + + In the end the trust that a validating resolver will be able to put + in a key that it cannot validate within DNSSEC will have to be a + function of + + * trust in the key issuer, aka the KSK holder + + * trust in the distribution method + + * trust in extra, out-of-band verification + + The KSK holder needs to be trusted not to accidentally lose private + keys in public places. Furthermore it needs to be trusted to + perform correct identification of the ZSK holders in case they are + separate from the KSK holder itself. + + The distribution mechanism can be more or less tamper-proof. If the + key holder publishes the public key, or perhaps just a secure + fingerprint of the key in a major newspaper it may be rather + difficult to tamper with. A key acquired that way may be easier to + trust than if it had just been downloaded from a web page. + + Out-of-band verification can for instance be the key being signed + by a certificate issued by a known Certificate Authority that the + resolver has reason to trust. + +3.1. Simplicity vs Trust + + The fewer keys that are in use the simpler the key management + becomes. Therefore increasing the number of keys should only be + considered when the complexity is not the major concern. A perfect + example of this is the distinction between so called Key Signing + Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds + overall complexity but simplifies real life operations and was an + overall gain since operational simplification was considered to be + a more crucial issue than the added complexity. + + In the case of a security apex there are additional issues to + consider, among them + + * maximizing trust in the KSK received out-of-band + + * authenticating the legitimacy of the ZSKs used + + In some cases this will be easy, since the same entity will manage + both ZSKs and KSKs (i.e. it will authenticate itself, somewhat + similar to a self-signed certificate). In some environments it will + be possible to get the trusted key installed in the resolver end by + decree (this would seem to be a likely method within corporate and + government environments). + + In other cases, however, this will possibly not be sufficient. In + the case of the root zone this is obvious, but there may well be + other cases. + +3.2. Expanding the "Trust Base" + + For a security apex where the ZSKs and KSK are not held by the same + entity the KSK will effectively authenticate the identity of + whoever does real operational zone signing. The amount of trust + that the data signed by a ZSK will get is directly dependent on + whether the end resolver trusts the KSK or not, since the resolver + has no OOB access to the public part of the ZSKs (for practical + reasons). + + Since the KSK holder is distinct from the ZSK holder the obvious + question is whether it would then be possible to further improve + the situation by using multiple KSK holders and thereby expanding + the trust base to the union of that available to each individual + KSK holder. "Trust base" is an invented term intended to signify + the aggregate of Internet resolvers that will eventually choose to + trust a key issued by a particular KSK holder. + + A crucial issue when considering trust expansion through addition + of multiple KSK holders is that the KSK holders are only used to + authenticate the ZSKs used for signing the zone. I.e. the function + performed by the KSK is basically: + + "This is indeed the official ZSK holder for this zone, + I've verified this fact to the best of my abilitites." + + Which can be thought of as similar to the service of a public + notary. I.e. the point with adding more KSK holders is to improve + the public trust in data signed by the ZSK holders by improving the + strength of available authentication. + + Therefore adding more KSK holders, each with their own trust base, + is by definition a good thing. More authentication is not + controversial. On the contrary, when it comes to authentication, + the more the merrier. + + +4. Proposed Semantics for Signing the KEY Resource Record Set + + In DNSSEC according to RFC2535 all KEY Resource Records are used to + sign all authoritative data in the zone, including the KEY RRset + itself, since RFC2535 makes no distinction between Key Signing + Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS] + it is possible to change this to the KEY RRset being signed with + all KSKs and ZSKs but the rest of the zone only being signed by the + ZSKs. + + This proposal changes this one step further, by recommending that + the KEY RRset is only signed by the Key Signing Keys, KSK, and + explicitly not by the Zone Signing Keys, ZSK. The reason for this + is to maximize the amount of space in the DNS response packet that + is available for additional KSKs and signatures thereof. The rest + of the authoritative zone contents are as previously signed by only + the ZSKs. + +4.1. Packet Size Considerations + + The reason for the change is to keep down the size of the aggregate + of KEY RRset plus SIG(KEY) that resolvers will need to acquire to + perform validation of data below a security apex. For DNSSEC data + to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be + set, and therefore the allowed packet size can be assumed to be at + least the EDNS0 minimum of 4000 bytes. + + When querying for KEY + SIG(KEY) for "." (the case that is assumed + to be most crucial) the size of the response packet after the + change to only sign the KEY RR with the KSKs break down into a + rather large space of possibilities. Here are a few examples for + the possible alternatives for different numbers of KSKs and ZSKs + for some different key lengths (all RSA keys, with a public + exponent that is < 254). This is all based upon the size of the + response for the particular example of querying for + + ". KEY IN" + + with a response of entire KEY + SIG(KEY) with the authority and + additional sections empty: + + ZSK/768 and KSK/1024 (real small) + Max 12 KSK + 3 ZSK at 3975 + 10 KSK + 8 ZSK at 3934 + 8 KSK + 13 ZSK at 3893 + + ZSK/768 + KSK/1280 + MAX 10 KSK + 2 ZSK at 3913 + 8 KSK + 9 ZSK at 3970 + 6 KSK + 15 ZSK at 3914 + + ZSK/768 + KSK/1536 + MAX 8 KSK + 4 ZSK at 3917 + 7 KSK + 8 ZSK at 3938 + 6 KSK + 12 ZSK at 3959 + + ZSK/768 + KSK/2048 + MAX 6 KSK + 5 ZSK at 3936 + 5 KSK + 10 ZSK at 3942 + + ZSK/1024 + KSK/1024 + MAX 12 KSK + 2 ZSK at 3943 + 11 KSK + 4 ZSK at 3930 + 10 KSK + 6 ZSK at 3917 + 8 KSK + 10 ZSK at 3891 + + ZSK/1024 + KSK/1536 + MAX 8 KSK + 3 ZSK at 3900 + 7 KSK + 6 ZSK at 3904 + 6 KSK + 9 ZSK at 3908 + + ZSK/1024 + KSK/2048 + MAX 6 KSK + 4 ZSK at 3951 + 5 KSK + 8 ZSK at 3972 + 4 KSK + 12 ZSK at 3993 + + Note that these are just examples and this document is not making + any recommendations on suitable choices of either key lengths nor + number of different keys employed at a security apex. + + This document does however, based upon the above figures, make the + recommendation that at a security apex that expects to distribute + "trusted keys" the KEY RRset should only be signed with the KSKs + and not with the ZSKs to keep the size of the response packets + down. + + +5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver + + In DNSSEC according to RFC2535[RFC2535] validation is the process + of tracing a chain of signatures (and keys) upwards through the DNS + hierarchy until a "trusted key" is reached. If there is a known + trusted key present at a security apex above the starting point + validation becomes an exercise with a binary outcome: either the + validation succeeds or it fails. No intermediate states are + possible. + + With multiple "trusted keys" (i.e. the KEY RRset for the security + apex signed by multiple KSKs) this changes into a more complicated + space of alternatives. From the perspective of complexity that may + be regarded as a change for the worse. However, from a perspective + of maximizing available trust the multiple KSKs add value to the + system. + +5.1. Possible to do Threshold Validation + + With multiple KSKs a new option that opens for the security + concious resolver is to not trust a key individually. Instead the + resolver may decide to require the validated signatures to exceed a + threshold. For instance, given M trusted keys it is possible for + the resolver to require N-of-M signatures to treat the data as + validated. + + I.e. with the following pseudo-configuration in a validating + resolver + + security-apex "." IN { + keys { ksk-1 .... ; + ksk-2 .... ; + ksk-3 .... ; + ksk-4 .... ; + ksk-5 .... ; + }; + validation { + # Note that ksk-4 is not present below + keys { ksk-1; ksk-2; ksk-3; ksk-5; }; + # 3 signatures needed with 4 possible keys, aka 75% + needed-signatures 3; + }; + }; + + we configure five trusted keys for the root zone, but require two + valid signatures for the top-most KEY for validation to + succeed. I.e. threshold validation does not force multiple + signatures on the entire signature chain, only on the top-most + signature, closest to the security apex for which the resolver has + trusted keys. + +5.2. Not All Trusted Keys Will Be Available + + With multiple KSKs held and managed by separate entities the end + resolvers will not always manage to get access to all possible + trusted keys. In the case of just a single KSK this would be fatal + to validation and necessary to avoid at whatever cost. But with + several fully trusted keys available the resolver can decide to + trust several of them individually. An example based upon more + pseudo-configuration: + + security-apex "." IN { + keys { ksk-1 .... ; + ksk-2 .... ; + ksk-3 .... ; + ksk-4 .... ; + ksk-5 .... ; + }; + validation { + # Only these two keys are trusted independently + keys { ksk-1; ksk-4; }; + # With these keys a single signature is sufficient + needed-signatures 1; + }; + }; + + Here we have the same five keys and instruct the validating + resolver to fully trust data that ends up with just one signature + from by a fully trusted key. + + The typical case where this will be useful is for the case where + there is a risk of the resolver not catching a rollover event by + one of the KSKs. By doing rollovers of different KSKs with + different schedules it is possible for a resolver to "survive" + missing a rollover without validation breaking. This improves + overall robustness from a management point of view. + +5.3. Not All Possible KSKs Need to Be Trusted + + With just one key available it simply has to be trusted, since that + is the only option available. With multiple KSKs the validating + resolver immediately get the option of implementing a local policy + of only trusting some of the possible keys. + + This local policy can be implemented either by simply not + configuring keys that are not trusted or, possibly, configure them + but specify to the resolver that certain keys are not to be + ultimately trusted alone. + + +6. Additional Benefits from Having Multiple KSKs + +6.1. More Robust Key Rollovers + + With only one KSK the rollover operation will be a delicate + operation since the new trusted key needs to reach every validating + resolver before the old key is retired. For this reason it is + expected that long periods of overlap will be needed. + + With multiple KSKs this changes into a system where different + "series" of KSKs can have different rollover schedules, thereby + changing from one "big" rollover to several "smaller" rollovers. + + If the resolver trusts several of the available keys individually + then even a failure to track a certain rollover operation within + the overlap period will not be fatal to validation since the other + available trusted keys will be sufficient. + +6.2. Evaluation of Multiple Key Distribution Mechanisms + + Distribution of the trusted keys for the DNS root zone is + recognized to be a difficult problem that ... + + With only one trusted key, from one single "source" to distribute + it will be difficult to evaluate what distribution mechanism works + best. With multiple KSKs, held by separate entitites it will be + possible to measure how large fraction of the resolver population + that is trusting what subsets of KSKs. + + +7. Security Considerations + + From a systems perspective the simplest design is arguably the + best, i.e. one single holder of both KSK and ZSKs. However, if that + is not possible in all cases a more complex scheme is needed where + additional trust is injected by using multiple KSK holders, each + contributing trust, then there are only two alternatives + available. The first is so called "split keys", where a single key + is split up among KSK holders, each contributing trust. The second + is the multiple KSK design outlined in this proposal. + + Both these alternatives provide for threshold mechanisms. However + split keys makes the threshold integral to the key generating + mechanism (i.e. it will be a property of the keys how many + signatures are needed). In the case of multiple KSKs the threshold + validation is not a property of the keys but rather local policy in + the validating resolver. A benefit from this is that it is possible + for different resolvers to use different trust policies. Some may + configure threshold validation requiring multiple signatures and + specific keys (optimizing for security) while others may choose to + accept a single signature from a larger set of keys (optimizing for + redundancy). Since the security requirements are different it would + seem to be a good idea to make this choice local policy rather than + global policy. + + Furthermore, a clear issue for validating resolvers will be how to + ensure that they track all rollover events for keys they + trust. Even with operlap during the rollover (which is clearly + needed) there is still a need to be exceedingly careful not to miss + any rollovers (or fail to acquire a new key) since without this + single key validation will fail. With multiple KSKs this operation + becomes more robust, since different KSKs may roll at different + times according to different rollover schedules and losing one key, + for whatever reason, will not be crucial unless the resolver + intentionally chooses to be completely dependent on that exact key. + +8. IANA Considerations. + + NONE. + + +9. References + +9.1. Normative. + + [RFC2535] Domain Name System Security Extensions. D. Eastlake. + March 1999. + + [RFC3090] DNS Security Extension Clarification on Zone Status. + E. Lewis. March 2001. + + +9.2. Informative. + + [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS). D. Eastlake 3rd. May 2001. + + [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. + December 2001. + + [DS] Delegation Signer Resource Record. + O. Gudmundsson. October 2002. Work In Progress. + +10. Acknowledgments. + + Bill Manning came up with the original idea of moving complexity + from the signing side down to the resolver in the form of threshold + validation. I've also had much appreciated help from (in no + particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and + Olaf Kolkman. + + +11. Authors' Address +Johan Ihren +Autonomica AB +Bellmansgatan 30 +SE-118 47 Stockholm, Sweden +johani@autonomica.se diff --git a/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt b/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt new file mode 100644 index 000000000000..d857cd95806b --- /dev/null +++ b/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt @@ -0,0 +1,295 @@ + + + +Internet Engineering Task Force Akira Kato, WIDE +INTERNET-DRAFT Paul Vixie, ISC +Expires: August 24, 2003 February 24, 2003 + + + Operational Guidelines for "local" zones in the DNS + draft-kato-dnsop-local-zones-00.txt + +Status of this Memo + + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference material +or to cite them other than as ``work in progress.'' + +To view the list Internet-Draft Shadow Directories, see +http://www.ietf.org/shadow.html. + +Distribution of this memo is unlimited. + +The internet-draft will expire in 6 months. The date of expiration will +be August 24, 2003. + + +Abstract + +A large number of DNS queries regarding to the "local" zones are sent +over the Internet in every second. This memo describes operational +guidelines to reduce the unnecessary DNS traffic as well as the load of +the Root DNS Servers. + +1. Introduction + +While it has yet been described in a RFC, .local is used to provide a +local subspace of the DNS tree. Formal delegation process has not been +completed for this TLD. In spite of this informal status, .local has +been used in many installations regardless of the awareness of the +users. Usually, the local DNS servers are not authoritative to the +.local domain, they end up to send queries to the Root DNS Servers. + +There are several other DNS zones which describe the "local" +information. .localhost has been used to describe the localhost for +more than a couple of decades and virtually all of the DNS servers are +configured authoritative for .localhost and its reverse zone .127.in- + + +KATO Expires: August 24, 2003 [Page 1] + + +DRAFT DNS local zones February 2003 + +addr.arpa. However, there are other "local" zones currently used in the +Internet or Intranets connected to the Internet through NATs or similar +devices. + +At a DNS server of an university in Japan, half of the DNS queries sent +to one of the 13 Root DNS Servers were regarding to the .local. At +another DNS Server running in one of the Major ISPs in Japan, the 1/4 +were .local. If those "local" queries are able to direct other DNS +servers than Root, or they can be resolved locally, it contributes the +reduction of the Root DNS Servers. + +2. Rationale + +Any DNS queries regarding to "local" names should not be sent to the DNS +servers on the Internet. + +3. Operational Guidelines + +Those queries should be processed at the DNS servers internal to each +site so that the severs respond with NXDOMAIN rather than sending +queries to the DNS servers outside. + +The "local" names have common DNS suffixes which are listed below: + +3.1. Local host related zones: + +Following two zones are described in [Barr, 1996] and .localhost is also +defined in [Eastlake, 1999] . + + o .localhost + o .127.in-addr.arpa + + +Following two zones are for the loopback address in IPv6 [Hinden, 1998] +. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush, +2001] , the old TLD .int has been used for this purpose for years +[Thomson, 1995] and many implementations still use .int. So it is +suggested that both zones should be provided for each IPv6 reverse +lookup zone for a while. + + o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int + o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa + + +3.2. Locally created name space + +While the use of .local has been proposed in several Internet-Drafts, it +has not been described in any Internet documents with formal status. +However, the amount of the queries for .local is much larger than +others, it is suggested to resolve the following zone locally: + + + + +KATO Expires: August 24, 2003 [Page 2] + + +DRAFT DNS local zones February 2003 + + o .local + + + +3.3. Private or site-local addresses + +The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site- +local addresses [Hinden, 1998] should be resolved locally: + + o 10.in-addr.arpa + o 16.172.in-addr.arpa + o 17.172.in-addr.arpa + o 18.172.in-addr.arpa + o 19.172.in-addr.arpa + o 20.172.in-addr.arpa + o 21.172.in-addr.arpa + o 22.172.in-addr.arpa + o 23.172.in-addr.arpa + o 24.172.in-addr.arpa + o 25.172.in-addr.arpa + o 26.172.in-addr.arpa + o 27.172.in-addr.arpa + o 28.172.in-addr.arpa + o 29.172.in-addr.arpa + o 30.172.in-addr.arpa + o 31.172.in-addr.arpa + o 168.192.in-addr.arpa + o c.e.f.ip6.int + o d.e.f.ip6.int + o e.e.f.ip6.int + o f.e.f.ip6.int + o c.e.f.ip6.arpa + o d.e.f.ip6.arpa + o e.e.f.ip6.arpa + o f.e.f.ip6.arpa + + +3.4. Link-local addresses + +The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden, +1998] should be resolved locally: + + o 254.169.in-addr.arpa + o 8.e.f.ip6.int + o 9.e.f.ip6.int + o a.e.f.ip6.int + o b.e.f.ip6.int + o 8.e.f.ip6.arpa + o 9.e.f.ip6.arpa + o a.e.f.ip6.arpa + o b.e.f.ip6.arpa + + + +KATO Expires: August 24, 2003 [Page 3] + + +DRAFT DNS local zones February 2003 + +4. Suggestions to developers + +4.1. Suggestions to DNS software implementors + +In order to avoid unnecessary traffic, it is suggested that DNS software +implementors provide configuration templates or default configurations +so that the names described in the previous section are resolved locally +rather than sent to other DNS servers in the Internet. + +4.2. Suggestions to developers of NATs or similar devices + +There are many NAT or similar devices available in the market. +Regardless of the availability of DNS Servers in those devices, it is +suggested that those devices are able to filter the DNS traffic or +respond to the DNS traffic related to "local" zones by configuration +regardless of its ability of DNS service. It is suggested that this +functionality is activated by default. + +5. IANA Consideration + +While .local TLD has yet defined officially, there are substantial +queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the +traffic sent to the Root DNS Servers are related to the .local zone. +Therefore, while it is not formally defined, it is suggested that IANA +delegates .local TLD to an organization. + +The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918 +address and the link-local address. It has several DNS server instances +around the world by using BGP Anycast [Hardie, 2002] . So the AS112 +Project is one of the candidates to host the .local TLD. + +Authors' addresses + + Akira Kato + The University of Tokyo, Information Technology Center + 2-11-16 Yayoi Bunkyo + Tokyo 113-8658, JAPAN + Tel: +81 3-5841-2750 + Email: kato@wide.ad.jp + + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063, USA + Tel: +1 650-779-7001 + Email: vixie@isc.org + + + + + + + +KATO Expires: August 24, 2003 [Page 4] + + +DRAFT DNS local zones February 2003 + +References + +To be filled + +References + +Barr, 1996. +D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912 +(February 1996). + +Eastlake, 1999. +D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999). + +Hinden, 1998. +R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in +RFC2373 (July 1998). + +Bush, 2001. +R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001). + +Thomson, 1995. +S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in +RFC1886 (December 1995). + +Rekhter, 1996. +Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, +"Address Allocation for Private Internets" in RFC1918 (February 1996). + +IANA, 2002. +IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002). + +Vixie, . +P. Vixie, "AS112 Project" in AS112. http://www.as112.net/. + +Hardie, 2002. +T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast +Addresses" in RFC3258 (April 2002). + + + + + + + + + + + + + + + + + +KATO Expires: August 24, 2003 [Page 5] + diff --git a/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt new file mode 100644 index 000000000000..f9eaf268194f --- /dev/null +++ b/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt @@ -0,0 +1,1830 @@ + + + + INTERNET-DRAFT S. Daniel Park + Expires: October 2003 Syam Madanapalli + File: SAMSUNG Electronics + draft-park-ipv6-extensions-dns-pnp-00.txt April 2003 + + + + + IPv6 Extensions for DNS Plug and Play + + + + Status of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + + Abstract + + This document proposes automatic configuration of domain name (FQDN) + for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as + a part of IPv6 plug and play feature. 6DNAC allows the automatic + registration of domain name and corresponding IPv6 Addresses with + the DNS server. In order to provide 6DNAC function, Neighbor Discovery + Protocol [2461] will be used. Moreover, 6DNAC does not require any + changes to the existing DNS system. + + + Table of Contents + + 1. Introduction ............................................. 3 + 2. Terminology .............................................. 3 + 3. 6DNAC Design Principles .................................. 4 + 4. 6DNAC Overview ........................................... 4 + 5. 6DNAC Requirements ....................................... 5 + 5.1. 6DANR Client Requirements ................................ 5 + 5.2. 6DNAC Server Requirements ................................ 6 + +Park & Madanapalli Expires October 2003 [Page 1] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 6. 6DNAC Messages and Option Formats ........................ 6 + 6.1. Router Advertisement (RA) Message Format ................. 6 + 6.2. Neighbor Solicitation (NS) Message Format ................ 7 + 6.3. Neighbor Advertisement (NA) Message Format ............... 8 + 6.4. Option Formats ........................................... 8 + 6.4.1. DNS Zone Suffix Information Option Format ................ 8 + 6.4.2. Domain Name (FQDN) Option Format ......................... 9 + 6.4.3. Router Alert Option for 6DNAC ............................ 10 + 7. 6DNAC Operation .......................................... 10 + 7.1. 6DNAC Network Topology ................................... 11 + 7.2. 6DNAC Operational Scenarios .............................. 12 + 7.2.1. Domain Name Registration-Success Case .................... 12 + 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14 + 7.2.3. Domain Name Registration-Defend Case ..................... 16 + 7.2.4. Domain Name Registration in Retry Mode ................... 19 + 7.2.5. Domain Name Registration when DAD Fails .................. 20 + 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22 + 7.3.1. Sending Router Advertisement Messages .................... 22 + 7.3.2. Processing Router Advertisement Messages ................. 22 + 7.3.3. FQDN Lifetime expiry ..................................... 23 + 7.3.4. Host Naming Algorithm .................................... 23 + 7.4. Duplicate Domain Name Detection .......................... 23 + 7.4.1. DAD with All Nodes Multicast Address ..................... 24 + 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24 + 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24 + 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25 + 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25 + 7.4.1.5. Pros and Cons ............................................ 25 + 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25 + 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25 + 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26 + 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26 + 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26 + 7.4.2.5. Pros and Cons ............................................ 26 + 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26 + 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26 + 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26 + 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27 + 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27 + 7.4.3.5. Pros and Cons ............................................ 27 + 7.4.4. Retry Mode for Re-registering Domain Name ................ 27 + 7.5. Domain Name Registration ................................. 27 + 8. Security Consideration ................................... 27 + 9. IANA Consideration ....................................... 28 + 10. Acknowledgement .......................................... 28 + 11. Intellectual Property .................................... 28 + 12. Copyright ................................................ 28 + 13. References ............................................... 29 + 14. Author's Addresses ....................................... 30 + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 2] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 1. Introduction + + Today, most networks use DNS[1034][1035] for convenience. In case of + IPv6, DNS is more important element because of IPv6 long addresses + which are difficult to remember. In addition, small networks like home + networks using IPv6, should be able to make network easily without + manual configuration. Also, these small networks may not have DHCP + Server, DNS Server etc. that are used to configure the network. This + document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure + for generating and registering the Domain Name and IPv6 addresses with + the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are + required to implement lightweight functions specified in this document. + 6DNAC can be applied to all defined IPv6 unicast addresses except Link + local IPv6 addresses, viz: Site-local and Global addresses. + + 6DNAC uses Neighbor Discovery Protocol [2461] with new additions + (defined in section 6) and DAD procedures for generating and + registering the Domain Name with the DNS server automatically. + + + 2. Terminology + + 6DNAC - IPv6 Domain Name Auto Configuration. It can provide + IPv6 hosts with Domain Name Generation and + Registration automatically. + + 6DNAC Client - An IPv6 node that can generate its own unique Domain + Name. Section 3 identifies the new requirements that + 6DNAC places on an IPv6 node to be a 6DNAC node. + + 6DNAC Server - An IPv6 node that can collect and registrate Domain + Name and IPv6 addresses automatically. 6DNAC server + uses the information from the DAD operation messages + with newly defined options for the registration of the + Domain Name and IPv6 Addresses. Section 3 identifies + the new requirements that 6DNAC places on an IPv6 + node to be a 6DNAC server. Also 6DNAC server can have + various other functions depending on network + environment and the network operator. For instance + 6DNAC Server can acts as a Gateway as well Home Server + in Home Networks. + + DAD - Duplicate Address Detection (is defined [2461]) + + DFQDND - Duplicate Domain Name Detection + + FQDN - Fully Qualified Domain Name - FQDN and Domain Name are + used interchangeably in this document. + + NA - Neighbor Advertisement message (is defined [2461]) + + NS - Neighbor Solicitation message (is defined [2461]) + + RA - Router Advertisement message (is defined [2461]) + + SLAAC - Stateless Address Autoconfiguration [2462]. + +Park & Madanapalli Expires October 2003 [Page 3] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 3. 6DNAC Design Principles + + This section discusses the design principles of 6DNAC mechanism. + + 1. The new procedures for plug and play DNS should not cause changes + to existing DNS system. 6DNAC requires lightweight functions to be + implemented only at the client side of the DNS system, and uses the + existing DDNS UPDATE [2136] to communicate with DNS Servers. + + 2. Introducing a new protocol will always introduce new problems. + 6DNAC uses the existing protocols NDP [2461] with minor extensions + for generating and registering the domain name automatically + without defining a new protocol + + 3. Reusing proven and well understood design principles/patterns + will always yield a robust system. 6DNAC is based on IPv6 Address + Auotoconfiguration principle, where routers advertise the prefix + and host adds the interface ID to the prefix and forms the IPv6 + address. Domain Name (FQDN) also contains two parts: host name + and DNS zone suffix. Routers can advertise the DNS zone suffix + on a particular link in Router Advertisements (RA Messages) and + hosts can prefix their preferred host name to the DNS zone suffix + and form the fully qualified domain name. Also the detection of + duplicate domain name is similar to Duplicate Address Detection + (DAD) and can be part of DAD operation itself. + + + 4. 6DNAC Overview + + 6DNAC proposes minor extensions to NDP [2461] for automatic generation + and registration of domain name with the DNS server. It introduces two + new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone + Suffix option is carried in Router Advertisement (RA) messages for + notifying IPv6 nodes about the valid DNS Zone Suffix on the link and + FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement + (NA) messages to detect duplicate domain name. 6DNAC consists of two + components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the + domain name based on DNS Zone Suffix using Host Naming Algorithm (see + section 7.3.1) and 6DNAC Server collects and registers the DNS + information with the DNS Server on behalf of 6DNAC Clients. + + The automatic configuration of domain name using 6DNAC consists of + three parts. + + - DNS Zone Suffix Discovery and FQDN Construction: + + IPv6 Nodes collect DNS Zone Suffix information from Router + Advertisements and constructs FQDN by prefixing host name to the + DNS Zone Suffix. The IPv6 Nodes are required to implement Host + Naming Algorithm for generating host part of the FQDN in the + absence of administrator. + + Generation of node's FQDN within the node itself has advantages. Nodes + can provide forward and reverse name lookups independent of the DNS + System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain + Name is some thing that is owned by the node. + +Park & Madanapalli Expires October 2003 [Page 4] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + - Duplicate Domain Name Detection + + All nodes are expected to go for DAD for all new IPv6 unicast + addresses, regardless of whether they are obtained through + stateful, stateless or manual configuration. 6DNAC uses the DAD + messages with new option for carrying the Domain Name along with + the new IPv6 Address. 6DNAC Server captures this information and + updates DNS Server provided that the IPv6 Address and its domain + name are not duplicate. If the domain name is already in use, + the 6DNAC server replies to the sender with FQDN Option in NA + message indicating that the domain name is duplicate. Then the + node is expected to generate another domain name using host + naming algorithm and go for DAD. This time the DAD is only for + duplicate domain name detection (DFQDND). In order to avoid + confusion with the normal NDP processing, the target address + field of the NS message must carry the unspecified address + in retry mode. This can be repeated depending on number of + retries defined by the administrator in the host naming algorithm. + + + - Domain Name Registration + + 6DNAC Server detects the DNS information (IPv6 Address and + corresponding FQDN) from DAD/DFQDND messages and updates DNS + Server using existing protocol DDNS UPDATE [2136] provided that + the IPv6 Address and its domain name are not duplicate. + + If an IPv6 Address is duplicate, the IPv6 node cannot perform + stateless address autoconfiguration repeatedly. Unlike IPv6 stateless + address autoconfiguration, 6DNAC allows the automatic configuration of + domain name repeatedly if the domain name is duplicate depending on + number of retries defined by the administrator in the host naming + algorithm. + + + 5. 6DNAC Requirements + + Depending on the 6DNAC functionality, the IPv6 nodes implement, they + are called either 6DNAC Clients or 6DNAC Servers. The following + sections lists the requirements that the 6DNAC Client and 6DNAC server + must support. + + + 5.1. 6DANC Client Requirements + + - 6DNAC Client must recognize and process the following NDP + extensions + + - DNS Zone Suffix option in RA messages for generating its + domain name (FQDN). + + - Domain Name option in NS and NA messages for detecting + the duplicate domain name + + + + +Park & Madanapalli Expires October 2003 [Page 5] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + - It must generate its domain name (FQDN) based on the DNS + suffix that it got from the router advertisement. And it must + have a host naming algorithm for generating the host part of + the FQDN. + + - If NA message is received with unspecified target address and + FQDN option, then the node must treat that the domain is + duplicate. + + + 5.2. 6DNAC Server Requirements + + - 6DNAC Server must recognize and process the following NDP + extensions + + - If the 6DNAC Server is a router on the link, then it + must advertise DNS Zone Suffix option in RA messages + for hosts to generate their domain name (FQDN). + + - FQDN option in NS messages for detecting new DNS + information for of nodes on the link for which it + must update the AAAA RR and PTR RR in DNS Server. + + - FQDN option in NA messages for notifying duplicate + domain name with unspecified target address. + + - 6DNAC server must update the DNS Server (both AAAA RR and + PTR RR) dynamically using DDNS UPDATE [2136]. + + - 6DNAC server must cache this (newly detected) FQDN, Link + Layer Address, and IPv6 Address information, so that it can + decide whether it really needs to update DNS Server or not, + to avoid redundant updates. This information will also be + used for notifying the duplicate domain name. + + + 6. 6DNAC Messages and Option Formats + + In order to achieve the plug and play DNS, 6DNAC proposes new + extensions to the NDP [2461]. This section specifies the new + additions to NDP messages and formats of new options. + + + 6.1. Router Advertisement (RA) Message Format + + Routers send out Router Advertisement (RA) message periodically, or + in response to a Router Solicitation. 6DNAC does not modify the format + of the RA message, but proposes new option (DNS Zone Suffix Information) + to be carried in RA messages. + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 6] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cur Hop Limit |M|O| Reserved | Router Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reachable Time | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Retrans Timer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | DNS Zone Suffix Information | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + 6.2. Neighbor Solicitation (NS) Message Format + + 6DNAC does not modify the format of the Neighbor Solicitation (NS) + message, but proposes new option (FQDN Option) to be carried in NS + messages. When a node is going for DAD, the node must include FQDN + option in NS message to participate in plug and play DNS. If the + node is going for Explicit Detection of Duplicate Domain Name, the + node must use FQDN option in NS message and unspecified address in + the target address field. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | Domain Name | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Park & Madanapalli Expires October 2003 [Page 7] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 6.3. Neighbor Advertisement (NA) Message Format + + 6DNAC does not modify the format of the Neighbor Advertisement (NA) + message, but proposes new option (FQDN Option) to be carried in NA + messages. 6DNAC Server sends NA message with FQDN option to 6DNAC + Client that is performing duplicate domain name detection in case + the domain name found to be duplicate. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R|S|O| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | FQDN Option | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + 6.4 Option Formats + + 6.4.1. DNS Zone Suffix Information Option Format + + IPv6 nodes require DNS Zone Suffix for constructing their FQDN. + 6DNAC introduces new option for routers to advertise the DNS Zone + Suffix Information for IPv6 nodes on the link. The suffix information + should be configured into routers manually. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / DNS Zone Suffix / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Park & Madanapalli Expires October 2003 [Page 8] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + Type [TBD] + + Length 8-bit unsigned integer. The length of the option + (including the type and length fields) in units of + 8 octets. + + Reserved This field is unused. It must be initialized to zero + by the sender and must be ignored by the receiver. + + Valid Life Time 32-bit signed integer. The maximum time, in + seconds, over which this suffix is valid. Nodes + should treat this as the life time for their domain + name. Nodes should contact the source of this + information before expiry of this time interval. + A value of all one bits (0xFFFFFFFF) represents + infinity. + + DNS Zone Suffix The suffix part of the FQDN. The data in the DNS + Zone Suffix field should be encoded according to + DNS encoding rules specified in [1035]. + + + + 6.4.2. Domain Name (FQDN) Option Format + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + FQDN Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / Domain Name / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + Type [TBD] + + Length 8-bit unsigned integer. The length of the option + (including the type and length fields) in units + of 8 octets. It must be greater than 3. + + + +Park & Madanapalli Expires October 2003 [Page 9] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + Reserved This field is unused. It must be initialized to + zero by the sender and must be ignored by the + receiver. + + Valid Life Time 32-bit signed integer. The maximum time, in + seconds, over which this domain name is valid + 6DNAC should deregister this domain name at + the expiry of this interval. 6DNAC clients + should send updates by the expiry of this + interval. A value of all one bits (0xFFFFFFFF) + represents infinity. + + FQDN Target Address The Address for which the FQDN maps to. It + should be same as Target Address field of the + NS message in case of DAD & duplicate FQDN are + running in parallel. + + Domain Name The domain name (FQDN) of the node. The data in + the domain name should be encoded according to + DNS encoding rules specified in [1035]. + + + 6.4.3. Router Alert Option for 6DNAC + + Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop + Header for using in NDP messages. The presence of this option in NS + message informs the router that this NS message is carrying Domain + Name information and must be processed by the 6DNAC Server on the router. + 6DNAC Clients can use this option for sending DAD packets instead + of addressing the DAD packets to the all-nodes multicast address + when 6DNAC Server is implemented on router. + + The Router Alert option has the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Length = 2 + + Values are registered and maintained by the IANA. For 6DNAC, the + value has to be assigned by IANA. + + Further information about this option can be obtained from + IPv6 Router Alert Option [2711]. + + + 7. 6DNAC Operation + + 6DNAC provides mechanisms for automatic generation of domain name + and registering it with the DNS Server for IPv6 nodes. 6DNAC consists + of two components: 6DNAC Client and 6DNAC Server. All nodes that want + to participate in plug and play DNS are required to implement 6DNAC + Client functionality, and one of the IPv6 nodes is required to + implement 6DNAC Server functionality. The IPv6 node that implements + the 6DNAC Server functionality must know the location of the DNS + Server and must be a trusted node to send DDNS UPDATE [2136] messages. + +Park & Madanapalli Expires October 2003 [Page 10] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 7.1. 6DNAC Network Topology + + This section identifies the possible locations for the 6DNAC Server. + Note that, all nodes are required to implement 6DNAC Client + functionality for constructing the domain name from the DNS Zone + Suffix Information advertised by the router. Figure 6 illustrates + IPv6 host (H4) implementing 6DNAC Server functionality. In this case + H4 can serve only one link (that it belongs to) for automatic + registration of domain name. H4 must observe the DAD packets on the + link to detect the DNS information, this requires all nodes on the + link must belong to same solicited node multicast address. In general, + this may not be the case. So the node that is going for DAD must use + all nodes multicast address for DAD packets, so that the 6DNAC Server + (H4) can observe the DAD packets, detects IPv6 address and + corresponding domain name, checks if this domain name is duplicate + and finally registers the domain name with the DNS Server. + + + 6DNAC Server + +---+ +---+ +----------+ + | H1| | H4|<--- DDNS UPDATE --->|DNS Server| + +-+-+ +-+-+ +----+-----+ + | | +----+ +---/ + | | | | / + ---+-----+-----------+-----+-----------+ R1 +-----+ + | | | | + | | +----+ + +-+-+ +-+-+ + | H2| | H3| + +---+ +---+ + + + H1, H2, H3 - 6DNAC Clients + H4 - 6DNAC Server + R1 - Router + + + + + + Figure 7 shows the 6DNAC Server implemented on a router R1. In this + case a single 6DNAC server can serve multiple links for automatic + configuration of the domain name. This topology also has flexibility + of using DAD packets with Router Alert option instead of sending DAD + packets to all nodes multicast address. The routers are required to + process all the packets with Router Alert option as per [2711]. + + In case of Home Networks, R1 is will acts as a Home Gateway (CPE) + connected to ISP. R1 delegates the prefix from the ISP edge router. + After delegating the prefix the CPE can advertise the DNS Zone suffix + along with the prefix information to the nodes on the links to which + the router is connected to. Note that the R1 must be configured with + the DNS Zone suffix Information manually. + + + + +Park & Madanapalli Expires October 2003 [Page 11] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---+ +---+ + | H3+ | H4| + +-+-+ +-+-+ + | | + | LINK2 | + +---+ ---+--------+--+-- +----------+ + | H1| | |DNS Server| + +-+-+ | +----+-----+ + | +--+-+ -------/ + | LINK 1 | | / + ---+-----+------------------+ R1 +---------+ + | | | DDNS UPDATE + | +----+ + +-+-+ 6DNAC Server + | H2| + +---+ + + + H1, H2 - 6DNAC Clients on Link1 + H3, H4 - 6DNAC Clients on Link2 + R1 - Router with 6DNAC Server, serving both Link1 and Link2 + + + + + + 7.2. 6DNAC Operational Scenarios + + This section provides message sequence charts for various 6DNAC + operational scenarios assuming that the 6DNAC Server is implemented + on a router. All the scenarios assume that the normal boot up time + stateless address autoconfiguration of Link Local address derived + from the Interface Identifier has been completed successfully. And + it is also assumed that the router is already configured with the + DNS Zone Suffix Information. + + + Legend: + + 6DNAC-A, B, C : 6DNAC Clients + 6DNAC-S : 6DNAC Server/Router + DAD : Duplicate Address Detection + DFQDND : Duplicate Domain Name Detection + DNS-S : DNS Server + + + 7.2.1. Domain Name Registration-Successful Case + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. It is Assumed that the + DupAddrDetectTransmits is set to 1. + + + + +Park & Madanapalli Expires October 2003 [Page 12] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + | RA with | | + | DNS Suffix Opt | | + |<---------------| | + | #1 | | + |---+ | | + Construct |#2 | | + FQDN | | | + |<--+ | | +DAD/DFQDND Starts | | + | | | + | | | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #3 | | + | | | + | |------+ | + | Create FQDN | #4 | + | | | + | |<-----+ | + | | | + | | Register FQDN | + | |--------------->| + | | #5 | + | #6 | | + |--------+ | | + No Response | | | + DFQDND-Success | | | + |<-------+ | | + | | | + | | | + v V v + + + + + + #1. 6DNAC Server (Router) sends out router advertisement with DNS + Suffix information along with other parameters as specified in + NDP [2461]. + + #2. 6DNAC Client processes the router advertisement and constructs + the FQDN by prefixing hostname to the DNS Zone Suffix. It also + constructs IPv6 address from the autoconfiguration prefix + information option. + + #3. 6DNAC Client starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor + Solicitation message with FQDN option. + + Note that the DAD packets must be addressed to all nodes multicast + address if Router Alert option is not used. + +Park & Madanapalli Expires October 2003 [Page 13] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #4. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client as part of duplicate FQDN detection procedure and + creates a FQDN entry in its FQDN Cache (assuming that there is no + entry ), where C is Link Layer Address of the 6DNAC Client. + + #5. 6DNAC Server then registers FQDN and corresponding IPv6 address + through the existing protocol DDNS UPDATE. + + #6. 6DNAC Client times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name. + + Note that, Stateless Address Autoconfiguration DAD procedure is not + depicted in the following message sequence chart, which simultaneously + happens along with duplicate FQDN detection. + + + 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. The node is configured with + DupAddrDetectTransmits = 2 for reliability in delivering DAD messages. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 14] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + | RA with | | + | DNS Suffix Opt | | + |<---------------| | + | #1 | | + |---+ | | + Construct |#2 | | + FQDN | | | + |<--+ | | +DAD/DFQDND Starts | | + | | | + | | | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #3 | | + | | | + | |------+ | + | Create FQDN | #4 | + | | | + | |<-----+ | + | | | + | | Register FQDN | + | |--------------->| + | | #5 | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #6 | | + | | | + | Lookup FQDN | + | Entry exists | + | |------+ | + | Ignore | #7 | + | |<-----+ | + | #8 | | + |--------+ | | + No Response | | | + DFQDND-Success | | | + |<-------+ | | + | | | + | | | + v V v + + + + + + + Steps from #1 to #5 are same as that of scenario.7.2.1. + + #6. 6DNAC Client sends out second Neighbor Solicitation message with + FQDN option as part of duplicate FQDN detection. + +Park & Madanapalli Expires October 2003 [Page 15] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #7. 6DNAC Server receives and observes that the FQDN Cache exactly + matches with that of the NS information and ignores the NS message. + + #8. 6DNAC Client times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name.. + + + 7.2.3. Domain Name Registration-Defend Case + + This scenario starts when two 6DNAC Client receive RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and both the nodes want configure their IPv6 + address (Global or Site Local) and domain name. In this scenario both + the nodes want to have same domain name. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 16] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + + +---------+ +---------+ +---------+ +---------+ + | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | + +----+----+ +----+----+ +----+----+ +----+----+ + | | | | + | RA with | RA with | | + | DNS Suffix Opt | DNS Suffix Opt | | + |<---------------|--------------->| | + | #1 | #1 | | + |---+ | |---+ | + Construct | #2 | Construct | #2 | + FQDN | | FQDN | | + |<--+ | |<--+ | + DAD/DFQDND Starts | DAD/DFQDND Starts | + | | | + | | | | + | NS with | | | + | FQDN Opt | | | + |--------------->| | | + | #3 | | | + | No Entry | | + | |------+ | | + | Create FQDN | #4 | | + | | | | + | |<-----+ | | + | | | | + | | Register FQDN #5 | + | |-------------------------------->| + | | | | + | | NS with | | + | | FQDN Opt | | + | |<---------------| | + | | #6 | | + | |------+ | | + | FQDN is in use| | | + | Defend DFQDND| #7 | | + | |<-----+ | | + | | | | + | | NA with | | + | | D-flag Set | | + | |--------------->| | + | | #8 | | + |------+ | |---+ | + No Response | #9 | Enter | #10 | + DFQDND Success| | Retry Mode| | + |<-----+ | |<--+ | + | | | | + v v v v + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 17] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #1. 6DNAC Server (Router) sends out router advertisement with DNS + Suffix information. + + #2. 6DNAC Clients A&B process the router advertisement and construct + their FQDN by prefixing hostname to the DNS Zone Suffix. They + also construct IPv6 address from the autoconfiguration prefix + information option. + + When each host is trying to go for DAD, all hosts must have + random delay to avoid the traffic congestion according to [2461]. + So here it is assumed that 6DNAC Client-A starts DAD first and + 6DNAC Client-B starts DAD later. + + #3. 6DNAC Client-A starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor + Solicitation message with FQDN option. + + #4. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client-A as part of duplicate FQDN detection procedure and + creates a FQDN entry in its FQDN Cache (assuming that there is no + entry ), where A is Link Layer Address of the 6DNAC Client-A. + + #5. 6DNAC Server then registers FQDN and corresponding IPv6 address + through the existing protocol DDNS UPDATE. + + #6. 6DNAC Client-B starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor Solicitation + message with FQDN option. + + #7. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client-B as part of duplicate FQDN detection procedure and + finds that the domain name is already in use by the 6DNAC Client-A. + Hence, concludes to defend the duplicate FQDN detection of 6DNAC + Client-B. + + #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN + option to 6DNAC Client-B to defend its duplicate FQDN detection. + + #9. 6DNAC Client-A times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name. + + #10. 6DNAC Client-B observes that there is a NA with FQDN option + indicating that the domain name is duplicate and enters Retry + Mode. In retry mode, 6DNAC Client constructs another FQDN based + on Host Naming Algorithm. The number of retries is defined by the + administrator and must be a configurable value. + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 18] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 7.2.4. Domain Name Registration in Retry Mode + + Pre-Conditions: + + 1. Duplicate Address Detection has succeeded + 2. Duplicate FQDN Detection FAILED + 3. FQDN is the first FQDN one constructed and FAILED + 4. FQDN2 is the second FQDN to be constructed + 5. The Neighbor Solicitation in the 'Retry Mode' + carries unspecified address in its target field (NS*). + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + |--------+ | | + Construct | #1 | | + new FQDN2 | | | + |<-------+ | | + | | | + DFQDND Restarts | | + | | | + | | | + | NS* With | | + | FQDN Opt | | + |--------------->| | + | #2 | | + | | | + | No Entry | + | |------+ | + | Create FQDN | #3 | + | | | + | |<-----+ | + | | | + | | Register FQDN2 | + | |--------------->| + | | #4 | + | | | + |--------+ | | + No Response | #5 | | + DFQDND-Success | | | + |<-------+ | | + | | | + v V v + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 19] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm, + the DNS Zone Suffix, and it is FQDN2. + #2. It then starts Duplicate Detection only for Domain Name. 6DNAC + Client sends out NS with FQDN option and unspecified target + address. + + #3. 6DNAC Server processes the Retry Mode NS message and finds that + the FQDN2 is not in use and creates Cache entry as . + + #4. It then starts registration procedures with the DNS Server. + + #5. Meanwhile, 6DNAC Client timesout and observes that there is no + defending NA for its DFQDND NS sent out and successfully + configures its domain name. + + + 7.2.5. Domain Name Registration when DAD Fails + + Duplicate domain name detection and subsequent registration starts + if and only if the DAD for IPv6 address succeeds. If the DAD for + IPv6 address fails then no actions are taken for domain name. When + DAD fails for stateless address autoconfiguration, then the domain + configuration starts only when the address has been configured using + Stateful Address Configuration methods and the node is going on DAD + for this address. + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 20] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ +---------+ + | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | + +----+----+ +----+----+ +----+----+ +----+----+ + | | | | + | | | | + | RA with | | | + | DNS Suffix Opt | | | + |<---------------| | | + | #1 | | | + |-----+ | | | + Construct | | | | + FQDN& | #2 | | | + IPv6 Addr | | | | + |<----+ | | | + DAD/DFQDND Starts | | | + | | | | + | | | | + | NS with | | | + | FQDN Opt | | | + |--------------->+--------------->| | + | #3 | #3 | | + | No Entry | | + | |------+ | | + | Create FQDN | | | + | | #4 | | + | |<-----+ | | + | | | | + | | |------+ | + | | My IPv6 Addr| #5 | + | | |<-----+ | + | | Defend DAD | | + | | with NA | | + |<---------------+<---------------| | + | #6 | #6 | | + | Entry | | + | |------+ | | + | Delete FQDN | #7 | | + | |<-----+ | | + | | | | + |----+ | | | + DAD Failed | #8 | | | + Stop DFQDND | | | | + |<---+ | | | + | | | | + v v v v + + + + #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A. + + #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and + FQDN as per Host Naming Algorithm. + + #3. It then starts Duplicate address & FQDN Detection, for the newly + constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS + with FQDN option. + +Park & Madanapalli Expires October 2003 [Page 21] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #4. 6DNAC Server processes the DAD/DFQDND NS message and finds + that there is no entry for the FQDN in its cache. And, + creates Cache entry as and starts a Registration + timer with RegistrationWaitTime seconds. + + #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is + in its unicast address list. + + #6. It then starts defending DAD by sending NA to all-nodes multicast. + + #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A. + And, deletes its FQDN Cache entry . + + #8. 6DNAC Client gets defending DAD-NA and desists from DAD. + And also, stops Duplicate FQDN Detection as well. + At this point the address must be configured using stateful + methods and the domain name registration starts with the DAD + for the newly constructed IPv6 address. + + 7.3. DNS Zone Suffix Discovery and FQDN Construction + + 7.3.1. Sending Router Advertisement Messages + + Routers send out Router Advertisement message periodically, + or in response to a Router Solicitation. Router should include + the DNS Zone Suffix Option in their advertisements. If the DNS + Zone Suffix changes (similar to Site Renumbering), then it should + advertise the Old Zone Suffix with zero Valid Lifetime and New + Zone Suffix with proper non-zero Valid Lifetime. In any other + case, a router should not send this option twice in a single + router advertisement. + + 7.3.2. Processing Router Advertisement Messages + + For each DNS Zone Suffix Option in Router Advertisement, + + a. 6DNAC node stores the Zone Suffix information in its local + database. Also, constructs FQDN as per Host Naming Algorithm. + + b. If the node has not configured FQDN yet, + + 1. If the node is going to perform DAD for either Site local or + Global Address, then it should include FQDN option to perform + Duplicate FQDN Detection in parallel with DAD. + + 2. If the node has already got either Site local or Global + address, then it should send out NS with FQDN option and + unspecified target address to perform Duplicate FQDN + Detection. + + c. If the node has already configured FQDN, and if the + advertisement carries two DNS Zone Suffix Options, + First DNS Zone Suffix should match with the configured FQDN + Suffix and its Valid Lifetime must be zero. Second DNS Zone + + + +Park & Madanapalli Expires October 2003 [Page 22] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + Suffix should have non-zero Valid Lifetime. In this case, the + node constructs new FQDN based on the new DNS Zone Suffix (from + second DNS Zone Suffix option), and perform Duplicate FQDN + Detection with unspecified target address. Also, it should + overwrite the old FQDN with the newly constructed FQDN. + + + 7.3.3. FQDN Lifetime expiry + + 6DNAC Server: + It should delete the FQDN cache entry and should de-register from + the DNS Server. + + 6DNAC Client: + It should send update to 6DNAC Server by restarting the Duplicate + FQDN Detection. + + 7.3.4. Host Naming Algorithm + + A node constructs FQDN by combining DNS Zone Suffix and the hostname + as depicted in the following diagram. + + +------------------+----------------------------------+ + | Host Name | Advertised Suffix | + +------------------+----------------------------------+ + +
+ + A node can choose Host Name using any of the following methods: + + a. String form of random number generated from the Interface + Identifier. + + b. List of configured Host Names provided by the administrator. + + + The number of retries must be specified in this algorithm in + case of domain name duplication. + + + 7.4. Duplicate Domain Name Detection + + The procedure for detecting duplicated FQDNs uses Neighbor + Solicitation and Advertisement messages as described below. + + If a duplicate FQDN is detected during the procedure, the + FQDN cannot be assigned to the node. + + An FQDN on which the DFQDND Procedure is applied is said + to be tentative until the procedure has completed successfully. + A tentative FQDN is not considered "assigned to the node" in the + traditional sense. That is, the node must accept Neighbor + Advertisement message containing the tentative FQDN in the FQDN + Option. + + +Park & Madanapalli Expires October 2003 [Page 23] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + It should also be noted that DFQDN must be performed prior to + registering with DNS Server to prevent multiple nodes from using + the same FQDN simultaneously. All the Duplicate Address Detection + Neighbor Solicitation messages must carry Source Link Layer Address + Option as specified in NDP [2461]. + + The detection of duplicate FQDN can be achieved through one of the + following three types of procedures. + + 1. DAD with All Nodes Multicast Address + 2. DAD with Router Alert Option for 6DNAC. + 3. Explicit Detection of Duplicate Domain Name + + Even though three solutions are listed, authors prefer only one + procedure to be followed in future based on further analysis and + comments received from others. + + 7.4.1. DAD with All Nodes Multicast Address + + 7.4.1.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate Address Detection SLAAC [2462] with the following + extra information and modifications: + + a. Include FQDN Option in the DAD Neighbor Solicitation Message + b. Destination Address is set to All Nodes Multicast Address + + There may be a case where DAD has succeeded but DFQDND is in Retry + Mode. In such case, the Neighbor Solicitation must carry unspecified + address in the ICMP target address field and new domain name in FQDN + option to re-try the registration of the domain name. + + 7.4.1.2. Processing Neighbor Solicitation Messages + + 6DNAC Clients must ignore the FQDN option found in any of the + neighbor solicitation messages. + + 6DNAC Server processes FQDN Option found in the Duplicate Address + Detection Neighbor Solicitation Messages as described below: + + Lookup FQDN Cache for the domain name in FQDN Option. + + If the entry exists and + i. Link Layer Address matches with SLLA option, this is the case, + where node has changed its IPv6 address or updating the valid + life time. 6DNAC Server updates its cache and also updates DNS + Server using DDNS-UPDATE. If there is no change in IPv6 address + or life time then no updates are sent to the DNS server. + + ii. Link Layer Address differs with SLLA option, defend the duplicate + FQDN Detection by sending Neighbor Advertisement Message as + described in $7.4.1.3$. + + + +Park & Madanapalli Expires October 2003 [Page 24] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + else, + Lookup FQDN Cache for the Link Layer Address in SLLA Option. + + If the entry exists, update the FQDN Cache and update DNS Server + using DDNS-UPDATE. This is the case, where node has changed its + domain name (similar to Site Re-numbering). + + If then entry does not exists, then it means that this is the new + registration. It must create a cache entry and start Registration + + timer with RegistrationWaitTime. At the expiry of the Registration + timer, it should update DNS Server with DDNS-UPDATE. + + 7.4.1.3. Sending Neighbor Advertisement Messages + + 6DNAC Server sends Neighbor Advertisement Messages as part + of Duplicate Address Detection SLAAC [2462] with the FQDN Option + in Neighbor Advertisement message to defend duplicate FQDN + detection. + + There may be the case where defending of duplicate address detection + is not required but defending of FQDN is required. In such instance, + the defending Neighbor Advertisement must carry FQDN and unspecified + address in the ICMP target address field. + + 7.4.1.4. Processing Neighbor Advertisement Messages + + 6DNAC Server must ignore the any FQDN option found any of + the neighbor advertisement messages. If the Neighbor Advertisement + is a DAD defending, then it must delete its FQDN Cache entry created + on the reception of DAD Neighbor Solicitation message. + + When 6DNAC Clients gets the duplicate address detection neighbor + advertisement messages with FQDN option set it means that its + duplicate FQDN detection failed and enters Retry Mode. + + 7.4.1.5. Pros and Cons + + The advantage of this procedure is that it does not need any + extension header options to be included. The disadvantage of this + procedure is that, it needs change in the existing DAD procedure. + The change is only that the DAD neighbor solicitations are to be + addressed to all nodes multicast address instead of solicited + node multicast address. The another disadvantage is that, it needs + the existence of Duplicate Address Detection Procedure to + perform duplicate FQDN detection. + + 7.4.2. DAD with Router Alert Option for 6DNAC + + 7.4.2.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate Address Detection SLAAC [2462] with the following + extra information: + + +Park & Madanapalli Expires October 2003 [Page 25] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + a. Include Hop-by-Hop extension Header with Router Alert Option + for 6DNAC as described in IPv6 Router Alert Option[2711]. + + b. Include FQDN Option in the DAD Neighbor Solicitation Message + + 7.4.2.2. Processing Neighbor Solicitation Messages + + This is same as described in $7.4.1.2$. + + 7.4.2.3. Sending Neighbor Advertisement Messages + + This is same as described in $7.4.1.3$. + + 7.4.2.4. Processing Neighbor Advertisement Messages + + This is same as described in $7.4.1.4$. + + 7.4.2.5. Pros and Cons + + The advantage of this procedure is that it does not disturb + the existing implementation and their way of processing the + packets. The disadvantage is that, it needs the existence + of Duplicate Address Detection Procedure to perform duplicate + FQDN detection. Another disadvantage is that this procedure + requires 6DNAC Server functionality to be implemented on Router. + However, in this case 6DNAC Server can serve multiple links. + + 7.4.3. Explicit Detection of Duplicate Domain Name + + In this procedure Duplicate FQDN Detection starts after completion + of successful Site local or Global Address configuration. + + 7.4.3.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate FQDN Detection with the following information: + + a. Include FQDN Option in the Neighbor Solicitation Message + + b. Destination Address is set to All Nodes Multicast Address + or uses Router Alert Option for 6DNAC, when 6DNAC Server is + implemented on router. + + c. Target Address is set to Unspecified Address + + d. Other fields are set as per DAD SLAAC [2462]. + + 7.4.3.2. Processing Neighbor Solicitation Messages + + This is same as described in $7.4.1.2$. + + + + + + +Park & Madanapalli Expires October 2003 [Page 26] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + 7.4.3.3. Sending Neighbor Advertisement Messages + + This is same as described in $7.4.1.3$. + + 7.4.3.4. Processing Neighbor Advertisement Messages + + This is same as described in $7.4.1.4$. + + 7.4.3.5. Pros and Cons + + The advantage of this procedure is that it does not need the + existing duplicate address detection procedure. This is introduced + as the DAD procedure is found to be redundant in when IPv6 addresses + are constructed from the interface ID [DIID]. + + Note that, if 6DNAC Clients know the address of 6DNAC Server then + they can directly send DFQDND-NS to 6DNAC Server. + + 7.4.4. Retry Mode for Re-registering Domain Name + + In retry mode, nodes construct new FQDN as per Host Naming Algorithm. + Then they restart Duplicate FQDN Detection as described in $7.4.3$. + + + 7.5. Domain Name Registration + + 6DNAC Server must be an authenticated to update the DNS Server. + 6DNAC Server must also be configured with the DNS Server + information. + + 6DNAC Server detects the DNS information (IPv6 Address and + corresponding FQDN) from DAD/DFQDND messages and caches the + information. It also have an associated Registration Timer with + RegistrationWaitTime to wait for the successful completion of + DFQDND and update DNS Server using existing protocol DDNS UPDATE + [2136]. + + + 8. Security Consideration + + If someone wants to hijack correct Domain Name registration, they + could send a NS message with incorrect or same Domain Name to the + 6DNAC server repeatedly and server would start the Domain Name + registration through above mechanism, which is a security hole. + As described in [2461], a host can check validity of NDP messages. + If the NDP message include an IP Authentication Header, the message + authenticates correctly. For DNS UPDATE processing, secure DNS + Dynamic Update is described in [3007]. + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 27] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + 9. IANA Consideration + + Values in the Router Alert Option are registered and maintained by + IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is + required to assign the Type values for DNS Zone Suffix Information + option and FADN option. + + + 10. Acknowledgement + + Special thanks are due to Badrinarayana N.S. and Christian Huitema for + many helpful suggestions and revisions. + + + 11. Intellectual Property + + The following notice is copied from RFC 2026 [Bradner, 1996], + Section 10.4, and describes the position of the IETF concerning + intellectual property claims made against this document. + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use other technology described in + + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances + of licenses to be made available, or the result of an attempt made + to obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification + can be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + 12. Copyright + + The following copyright notice is copied from RFC 2026 [Bradner, + 1996], Section 10.4, and describes the applicable copyright for this + document. + + Copyright (C) The Internet Society July 12, 2001. All Rights + Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + +Park & Madanapalli Expires October 2003 [Page 28] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + 13. References + + [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [2460] Deering, S. abd R. Hinden, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 2460, + December 1998. + + [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP version 6(IPv6)", RFC 2461, December + 1998. + + [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto- + Configuration", RFC 2462, December 1998. + + [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option", + RFC 2711, October 1999. + + [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND + FACILITIES", RFC 1034, November 1987. + + [1035] P. Mockapetris, "Domain Names - Implementation and + Specification" RFC 1035, November 1987. + + [2136] P. Vixie et al., "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC2136, April 1997. + + [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + +Park & Madanapalli Expires October 2003 [Page 29] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + [DIID] yokohama-dad-vs-diid.pdf + at http://playground.sun.com/ipng/presentations/July2002/ + + [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf- + dnsop-ipv6-dns-issues-00.txt, work in progress. + + [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix + delegation", draft-ietf-ipv6-prefix-delegation- + requirement-01.txt, work in progress. + + [Autoreg] H. Kitamura, "Domain Name Auto-Registration for + Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name- + auto-reg-00.txt, work in progress. + + [NIQ] Matt Crawford, "IPv6 Node Information Queries", , work in progress. + + + 14. Author's Addresses + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics, KOREA + Phone: +82-31-200-3728 + Email:soohong.park@samsung.com + + Syam Madanapalli + Network Systems Division, SAMSUNG India Software Operations, INDIA + Phone: +91-80-5550555 + Email:syam@samsung.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 30] diff --git a/contrib/bind9/doc/draft/update b/contrib/bind9/doc/draft/update new file mode 100644 index 000000000000..6ac20904ab20 --- /dev/null +++ b/contrib/bind9/doc/draft/update @@ -0,0 +1,46 @@ +#!/bin/sh +commit= +for i +do + z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'` + if test -n "$z" + then + i="$z" + fi + if test -f "$i" + then + continue + fi + pat=`echo "$i" | sed 's/...txt/??.txt/'` + old=`echo $pat 2> /dev/null` + if test "X$old" != "X$pat" + then + newer=0 + for j in $old + do + if test $j ">" $i + then + newer=1 + fi + done + if test $newer = 1 + then + continue; + fi + fi + if fetch "http://www.ietf.org/internet-drafts/$i" + then + cvs add "$i" + if test "X$old" != "X$pat" + then + rm $old + cvs delete $old + commit="$commit $old" + fi + commit="$commit $i" + fi +done +if test -n "$commit" +then + cvs commit -m "new draft" $commit +fi diff --git a/contrib/bind9/doc/misc/Makefile.in b/contrib/bind9/doc/misc/Makefile.in new file mode 100644 index 000000000000..81f13beee5ce --- /dev/null +++ b/contrib/bind9/doc/misc/Makefile.in @@ -0,0 +1,36 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.1.12.3 2004/03/08 09:04:25 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_MAKE_RULES@ + +PERL = @PERL@ + +MANOBJS = options + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f options + +options: ../../bin/tests/cfg_test + ../../bin/tests/cfg_test --named --grammar | \ + ${PERL} ${srcdir}/format-options.pl >options || \ + rm -f options diff --git a/contrib/bind9/doc/misc/dnssec b/contrib/bind9/doc/misc/dnssec new file mode 100644 index 000000000000..79d91cf971a9 --- /dev/null +++ b/contrib/bind9/doc/misc/dnssec @@ -0,0 +1,84 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000-2002 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +DNSSEC Release Notes + +This document summarizes the state of the DNSSEC implementation in +this release of BIND9. + + +OpenSSL Library Required + +To support DNSSEC, BIND 9 must be linked with version 0.9.6e or newer of +the OpenSSL library. As of BIND 9.2, the library is no longer +included in the distribution - it must be provided by the operating +system or installed separately. + +To build BIND 9 with OpenSSL, use "configure --with-openssl". If +the OpenSSL library is installed in a nonstandard location, you can +specify a path as in "configure --with-openssl=/var". + + +Key Generation and Signing + +The tools for generating DNSSEC keys and signatures are now in the +bin/dnssec directory. Documentation for these programs can be found +in doc/arm/Bv9ARM.4.html and the man pages. + +The random data used in generating DNSSEC keys and signatures comes +from either /dev/random (if the OS supports it) or keyboard input. +Alternatively, a device or file containing entropy/random data can be +specified. + + +Serving Secure Zones + +When acting as an authoritative name server, BIND9 includes KEY, SIG +and NXT records in responses as specified in RFC2535 when the request +has the DO flag set in the query. + + +Secure Resolution + +Basic support for validation of DNSSEC signatures in responses has +been implemented but should still be considered experimental. + +When acting as a caching name server, BIND9 is capable of performing +basic DNSSEC validation of positive as well as nonexistence responses. +This functionality is enabled by including a "trusted-keys" clause +in the configuration file, containing the top-level zone key of the +the DNSSEC tree. + +Validation of wildcard responses is not currently supported. In +particular, a "name does not exist" response will validate +successfully even if it does not contain the NXT records to prove the +nonexistence of a matching wildcard. + +Proof of insecure status for insecure zones delegated from secure +zones works when the zones are completely insecure. Privately +secured zones delegated from secure zones will not work in all cases, +such as when the privately secured zone is served by the same server +as an ancestor (but not parent) zone. + +Handling of the CD bit in queries is now fully implemented. Validation +is not attempted for recursive queries if CD is set. + + +Secure Dynamic Update + +Dynamic update of secure zones has been implemented, but may not be +complete. Affected NXT and SIG records are updated by the server when +an update occurs. Advanced access control is possible using the +"update-policy" statement in the zone definition. + + +Secure Zone Transfers + +BIND 9 does not implement the zone transfer security mechanisms of +RFC2535 section 5.6, and we have no plans to implement them in the +future as we consider them inferior to the use of TSIG or SIG(0) to +ensure the integrity of zone transfers. + + +$Id: dnssec,v 1.14.2.6.4.4 2004/03/08 09:04:25 marka Exp $ diff --git a/contrib/bind9/doc/misc/format-options.pl b/contrib/bind9/doc/misc/format-options.pl new file mode 100644 index 000000000000..5f0975ade820 --- /dev/null +++ b/contrib/bind9/doc/misc/format-options.pl @@ -0,0 +1,36 @@ +#!/usr/bin/perl +# +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: format-options.pl,v 1.1.206.1 2004/03/06 13:16:19 marka Exp $ + +print <) { + s/\t/ /g; + if (length >= 79) { + m!^( *)!; + my $indent = $1; + s!^(.{0,75}) (.*)$!\1\n$indent \2!; + } + print; +} diff --git a/contrib/bind9/doc/misc/ipv6 b/contrib/bind9/doc/misc/ipv6 new file mode 100644 index 000000000000..dd96cd27a337 --- /dev/null +++ b/contrib/bind9/doc/misc/ipv6 @@ -0,0 +1,113 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +Currently, there are multiple interesting problems with ipv6 +implementations on various platforms. These problems range from not +being able to use ipv6 with bind9 (or in particular the ISC socket +library, contained in libisc) to listen-on lists not being respected, +to strange warnings but seemingly correct behavior of named. + +COMPILE-TIME ISSUES +------------------- + +The socket library requires a certain level of support from the +operating system. In particular, it must follow the advanced ipv6 +socket API to be usable. The systems which do not follow this will +currently not get any warnings or errors, but ipv6 will simply not +function on them. + +These systems currently include, but are not limited to: + + AIX 3.4 (with ipv6 patches) + + +RUN-TIME ISSUES +--------------- + +In the original drafts of the ipv6 RFC documents, binding an ipv6 +socket to the ipv6 wildcard address would also cause the socket to +accept ipv4 connections and datagrams. When an ipv4 packet is +received on these systems, it is mapped into an ipv6 address. For +example, 1.2.3.4 would be mapped into ::ffff:1.2.3.4. The intent of +this mapping was to make transition from an ipv4-only application into +ipv6 easier, by only requiring one socket to be open on a given port. + +Later, it was discovered that this was generally a bad idea. For one, +many firewalls will block connection to 1.2.3.4, but will let through +::ffff:1.2.3.4. This, of course, is bad. Also, access control lists +written to accept only ipv4 addresses were suddenly ignored unless +they were rewritten to handle the ipv6 mapped addresses as well. + +Partly because of these problems, the latest IPv6 API introduces an +explicit knob (the "IPV6_V6ONLY" socket option ) to turn off the ipv6 +mapped address usage. + +In bind9, we first check if both the advanced API and the IPV6_V6ONLY +socket option are available. If both of them are available, bind9 +named will bind to the ipv6 wildcard port for both TCP and UDP. +Otherwise named will make a warning and try to bind to all available +ipv6 addresses separately. + +In any case, bind9 named binds to specific addresses for ipv4 sockets. + +The followings are historical notes when we always bound to the ipv6 +wildcard port regardless of the availability of the API support. +These problems should not happen with the closer checks above. + + +IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail +--------------------------------------------------------------- + +The only OS which seems to do this is (some kernel versions of) linux. +If an ipv6 socket is bound to the ipv6 wildcard socket, and a specific +ipv4 socket is later bound (say, to 1.2.3.4 port 53) the ipv4 binding +will fail. + +What this means to bind9 is that the application will log warnings +about being unable to bind to a socket because the address is already +in use. Since the ipv6 socket will accept ipv4 packets and map them, +however, the ipv4 addresses continue to function. + +The effect is that the config file listen-on directive will not be +respected on these systems. + + +IPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed +---------------------------------------------------------------- + +In this case, the system allows opening an ipv6 wildcard address +socket and then binding to a more specific ipv4 address later. An +example of this type of system is Digital Unix with ipv6 patches +applied. + +What this means to bind9 is that the application will respect +listen-on in regards to ipv4 sockets, but it will use mapped ipv6 +addresses for any that do not match the listen-on list. This, in +effect, makes listen-on useless for these machines as well. + + +IPV6 Sockets Do Not Accept IPV4 +------------------------------- + +On these systems, opening an IPV6 socket does not implicitly open any +ipv4 sockets. An example of these systems are NetBSD-current with the +latest KAME patch, and other systems which use the latest KAME patches +as their ipv6 implementation. + +On these systems, listen-on is fully functional, as the ipv6 socket +only accepts ipv6 packets, and the ipv4 sockets will handle the ipv4 +packets. + + +RELEVANT RFCs +------------- + +3513: Internet Protocol Version 6 (IPv6) Addressing Architecture + +3493: Basic Socket Interface Extensions for IPv6 + +3542: Advanced Sockets Application Program Interface (API) for IPv6 + + +$Id: ipv6,v 1.5.206.4 2004/08/10 04:28:15 jinmei Exp $ diff --git a/contrib/bind9/doc/misc/migration b/contrib/bind9/doc/misc/migration new file mode 100644 index 000000000000..97b645abe4ef --- /dev/null +++ b/contrib/bind9/doc/misc/migration @@ -0,0 +1,246 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001, 2003 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + + BIND 8 to BIND 9 Migration Notes + +BIND 9 is designed to be mostly upwards compatible with BIND 8, but +there is still a number of caveats you should be aware of when +upgrading an existing BIND 8 installation to use BIND 9. + + +1. Configuration File Compatibility + +1.1. Unimplemented Options and Changed Defaults + +BIND 9 supports most, but not all of the named.conf options of BIND 8. +For a complete list of implemented options, see doc/misc/options. + +If your named.conf file uses an unimplemented option, named will log a +warning message. A message is also logged about each option whose +default has changed unless the option is set explicitly in named.conf. + +The default of the "transfer-format" option has changed from +"one-answer" to "many-answers". If you have slave servers that do not +understand the many-answers zone transfer format (e.g., BIND 4.9.5 or +older) you need to explicitly specify "transfer-format one-answer;" in +either the options block or a server statement. + +1.2. Handling of Configuration File Errors + +In BIND 9, named refuses to start if it detects an error in +named.conf. Earlier versions would start despite errors, causing the +server to run with a partial configuration. Errors detected during +subsequent reloads do not cause the server to exit. + +Errors in master files do not cause the server to exit, but they +do cause the zone not to load. + +1.3. Logging + +The set of logging categories in BIND 9 is different from that +in BIND 8. If you have customised your logging on a per-category +basis, you need to modify your logging statement to use the +new categories. + +Another difference is that the "logging" statement only takes effect +after the entire named.conf file has been read. This means that when +the server starts up, any messages about errors in the configuration +file are always logged to the default destination (syslog) when the +server first starts up, regardless of the contents of the "logging" +statement. In BIND 8, the new logging configuration took effect +immediately after the "logging" statement was read. + +1.4. Notify messages and Refresh queries + +The source address and port for these is now controlled by +"notify-source" and "transfer-source", respectively, rather that +query-source as in BIND 8. + +1.5. Multiple Classes. + +Multiple classes have to be put into explicit views for each class. + + +2. Zone File Compatibility + +2.1. Strict RFC1035 Interpretation of TTLs in Zone Files + +BIND 9 strictly complies with the RFC1035 and RFC2308 rules regarding +omitted TTLs in zone files. Omitted TTLs are replaced by the value +specified with the $TTL directive, or by the previous explicit TTL if +there is no $TTL directive. + +If there is no $TTL directive and the first RR in the file does not +have an explicit TTL field, the zone file is illegal according to +RFC1035 since the TTL of the first RR is undefined. Unfortunately, +BIND 4 and many versions of BIND 8 accept such files without warning +and use the value of the SOA MINTTL field as a default for missing TTL +values. + +BIND 9.0 and 9.1 completely refused to load such files. BIND 9.2 +emulates the nonstandard BIND 4/8 SOA MINTTL behaviour and loads the +files anyway (provided the SOA is the first record in the file), but +will issue the warning message "no TTL specified; using SOA MINTTL +instead". + +To avoid problems, we recommend that you use a $TTL directive in each +zone file. + +2.2. Periods in SOA Serial Numbers Deprecated + +Some versions of BIND allow SOA serial numbers with an embedded +period, like "3.002", and convert them into integers in a rather +unintuitive way. This feature is not supported by BIND 9; serial +numbers must be integers. + +2.3. Handling of Unbalanced Quotes + +TXT records with unbalanced quotes, like 'host TXT "foo', were not +treated as errors in some versions of BIND. If your zone files +contain such records, you will get potentially confusing error +messages like "unexpected end of file" because BIND 9 will interpret +everything up to the next quote character as a literal string. + +2.4. Handling of Line Breaks + +Some versions of BIND accept RRs containing line breaks that are not +properly quoted with parentheses, like the following SOA: + + @ IN SOA ns.example. hostmaster.example. + ( 1 3600 1800 1814400 3600 ) + +This is not legal master file syntax and will be treated as an error +by BIND 9. The fix is to move the opening parenthesis to the first +line. + +2.5. Unimplemented BIND 8 Extensions + +$GENERATE: The "$$" construct for getting a literal $ into a domain +name is deprecated. Use \$ instead. + + +3. Interoperability Impact of New Protocol Features + +3.1. EDNS0 + +BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size. It +also sets an EDNS flag bit in queries to indicate that it wishes to +receive DNSSEC responses; this flag bit usage is not yet standardised, +but we hope it will be. + +Most older servers that do not support EDNS0, including prior versions +of BIND, will send a FORMERR or NOTIMP response to these queries. +When this happens, BIND 9 will automatically retry the query without +EDNS0. + +Unfortunately, there exists at least one non-BIND name server +implementation that silently ignores these queries instead of sending +an error response. Resolving names in zones where all or most +authoritative servers use this server will be very slow or fail +completely. We have contacted the manufacturer of the name server in +case, and they are working on a solution. + +When BIND 9 communicates with a server that does support EDNS0, such as +another BIND 9 server, responses of up to 4096 bytes may be +transmitted as a single UDP datagram which is subject to fragmentation +at the IP level. If a firewall incorrectly drops IP fragments, it can +cause resolution to slow down dramatically or fail. + +3.2. Zone Transfers + +Outgoing zone transfers now use the "many-answers" format by default. +This format is not understood by certain old versions of BIND 4. +You can work around this problem using the option "transfer-format +one-answer;", but since these old versions all have known security +problems, the correct fix is to upgrade the slave servers. + +Zone transfers to Windows 2000 DNS servers sometimes fail due to a +bug in the Windows 2000 DNS server where DNS messages larger than +16K are not handled properly. Obtain the latest service pack for +Windows 2000 from Microsoft to address this issue. In the meantime, +the problem can be worked around by setting "transfer-format one-answer;". +http://support.microsoft.com/default.aspx?scid=kb;en-us;297936 + +4. Unrestricted Character Set + +BIND 9 does not restrict the character set of domain names - it is +fully 8-bit clean in accordance with RFC2181 section 11. + +It is strongly recommended that hostnames published in the DNS follow +the RFC952 rules, but BIND 9 will not enforce this restriction. + +Historically, some applications have suffered from security flaws +where data originating from the network, such as names returned by +gethostbyaddr(), are used with insufficient checking and may cause a +breach of security when containing unexpected characters; see + +for details. Some earlier versions of BIND attempt to protect these +flawed applications from attack by discarding data containing +characters deemed inappropriate in host names or mail addresses, under +the control of the "check-names" option in named.conf and/or "options +no-check-names" in resolv.conf. BIND 9 provides no such protection; +if applications with these flaws are still being used, they should +be upgraded. + + +5. Server Administration Tools + +5.1 Ndc Replaced by Rndc + +The "ndc" program has been replaced by "rndc", which is capable of +remote operation. Unlike ndc, rndc requires a configuration file. +The easiest way to generate a configuration file is to run +"rndc-confgen -a"; see the man pages for rndc(8), rndc-confgen(8), +and rndc.conf(5) for details. + +5.2. Nsupdate Differences + +The BIND 8 implementation of nsupdate had an undocumented feature +where an update request would be broken down into multiple requests +based upon the discovered zones that contained the records. This +behaviour has not been implemented in BIND 9. Each update request +must pertain to a single zone, but it is still possible to do multiple +updates in a single invocation of nsupdate by terminating each update +with an empty line or a "send" command. + + +6. No Information Leakage between Zones + +BIND 9 stores the authoritative data for each zone in a separate data +structure, as recommended in RFC1035 and as required by DNSSEC and +IXFR. When a BIND 9 server is authoritative for both a child zone and +its parent, it will have two distinct sets of NS records at the +delegation point: the authoritative NS records at the child's apex, +and a set of glue NS records in the parent. + +BIND 8 was unable to properly distinguish between these two sets of NS +records and would "leak" the child's NS records into the parent, +effectively causing the parent zone to be silently modified: responses +and zone transfers from the parent contained the child's NS records +rather than the glue configured into the parent (if any). In the case +of children of type "stub", this behaviour was documented as a feature, +allowing the glue NS records to be omitted from the parent +configuration. + +Sites that were relying on this BIND 8 behaviour need to add any +omitted glue NS records, and any necessary glue A records, to the +parent zone. + +Although stub zones can no longer be used as a mechanism for injecting +NS records into their parent zones, they are still useful as a way of +directing queries for a given domain to a particular set of name +servers. + + +7. Umask not Modified + +The BIND 8 named unconditionally sets the umask to 022. BIND 9 does +not; the umask inherited from the parent process remains in effect. +This may cause files created by named, such as journal files, to be +created with different file permissions than they did in BIND 8. If +necessary, the umask should be set explicitly in the script used to +start the named process. + + +$Id: migration,v 1.37.2.3.2.2 2004/03/06 13:16:19 marka Exp $ diff --git a/contrib/bind9/doc/misc/migration-4to9 b/contrib/bind9/doc/misc/migration-4to9 new file mode 100644 index 000000000000..fa75bacb7013 --- /dev/null +++ b/contrib/bind9/doc/misc/migration-4to9 @@ -0,0 +1,57 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +$Id: migration-4to9,v 1.3.206.1 2004/03/06 13:16:19 marka Exp $ + + BIND 4 to BIND 9 Migration Notes + +To transition from BIND 4 to BIND 9 you first need to convert your +configuration file to the new format. There is a conversion tool in +contrib/named-bootconf that allows you to do this. + + named-bootconf.sh < /etc/named.boot > /etc/named.conf + +BIND 9 uses a system assigned port for the UDP queries it makes rather +than port 53 that BIND 4 uses. This may conflict with some firewalls. +The following directives in /etc/named.conf allows you to specify +a port to use. + + query-source address * port 53; + transfer-source * port 53; + notify-source * port 53; + +BIND 9 no longer uses the minimum field to specify the TTL of records +without a explicit TTL. Use the $TTL directive to specify a default TTL +before the first record without a explicit TTL. + + $TTL 3600 + @ IN SOA ns1.example.com. hostmaster.example.com. ( + 2001021100 + 7200 + 1200 + 3600000 + 7200 ) + +BIND 9 does not support multiple CNAMEs with the same owner name. + + Illegal: + www.example.com. CNAME host1.example.com. + www.example.com. CNAME host2.example.com. + +BIND 9 does not support "CNAMEs with other data" with the same owner name, +ignoring the DNSSEC records (SIG, NXT, KEY) that BIND 4 did not support. + + Illegal: + www.example.com. CNAME host1.example.com. + www.example.com. MX 10 host2.example.com. + +BIND 9 is less tolerant of errors in master files, so check your logs and +fix any errors reported. The named-checkzone program can also be to check +master files. + +Outgoing zone transfers now use the "many-answers" format by default. +This format is not understood by certain old versions of BIND 4. +You can work around this problem using the option "transfer-format +one-answer;", but since these old versions all have known security +problems, the correct fix is to upgrade the slave servers. diff --git a/contrib/bind9/doc/misc/options b/contrib/bind9/doc/misc/options new file mode 100644 index 000000000000..f77e4940c58d --- /dev/null +++ b/contrib/bind9/doc/misc/options @@ -0,0 +1,384 @@ + +This is a summary of the named.conf options supported by +this version of BIND 9. + +options { + avoid-v4-udp-ports { ; ... }; + avoid-v6-udp-ports { ; ... }; + blackhole { ; ... }; + coresize ; + datasize ; + deallocate-on-exit ; // obsolete + directory ; + dump-file ; + fake-iquery ; // obsolete + files ; + has-old-clients ; // obsolete + heartbeat-interval ; + host-statistics ; // not implemented + hostname ( | none ); + interface-interval ; + listen-on [ port ] { ; ... }; + listen-on-v6 [ port ] { ; ... }; + match-mapped-addresses ; + memstatistics-file ; + multiple-cnames ; // obsolete + named-xfer ; // obsolete + pid-file ( | none ); + port ; + querylog ; + recursing-file ; + random-device ; + recursive-clients ; + serial-queries ; // obsolete + serial-query-rate ; + server-id ( | none |; + stacksize ; + statistics-file ; + statistics-interval ; // not yet implemented + tcp-clients ; + tcp-listen-queue ; + tkey-dhkey ; + tkey-gssapi-credential ; + tkey-domain ; + transfers-per-ns ; + transfers-in ; + transfers-out ; + treat-cr-as-space ; // obsolete + use-id-pool ; // obsolete + use-ixfr ; + version ( | none ); + allow-recursion { ; ... }; + allow-v6-synthesis { ; ... }; // obsolete + sortlist { ; ... }; + topology { ; ... }; // not implemented + auth-nxdomain ; // default changed + minimal-responses ; + recursion ; + rrset-order { [ class ] [ type ] [ name + ] ; ... }; + provide-ixfr ; + request-ixfr ; + fetch-glue ; // obsolete + rfc2308-type1 ; // not yet implemented + additional-from-auth ; + additional-from-cache ; + query-source ; + query-source-v6 ; + cleaning-interval ; + min-roots ; // not implemented + lame-ttl ; + max-ncache-ttl ; + max-cache-ttl ; + transfer-format ( many-answers | one-answer ); + max-cache-size ; + check-names ( master | slave | response ) ( fail | warn | ignore ); + cache-file ; + suppress-initial-notify ; // not yet implemented + preferred-glue ; + dual-stack-servers [ port ] { ( [port + ] | [port ] | [port ] ); ... }; + edns-udp-size ; + root-delegation-only [ exclude { ; ... } ]; + disable-algorithms { ; ... }; + dnssec-enable ; + dnssec-lookaside trust-anchor ; + dnssec-must-be-secure ; + allow-query { ; ... }; + allow-transfer { ; ... }; + allow-update-forwarding { ; ... }; + allow-notify { ; ... }; + notify ; + notify-source ( | * ) [ port ( | * ) ]; + notify-source-v6 ( | * ) [ port ( | * ) ]; + also-notify [ port ] { ( | + ) [ port ]; ... }; + dialup ; + forward ( first | only ); + forwarders [ port ] { ( | ) + [ port ]; ... }; + ixfr-from-differences ; + maintain-ixfr-base ; // obsolete + max-ixfr-log-size ; // obsolete + max-journal-size ; + max-transfer-time-in ; + max-transfer-time-out ; + max-transfer-idle-in ; + max-transfer-idle-out ; + max-retry-time ; + min-retry-time ; + max-refresh-time ; + min-refresh-time ; + multi-master ; + sig-validity-interval ; + transfer-source ( | * ) [ port ( | * ) ]; + transfer-source-v6 ( | * ) [ port ( | * ) ]; + alt-transfer-source ( | * ) [ port ( | * ) + ]; + alt-transfer-source-v6 ( | * ) [ port ( | + * ) ]; + use-alt-transfer-source ; + zone-statistics ; + key-directory ; +}; + +controls { + inet ( | | * ) [ port ( | * + ) ] allow { ; ... } [ keys { ; ... } ]; + unix ; // not implemented +}; + +acl { ; ... }; + +masters [ port ] { ( | [port + ] | [port ] ) [ key ]; ... }; + +logging { + channel { + file ; + syslog ; + null; + stderr; + severity ; + print-time ; + print-severity ; + print-category ; + }; + category { ; ... }; +}; + +view { + match-clients { ; ... }; + match-destinations { ; ... }; + match-recursive-only ; + key { + algorithm ; + secret ; + }; + zone { + type ( master | slave | stub | hint | forward | + delegation-only ); + allow-update { ; ... }; + file ; + ixfr-base ; // obsolete + ixfr-tmp-file ; // obsolete + masters [ port ] { ( | + [port ] | [port ] ) [ key ]; ... }; + pubkey ; // + obsolete + update-policy { ( grant | deny ) ( name | + subdomain | wildcard | self ) ; ... }; + database ; + delegation-only ; + check-names ( fail | warn | ignore ); + allow-query { ; ... }; + allow-transfer { ; ... }; + allow-update-forwarding { ; ... }; + allow-notify { ; ... }; + notify ; + notify-source ( | * ) [ port ( | * + ) ]; + notify-source-v6 ( | * ) [ port ( + | * ) ]; + also-notify [ port ] { ( | + ) [ port ]; ... }; + dialup ; + forward ( first | only ); + forwarders [ port ] { ( | + ) [ port ]; ... }; + ixfr-from-differences ; + maintain-ixfr-base ; // obsolete + max-ixfr-log-size ; // obsolete + max-journal-size ; + max-transfer-time-in ; + max-transfer-time-out ; + max-transfer-idle-in ; + max-transfer-idle-out ; + max-retry-time ; + min-retry-time ; + max-refresh-time ; + min-refresh-time ; + multi-master ; + sig-validity-interval ; + transfer-source ( | * ) [ port ( | + * ) ]; + transfer-source-v6 ( | * ) [ port ( + | * ) ]; + alt-transfer-source ( | * ) [ port ( + | * ) ]; + alt-transfer-source-v6 ( | * ) [ port ( + | * ) ]; + use-alt-transfer-source ; + zone-statistics ; + key-directory ; + }; + server { + bogus ; + provide-ixfr ; + request-ixfr ; + support-ixfr ; // obsolete + transfers ; + transfer-format ( many-answers | one-answer ); + keys ; + edns ; + transfer-source ( | * ) [ port ( | + * ) ]; + transfer-source-v6 ( | * ) [ port ( + | * ) ]; + }; + trusted-keys { + ; ... }; + allow-recursion { ; ... }; + allow-v6-synthesis { ; ... }; // obsolete + sortlist { ; ... }; + topology { ; ... }; // not implemented + auth-nxdomain ; // default changed + minimal-responses ; + recursion ; + rrset-order { [ class ] [ type ] [ name + ] ; ... }; + provide-ixfr ; + request-ixfr ; + fetch-glue ; // obsolete + rfc2308-type1 ; // not yet implemented + additional-from-auth ; + additional-from-cache ; + query-source ; + query-source-v6 ; + cleaning-interval ; + min-roots ; // not implemented + lame-ttl ; + max-ncache-ttl ; + max-cache-ttl ; + transfer-format ( many-answers | one-answer ); + max-cache-size ; + check-names ( master | slave | response ) ( fail | warn | ignore ); + cache-file ; + suppress-initial-notify ; // not yet implemented + preferred-glue ; + dual-stack-servers [ port ] { ( [port + ] | [port ] | [port ] ); ... }; + edns-udp-size ; + root-delegation-only [ exclude { ; ... } ]; + disable-algorithms { ; ... }; + dnssec-enable ; + dnssec-lookaside trust-anchor ; + dnssec-must-be-secure ; + allow-query { ; ... }; + allow-transfer { ; ... }; + allow-update-forwarding { ; ... }; + allow-notify { ; ... }; + notify ; + notify-source ( | * ) [ port ( | * ) ]; + notify-source-v6 ( | * ) [ port ( | * ) ]; + also-notify [ port ] { ( | + ) [ port ]; ... }; + dialup ; + forward ( first | only ); + forwarders [ port ] { ( | ) + [ port ]; ... }; + ixfr-from-differences ; + maintain-ixfr-base ; // obsolete + max-ixfr-log-size ; // obsolete + max-journal-size ; + max-transfer-time-in ; + max-transfer-time-out ; + max-transfer-idle-in ; + max-transfer-idle-out ; + max-retry-time ; + min-retry-time ; + max-refresh-time ; + min-refresh-time ; + multi-master ; + sig-validity-interval ; + transfer-source ( | * ) [ port ( | * ) ]; + transfer-source-v6 ( | * ) [ port ( | * ) ]; + alt-transfer-source ( | * ) [ port ( | * ) + ]; + alt-transfer-source-v6 ( | * ) [ port ( | + * ) ]; + use-alt-transfer-source ; + zone-statistics ; + key-directory ; +}; + +lwres { + listen-on [ port ] { ( | ) + [ port ]; ... }; + view ; + search { ; ... }; + ndots ; +}; + +key { + algorithm ; + secret ; +}; + +zone { + type ( master | slave | stub | hint | forward | delegation-only ); + allow-update { ; ... }; + file ; + ixfr-base ; // obsolete + ixfr-tmp-file ; // obsolete + masters [ port ] { ( | [port + ] | [port ] ) [ key ]; ... }; + pubkey ; // obsolete + update-policy { ( grant | deny ) ( name | subdomain | + wildcard | self ) ; ... }; + database ; + delegation-only ; + check-names ( fail | warn | ignore ); + allow-query { ; ... }; + allow-transfer { ; ... }; + allow-update-forwarding { ; ... }; + allow-notify { ; ... }; + notify ; + notify-source ( | * ) [ port ( | * ) ]; + notify-source-v6 ( | * ) [ port ( | * ) ]; + also-notify [ port ] { ( | + ) [ port ]; ... }; + dialup ; + forward ( first | only ); + forwarders [ port ] { ( | ) + [ port ]; ... }; + ixfr-from-differences ; + maintain-ixfr-base ; // obsolete + max-ixfr-log-size ; // obsolete + max-journal-size ; + max-transfer-time-in ; + max-transfer-time-out ; + max-transfer-idle-in ; + max-transfer-idle-out ; + max-retry-time ; + min-retry-time ; + max-refresh-time ; + min-refresh-time ; + multi-master ; + sig-validity-interval ; + transfer-source ( | * ) [ port ( | * ) ]; + transfer-source-v6 ( | * ) [ port ( | * ) ]; + alt-transfer-source ( | * ) [ port ( | * ) + ]; + alt-transfer-source-v6 ( | * ) [ port ( | + * ) ]; + use-alt-transfer-source ; + zone-statistics ; + key-directory ; +}; + +server { + bogus ; + provide-ixfr ; + request-ixfr ; + support-ixfr ; // obsolete + transfers ; + transfer-format ( many-answers | one-answer ); + keys ; + edns ; + transfer-source ( | * ) [ port ( | * ) ]; + transfer-source-v6 ( | * ) [ port ( | * ) ]; +}; + +trusted-keys { ; ... }; + diff --git a/contrib/bind9/doc/misc/rfc-compliance b/contrib/bind9/doc/misc/rfc-compliance new file mode 100644 index 000000000000..6a3fac12f96e --- /dev/null +++ b/contrib/bind9/doc/misc/rfc-compliance @@ -0,0 +1,62 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +$Id: rfc-compliance,v 1.3.206.1 2004/03/06 13:16:20 marka Exp $ + +BIND 9 is striving for strict compliance with IETF standards. We +believe this release of BIND 9 complies with the following RFCs, with +the caveats and exceptions listed in the numbered notes below. Note +that a number of these RFCs do not have the status of Internet +standards but are proposed or draft standards, experimental RFCs, +or Best Current Practice (BCP) documents. + + RFC1034 + RFC1035 [1] [2] + RFC1123 + RFC1183 + RFC1535 + RFC1536 + RFC1706 + RFC1712 + RFC1750 + RFC1876 + RFC1982 + RFC1995 + RFC1996 + RFC2136 + RFC2163 + RFC2181 + RFC2230 + RFC2308 + RFC2535 [3] [4] + RFC2536 + RFC2537 + RFC2538 + RFC2539 + RFC2671 + RFC2672 + RFC2673 + RFC2782 + RFC2915 + RFC2930 + RFC2931 [5] + RFC3007 + + +[1] Queries to zones that have failed to load return SERVFAIL rather +than a non-authoritative response. This is considered a feature. + +[2] CLASS ANY queries are not supported. This is considered a feature. + +[3] Wildcard records are not supported in DNSSEC secure zones. + +[4] Servers authoritative for secure zones being resolved by BIND 9 +must support EDNS0 (RFC2671), and must return all relevant SIGs and +NXTs in responses rather than relying on the resolving server to +perform separate queries for missing SIGs and NXTs. + +[5] When receiving a query signed with a SIG(0), the server will only +be able to verify the signature if it has the key in its local +authoritative data; it will not do recursion or validation to +retrieve unknown keys. diff --git a/contrib/bind9/doc/misc/roadmap b/contrib/bind9/doc/misc/roadmap new file mode 100644 index 000000000000..72021b82f662 --- /dev/null +++ b/contrib/bind9/doc/misc/roadmap @@ -0,0 +1,47 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +$Id: roadmap,v 1.1.206.1 2004/03/06 13:16:20 marka Exp $ + +Road Map to the BIND 9 Source Tree + +bin/named The name server. This relies heavily on the + libraries in lib/isc and lib/dns. + client.c Handling of incoming client requests + query.c Query processing +bin/rndc The remote name daemon control program +bin/dig The "dig" program +bin/dnssec The DNSSEC signer and other DNSSEC tools +bin/nsupdate The "nsupdate" program +bin/tests Test suites and miscellaneous test programs +bin/tests/system System tests; see bin/tests/system/README +lib/dns The DNS library + resolver.c The "full resolver" (performs recursive lookups) + validator.c The DNSSEC validator + db.c The database interface + sdb.c The simple database interface + rbtdb.c The red-black tree database +lib/dns/rdata Routines for handling the various RR types +lib/dns/sec Cryptographic libraries for DNSSEC +lib/isc The ISC library + task.c Task library + unix/socket.c Unix implementation of socket library +lib/isccfg Routines for reading and writing ISC-style + configuration files like named.conf and rndc.conf +lib/isccc The command channel library, used by rndc. +lib/tests Support code for the test suites. +lib/lwres The lightweight resolver library. +doc/draft Current internet-drafts pertaining to the DNS +doc/rfc RFCs pertaining to the DNS +doc/misc Miscellaneous documentation +doc/arm The BIND 9 Administrator Reference Manual +doc/man Man pages +contrib Contributed and other auxiliary code +contrib/idn/mdnkit The multilingual domain name evaluation kit +contrib/sdb Sample drivers for the simple database interface +make Makefile fragments, used by configure + +The library interfaces are mainly documented in the form of comments +in the header files. For example, the task subsystem is documented in +lib/isc/include/isc/task.h diff --git a/contrib/bind9/doc/misc/sdb b/contrib/bind9/doc/misc/sdb new file mode 100644 index 000000000000..0de0ab8943c6 --- /dev/null +++ b/contrib/bind9/doc/misc/sdb @@ -0,0 +1,169 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +Using the BIND 9 Simplified Database Interface + +This document describes the care and feeding of the BIND 9 Simplified +Database Interface, which allows you to extend BIND 9 with new ways +of obtaining the data that is published as DNS zones. + + +The Original BIND 9 Database Interface + +BIND 9 has a well-defined "back-end database interface" that makes it +possible to replace the component of the name server responsible for +the storage and retrieval of zone data, called the "database", on a +per-zone basis. The default database is an in-memory, red-black-tree +data structure commonly referred to as "rbtdb", but it is possible to +write drivers to support any number of alternative database +technologies such as in-memory hash tables, application specific +persistent on-disk databases, object databases, or relational +databases. + +The original BIND 9 database interface defined in is +designed to efficiently support the full set of database functionality +needed by a name server that implements the complete DNS protocols, +including features such as zone transfers, dynamic update, and DNSSEC. +Each of these aspects of name server operations places its own set of +demands on the data store, with the result that the database API is +quite complex and contains operations that are highly specific to the +DNS. For example, data are stored in a binary format, the name space +is tree structured, and sets of data records are conceptually +associated with DNSSEC signature sets. For these reasons, writing a +driver using this interface is a highly nontrivial undertaking. + + +The Simplified Database Interface + +Many BIND users wish to provide access to various data sources through +the DNS, but are not necessarily interested in completely replacing +the in-memory "rbt" database or in supporting features like dynamic +update, DNSSEC, or even zone transfers. + +Often, all you want is limited, read-only DNS access to an existing +system. For example, you may have an existing relational database +containing hostname/address mappings and wish to provide forvard and +reverse DNS lookups based on this information. Or perhaps you want to +set up a simple DNS-based load balancing system where the name server +answers queries about a single DNS name with a dynamically changing +set of A records. + +BIND 9.1 introduced a new, simplified database interface, or "sdb", +which greatly simplifies the writing of drivers for these kinds of +applications. + + +The sdb Driver + +An sdb driver is an object module, typically written in C, which is +linked into the name server and registers itself with the sdb +subsystem. It provides a set of callback functions, which also serve +to advertise its capabilities. When the name server receives DNS +queries, invokes the callback functions to obtain the data to respond +with. + +Unlike the full database interface, the sdb interface represents all +domain names and resource records as ASCII text. + + +Writing an sdb Driver + +When a driver is registered, it specifies its name, a list of callback +functions, and flags. + +The flags specify whether the driver wants to use relative domain +names where possible. + +The callback functions are as follows. The only one that must be +defined is lookup(). + + - create(zone, argc, argv, driverdata, dbdata) + Create a database object for "zone". + + - destroy(zone, driverdata, dbdata) + Destroy the database object for "zone". + + - lookup(zone, name, dbdata, lookup) + Return all the records at the domain name "name". + + - authority(zone, dbdata, lookup) + Return the SOA and NS records at the zone apex. + + - allnodes(zone, dbdata, allnodes) + Return all data in the zone, for zone transfers. + +For more detail about these functions and their parameters, see +bind9/lib/dns/include/dns/sdb.h. For example drivers, see +bind9/contrib/sdb. + + +Rebuilding the Server + +The driver module and header file must be copied to (or linked into) +the bind9/bin/named and bind9/bin/named/include directories +respectively, and must be added to the DBDRIVER_OBJS and DBDRIVER_SRCS +lines in bin/named/Makefile.in (e.g. for the timedb sample sdb driver, +add timedb.c to DBDRIVER_SRCS and timedb.@O@ to DBDRIVER_OBJS). If +the driver needs additional header files or libraries in nonstandard +places, the DBDRIVER_INCLUDES and DBDRIVER_LIBS lines should also be +updated. + +Calls to dns_sdb_register() and dns_sdb_unregister() (or wrappers, +e.g. timedb_init() and timedb_clear() for the timedb sample sdb +driver) must be inserted into the server, in bind9/bin/named/main.c. +Registration should be in setup(), before the call to +ns_server_create(). Unregistration should be in cleanup(), +after the call to ns_server_destroy(). A #include should be added +corresponding to the driver header file. + +You should try doing this with one or more of the sample drivers +before attempting to write a driver of your own. + + +Configuring the Server + +To make a zone use a new database driver, specify a "database" option +in its "zone" statement in named.conf. For example, if the driver +registers itself under the name "acmedb", you might say + + zone "foo.com" { + database "acmedb"; + }; + +You can pass arbitrary arguments to the create() function of the +driver by adding any number of whitespace-separated words after the +driver name: + + zone "foo.com" { + database "acmedb -mode sql -connect 10.0.0.1"; + }; + + +Hints for Driver Writers + + - If a driver is generating data on the fly, it probably should + not implement the allnodes() function, since a zone transfer + will not be meaningful. The allnodes() function is more relevant + with data from a database. + + - The authority() function is necessary if and only if the lookup() + function will not add SOA and NS records at the zone apex. If + SOA and NS records are provided by the lookup() function, + the authority() function should be NULL. + + - When a driver is registered, an opaque object can be provided. This + object is passed into the database create() and destroy() functions. + + - When a database is created, an opaque object can be created that + is associated with that database. This object is passed into the + lookup(), authority(), and allnodes() functions, and is + destroyed by the destroy() function. + + +Future Directions + +A future release may support dynamic loading of sdb drivers. + + +$Id: sdb,v 1.5.206.1 2004/03/06 13:16:20 marka Exp $ diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index new file mode 100644 index 000000000000..fb72ccc314de --- /dev/null +++ b/contrib/bind9/doc/rfc/index @@ -0,0 +1,94 @@ + 952: DOD INTERNET HOST TABLE SPECIFICATION +1032: DOMAIN ADMINISTRATORS GUIDE +1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE +1034: DOMAIN NAMES - CONCEPTS AND FACILITIES +1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION +1101: DNS Encoding of Network Names and Other Types +1122: Requirements for Internet Hosts -- Communication Layers +1123: Requirements for Internet Hosts -- Application and Support +1183: New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT) +1348: DNS NSAP RRs +1535: A Security Problem and Proposed Correction + With Widely Deployed DNS Software +1536: Common DNS Implementation Errors and Suggested Fixes +1537: Common DNS Data File Configuration Errors +1591: Domain Name System Structure and Delegation +1611: DNS Server MIB Extensions +1612: DNS Resolver MIB Extensions +1706: DNS NSAP Resource Records +1712: DNS Encoding of Geographical Location +1750: Randomness Recommendations for Security +1876: A Means for Expressing Location Information in the Domain Name System +1886: DNS Extensions to support IP version 6 +1982: Serial Number Arithmetic +1995: Incremental Zone Transfer in DNS +1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) +2052: A DNS RR for specifying the location of services (DNS SRV) +2104: HMAC: Keyed-Hashing for Message Authentication +2119: Key words for use in RFCs to Indicate Requirement Levels +2133: Basic Socket Interface Extensions for IPv6 +2136: Dynamic Updates in the Domain Name System (DNS UPDATE) +2137: Secure Domain Name System Dynamic Update +2163: Using the Internet DNS to Distribute MIXER + Conformant Global Address Mapping (MCGAM) +2168: Resolution of Uniform Resource Identifiers using the Domain Name System +2181: Clarifications to the DNS Specification +2230: Key Exchange Delegation Record for the DNS +2308: Negative Caching of DNS Queries (DNS NCACHE) +2317: Classless IN-ADDR.ARPA delegation +2373: IP Version 6 Addressing Architecture +2374: An IPv6 Aggregatable Global Unicast Address Format +2375: IPv6 Multicast Address Assignments +2418: IETF Working Group Guidelines and Procedures +2535: Domain Name System Security Extensions +2536: DSA KEYs and SIGs in the Domain Name System (DNS) +2537: RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) +2538: Storing Certificates in the Domain Name System (DNS) +2539: Storage of Diffie-Hellman Keys in the Domain Name System (DNS) +2540: Detached Domain Name System (DNS) Information +2541: DNS Security Operational Considerations +2553: Basic Socket Interface Extensions for IPv6 +2671: Extension Mechanisms for DNS (EDNS0) +2672: Non-Terminal DNS Name Redirection +2673: Binary Labels in the Domain Name System +2782: A DNS RR for specifying the location of services (DNS SRV) +2825: A Tangled Web: Issues of I18N, Domain Names, and the + Other Internet protocols +2826: IAB Technical Comment on the Unique DNS Root +2845: Secret Key Transaction Authentication for DNS (TSIG) +2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering +2915: The Naming Authority Pointer (NAPTR) DNS Resource Record +2929: Domain Name System (DNS) IANA Considerations +2930: Secret Key Establishment for DNS (TKEY RR) +2931: DNS Request and Transaction Signatures ( SIG(0)s ) +3007: Secure Domain Name System (DNS) Dynamic Update +3008: Domain Name System Security (DNSSEC) Signing Authority +3071: Reflections on the DNS, RFC 1591, and Categories of Domains +3090: DNS Security Extension Clarification on Zone Status +3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) +3123: A DNS RR Type for Lists of Address Prefixes (APL RR) +3152: Delegation of IP6.ARPA +3197: Applicability Statement for DNS MIB Extensions +3225: Indicating Resolver Support of DNSSEC +3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements +3258: Distributing Authoritative Name Servers via Shared Unicast Addresses +3363: Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS) +3364: Tradeoffs in Domain Name System (DNS) Support + for Internet Protocol version 6 (IPv6) +3390: Internationalizing Domain Names In Applications (IDNA) +3425: Obsoleting IQUERY +3445: Limiting the Scope of the KEY Resource Record (RR) +3491: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) +3492: Punycode:A Bootstring encoding of Unicode for + Internationalized Domain Names in Applications (IDNA) +3493: Basic Socket Interface Extensions for IPv6 +3513: Internet Protocol Version 6 (IPv6) Addressing Architecture +3596: DNS Extensions to Support IP Version 6 +3597: Handling of Unknown DNS Resource Record (RR) Types +3645: Generic Security Service Algorithm for + Secret Key Transaction Authentication for DNS (GSS-TSIG) +3655: Redefinition of DNS Authenticated Data (AD) bit +3658: Delegation Signer (DS) Resource Record (RR) +3833: Threat Analysis of the Domain Name System (DNS) +3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format diff --git a/contrib/bind9/doc/rfc/rfc1032.txt b/contrib/bind9/doc/rfc/rfc1032.txt new file mode 100644 index 000000000000..0e82721cee71 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc1032.txt @@ -0,0 +1,781 @@ +Network Working Group M. Stahl +Request for Comments: 1032 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS GUIDE + + +STATUS OF THIS MEMO + + This memo describes procedures for registering a domain with the + Network Information Center (NIC) of Defense Data Network (DDN), and + offers guidelines on the establishment and administration of a domain + in accordance with the requirements specified in RFC-920. It is + intended for use by domain administrators. This memo should be used + in conjunction with RFC-920, which is an official policy statement of + the Internet Activities Board (IAB) and the Defense Advanced Research + Projects Agency (DARPA). Distribution of this memo is unlimited. + +BACKGROUND + + Domains are administrative entities that provide decentralized + management of host naming and addressing. The domain-naming system + is distributed and hierarchical. + + The NIC is designated by the Defense Communications Agency (DCA) to + provide registry services for the domain-naming system on the DDN and + DARPA portions of the Internet. + + As registrar of top-level and second-level domains, as well as + administrator of the root domain name servers on behalf of DARPA and + DDN, the NIC is responsible for maintaining the root server zone + files and their binary equivalents. In addition, the NIC is + responsible for administering the top-level domains of "ARPA," "COM," + "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it + becomes feasible for other appropriate organizations to assume those + responsibilities. + + It is recommended that the guidelines described in this document be + used by domain administrators in the establishment and control of + second-level domains. + +THE DOMAIN ADMINISTRATOR + + The role of the domain administrator (DA) is that of coordinator, + manager, and technician. If his domain is established at the second + level or lower in the tree, the DA must register by interacting with + the management of the domain directly above his, making certain that + + + +Stahl [Page 1] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + his domain satisfies all the requirements of the administration under + which his domain would be situated. To find out who has authority + over the name space he wishes to join, the DA can ask the NIC + Hostmaster. Information on contacts for the top-level and second- + level domains can also be found on line in the file NETINFO:DOMAIN- + CONTACTS.TXT, which is available from the NIC via anonymous FTP. + + The DA should be technically competent; he should understand the + concepts and procedures for operating a domain server, as described + in RFC-1034, and make sure that the service provided is reliable and + uninterrupted. It is his responsibility or that of his delegate to + ensure that the data will be current at all times. As a manager, the + DA must be able to handle complaints about service provided by his + domain name server. He must be aware of the behavior of the hosts in + his domain, and take prompt action on reports of problems, such as + protocol violations or other serious misbehavior. The administrator + of a domain must be a responsible person who has the authority to + either enforce these actions himself or delegate them to someone + else. + + Name assignments within a domain are controlled by the DA, who should + verify that names are unique within his domain and that they conform + to standard naming conventions. He furnishes access to names and + name-related information to users both inside and outside his domain. + He should work closely with the personnel he has designated as the + "technical and zone" contacts for his domain, for many administrative + decisions will be made on the basis of input from these people. + +THE DOMAIN TECHNICAL AND ZONE CONTACT + + A zone consists of those contiguous parts of the domain tree for + which a domain server has complete information and over which it has + authority. A domain server may be authoritative for more than one + zone. The domain technical/zone contact is the person who tends to + the technical aspects of maintaining the domain's name server and + resolver software, and database files. He keeps the name server + running, and interacts with technical people in other domains and + zones to solve problems that affect his zone. + +POLICIES + + Domain or host name choices and the allocation of domain name space + are considered to be local matters. In the event of conflicts, it is + the policy of the NIC not to get involved in local disputes or in the + local decision-making process. The NIC will not act as referee in + disputes over such matters as who has the "right" to register a + particular top-level or second-level domain for an organization. The + NIC considers this a private local matter that must be settled among + + + +Stahl [Page 2] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + the parties involved prior to their commencing the registration + process with the NIC. Therefore, it is assumed that the responsible + person for a domain will have resolved any local conflicts among the + members of his domain before registering that domain with the NIC. + The NIC will give guidance, if requested, by answering specific + technical questions, but will not provide arbitration in disputes at + the local level. This policy is also in keeping with the distributed + hierarchical nature of the domain-naming system in that it helps to + distribute the tasks of solving problems and handling questions. + + Naming conventions for hosts should follow the rules specified in + RFC-952. From a technical standpoint, domain names can be very long. + Each segment of a domain name may contain up to 64 characters, but + the NIC strongly advises DAs to choose names that are 12 characters + or fewer, because behind every domain system there is a human being + who must keep track of the names, addresses, contacts, and other data + in a database. The longer the name, the more likely the data + maintainer is to make a mistake. Users also will appreciate shorter + names. Most people agree that short names are easier to remember and + type; most domain names registered so far are 12 characters or fewer. + + Domain name assignments are made on a first-come-first-served basis. + The NIC has chosen not to register individual hosts directly under + the top-level domains it administers. One advantage of the domain + naming system is that administration and data maintenance can be + delegated down a hierarchical tree. Registration of hosts at the + same level in the tree as a second-level domain would dilute the + usefulness of this feature. In addition, the administrator of a + domain is responsible for the actions of hosts within his domain. We + would not want to find ourselves in the awkward position of policing + the actions of individual hosts. Rather, the subdomains registered + under these top-level domains retain the responsibility for this + function. + + Countries that wish to be registered as top-level domains are + required to name themselves after the two-letter country code listed + in the international standard ISO-3166. In some cases, however, the + two-letter ISO country code is identical to a state code used by the + U.S. Postal Service. Requests made by countries to use the three- + letter form of country code specified in the ISO-3166 standard will + be considered in such cases so as to prevent possible conflicts and + confusion. + + + + + + + + + +Stahl [Page 3] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +HOW TO REGISTER + + Obtain a domain questionnaire from the NIC hostmaster, or FTP the + file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA. + + Fill out the questionnaire completely. Return it via electronic mail + to HOSTMASTER@SRI-NIC.ARPA. + + The APPENDIX to this memo contains the application form for + registering a top-level or second-level domain with the NIC. It + supersedes the version of the questionnaire found in RFC-920. The + application should be submitted by the person administratively + responsible for the domain, and must be filled out completely before + the NIC will authorize establishment of a top-level or second-level + domain. The DA is responsible for keeping his domain's data current + with the NIC or with the registration agent with which his domain is + registered. For example, the CSNET and UUCP managements act as + domain filters, processing domain applications for their own + organizations. They pass pertinent information along periodically to + the NIC for incorporation into the domain database and root server + files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT + outlines this procedure. It is highly recommended that the DA review + this information periodically and provide any corrections or + additions. Corrections should be submitted via electronic mail. + +WHICH DOMAIN NAME? + + The designers of the domain-naming system initiated several general + categories of names as top-level domain names, so that each could + accommodate a variety of organizations. The current top-level + domains registered with the DDN Network Information Center are ARPA, + COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country + domains. To join one of these, a DA needs to be aware of the purpose + for which it was intended. + + "ARPA" is a temporary domain. It is by default appended to the + names of hosts that have not yet joined a domain. When the system + was begun in 1984, the names of all hosts in the Official DoD + Internet Host Table maintained by the NIC were changed by adding + of the label ".ARPA" in order to accelerate a transition to the + domain-naming system. Another reason for the blanket name changes + was to force hosts to become accustomed to using the new style + names and to modify their network software, if necessary. This + was done on a network-wide basis and was directed by DCA in DDN + Management Bulletin No. 22. Hosts that fall into this domain will + eventually move to other branches of the domain tree. + + + + + +Stahl [Page 4] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + "COM" is meant to incorporate subdomains of companies and + businesses. + + "EDU" was initiated to accommodate subdomains set up by + universities and other educational institutions. + + "GOV" exists to act as parent domain for subdomains set up by + government agencies. + + "MIL" was initiated to act as parent to subdomains that are + developed by military organizations. + + "NET" was introduced as a parent domain for various network-type + organizations. Organizations that belong within this top-level + domain are generic or network-specific, such as network service + centers and consortia. "NET" also encompasses network + management-related organizations, such as information centers and + operations centers. + + "ORG" exists as a parent to subdomains that do not clearly fall + within the other top-level domains. This may include technical- + support groups, professional societies, or similar organizations. + + One of the guidelines in effect in the domain-naming system is that a + host should have only one name regardless of what networks it is + connected to. This implies, that, in general, domain names should + not include routing information or addresses. For example, a host + that has one network connection to the Internet and another to BITNET + should use the same name when talking to either network. For a + description of the syntax of domain names, please refer to Section 3 + of RFC-1034. + +VERIFICATION OF DATA + + The verification process can be accomplished in several ways. One of + these is through the NIC WHOIS server. If he has access to WHOIS, + the DA can type the command "whois domain ". + The reply from WHOIS will supply the following: the name and address + of the organization "owning" the domain; the name of the domain; its + administrative, technical, and zone contacts; the host names and + network addresses of sites providing name service for the domain. + + + + + + + + + + +Stahl [Page 5] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + Example: + + @whois domain rice.edu + + Rice University (RICE-DOM) + Advanced Studies and Research + Houston, TX 77001 + + Domain Name: RICE.EDU + + Administrative Contact: + Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834 + Technical Contact, Zone Contact: + Riffle, Vicky R. (VRR) rif@RICE.EDU + (713) 527-8101 ext 3844 + + Domain servers: + + RICE.EDU 128.42.5.1 + PENDRAGON.CS.PURDUE.EDU 128.10.2.5 + + + Alternatively, the DA can send an electronic mail message to + SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the + DA should type "whois domain ". The requested + information will be returned via electronic mail. This method is + convenient for sites that do not have access to the NIC WHOIS + service. + + The initial application for domain authorization should be submitted + via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The + questionnaire described in the appendix may be used or a separate + application can be FTPed from host SRI-NIC.ARPA. The information + provided by the administrator will be reviewed by hostmaster + personnel for completeness. There will most likely be a few + exchanges of correspondence via electronic mail, the preferred method + of communication, prior to authorization of the domain. + +HOW TO GET MORE INFORMATION + + An informational table of the top-level domains and their root + servers is contained in the file NETINFO:DOMAINS.TXT online at SRI- + NIC.ARPA. This table can be obtained by FTPing the file. + Alternatively, the information can be acquired by opening a TCP or + UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA, + and invoking the command "ALL-DOM". + + + + + +Stahl [Page 6] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + The following online files, all available by FTP from SRI-NIC.ARPA, + contain pertinent domain information: + + - NETINFO:DOMAINS.TXT, a table of all top-level domains and the + network addresses of the machines providing domain name + service for them. It is updated each time a new top-level + domain is approved. + + - NETINFO:DOMAIN-INFO.TXT contains a concise list of all + top-level and second-level domain names registered with the + NIC and is updated monthly. + + - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the + top level and second-level domains, but includes the + administrative, technical and zone contacts for each as well. + + - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be + completed before registering a top-level or second-level + domain. + + For either general or specific information on the domain system, do + one or more of the following: + + 1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA + + 2. Call the toll-free NIC hotline at (800) 235-3155 + + 3. Use FTP to get background RFCs and other files maintained + online at the NIC. Some pertinent RFCs are listed below in + the REFERENCES section of this memo. + + + + + + + + + + + + + + + + + + + + + +Stahl [Page 7] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +REFERENCES + + The references listed here provide important background information + on the domain-naming system. Path names of the online files + available via anonymous FTP from the SRI-NIC.ARPA host are noted in + brackets. + + 1. Defense Communications Agency DDN Defense Communications + System, DDN Management Bulletin No. 22, Domain Names + Transition, March 1984. + [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ] + + 2. Defense Communications Agency DDN Defense Communications + System, DDN Management Bulletin No. 32, Phase I of the Domain + Name Implementation, January 1987. + [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ] + + 3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname + Server", RFC-953, DDN Network Information Center, SRI + International, October 1985. [ RFC:RFC953.TXT ] + + 4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD + Internet Host Table Specification", RFC-952, DDN Network + Information Center, SRI International, October 1985. + [ RFC:RFC952.TXT ] + + 5. ISO, "Codes for the Representation of Names of Countries", + ISO-3166, International Standards Organization, May 1981. + [ Not online ] + + 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031, + Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ] + + 7. Lottor, M.K., "Domain Administrators Operations Guide", + RFC-1033, DDN Network Information Center, SRI International, + July 1987. [ RFC:RFC1033.TXT ] + + 8. Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC-1034, USC Information Sciences Institute, October 1987. + [ RFC:RFC1034.TXT ] + + 9. Mockapetris, P., "Domain Names - Implementation and + Specification", RFC-1035, USC Information Sciences Institute, + October 1987. [ RFC:RFC1035.TXT ] + + 10. Mockapetris, P., "The Domain Name System", Proceedings of the + IFIP 6.5 Working Conference on Computer Message Services, + Nottingham, England, May 1984. Also as ISI/RS-84-133, June + + + +Stahl [Page 8] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + 1984. [ Not online ] + + 11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server + Design for Distributed Systems", Proceedings of the Seventh + International Conference on Computer Communication, October + 30 to November 3 1984, Sidney, Australia. Also as + ISI/RS-84-132, June 1984. [ Not online ] + + 12. Partridge, C., "Mail Routing and the Domain System", RFC-974, + CSNET-CIC, BBN Laboratories, January 1986. + [ RFC:RFC974.TXT ] + + 13. Postel, J., "The Domain Names Plan and Schedule", RFC-881, + USC Information Sciences Institute, November 1983. + [ RFC:RFC881.TXT ] + + 14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010 + USC Information Sciences Institute, May 1986. + [ RFC:RFC1010.TXT ] + + 15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020, + SRI, November 1987. + [ RFC:RFC1020.TXT ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stahl [Page 9] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +APPENDIX + + The following questionnaire may be FTPed from SRI-NIC.ARPA as + NETINFO:DOMAIN-TEMPLATE.TXT. + + --------------------------------------------------------------------- + + To establish a domain, the following information must be sent to the + NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA): + + NOTE: The key people must have electronic mailboxes and NIC + "handles," unique NIC database identifiers. If you have access to + "WHOIS", please check to see if you are registered and if so, make + sure the information is current. Include only your handle and any + changes (if any) that need to be made in your entry. If you do not + have access to "WHOIS", please provide all the information indicated + and a NIC handle will be assigned. + + (1) The name of the top-level domain to join. + + For example: COM + + (2) The NIC handle of the administrative head of the organization. + Alternately, the person's name, title, mailing address, phone number, + organization, and network mailbox. This is the contact point for + administrative and policy questions about the domain. In the case of + a research project, this should be the principal investigator. + + For example: + + Administrator + + Organization The NetWorthy Corporation + Name Penelope Q. Sassafrass + Title President + Mail Address The NetWorthy Corporation + 4676 Andrews Way, Suite 100 + Santa Clara, CA 94302-1212 + Phone Number (415) 123-4567 + Net Mailbox Sassafrass@ECHO.TNC.COM + NIC Handle PQS + + (3) The NIC handle of the technical contact for the domain. + Alternately, the person's name, title, mailing address, phone number, + organization, and network mailbox. This is the contact point for + problems concerning the domain or zone, as well as for updating + information about the domain or zone. + + + + +Stahl [Page 10] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + For example: + + Technical and Zone Contact + + Organization The NetWorthy Corporation + Name Ansel A. Aardvark + Title Executive Director + Mail Address The NetWorthy Corporation + 4676 Andrews Way, Suite 100 + Santa Clara, CA. 94302-1212 + Phone Number (415) 123-6789 + Net Mailbox Aardvark@ECHO.TNC.COM + NIC Handle AAA2 + + (4) The name of the domain (up to 12 characters). This is the name + that will be used in tables and lists associating the domain with the + domain server addresses. [While, from a technical standpoint, domain + names can be quite long (programmers beware), shorter names are + easier for people to cope with.] + + For example: TNC + + (5) A description of the servers that provide the domain service for + translating names to addresses for hosts in this domain, and the date + they will be operational. + + A good way to answer this question is to say "Our server is + supplied by person or company X and does whatever their standard + issue server does." + + For example: Our server is a copy of the one operated by + the NIC; it will be installed and made operational on + 1 November 1987. + + (6) Domains must provide at least two independent servers for the + domain. Establishing the servers in physically separate locations + and on different PSNs is strongly recommended. A description of the + server machine and its backup, including + + + + + + + + + + + + + +Stahl [Page 11] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (a) Hardware and software (using keywords from the Assigned + Numbers RFC). + + (b) Host domain name and network addresses (which host on which + network for each connected network). + + (c) Any domain-style nicknames (please limit your domain-style + nickname request to one) + + For example: + + - Hardware and software + + VAX-11/750 and UNIX, or + IBM-PC and MS-DOS, or + DEC-1090 and TOPS-20 + + - Host domain names and network addresses + + BAR.FOO.COM 10.9.0.193 on ARPANET + + - Domain-style nickname + + BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET) + + (7) Planned mapping of names of any other network hosts, other than + the server machines, into the new domain's naming space. + + For example: + + BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM + BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM + BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM + + + (8) An estimate of the number of hosts that will be in the domain. + + (a) Initially + (b) Within one year + (c) Two years + (d) Five years. + + For example: + + (a) Initially = 50 + (b) One year = 100 + (c) Two years = 200 + (d) Five years = 500 + + + +Stahl [Page 12] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (9) The date you expect the fully qualified domain name to become + the official host name in HOSTS.TXT. + + Please note: If changing to a fully qualified domain name (e.g., + FOO.BAR.COM) causes a change in the official host name of an + ARPANET or MILNET host, DCA approval must be obtained beforehand. + Allow 10 working days for your requested changes to be processed. + + ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites + should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for + further instructions. + + (10) Please describe your organization briefly. + + For example: The NetWorthy Corporation is a consulting + organization of people working with UNIX and the C language in an + electronic networking environment. It sponsors two technical + conferences annually and distributes a bimonthly newsletter. + + --------------------------------------------------------------------- + + This example of a completed application corresponds to the examples + found in the companion document RFC-1033, "Domain Administrators + Operations Guide." + + (1) The name of the top-level domain to join. + + COM + + (2) The NIC handle of the administrative contact person. + + NIC Handle JAKE + + (3) The NIC handle of the domain's technical and zone + contact person. + + NIC Handle DLE6 + + (4) The name of the domain. + + SRI + + (5) A description of the servers. + + Our server is the TOPS20 server JEEVES supplied by ISI; it + will be installed and made operational on 1 July 1987. + + + + + +Stahl [Page 13] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (6) A description of the server machine and its backup: + + (a) Hardware and software + + DEC-1090T and TOPS20 + DEC-2065 and TOPS20 + + (b) Host domain name and network address + + KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET + STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET + + (c) Domain-style nickname + + None + + (7) Planned mapping of names of any other network hosts, other than + the server machines, into the new domain's naming space. + + SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM + SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM + + (8) An estimate of the number of hosts that will be directly within + this domain. + + (a) Initially = 50 + (b) One year = 100 + (c) Two years = 200 + (d) Five years = 500 + + (9) A date when you expect the fully qualified domain name to become + the official host name in HOSTS.TXT. + + 31 September 1987 + + (10) Brief description of organization. + + SRI International is an independent, nonprofit, scientific + research organization. It performs basic and applied research + for government and commercial clients, and contributes to + worldwide economic, scientific, industrial, and social progress + through research and related services. + + + + + + + + + +Stahl [Page 14] + diff --git a/contrib/bind9/doc/rfc/rfc1033.txt b/contrib/bind9/doc/rfc/rfc1033.txt new file mode 100644 index 000000000000..37029fd9ae01 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc1033.txt @@ -0,0 +1,1229 @@ +Network Working Group M. Lottor +Request For Comments: 1033 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS OPERATIONS GUIDE + + + +STATUS OF THIS MEMO + + This RFC provides guidelines for domain administrators in operating a + domain server and maintaining their portion of the hierarchical + database. Familiarity with the domain system is assumed. + Distribution of this memo is unlimited. + +ACKNOWLEDGMENTS + + This memo is a formatted collection of notes and excerpts from the + references listed at the end of this document. Of particular mention + are Paul Mockapetris and Kevin Dunlap. + +INTRODUCTION + + A domain server requires a few files to get started. It will + normally have some number of boot/startup files (also known as the + "safety belt" files). One section will contain a list of possible + root servers that the server will use to find the up-to-date list of + root servers. Another section will list the zone files to be loaded + into the server for your local domain information. A zone file + typically contains all the data for a particular domain. This guide + describes the data formats that can be used in zone files and + suggested parameters to use for certain fields. If you are + attempting to do anything advanced or tricky, consult the appropriate + domain RFC's for more details. + + Note: Each implementation of domain software may require different + files. Zone files are standardized but some servers may require + other startup files. See the appropriate documentation that comes + with your software. See the appendix for some specific examples. + +ZONES + + A zone defines the contents of a contiguous section of the domain + space, usually bounded by administrative boundaries. There will + typically be a separate data file for each zone. The data contained + in a zone file is composed of entries called Resource Records (RRs). + + + + +Lottor [Page 1] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + You may only put data in your domain server that you are + authoritative for. You must not add entries for domains other than + your own (except for the special case of "glue records"). + + A domain server will probably read a file on start-up that lists the + zones it should load into its database. The format of this file is + not standardized and is different for most domain server + implementations. For each zone it will normally contain the domain + name of the zone and the file name that contains the data to load for + the zone. + +ROOT SERVERS + + A resolver will need to find the root servers when it first starts. + When the resolver boots, it will typically read a list of possible + root servers from a file. + + The resolver will cycle through the list trying to contact each one. + When it finds a root server, it will ask it for the current list of + root servers. It will then discard the list of root servers it read + from the data file and replace it with the current list it received. + + Root servers will not change very often. You can get the names of + current root servers from the NIC. + + FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to + NIC@SRI-NIC.ARPA. + + As of this date (June 1987) they are: + + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + +RESOURCE RECORDS + + Records in the zone data files are called resource records (RRs). + They are specified in RFC-883 and RFC-973. An RR has a standard + format as shown: + + [] [] + + The record is divided into fields which are separated by white space. + + + + The name field defines what domain name applies to the given + + + +Lottor [Page 2] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + RR. In some cases the name field can be left blank and it will + default to the name field of the previous RR. + + + + TTL stands for Time To Live. It specifies how long a domain + resolver should cache the RR before it throws it out and asks a + domain server again. See the section on TTL's. If you leave + the TTL field blank it will default to the minimum time + specified in the SOA record (described later). + + + + The class field specifies the protocol group. If left blank it + will default to the last class specified. + + + + The type field specifies what type of data is in the RR. See + the section on types. + + + + The data field is defined differently for each type and class + of data. Popular RR data formats are described later. + + The domain system does not guarantee to preserve the order of + resource records. Listing RRs (such as multiple address records) in + a certain order does not guarantee they will be used in that order. + + Case is preserved in names and data fields when loaded into the name + server. All comparisons and lookups in the name server are case + insensitive. + + Parenthesis ("(",")") are used to group data that crosses a line + boundary. + + A semicolon (";") starts a comment; the remainder of the line is + ignored. + + The asterisk ("*") is used for wildcarding. + + The at-sign ("@") denotes the current default domain name. + + + + + + + + +Lottor [Page 3] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +NAMES + + A domain name is a sequence of labels separated by dots. + + Domain names in the zone files can be one of two types, either + absolute or relative. An absolute name is the fully qualified domain + name and is terminated with a period. A relative name does not + terminate with a period, and the current default domain is appended + to it. The default domain is usually the name of the domain that was + specified in the boot file that loads each zone. + + The domain system allows a label to contain any 8-bit character. + Although the domain system has no restrictions, other protocols such + as SMTP do have name restrictions. Because of other protocol + restrictions, only the following characters are recommended for use + in a host name (besides the dot separator): + + "A-Z", "a-z", "0-9", dash and underscore + +TTL's (Time To Live) + + It is important that TTLs are set to appropriate values. The TTL is + the time (in seconds) that a resolver will use the data it got from + your server before it asks your server again. If you set the value + too low, your server will get loaded down with lots of repeat + requests. If you set it too high, then information you change will + not get distributed in a reasonable amount of time. If you leave the + TTL field blank, it will default to what is specified in the SOA + record for the zone. + + Most host information does not change much over long time periods. A + good way to set up your TTLs would be to set them at a high value, + and then lower the value if you know a change will be coming soon. + You might set most TTLs to anywhere between a day (86400) and a week + (604800). Then, if you know some data will be changing in the near + future, set the TTL for that RR down to a lower value (an hour to a + day) until the change takes place, and then put it back up to its + previous value. + + Also, all RRs with the same name, class, and type should have the + same TTL value. + +CLASSES + + The domain system was designed to be protocol independent. The class + field is used to identify the protocol group that each RR is in. + + The class of interest to people using TCP/IP software is the class + + + +Lottor [Page 4] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + "Internet". Its standard designation is "IN". + + A zone file should only contain RRs of the same class. + +TYPES + + There are many defined RR types. For a complete list, see the domain + specification RFCs. Here is a list of current commonly used types. + The data for each type is described in the data section. + + Designation Description + ========================================== + SOA Start Of Authority + NS Name Server + + A Internet Address + CNAME Canonical Name (nickname pointer) + HINFO Host Information + WKS Well Known Services + + MX Mail Exchanger + + PTR Pointer + +SOA (Start Of Authority) + + [] [] SOA ( + + + + + ) + + The Start Of Authority record designates the start of a zone. The + zone ends at the next SOA record. + + is the name of the zone. + + is the name of the host on which the master zone file + resides. + + is a mailbox for the person responsible for the zone. It is + formatted like a mailing address but the at-sign that normally + separates the user from the host name is replaced with a dot. + + is the version number of the zone file. It should be + incremented anytime a change is made to data in the zone. + + + + +Lottor [Page 5] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + is how long, in seconds, a secondary name server is to + check with the primary name server to see if an update is needed. A + good value here would be one hour (3600). + + is how long, in seconds, a secondary name server is to retry + after a failure to check for a refresh. A good value here would be + 10 minutes (600). + + is the upper limit, in seconds, that a secondary name server + is to use the data before it expires for lack of getting a refresh. + You want this to be rather large, and a nice value is 3600000, about + 42 days. + + is the minimum number of seconds to be used for TTL values + in RRs. A minimum of at least a day is a good value here (86400). + + There should only be one SOA record per zone. A sample SOA record + would look something like: + + @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( + 45 ;serial + 3600 ;refresh + 600 ;retry + 3600000 ;expire + 86400 ) ;minimum + + +NS (Name Server) + + [] [] NS + + The NS record lists the name of a machine that provides domain + service for a particular domain. The name associated with the RR is + the domain name and the data portion is the name of a host that + provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide + name lookup service for the domain COM then the following entries + would be used: + + COM. NS SRI-NIC.ARPA. + NS C.ISI.EDU. + + Note that the machines providing name service do not have to live in + the named domain. There should be one NS record for each server for + a domain. Also note that the name "COM" defaults for the second NS + record. + + NS records for a domain exist in both the zone that delegates the + domain, and in the domain itself. + + + +Lottor [Page 6] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +GLUE RECORDS + + If the name server host for a particular domain is itself inside the + domain, then a 'glue' record will be needed. A glue record is an A + (address) RR that specifies the address of the server. Glue records + are only needed in the server delegating the domain, not in the + domain itself. If for example the name server for domain SRI.COM was + KL.SRI.COM, then the NS record would look like this, but you will + also need to have the following A record. + + SRI.COM. NS KL.SRI.COM. + KL.SRI.COM. A 10.1.0.2 + + +A (Address) + + [] [] A
+ + The data for an A record is an internet address in dotted decimal + form. A sample A record might look like: + + SRI-NIC.ARPA. A 10.0.0.51 + + There should be one A record for each address of a host. + +CNAME ( Canonical Name) + + [] [] CNAME + + The CNAME record is used for nicknames. The name associated with the + RR is the nickname. The data portion is the official name. For + example, a machine named SRI-NIC.ARPA may want to have the nickname + NIC.ARPA. In that case, the following RR would be used: + + NIC.ARPA. CNAME SRI-NIC.ARPA. + + There must not be any other RRs associated with a nickname of the + same class. + + Nicknames are also useful when a host changes it's name. In that + case, it is usually a good idea to have a CNAME pointer so that + people still using the old name will get to the right place. + + + + + + + + + +Lottor [Page 7] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +HINFO (Host Info) + + [] [] HINFO + + The HINFO record gives information about a particular host. The data + is two strings separated by whitespace. The first string is a + hardware description and the second is software. The hardware is + usually a manufacturer name followed by a dash and model designation. + The software string is usually the name of the operating system. + + Official HINFO types can be found in the latest Assigned Numbers RFC, + the latest of which is RFC-1010. The Hardware type is called the + Machine name and the Software type is called the System name. + + Some sample HINFO records: + + SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 + UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX + + +WKS (Well Known Services) + + [] [] WKS
+ + The WKS record is used to list Well Known Services a host provides. + WKS's are defined to be services on port numbers below 256. The WKS + record lists what services are available at a certain address using a + certain protocol. The common protocols are TCP or UDP. A sample WKS + record for a host offering the same services on all address would + look like: + + Official protocol names can be found in the latest Assigned Numbers + RFC, the latest of which is RFC-1010. + + SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP + WKS 10.0.0.51 UDP TIME + WKS 26.0.0.73 TCP TELNET FTP SMTP + WKS 26.0.0.73 UDP TIME + +MX (Mail Exchanger) (See RFC-974 for more details.) + + [] [] MX + + MX records specify where mail for a domain name should be delivered. + There may be multiple MX records for a particular name. The + preference value specifies the order a mailer should try multiple MX + records when delivering mail. Zero is the highest preference. + Multiple records for the same name may have the same preference. + + + +Lottor [Page 8] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + A host BAR.FOO.COM may want its mail to be delivered to the host + PO.FOO.COM and would then use the MX record: + + BAR.FOO.COM. MX 10 PO.FOO.COM. + + A host BAZ.FOO.COM may want its mail to be delivered to one of three + different machines, in the following order: + + BAZ.FOO.COM. MX 10 PO1.FOO.COM. + MX 20 PO2.FOO.COM. + MX 30 PO3.FOO.COM. + + An entire domain of hosts not connected to the Internet may want + their mail to go through a mail gateway that knows how to deliver + mail to them. If they would like mail addressed to any host in the + domain FOO.COM to go through the mail gateway they might use: + + FOO.COM. MX 10 RELAY.CS.NET. + *.FOO.COM. MX 20 RELAY.CS.NET. + + Note that you can specify a wildcard in the MX record to match on + anything in FOO.COM, but that it won't match a plain FOO.COM. + +IN-ADDR.ARPA + + The structure of names in the domain system is set up in a + hierarchical way such that the address of a name can be found by + tracing down the domain tree contacting a server for each label of + the name. Because of this 'indexing' based on name, there is no easy + way to translate a host address back into its host name. + + In order to do the reverse translation easily, a domain was created + that uses hosts' addresses as part of a name that then points to the + data for that host. In this way, there is now an 'index' to hosts' + RRs based on their address. This address mapping domain is called + IN-ADDR.ARPA. Within that domain are subdomains for each network, + based on network number. Also, for consistency and natural + groupings, the 4 octets of a host number are reversed. + + For example, the ARPANET is net 10. That means there is a domain + called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at + 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA + (who's address is 10.0.0.51). Since the NIC is also on the MILNET + (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- + ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format + of these special pointers is defined below along with the examples + for the NIC. + + + + +Lottor [Page 9] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +PTR + + [] [] PTR + + The PTR record is used to let special names point to some other + location in the domain tree. They are mainly used in the IN- + ADDR.ARPA records for translation of addresses to names. PTR's + should use official names and not aliases. + + For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 + would have the following records in the respective zone files for net + 10 and net 26: + + 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + +GATEWAY PTR's + + The IN-ADDR tree is also used to locate gateways on a particular + network. Gateways have the same kind of PTR RRs as hosts (as above) + but in addition they have other PTRs used to locate them by network + number alone. These records have only 1, 2, or 3 octets as part of + the name depending on whether they are class A, B, or C networks, + respectively. + + Lets take the SRI-CSL gateway for example. It connects 3 different + networks, one class A, one class B and one class C. It will have the + standard RR's for a host in the CSL.SRI.COM zone: + + GW.CSL.SRI.COM. A 10.2.0.2 + A 128.18.1.1 + A 192.12.33.2 + + Also, in 3 different zones (one for each network), it will have one + of the following number to name translation pointers: + + 2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + In addition, in each of the same 3 zones will be one of the following + gateway location pointers: + + 10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + + + + +Lottor [Page 10] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +INSTRUCTIONS + + Adding a subdomain. + + To add a new subdomain to your domain: + + Setup the other domain server and/or the new zone file. + + Add an NS record for each server of the new domain to the zone + file of the parent domain. + + Add any necessary glue RRs. + + Adding a host. + + To add a new host to your zone files: + + Edit the appropriate zone file for the domain the host is in. + + Add an entry for each address of the host. + + Optionally add CNAME, HINFO, WKS, and MX records. + + Add the reverse IN-ADDR entry for each host address in the + appropriate zone files for each network the host in on. + + Deleting a host. + + To delete a host from the zone files: + + Remove all the hosts' resource records from the zone file of + the domain the host is in. + + Remove all the hosts' PTR records from the IN-ADDR zone files + for each network the host was on. + + Adding gateways. + + Follow instructions for adding a host. + + Add the gateway location PTR records for each network the + gateway is on. + + Deleting gateways. + + Follow instructions for deleting a host. + + Also delete the gateway location PTR records for each network + + + +Lottor [Page 11] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + the gateway was on. + +COMPLAINTS + + These are the suggested steps you should take if you are having + problems that you believe are caused by someone else's name server: + + + 1. Complain privately to the responsible person for the domain. You + can find their mailing address in the SOA record for the domain. + + 2. Complain publicly to the responsible person for the domain. + + 3. Ask the NIC for the administrative person responsible for the + domain. Complain. You can also find domain contacts on the NIC in + the file NETINFO:DOMAIN-CONTACTS.TXT + + 4. Complain to the parent domain authorities. + + 5. Ask the parent authorities to excommunicate the domain. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 12] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +EXAMPLE DOMAIN SERVER DATABASE FILES + + The following examples show how zone files are set up for a typical + organization. SRI will be used as the example organization. SRI has + decided to divided their domain SRI.COM into a few subdomains, one + for each group that wants one. The subdomains are CSL and ISTC. + + Note the following interesting items: + + There are both hosts and domains under SRI.COM. + + CSL.SRI.COM is both a domain name and a host name. + + All the domains are serviced by the same pair of domain servers. + + All hosts at SRI are on net 128.18 except hosts in the CSL domain + which are on net 192.12.33. Note that a domain does not have to + correspond to a physical network. + + The examples do not necessarily correspond to actual data in use + by the SRI domain. + + SRI Domain Organization + + +-------+ + | COM | + +-------+ + | + +-------+ + | SRI | + +-------+ + | + +----------++-----------+ + | | | + +-------+ +------+ +-------+ + | CSL | | ISTC | | Hosts | + +-------+ +------+ +-------+ + | | + +-------+ +-------+ + | Hosts | | Hosts | + +-------+ +-------+ + + + + + + + + + + +Lottor [Page 13] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "CONFIG.CMD". Since bootstrap files are not standardized, this + file is presented using a pseudo configuration file syntax.] + + load root server list from file ROOT.SERVERS + load zone SRI.COM. from file SRI.ZONE + load zone CSL.SRI.COM. from file CSL.ZONE + load zone ISTC.SRI.COM. from file ISTC.ZONE + load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE + load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 14] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "ROOT.SERVERS". Again, the format of this file is not + standardized.] + + ;list of possible root servers + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 15] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRI.ZONE"] + + SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( + 870407 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of an hour + ) + + SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + MX 10 KL.SRI.COM. + + ;SRI.COM hosts + + KL A 10.1.0.2 + A 128.18.10.6 + MX 10 KL.SRI.COM. + + STRIPE A 10.4.0.2 + STRIPE A 128.18.10.4 + MX 10 STRIPE.SRI.COM. + + NIC CNAME SRI-NIC.ARPA. + + Blackjack A 128.18.2.1 + HINFO VAX-11/780 UNIX + WKS 128.18.2.1 TCP TELNET FTP + + CSL A 192.12.33.2 + HINFO FOONLY-F4 TOPS20 + WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER + MX 10 CSL.SRI.COM. + + + + + + + + + + + + + + + + + +Lottor [Page 16] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "CSL.ZONE"] + + CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( + 870330 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + CSL.SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + A 192.12.33.2 + + ;CSL.SRI.COM hosts + + A CNAME CSL.SRI.COM. + B A 192.12.33.3 + HINFO FOONLY-F4 TOPS20 + WKS 192.12.33.3 TCP TELNET FTP SMTP + GW A 10.2.0.2 + A 192.12.33.1 + A 128.18.1.1 + HINFO PDP-11/23 MOS + SMELLY A 192.12.33.4 + HINFO IMAGEN IMAGEN + SQUIRREL A 192.12.33.5 + HINFO XEROX-1100 INTERLISP + VENUS A 192.12.33.7 + HINFO SYMBOLICS-3600 LISPM + HELIUM A 192.12.33.30 + HINFO SUN-3/160 UNIX + ARGON A 192.12.33.31 + HINFO SUN-3/75 UNIX + RADON A 192.12.33.32 + HINFO SUN-3/75 UNIX + + + + + + + + + + + + + + + +Lottor [Page 17] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "ISTC.ZONE"] + + ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. ( + 870406 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + ISTC.SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + MX 10 SPAM.ISTC.SRI.COM. + + ; ISTC hosts + + joyce A 128.18.4.2 + HINFO VAX-11/750 UNIX + bozo A 128.18.0.6 + HINFO SUN UNIX + sundae A 128.18.0.11 + HINFO SUN UNIX + tsca A 128.18.0.201 + A 10.3.0.2 + HINFO VAX-11/750 UNIX + MX 10 TSCA.ISTC.SRI.COM. + tsc CNAME tsca + prmh A 128.18.0.203 + A 10.2.0.51 + HINFO PDP-11/44 UNIX + spam A 128.18.4.3 + A 10.2.0.107 + HINFO VAX-11/780 UNIX + MX 10 SPAM.ISTC.SRI.COM. + + + + + + + + + + + + + + + + + +Lottor [Page 18] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRINET.ZONE"] + + 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( + 870406 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + 18.128.IN-ADDR.ARPA. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + PTR GW.CSL.SRI.COM. + + ; SRINET [128.18.0.0] Address Translations + + ; SRI.COM Hosts + 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM. + + ; ISTC.SRI.COM Hosts + 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM. + 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. + 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. + 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. + 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. + 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM. + + ; CSL.SRI.COM Hosts + 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 19] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRI-CSL-NET.ZONE"] + + 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( + 870404 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + PTR GW.CSL.SRI.COM. + + ; SRI-CSL-NET [192.12.33.0] Address Translations + + ; SRI.COM Hosts + 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM. + + ; CSL.SRI.COM Hosts + 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM. + 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM. + 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM. + 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM. + 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM. + 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM. + 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM. + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 20] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +APPENDIX + + BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD + UNIX + + This section describes two BIND implementation specific files; the + boot file and the cache file. BIND has other options, files, and + specifications that are not described here. See the Name Server + Operations Guide for BIND for details. + + The boot file for BIND is usually called "named.boot". This + corresponds to file "CONFIG.CMD" in the example section. + + -------------------------------------------------------- + cache . named.ca + primary SRI.COM SRI.ZONE + primary CSL.SRI.COM CSL.ZONE + primary ISTC.SRI.COM ISTC.ZONE + primary 18.128.IN-ADDR.ARPA SRINET.ZONE + primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE + -------------------------------------------------------- + + The cache file for BIND is usually called "named.ca". This + corresponds to file "ROOT.SERVERS" in the example section. + + ------------------------------------------------- + ;list of possible root servers + . 1 IN NS SRI-NIC.ARPA. + NS C.ISI.EDU. + NS BRL-AOS.ARPA. + NS C.ISI.EDU. + ;and their addresses + SRI-NIC.ARPA. A 10.0.0.51 + A 26.0.0.73 + C.ISI.EDU. A 10.0.0.52 + BRL-AOS.ARPA. A 192.5.25.82 + A 192.5.22.82 + A 128.20.1.2 + A.ISI.EDU. A 26.3.0.103 + ------------------------------------------------- + + + + + + + + + + + +Lottor [Page 21] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +REFERENCES + + [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG, + Department of Electrical Engineering and Computer Sciences, + University of California, Berkeley, California. + + [2] Partridge, C., "Mail Routing and the Domain System", RFC-974, + CSNET CIC BBN Laboratories, January 1986. + + [3] Mockapetris, P., "Domains Names - Concepts and Facilities", + RFC-1034, USC/Information Sciences Institute, November 1987. + + [4] Mockapetris, P., "Domain Names - Implementations Specification", + RFC-1035, USC/Information Sciences Institute, November 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 22] + diff --git a/contrib/bind9/doc/rfc/rfc1034.txt b/contrib/bind9/doc/rfc/rfc1034.txt new file mode 100644 index 000000000000..55cdb21fe652 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc1034.txt @@ -0,0 +1,3077 @@ +Network Working Group P. Mockapetris +Request for Comments: 1034 ISI +Obsoletes: RFCs 882, 883, 973 November 1987 + + + DOMAIN NAMES - CONCEPTS AND FACILITIES + + + +1. STATUS OF THIS MEMO + +This RFC is an introduction to the Domain Name System (DNS), and omits +many details which can be found in a companion RFC, "Domain Names - +Implementation and Specification" [RFC-1035]. That RFC assumes that the +reader is familiar with the concepts discussed in this memo. + +A subset of DNS functions and data types constitute an official +protocol. The official protocol includes standard queries and their +responses and most of the Internet class data formats (e.g., host +addresses). + +However, the domain system is intentionally extensible. Researchers are +continuously proposing, implementing and experimenting with new data +types, query types, classes, functions, etc. Thus while the components +of the official protocol are expected to stay essentially unchanged and +operate as a production service, experimental behavior should always be +expected in extensions beyond the official protocol. Experimental or +obsolete features are clearly marked in these RFCs, and such information +should be used with caution. + +The reader is especially cautioned not to depend on the values which +appear in examples to be current or complete, since their purpose is +primarily pedagogical. Distribution of this memo is unlimited. + +2. INTRODUCTION + +This RFC introduces domain style names, their use for Internet mail and +host address support, and the protocols and servers used to implement +domain name facilities. + +2.1. The history of domain names + +The impetus for the development of the domain system was growth in the +Internet: + + - Host name to address mappings were maintained by the Network + Information Center (NIC) in a single file (HOSTS.TXT) which + was FTPed by all hosts [RFC-952, RFC-953]. The total network + + + +Mockapetris [Page 1] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + bandwidth consumed in distributing a new version by this + scheme is proportional to the square of the number of hosts in + the network, and even when multiple levels of FTP are used, + the outgoing FTP load on the NIC host is considerable. + Explosive growth in the number of hosts didn't bode well for + the future. + + - The network population was also changing in character. The + timeshared hosts that made up the original ARPANET were being + replaced with local networks of workstations. Local + organizations were administering their own names and + addresses, but had to wait for the NIC to change HOSTS.TXT to + make changes visible to the Internet at large. Organizations + also wanted some local structure on the name space. + + - The applications on the Internet were getting more + sophisticated and creating a need for general purpose name + service. + + +The result was several ideas about name spaces and their management +[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a +common thread was the idea of a hierarchical name space, with the +hierarchy roughly corresponding to organizational structure, and names +using "." as the character to mark the boundary between hierarchy +levels. A design using a distributed database and generalized resources +was described in [RFC-882, RFC-883]. Based on experience with several +implementations, the system evolved into the scheme described in this +memo. + +The terms "domain" or "domain name" are used in many contexts beyond the +DNS described here. Very often, the term domain name is used to refer +to a name with structure indicated by dots, but no relation to the DNS. +This is particularly true in mail addressing [Quarterman 86]. + +2.2. DNS design goals + +The design goals of the DNS influence its structure. They are: + + - The primary goal is a consistent name space which will be used + for referring to resources. In order to avoid the problems + caused by ad hoc encodings, names should not be required to + contain network identifiers, addresses, routes, or similar + information as part of the name. + + - The sheer size of the database and frequency of updates + suggest that it must be maintained in a distributed manner, + with local caching to improve performance. Approaches that + + + +Mockapetris [Page 2] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + attempt to collect a consistent copy of the entire database + will become more and more expensive and difficult, and hence + should be avoided. The same principle holds for the structure + of the name space, and in particular mechanisms for creating + and deleting names; these should also be distributed. + + - Where there tradeoffs between the cost of acquiring data, the + speed of updates, and the accuracy of caches, the source of + the data should control the tradeoff. + + - The costs of implementing such a facility dictate that it be + generally useful, and not restricted to a single application. + We should be able to use names to retrieve host addresses, + mailbox data, and other as yet undetermined information. All + data associated with a name is tagged with a type, and queries + can be limited to a single type. + + - Because we want the name space to be useful in dissimilar + networks and applications, we provide the ability to use the + same name space with different protocol families or + management. For example, host address formats differ between + protocols, though all protocols have the notion of address. + The DNS tags all data with a class as well as the type, so + that we can allow parallel use of different formats for data + of type address. + + - We want name server transactions to be independent of the + communications system that carries them. Some systems may + wish to use datagrams for queries and responses, and only + establish virtual circuits for transactions that need the + reliability (e.g., database updates, long transactions); other + systems will use virtual circuits exclusively. + + - The system should be useful across a wide spectrum of host + capabilities. Both personal computers and large timeshared + hosts should be able to use the system, though perhaps in + different ways. + +2.3. Assumptions about usage + +The organization of the domain system derives from some assumptions +about the needs and usage patterns of its user community and is designed +to avoid many of the the complicated problems found in general purpose +database systems. + +The assumptions are: + + - The size of the total database will initially be proportional + + + +Mockapetris [Page 3] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + to the number of hosts using the system, but will eventually + grow to be proportional to the number of users on those hosts + as mailboxes and other information are added to the domain + system. + + - Most of the data in the system will change very slowly (e.g., + mailbox bindings, host addresses), but that the system should + be able to deal with subsets that change more rapidly (on the + order of seconds or minutes). + + - The administrative boundaries used to distribute + responsibility for the database will usually correspond to + organizations that have one or more hosts. Each organization + that has responsibility for a particular set of domains will + provide redundant name servers, either on the organization's + own hosts or other hosts that the organization arranges to + use. + + - Clients of the domain system should be able to identify + trusted name servers they prefer to use before accepting + referrals to name servers outside of this "trusted" set. + + - Access to information is more critical than instantaneous + updates or guarantees of consistency. Hence the update + process allows updates to percolate out through the users of + the domain system rather than guaranteeing that all copies are + simultaneously updated. When updates are unavailable due to + network or host failure, the usual course is to believe old + information while continuing efforts to update it. The + general model is that copies are distributed with timeouts for + refreshing. The distributor sets the timeout value and the + recipient of the distribution is responsible for performing + the refresh. In special situations, very short intervals can + be specified, or the owner can prohibit copies. + + - In any system that has a distributed database, a particular + name server may be presented with a query that can only be + answered by some other server. The two general approaches to + dealing with this problem are "recursive", in which the first + server pursues the query for the client at another server, and + "iterative", in which the server refers the client to another + server and lets the client pursue the query. Both approaches + have advantages and disadvantages, but the iterative approach + is preferred for the datagram style of access. The domain + system requires implementation of the iterative approach, but + allows the recursive approach as an option. + + + + + +Mockapetris [Page 4] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +The domain system assumes that all data originates in master files +scattered through the hosts that use the domain system. These master +files are updated by local system administrators. Master files are text +files that are read by a local name server, and hence become available +through the name servers to users of the domain system. The user +programs access name servers through standard programs called resolvers. + +The standard format of master files allows them to be exchanged between +hosts (via FTP, mail, or some other mechanism); this facility is useful +when an organization wants a domain, but doesn't want to support a name +server. The organization can maintain the master files locally using a +text editor, transfer them to a foreign host which runs a name server, +and then arrange with the system administrator of the name server to get +the files loaded. + +Each host's name servers and resolvers are configured by a local system +administrator [RFC-1033]. For a name server, this configuration data +includes the identity of local master files and instructions on which +non-local master files are to be loaded from foreign servers. The name +server uses the master files or copies to load its zones. For +resolvers, the configuration data identifies the name servers which +should be the primary sources of information. + +The domain system defines procedures for accessing the data and for +referrals to other name servers. The domain system also defines +procedures for caching retrieved data and for periodic refreshing of +data defined by the system administrator. + +The system administrators provide: + + - The definition of zone boundaries. + + - Master files of data. + + - Updates to master files. + + - Statements of the refresh policies desired. + +The domain system provides: + + - Standard formats for resource data. + + - Standard methods for querying the database. + + - Standard methods for name servers to refresh local data from + foreign name servers. + + + + + +Mockapetris [Page 5] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +2.4. Elements of the DNS + +The DNS has three major components: + + - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are + specifications for a tree structured name space and data + associated with the names. Conceptually, each node and leaf + of the domain name space tree names a set of information, and + query operations are attempts to extract specific types of + information from a particular set. A query names the domain + name of interest and describes the type of resource + information that is desired. For example, the Internet + uses some of its domain names to identify hosts; queries for + address resources return Internet host addresses. + + - NAME SERVERS are server programs which hold information about + the domain tree's structure and set information. A name + server may cache structure or set information about any part + of the domain tree, but in general a particular name server + has complete information about a subset of the domain space, + and pointers to other name servers that can be used to lead to + information from any part of the domain tree. Name servers + know the parts of the domain tree for which they have complete + information; a name server is said to be an AUTHORITY for + these parts of the name space. Authoritative information is + organized into units called ZONEs, and these zones can be + automatically distributed to the name servers which provide + redundant service for the data in a zone. + + - RESOLVERS are programs that extract information from name + servers in response to client requests. Resolvers must be + able to access at least one name server and use that name + server's information to answer a query directly, or pursue the + query using referrals to other name servers. A resolver will + typically be a system routine that is directly accessible to + user programs; hence no protocol is necessary between the + resolver and the user program. + +These three components roughly correspond to the three layers or views +of the domain system: + + - From the user's point of view, the domain system is accessed + through a simple procedure or OS call to a local resolver. + The domain space consists of a single tree and the user can + request information from any section of the tree. + + - From the resolver's point of view, the domain system is + composed of an unknown number of name servers. Each name + + + +Mockapetris [Page 6] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + server has one or more pieces of the whole domain tree's data, + but the resolver views each of these databases as essentially + static. + + - From a name server's point of view, the domain system consists + of separate sets of local information called zones. The name + server has local copies of some of the zones. The name server + must periodically refresh its zones from master copies in + local files or foreign name servers. The name server must + concurrently process queries that arrive from resolvers. + +In the interests of performance, implementations may couple these +functions. For example, a resolver on the same machine as a name server +might share a database consisting of the the zones managed by the name +server and the cache managed by the resolver. + +3. DOMAIN NAME SPACE and RESOURCE RECORDS + +3.1. Name space specifications and terminology + +The domain name space is a tree structure. Each node and leaf on the +tree corresponds to a resource set (which may be empty). The domain +system makes no distinctions between the uses of the interior nodes and +leaves, and this memo uses the term "node" to refer to both. + +Each node has a label, which is zero to 63 octets in length. Brother +nodes may not have the same label, although the same label can be used +for nodes which are not brothers. One label is reserved, and that is +the null (i.e., zero length) label used for the root. + +The domain name of a node is the list of the labels on the path from the +node to the root of the tree. By convention, the labels that compose a +domain name are printed or read left to right, from the most specific +(lowest, farthest from the root) to the least specific (highest, closest +to the root). + +Internally, programs that manipulate domain names should represent them +as sequences of labels, where each label is a length octet followed by +an octet string. Because all domain names end at the root, which has a +null string for a label, these internal representations can use a length +byte of zero to terminate a domain name. + +By convention, domain names can be stored with arbitrary case, but +domain name comparisons for all present domain functions are done in a +case-insensitive manner, assuming an ASCII character set, and a high +order zero bit. This means that you are free to create a node with +label "A" or a node with label "a", but not both as brothers; you could +refer to either using "a" or "A". When you receive a domain name or + + + +Mockapetris [Page 7] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +label, you should preserve its case. The rationale for this choice is +that we may someday need to add full binary domain names for new +services; existing services would not be changed. + +When a user needs to type a domain name, the length of each label is +omitted and the labels are separated by dots ("."). Since a complete +domain name ends with the root label, this leads to a printed form which +ends in a dot. We use this property to distinguish between: + + - a character string which represents a complete domain name + (often called "absolute"). For example, "poneria.ISI.EDU." + + - a character string that represents the starting labels of a + domain name which is incomplete, and should be completed by + local software using knowledge of the local domain (often + called "relative"). For example, "poneria" used in the + ISI.EDU domain. + +Relative names are either taken relative to a well known origin, or to a +list of domains used as a search list. Relative names appear mostly at +the user interface, where their interpretation varies from +implementation to implementation, and in master files, where they are +relative to a single origin domain name. The most common interpretation +uses the root "." as either the single origin or as one of the members +of the search list, so a multi-label relative name is often one where +the trailing dot has been omitted to save typing. + +To simplify implementations, the total number of octets that represent a +domain name (i.e., the sum of all label octets and label lengths) is +limited to 255. + +A domain is identified by a domain name, and consists of that part of +the domain name space that is at or below the domain name which +specifies the domain. A domain is a subdomain of another domain if it +is contained within that domain. This relationship can be tested by +seeing if the subdomain's name ends with the containing domain's name. +For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". + +3.2. Administrative guidelines on use + +As a matter of policy, the DNS technical specifications do not mandate a +particular tree structure or rules for selecting labels; its goal is to +be as general as possible, so that it can be used to build arbitrary +applications. In particular, the system was designed so that the name +space did not have to be organized along the lines of network +boundaries, name servers, etc. The rationale for this is not that the +name space should have no implied semantics, but rather that the choice +of implied semantics should be left open to be used for the problem at + + + +Mockapetris [Page 8] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +hand, and that different parts of the tree can have different implied +semantics. For example, the IN-ADDR.ARPA domain is organized and +distributed by network and host address because its role is to translate +from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- +1002] are flat because that is appropriate for that application. + +However, there are some guidelines that apply to the "normal" parts of +the name space used for hosts, mailboxes, etc., that will make the name +space more uniform, provide for growth, and minimize problems as +software is converted from the older host table. The political +decisions about the top levels of the tree originated in RFC-920. +Current policy for the top levels is discussed in [RFC-1032]. MILNET +conversion issues are covered in [RFC-1031]. + +Lower domains which will eventually be broken into multiple zones should +provide branching at the top of the domain so that the eventual +decomposition can be done without renaming. Node labels which use +special characters, leading digits, etc., are likely to break older +software which depends on more restrictive choices. + +3.3. Technical guidelines on use + +Before the DNS can be used to hold naming information for some kind of +object, two needs must be met: + + - A convention for mapping between object names and domain + names. This describes how information about an object is + accessed. + + - RR types and data formats for describing the object. + +These rules can be quite simple or fairly complex. Very often, the +designer must take into account existing formats and plan for upward +compatibility for existing usage. Multiple mappings or levels of +mapping may be required. + +For hosts, the mapping depends on the existing syntax for host names +which is a subset of the usual text representation for domain names, +together with RR formats for describing host addresses, etc. Because we +need a reliable inverse mapping from address to host name, a special +mapping for addresses into the IN-ADDR.ARPA domain is also defined. + +For mailboxes, the mapping is slightly more complex. The usual mail +address @ is mapped into a domain name by +converting into a single label (regardles of dots it +contains), converting into a domain name using the usual +text format for domain names (dots denote label breaks), and +concatenating the two to form a single domain name. Thus the mailbox + + + +Mockapetris [Page 9] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by +HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this +design also must take into account the scheme for mail exchanges [RFC- +974]. + +The typical user is not concerned with defining these rules, but should +understand that they usually are the result of numerous compromises +between desires for upward compatibility with old usage, interactions +between different object definitions, and the inevitable urge to add new +features when defining the rules. The way the DNS is used to support +some object is often more crucial than the restrictions inherent in the +DNS. + +3.4. Example name space + +The following figure shows a part of the current domain name space, and +is used in many examples in this RFC. Note that the tree is a very +small subset of the actual name space. + + | + | + +---------------------+------------------+ + | | | + MIL EDU ARPA + | | | + | | | + +-----+-----+ | +------+-----+-----+ + | | | | | | | + BRL NOSC DARPA | IN-ADDR SRI-NIC ACC + | + +--------+------------------+---------------+--------+ + | | | | | + UCI MIT | UDEL YALE + | ISI + | | + +---+---+ | + | | | + LCS ACHILLES +--+-----+-----+--------+ + | | | | | | + XX A C VAXA VENERA Mockapetris + +In this example, the root domain has three immediate subdomains: MIL, +EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named +XX.LCS.MIT.EDU. All of the leaves are also domains. + +3.5. Preferred name syntax + +The DNS specifications attempt to be as general as possible in the rules + + + +Mockapetris [Page 10] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +for constructing domain names. The idea is that the name of any +existing object can be expressed as a domain name with minimal changes. +However, when assigning a domain name for an object, the prudent user +will select a name which satisfies both the rules of the domain system +and any existing rules for the object, whether these rules are published +or implied by existing programs. + +For example, when naming a mail domain, the user should satisfy both the +rules of this memo and those in RFC-822. When creating a new host name, +the old rules for HOSTS.TXT should be followed. This avoids problems +when old software is converted to use domain names. + +The following syntax will result in fewer problems with many +applications that use domain names (e.g., mail, TELNET). + + ::= | " " + + ::=